Комментарии 46
Первая реакция на картинку: «Ага, снова что-то сделали с дисплеем из Playboy/Vogue».
Спасибо за статью! Хотелось бы более подробно узнать про следующие вещи:
1. Сравнение скорости работы «на голом железе» и под .NET
2. Портирование под конкретную платформу: алгоритм, подводные камни
3. WPF. Чем отличается от большого брата и Silverlight
1. Сравнение скорости работы «на голом железе» и под .NET
2. Портирование под конкретную платформу: алгоритм, подводные камни
3. WPF. Чем отличается от большого брата и Silverlight
4. Подходит ли .Net Micro Framework для обучения программированию контроллеров?
ИМХО вряд ли. В условиях ограниченной производительности важно чётко знать, что происходит на самом низком уровне. Применять фреймворк в таких системах стоит только если чётко осознаёшь, во что выльется написанный тобой код и какие тебя могут поджидать подводные грабли. Если начинать обучение с фреймворка, у человека может сложиться нехорошая привычка разбрасываться ресурсами (что простительно на ПК) и писать гогнокодэ :)
Я тоже думаю что не стоит начинать с этого. Сначала нужно знать что и как работает внутри микроконтроллера.
Кстати, Microsoft буквально пару недель назад запустила новый проект на базе .Net MF — .NET Gadgeteer. Это что-то вроде конструктора, который можно программировать. По их мнению, этот проект должен служить образовательным целям.
Кстати, Microsoft буквально пару недель назад запустила новый проект на базе .Net MF — .NET Gadgeteer. Это что-то вроде конструктора, который можно программировать. По их мнению, этот проект должен служить образовательным целям.
Собственно такая проблема в существует в любой сфере программирования.
И первый изученый язык программирования должен быть неупавляемый и т.д.
Лично я всегда сталкиваюсь с проблемой, что в новой сфере легко сделать «hello world».
Только удовольствия от сделаной мигающей лампочки очень быстро уходит.
А перейти от нее к чему-то серьезному, чем будешь сам гордится — это проблема.
Как мне кажется, некоторые фреймворки могут помогать в этом, в вот некоторые — вредят.
И первый изученый язык программирования должен быть неупавляемый и т.д.
Лично я всегда сталкиваюсь с проблемой, что в новой сфере легко сделать «hello world».
Только удовольствия от сделаной мигающей лампочки очень быстро уходит.
А перейти от нее к чему-то серьезному, чем будешь сам гордится — это проблема.
Как мне кажется, некоторые фреймворки могут помогать в этом, в вот некоторые — вредят.
1) Конкретных замеров по скорости я не производил. Но на вид, работает все быстро. Например, в поставке есть приложение — семпл, представляющее собой web-сервер. Он работает вполне быстро. Есть конечно и косячки. У нас сейчас проблема со скоростью отклика на нажатие кнопок, но похоже это проблема нашего порта а не самого .Net MF
2) Насчет портирования — я думаю, я напишу статью поподробнее.
3) Главное отличие — нет официальной поддержки XAML. То есть весь код пишется на C#. Ну и основные объекты можно пересчитать по пальцам. Правда, это не мешает делать хорошие интерфейсы и, на мой взгляд, это несет больше порядка. На базе .Net MF есть полноценная графическая оболочка — Pyxis 2.0. Она, кстати, тоже бесплатная.
2) Насчет портирования — я думаю, я напишу статью поподробнее.
3) Главное отличие — нет официальной поддержки XAML. То есть весь код пишется на C#. Ну и основные объекты можно пересчитать по пальцам. Правда, это не мешает делать хорошие интерфейсы и, на мой взгляд, это несет больше порядка. На базе .Net MF есть полноценная графическая оболочка — Pyxis 2.0. Она, кстати, тоже бесплатная.
Ага. Ну что ж, ждём статью про портирование :)
>> Главное отличие — нет официальной поддержки XAML.
Это простите как? Какой тут WPF тогда? оО
Это простите как? Какой тут WPF тогда? оО
WPF — это концепция а не язык. Он позволяет писать код как на XAML так и на C#. Разница только в представлении.
Для .Net MF же есть неофициальная надстройка, позволяющая использовать XAML.
Для .Net MF же есть неофициальная надстройка, позволяющая использовать XAML.
Да, но только behind-код в WPF — зло. Он декларитивен, и в этом вся его прелесть. А тут получается мы опять возвращаемся к императивному методу.
Вполне может быть и зло. Я не специалист по WPF и XAML, хотя и писал WPF приложения.
В .Net MF WPF урезан, но все же он остается WPF. Сам движок, структура классов, их свойства и методы, подходы к созданию интерфейсов — все соответствуют WPF из «большого» .Net.
Все таки микроконтроллеры — не та платформа, где вам нужно рисовать сногсшибательные интерфейсы.
Посмотрите вот этот ролик Это все сделано на урезанном WPF.
В .Net MF WPF урезан, но все же он остается WPF. Сам движок, структура классов, их свойства и методы, подходы к созданию интерфейсов — все соответствуют WPF из «большого» .Net.
Все таки микроконтроллеры — не та платформа, где вам нужно рисовать сногсшибательные интерфейсы.
Посмотрите вот этот ролик Это все сделано на урезанном WPF.
5. Сравнение трудозатрат по портированию Linux на новую платформу с трудозатратами по портированию .NET
5a. Сравнение возможностей системы с эмбеддед-линукс на борту с возможностями системы с микро-дотнетом на борту (удобство в разработке и поддержке приложений, расширения под новое железо, буде таковое обхявится)
P.S.
Спасибо за обзор, надеюсь, вы не остановитесь на одной статье.
5a. Сравнение возможностей системы с эмбеддед-линукс на борту с возможностями системы с микро-дотнетом на борту (удобство в разработке и поддержке приложений, расширения под новое железо, буде таковое обхявится)
P.S.
Спасибо за обзор, надеюсь, вы не остановитесь на одной статье.
5. Я не работал особо никогда с Linux, но могу сказать что, в основном, для Linux нужны процессоры с MMU. А контроллеры типа ARM7 или CortexM таковых не имеют. Единственный дистрибутив, не требующий наличия MMU, о котором я знаю — uClinux. Но о его портировании я ни чего сказать не могу.
5а. Тут сравнить легко. Linux — ОС, а .Net MF — нет. Я думаю, что Linux обладает бОльшими возможностями.
По поводу разработки: разница та же что и между разработкой для десктопного Linux на C++ и разработкой на C# под .NET. На мой взгляд, по удобству и поддержке .NET будет привлекательнее.
А вообще тут вопрос в том, что вы хотите сделать и сколько на это потратить. Все-таки Linux это больше уровень WinCE а не .NetMF. Ну плюс еще личные предпочтения :).
Лично я считаю, что использование .Net MF будет немного быстрее и дешевле чем Linux.
5а. Тут сравнить легко. Linux — ОС, а .Net MF — нет. Я думаю, что Linux обладает бОльшими возможностями.
По поводу разработки: разница та же что и между разработкой для десктопного Linux на C++ и разработкой на C# под .NET. На мой взгляд, по удобству и поддержке .NET будет привлекательнее.
А вообще тут вопрос в том, что вы хотите сделать и сколько на это потратить. Все-таки Linux это больше уровень WinCE а не .NetMF. Ну плюс еще личные предпочтения :).
Лично я считаю, что использование .Net MF будет немного быстрее и дешевле чем Linux.
Несмотря на то что Линукс это ОС а микродотнет это фреймворк, они в данном случае выполняют одну и ту же задачу — предоставляют АПИ для разработки приложений и абстракцию от оборудывания.
Механизм тредов в дотнет фреймворке вполне можно использовать для запуска пользовательских «процессов».
Вопрос в том, как именно организован HAL. В частности исходный код ядра линукса по мне выглядит мягко говоря *малоструктурированно*, если микрофреймворк позволяет добавлять HAL-фичи в интуитивно понятном виде, то, конечно, это будет большой плюс.
То есть меня больше всего интересует именно стык железа и софта. Надеюсь, эти вопросы вы рассмотрите в статьях про портирование, буду ждать)
Механизм тредов в дотнет фреймворке вполне можно использовать для запуска пользовательских «процессов».
Вопрос в том, как именно организован HAL. В частности исходный код ядра линукса по мне выглядит мягко говоря *малоструктурированно*, если микрофреймворк позволяет добавлять HAL-фичи в интуитивно понятном виде, то, конечно, это будет большой плюс.
То есть меня больше всего интересует именно стык железа и софта. Надеюсь, эти вопросы вы рассмотрите в статьях про портирование, буду ждать)
Я не видел как выглядит код ядра линукса, но в .Net MF HAL достаточно запутан.
Если коротко, то когда вы делаете новый порт, вы выбираете фичи, которые хотите реализовать, и вам собирается специальным Wizard'ом проект, содержащий заглушки, вместо которых нужно написать код. Все нужно реализовать более 100 функций.
Вот только порт разделен на элементы, которые взаимосвязаны друг с другом. Это взаимосвязи отследить сложно. Понять откуда тут взялась эта функция и кто ее вызывает порой очень не просто.
В свое время мы всю голову словами. Хотя проблема там не столько в структурировании, сколько в скудности документации.
Мы с коллегой в процессе работы сделали специальную прогу, помогающую делать порты.
Сейчас она на стадии включения в netmf.codeplex.com. Надеемся что она поможет…
Я попозже, подготовлю статью, где постараюсь изложить общую информацию о портировании.
Если коротко, то когда вы делаете новый порт, вы выбираете фичи, которые хотите реализовать, и вам собирается специальным Wizard'ом проект, содержащий заглушки, вместо которых нужно написать код. Все нужно реализовать более 100 функций.
Вот только порт разделен на элементы, которые взаимосвязаны друг с другом. Это взаимосвязи отследить сложно. Понять откуда тут взялась эта функция и кто ее вызывает порой очень не просто.
В свое время мы всю голову словами. Хотя проблема там не столько в структурировании, сколько в скудности документации.
Мы с коллегой в процессе работы сделали специальную прогу, помогающую делать порты.
Сейчас она на стадии включения в netmf.codeplex.com. Надеемся что она поможет…
Я попозже, подготовлю статью, где постараюсь изложить общую информацию о портировании.
Да, если не трудно, проясните в последующих статьях такой важный момент как обработку прерываний.
У тех же кортексов отличный NVIC, сиречь контроллер вложенных прерываний, позволяющий программировать им приоритеты и, главное, обеспечивающий всегда предсказуемое время реакции на прерывание (12 тактов, если мне не изменяет память)
Как обстоит дело с обработкой прерываний при использовании фреймворка, насколько предсказуемо время реакции системы, возможно ли построение реал-тайм систем с его использованием.
У тех же кортексов отличный NVIC, сиречь контроллер вложенных прерываний, позволяющий программировать им приоритеты и, главное, обеспечивающий всегда предсказуемое время реакции на прерывание (12 тактов, если мне не изменяет память)
Как обстоит дело с обработкой прерываний при использовании фреймворка, насколько предсказуемо время реакции системы, возможно ли построение реал-тайм систем с его использованием.
Real time систему построить нельзя, из-за сборщика мусора. Время его включения не просто предсказать.
Насчет прерываний, они используются на уровне HAL. Я на 100% не уверен, но по-моему на уровень управляемого кода аппаратные прерывания не выносятся вообще. Там работа с периферией абстрагирована от аппаратной платформы.
Например вся работа с I2C сводится по сути к 1 функции — Execute, которая синхронно выполняет транзакции чтения или транзакции записи. Если нужна асинхронность — нужно создавать отдельный поток. А вот отработка Execute с обработкой прерываний I2C уже реализована на уровне HAL из управляемого кода не видна вообще.
Насчет прерываний, они используются на уровне HAL. Я на 100% не уверен, но по-моему на уровень управляемого кода аппаратные прерывания не выносятся вообще. Там работа с периферией абстрагирована от аппаратной платформы.
Например вся работа с I2C сводится по сути к 1 функции — Execute, которая синхронно выполняет транзакции чтения или транзакции записи. Если нужна асинхронность — нужно создавать отдельный поток. А вот отработка Execute с обработкой прерываний I2C уже реализована на уровне HAL из управляемого кода не видна вообще.
Ну бывают такие вещи как «предсказуемые сборщики мусора», грубо говоря. То есть тут такого нет?
Вообще, эмбеддед система без прерываний это очень и очень странно. Ну скажем так, допустим я хочу использовать этот фреймворк на своей железке, которой нужно контролить уровень нескольких входных сигналов. Сигналы висят на компараторах, превышение порога вызовет прерывание.
Что нужно чтобы эту ситуацию обработать и сделать приложение, которое, допустим, будет что-то выводить на экран при наступлении этих событий?
Я так понимаю, написать нечто вроде драйвера, дополнение к HAL-уровню фреймворка, так? В котором будут нативные обработчики. (Не может же фреймвор полностью заставить отказаться от прерываний?) Как, в таком случае, будет выглядеть полная картина распространения информации о наступлении события?
Изменение сигнала => аппаратное прерывание => Нативный обработчик (?) => ....?
Вообще, эмбеддед система без прерываний это очень и очень странно. Ну скажем так, допустим я хочу использовать этот фреймворк на своей железке, которой нужно контролить уровень нескольких входных сигналов. Сигналы висят на компараторах, превышение порога вызовет прерывание.
Что нужно чтобы эту ситуацию обработать и сделать приложение, которое, допустим, будет что-то выводить на экран при наступлении этих событий?
Я так понимаю, написать нечто вроде драйвера, дополнение к HAL-уровню фреймворка, так? В котором будут нативные обработчики. (Не может же фреймвор полностью заставить отказаться от прерываний?) Как, в таком случае, будет выглядеть полная картина распространения информации о наступлении события?
Изменение сигнала => аппаратное прерывание => Нативный обработчик (?) => ....?
На этот случай существует InterruptPort. Из любого GPIO пина .Net MF может сделать аналог внешнего прерывания. Вы можете настроить любой пин так, чтобы вам приходило вобытие OnInterrupt по фронту или срезу, по фронту и срезу или по уровням.
Вот пример:
Пины, разрешенные для такого использования настраиваются как раз при портировании.
Я проверил, остальные прерывания при работе периферии скрыты на уровне HAL.
А вообще, вы можете дополнить библиотеку своими собственными драйверами.
Нас например не устраивает то, что можно работать только с 1 I2C. Мы собираемся добавить свой собственный класс для работы с I2C.
Вот пример:
public enum InterruptMode
{
InterruptNone, // The port is deactivated
InterruptEdgeLow, // falling edge (Change from high to low)
InterruptEdgeHigh, // rising edge (Change from low to high)
InterruptEdgeBoth, // both edges (Any state change)
InterruptEdgeLevelHigh, // high
InterruptEdgeLevelLow // low
}
public static void Main()
{
InterruptPort port = new InterruptPort(Cpu.Pin.GPIO_Pin3,false,Port.ResistorMode.PullDown,
Port.InterruptMode.InterruptEdgeBoth);
port.OnInterrupt += new NativeEventHandler(port_OnInterrupt);
Thread.Sleep(Timeout.Infinite);
}
private static void port_OnInterrupt(uint port,uint state,TimeSpan time)
{
Debug.Print("Pin=" + port + " State=" + state + " Time=" + time);
}
Пины, разрешенные для такого использования настраиваются как раз при портировании.
Я проверил, остальные прерывания при работе периферии скрыты на уровне HAL.
А вообще, вы можете дополнить библиотеку своими собственными драйверами.
Нас например не устраивает то, что можно работать только с 1 I2C. Мы собираемся добавить свой собственный класс для работы с I2C.
Ну а с реальным временем, в стандартном варианте к сожалению никак.
Если только кто-то специальную модификацию .Net MF сделает.
Если только кто-то специальную модификацию .Net MF сделает.
3. Отличается тем, что много более урезан по сравнению даже с Silverlight.
Конечно пишите, и поподробнее. Хабр для таких вещей и существует.
Забавно.
1. Это как я понял не RTOS?
2. Какие-нибудь особые требования к обвязке есть? Как переносится программа в mcu, стандартными средствами?
1. Это как я понял не RTOS?
2. Какие-нибудь особые требования к обвязке есть? Как переносится программа в mcu, стандартными средствами?
Это не ОС вообще. Это среда исполнения управляемого кода, запущенная на «голом процессоре». Можно кстати сделать порт и под любую ОС.
Основные требования — 32 разрядность и достаточное количество памяти.
По поводу переноса — если вы имеете ввиду как запустить TinyCLR на не прошитом микроконтроллере — то нужно шить так же как и любую другую программу.
Если вы имеете ввиду само приложение, то есть специальные программы для «разворачивания» приложений. Такую программу можно написать и самому. Visual Studio это делает автоматически при отладке.
Основные требования — 32 разрядность и достаточное количество памяти.
По поводу переноса — если вы имеете ввиду как запустить TinyCLR на не прошитом микроконтроллере — то нужно шить так же как и любую другую программу.
Если вы имеете ввиду само приложение, то есть специальные программы для «разворачивания» приложений. Такую программу можно написать и самому. Visual Studio это делает автоматически при отладке.
А, и вот что забыл спросить: у этой tinyCLR есть JIT-компиляция? Или она всегда интерпретирует байт-код?
Что-то сильно усложняется, по сравнению с тем же Arduino.
Это наверно как запустить Windows вместе с Net Framework на micro-ATX…
Это наверно как запустить Windows вместе с Net Framework на micro-ATX…
Присмотритесь к Netduino. Вроде как это порт .Net MF на Arduino.
А вот тут даже более интересные штуки продаются: tinyclr.com/compare/
Это продукция американской компании GHI Electronics. Сайт, кстати, тоже их. Они давно уже специализируются на .Net MF. На «поиграть» у них можно купить что-нибудь. Правда ближайший ретейлир находится в Чехии. Но вот строить производство на их продукции не выгодно. Слишком дорого выходит.
Кстати есть и другие производители, но их не много.
Кстати есть и другие производители, но их не много.
Очень интересная тема.
Жду еще статей!
Жду еще статей!
А в чём заключаются ваши проекты?
Мы разрабатываем контрольно-кассовую технику.
Мне интересно. Если можно по-простому о написании порта.
У меня есть вот такой девайc — http://www.netduino.com/netduino/ Внутри тоже микрофреймворк, снаружи — форм-фактор, совместивый с шилдами для Ардуино. Сейчас я нахожусь в состоянии ожидания кучи посылок с ебея со всякими электрокомпонентами. =) Когда все приедет, планирую тоже написать рассказ, об общении с этим зверем. Пока что только мигал светодиодиками, об этом смысла нет писать.
Да, было бы очень интересно почитать про особенности и подводные камни.
>Сейчас мы полностью перевели наши разработки на .Net Micro Framework
Вы перешли с 8-битного микроконтроллера на 32-х разрядный процессор общего назначения.
Неудивительно, что в результате появилась возможность запускать приложения совсем другого уровня.
Вы перешли с 8-битного микроконтроллера на 32-х разрядный процессор общего назначения.
Неудивительно, что в результате появилась возможность запускать приложения совсем другого уровня.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Знакомство с .Net Micro Framework