Netduino (.net mf)

[LionRJ]

Поглядите еще в сторону LabVIEW ARM Module. Поиграться тоже очень хорошо. Только там используется родная для мк ОСЬ от keil. Производительность получается выше значительно. И пишется все на уровне блок диаграмм, на языке G.

[KoliaZP]

Поглядите еще в сторону LabVIEW ARM Module. Поиграться тоже очень хорошо. Только там используется родная для мк ОСЬ от keil. Производительность получается выше значительно. И пишется все на уровне блок диаграмм, на языке G.

Цена несколько пугает...

[gary2007]

Кто не знает, программы написанные с .Net Framework исполняются в виртуальной машине CLR, как Java. На микроконтроллере так же. Производительность соответствующая.
Код типа
Код:
while (true) pin = !pin;
мигает пином с частотой 5.4KHz (при частоте МК — 72MHz).

Это уже перебор, по моему.
Просветите, в чем прелесть этого всего. Естественно, кроме того, что вам приятно работать в этой среде.

[Boba_spb]

Эт в Debug или Release такая скорострельность 5.4КГц?
На WinСЕ и ARM 400 - тормозов не наблюдал вроде.

[KoliaZP]

Я немного неправильно написал. Код выполняется не в виртуальной среде, но все равно остается достаточно много "лишнего" кода. Изначально код компилируется в ассемблер виртуальной машини CLR (сам ассемблер зовется IL -- intermediate language). Потом уже в ассемблер целевого процессора.

Большое падение производительности в случае мигания пина происходит из-за больших задержек при вызове нативного кода из управляемого. Если использовать более высокоуровневые интерфейсы то скорость передачи данных вполне сравнима с обычным нативным кодом.
Я большую часть того "драйвера" для экрана переписал на C, с производительностью все гуд.

Да, прелесть всего этого исключительно в большом удобстве IDE. Покрутив немного настройки проекта я и на C/C++ код под контроллеры пишу там. Осталось отладку прикрутить, тогда моему счастью не будет предела.

UPD:
Утверждение о большом удобстве писания кода в Visual Studio исключительно ИМХО. Не холивара ради.

[KoliaZP]

Эт в Debug или Release такая скорострельность 5.4КГц?
На WinСЕ и ARM 400 - тормозов не наблюдал вроде.

В случае .Net разница будет не столь велика между Debug и Release. У вас же наверное было обычное нативное приложение на C/C++/Asm?

[Boba_spb]

Ну да нативная, на C# , для промышленой панели MT6000 тама WinCE 5 стоит.

Пульты на них рисовал для АСУ - очень удобные штуки. Кнопочки, лампочки, тумблерочки - классная вещь.

[KoliaZP]

Ну да нативная, на C# , для промышленой панели MT6000 тама WinCE 5 стоит.

Пульты на них рисовал для АСУ - очень удобные штуки. Кнопочки, лампочки, тумблерочки - классная вещь.

C# по определению управляемый (managed). Нативный -- C, C++...
В любом случае проблемы с производительностью дает именно большое фрагментирования кода между C# и нативным а не сам факт использования .Net'а.

[Boba_spb]

именно большое фрагментирования код

Это что такое фрагментирование кода ?
Блин..... пора на пенсию, похоже - стоко нового

[KoliaZP]

Это что такое фрагментирование кода ?

Вызов какой-либо нативной функции (я имею ввиду нечто, скомпиленое в асссемлер контроллера) из C# довольно тяжелая операция.
Под фрагментированием я имел ввиду, что если код на C# будет часто дергать код написаный на C, то из-за длительного вызова прирост производительности не будет ощутим.

Тот экранчик, с которым я работал, общается по 9-битному SPI. Контролер железом поддерживает только 8- или 16-битный. Соотвественно пришлось самому пины дергать.
Это я вот к чему. Когда я написал на C функцию "послать 9-битную посылку" и вызывал ее из C#, быстрее не заработало (хотя я избавился от набора проверок и контроля со стороны среды выполнения). Но когда я перенес больше кода на C написав функцию "послать команду и массив данных", тут уже все стало круто. Получалось что вместо 16 тысяч вызовов нативного кода стало только около 10-ка.
Вот, как-то так