Pull to refresh

Знакомство с .Net Micro Framework

IOT IT-companies


Первый раз о .Net Micro Framework мы услышали около года назад на одной из конференций по встраиваемым технологиям. На тот момент мы с коллегой размышляли на тему новой платформы для наших встраиваемых разработок и потому решили присмотреться к .Net Micro Framework более внимательно. С тех пор мы довольно глубоко изучили эту платформу. И хотя не все там так гладко, все-таки платформа .Net Micro Framework оказалась очень удобной и полезной в нашей работе. В этой статье я расскажу почему.

Предыдущая наша разработка была на базе микроконтроллера uPSD3234. В принципе, все было хорошо, пока мы не столкнулись с проблемой, знакомой многим разработчикам встраиваемых устройств. ST Microelectronics, производитель микроконтроллеров, неожиданно заявил, что вся серия, куда входит и наш uPSD3234, в течение полугода будет снята с производства. Получилось, что мы зря потратили год работы. Пришлось искать новую платформу. Архитектура uPSD3234 уже порядком устарела, а кода было написано много, поэтому переносить его на новый процессор с другой архитектурой было трудно и бессмысленно. В итоге мы решили делать новое устройство с нуля. Сразу же захотелось получить такие «прелести», как ООП и обработку исключений, ведь XXI век на дворе. А главное – как можно меньше привязки к аппаратной реализации, что бы избежать новых проблем.

И тут в поле зрения попал .Net Micro Framework. Общий смысл данной платформы – выполнение управляемого .Net кода на 32-разрядном микроконтроллере без операционной системы. С 2010 года Microsoft сделала .Net Micro Framework бесплатным open-source проектом. До этого они брали отчисления за использование. На текущий момент разработка ведется на базе интернет-сообщества, но под руководством Microsoft.

Идея писать код для микроконтроллера на C# в Visual Studio нам очень понравилась. Удобная и мощная IDE и управляемый код сулили кучу преимуществ: сборщики мусора, многопоточность, обработка исключений, ООП и т.д. Хочешь XML – бери, хочешь Ethernet с TCP/IP – бери, хочешь LCD с touch-панелью и распознаванием жестов – бери. А самое главное — код, написанный для .Net Micro Framework, не привязан ни к какой аппаратной платформе.

Но за все прелести нужно платить. Конечно, управляемый код исполняется немного медленнее обычного. Конечно, из-за метаданных объем кода возрастает. Все это ведет к удорожанию аппаратной части. Ну и естественно, .Net Micro Framework требует портирования, если мы хотим использовать свою аппаратную платформу, что не так уж и быстро. Существуют уже готовые платы, но для массового производства они дороговаты, да и ввозить их нужно из-за границы.

Начинали работу мы вот так:




Фото в шапке статьи это — отладочная плата от Embedded Artists. Порт .Net Micro Framework для этой платы предоставляется Microsoft бесплатно, но запустить его оказалось не так то и просто. Зато после успешного запуска порта с развертыванием приложений проблем уже не возникло. На фотографии, для примера, семпл-приложение «Puzzle».

Основная проблема с портированием это крайне скудная документация. Там вроде бы написано что и как, но, после прочтения все равно мало что понятно.

Весь .Net Micro Framework разделен на несколько слоев:



Два верхних слоя (приложения пользователя и системные библиотеки) написаны на управляем коде. Это то, что мы видим в Visual Studio. Слой аппаратного обеспечения — это и есть сама «железка». Ну а слой TinyCLR — это сама среда исполнения кода.

TinyCLR разделена на 3 части:
1) CLR — тут все, что касается исполнения управляемого кода, типизации, сборки мусора и т.д.
2) PAL (Platform Abstraction Layer) — Классы и функции для работы с общими абстракциями, такими как счетчики, таймеры, ввод-вывод. Эти классы одинаковы для всех аппаратных платформ.
3) HAL (Hardware Abstraction Layer) — Классы и функции дня работы непосредственно с «железом».

Портирование представляет собой процесс создания HAL для конкретной аппаратной платформы. Код пишется поэтапно, постепенно наращивая функционал. Основной целью является реализация базового набора функций для запуска CLR. Остальной код пишется по необходимости. После того, как понимаешь как и что должно работать, процесс этот превращается в рутину.

Что касается порта для платы Embedded Artists, то мы столкнулись с двумя проблемами:
1) Код, идущий в поставке, был почему-то с ошибками. Например, не правильно рассчитывался Baud Rate для UART.
2) Распределение памяти. Мы потратили много времени, чтобы понять что и куда должно быть прошито. Хотя эта информация касается и любого другого порта.

В общем, в итоге все оказалось не так уж страшно. Начав с нуля, мы смогли вдвоем за несколько месяцев сделать порт на нашу плату на базе ARM7. Стоимость новой платы выросла всего на $5 по сравнению с платой на базе uPSD3234. Проблем с производительностью мы так же не заметили. Конечно, были и еще небольшие трудности, но они достаточно быстро разрешились благодаря общению с разработчиками .Net Micro Framework на форуме сообщества.

Сейчас мы полностью перевели наши разработки на .Net Micro Framework. Надеюсь, наш опыт будет кому-то полезен. Если кому-то будет интересно, то я могу написать несколько более подробных статей.

Update:
Продолжение: .NET Micro Framework: кратко о портировании
Tags:
Hubs:
Total votes 96: ↑76 and ↓20 +56
Views 8.4K
Comments Comments 46