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

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