Netduino (.net mf)

KoliaZP · 27.10.2011, 02:26

Пару недель назад приехала ко мне платка на базе ARM FEZ Panda II (более известная по совместимости с netduino). Играюсь...
Программируется на C# с использованием .Net Micro Framework.
Есть здесь люди кодящие под на .net mf? Было бы интересно пообщаться.

KoliaZP · 31.10.2011, 19:33

Ну, раз единодумцев нету, буду описывать свое знакомство с .Net MF, может еще кого заинтересую.

Очень понравилось программировать микроконтроллер с использованием C# и ООП — мне, как прикладному программисту, так значительно приятнее писать код. Не говоря уже об IDE — Visual Studio значительно удобнее любой из IDE с которыми мне приходилось сталкиваться (конечно же IMHO).
Прикрутил к нему экранчик на базе PCF8833 и очень разочаровался...

Кто не знает, программы написанные с .Net Framework исполняются в виртуальной машине CLR, как Java. На микроконтроллере так же. Производительность соответствующая.
Код типа

Код:

while (true) pin = !pin;

мигает пином с частотой 5.4KHz (при частоте МК — 72MHz).
При программном SPI экранчик очищается за 20–25 сек. Аппаратное SPI (предоставляемое в framework'е GHI, разработчика платы) задействовать не выходит, т.к. PCF8833 принимает 9-битные посылки, а SPI умеет работать только с байтами.
Решения проблемы — писать на базовый код на C и юзать его в C# (еще не попробовал). Правда возникла мысль попробовать общаться с экранчиком 9-байтными посылками... Но еще не успел попробовать.

Но общие впечатления крайне положительные. На днях прикручу экранчик с параллельным интерфейсом, хорошо что пинов предостаточно, думаю там эта проблема сразу исчезнет.

ut1wpr · 31.10.2011, 22:03

Сообщение от KoliaZP

При программном SPI экранчик очищается за 20–25 сек.

Не ошибся? Может, миллисекунд? Или оно там байты ножками в дисплей относит?

KoliaZP · 31.10.2011, 23:33

Не, не ошибся. 20 мс я бы и не заметил.
Даже в теории:
5.4KHz мигание пином — 10 800 изменений состояния пина в секунду.
Очистить дисплей:
1. Выбрать диапазон строк (3 посылки)
2. Выбрать диапазон столбцов (3 посылки)
3. Команда записи в память (1 посылка)
4. Данные (1-байтный цвет — 130*130 посылок)
Итого 16 906 посылок.
1 посылка — 9 бит, 9*3 изменений состояния пина.
456 462 изменений пина, 42.6 секунды.

Я добился скорости в 20 секунд за счет того, что не изменяю состояния пина данных если оно не изменилось.

UPD:
Не сразу дошел вопрос. Да, очистка дисплея на практике это установка каждого пикселя в отдельности.

Yurkin2007 · 01.11.2011, 03:17

Сообщение от KoliaZP

Очень понравилось программировать микроконтроллер с использованием C# и ООП...

Да, у меня сложилось такое же ощущение. Программировать легко и приятно. Единственно, что не понравилось - графика из-под MicroFramework тормозит очень.
Пробовал модуль Embedded Master + VGA TFT. В этом модуле используется проц LPC2478, у которого встроен контроллер экрана. Удалось достичь сносных 12 fps, при этом программа не тормозила заметно. При выставлении же человеческих 60fps всё жутко тормозило, время реакции на нажатие на кнопку составляло 2-3 секунды!

Сообщение от KoliaZP

мигает пином с частотой 5.4KHz

Кстати, эти ребята из GHI Electronics предлагают технологию RLP. То есть особо тяжёлые куски программы писать в нативном С, компилировать и использовать как внешние процедуры уже в С#. Попробуйте написать таким образом Вашу процедуру

Код:

while (true) pin = !pin;

и легко получите пару МГц

qwerky · 01.11.2011, 09:11

чем этот изврат лучше С++ ? тем более что на таких толстых контроллерах можно писать с использованием STL,Boost и многими новыми фишками С++11, получится ненамного хуже .Net.

KoliaZP · 01.11.2011, 09:58

Сообщение от Yurkin2007

Кстати, эти ребята из GHI Electronics предлагают технологию RLP.

Да, я тоже об этом думал. Не успел попробовать...

Сообщение от qwerky

чем этот изврат лучше С++ ?

Оно не лучше. Оно другое.

Сообщение от qwerky

получится ненамного хуже .Net.

Я думаю даже лучше, т.к. производительность будет соизмерима с нативным ассемблерным кодом. Но я все равно бы не отказался бы от C# в пользу полноценного C++ — мне, все же, на C# гораздо приятнее программировать. Хотя подозреваю, что в таком моем выборе играет роль и менее удобная IDE...

Ты когда нибудь кодил на Java, C# или VB.net? На них гораздо проще писать код (особенно C#). У тебя уже сразу есть огромное кол-во абстракций (делегаты, события, разные виды контейнеров), огромное кол-во готовых методов для работы с ними (LINQ содержит всевозможные операции над множествами). И конечно же сборшик мусора... Ты программируешь думая о том, что тебе нужно сделать, не задумываясь о том что где-то забыл освободить память.

Плата за все это — низкая производительность; все таки код выполняется в виртуальной машине. Но сейчас уже компьютеры достаточно производительны, и эта разница совершенно не заметна.

qwerky · 01.11.2011, 11:45

Цитата:

Ты когда нибудь кодил на Java, C# или VB.net?

на этих нет, но постоянно пишу на Scala и Python

Цитата:

У тебя уже сразу есть огромное кол-во абстракций

ну да, но зачем это все на контроллере, не понимаю

KoliaZP · 01.11.2011, 12:08

Сообщение от qwerky

на этих нет, но постоянно пишу на Scala и Python

А хотелось бы на них кодить МК? Хотя бы ради научного интереса?

Сообщение от qwerky

ну да, но зачем это все на контроллере, не понимаю

Для реальных применений думаю они малополезны (как минимум из-за производительности). А если просто "поиграться" — с ними гораздо интересней.
Например работа с файлами... Не сильно знаю как это делалось бы на ARM с использованием C/C++, на C# это делается так же легко как и на компе (msdn)...

qwerky · 01.11.2011, 12:21

Цитата:

Например работа с файлами... Не сильно знаю как это делалось бы на ARM с использованием C/C++

гляньте fatfs, ее функционала достаточно для примитивных операций с файлами, что-то более сложное на контроллерах делать не приходилось, и не факт что придется. Если задействовать обертку на STL/Boost то работа с файлами будет не намного сложнее приведенного вами примера. http://www.decompile.com/cpp/faq/file_to_vector.htm