Первый раз о .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: кратко о портировании
