Опыт программирования с .NET Micro Framework

Question

Компания, к которой я обращаюсь, ищет, по моему убеждению, переключиться на устройства на платформе .NET Micro Framework, чтобы мы могли быстрее выводить устройства на рынок. Идея, по крайней мере теоретическая, заключается в том, что кодирование на C #, а не на C или сборке будет намного быстрее и менее подвержено ошибкам. Как я уже сказал, это все теория, поскольку я никогда не программировал встроенное устройство.

Мои вопросы следующие:

1. .NET Micro Framework соответствует задаче?
2. Что не может делать .NET Micro Framework?
3. Каковы некоторые из ошибок?
4. Существует ли жизнеспособная сторонняя торговая площадка для подключаемых устройств? Я не очень много видел на сайте Microsoft.
5. Может кто-то указать на коммерческое устройство, которое было разработано с помощью MF Framework.

Спасибо.

Answer 1

Не зная вашего приложения и текущих возможностей встроенного устройства, мне будет сложно дать однозначное мнение, если .NET MF справится с этой задачей. Если встроенное устройство представляет собой 8-разрядный процессор с низким энергопотреблением с 2 КБ ОЗУ и 32 КБ ПЗУ, то .NET MF не подойдет для этого дизайна.

В большинстве случаев переход на .NET MF повлечет за собой изменения аппаратного обеспечения в наборе микросхем, предпочитаемого многими поставщиками, которые обычно ориентированы на ядра ARM7 или ARM9. Основная причина этого заключается в использовании уже проделанной работы по переносу HAL и кросс-компиляции PAL & TinyCLR в нативный код для рассматриваемого процессора. Затем, если ваше приложение соответствует модели .NET MF, вам нужно только разработать управляемый код.

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

Ответ на вопрос 1. Соответствует ли .NET Micro Framework этой задаче?

Извините, я не могу ответить на этот вопрос о вашей заявке без дополнительной информации.

Ответ на вопрос 2: Что не может сделать .NET Micro Framework?

Микро-фреймворк не в реальном времени похож на многие конкурирующие продукты. Планировщик довольно прост и не оптимизирован для систем, которые требуют детерминированной синхронизации.
TinyCLR интерпретирует IL из следующей ожидающей «нити» в течение 20 мс. Потоки могут выдать свой выделенный временной интервал, вызвав Thread.Sleep(0). ТОЛЬКО между каждым отрезком времени потока Интерпретатор времени выполнения проверяет флаги от оборудования и отправляет события в управляемый код или пробуждающие потоки, если они заблокированы в ожидании аппаратного обеспечения. Насколько я понимаю, поток не может быть разблокирован из процедур обработки прерываний собственного кода (ISR) или для потока с более высоким приоритетом с преимущественным прерыванием потока с более низким приоритетом.

Ответ на вопрос 3: Какие у вас есть ошибки?

Кажется, все работает, вы поняли, как работает цикл прерывания во время выполнения (планирование потоков и реагирование на аппаратные события), а затем забыли о GARBAGE COLLECTION !!
Лучше всего минимизировать объем памяти (внимательно просматривайте каждый раз, когда вы new объект). Вместо того, чтобы создавать и уничтожать часто используемые объекты, рассмотрите возможность хранения пула объектов, обычно GC'd, и утилизируйте их при необходимости снова.

Ответ на вопрос 4: Существует ли жизнеспособная сторонняя торговая площадка для подключаемых устройств?

Участие третьей стороны в основном связано с разработкой плат и эталонных конструкций с аппаратной стороны. С программной точки зрения эта ссылка на кодовый ресурс может представлять интерес. В качестве дополнительной проблемы не забывайте, что большинство инструментов разработки VS2008 также работают на .NET MF (например, Resharper и VisualSVN)

Извините, у меня нет ответа на вопрос 5, так как я не следую этому типу вещей. На целевой странице для .NET MF в Microsoft, похоже, есть изображения коммерческих устройств, но я никогда не переходил по ссылкам.

Answer 2

.Net Micro Framework очень прост в работе по сравнению со многими другими встроенными платформами, с которыми я работал. Но в настоящее время у него есть несколько недостатков, таких как отсутствие поддержки в реальном времени. Также некоторые из комплектов SDK имеют проблемы из-за аппаратного состязания всех дополнительных устройств, использующих одинаковые шины. Если вам нужно множество устройств, висящих на вашем контроллере, я бы вместо этого посмотрел на платформу Windows CE. Текущий выбор оборудования для Micro Framework просто очень ограничен.

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

Как и многое другое в этой отрасли, это зависит. Но за то, что вы можете получить развитие комплект за менее чем 100 долларов, возможно, стоит проверить.

---

Я использовал Tahoe-II от DeviceSolutions.Net с .Net Micro Framework 2.0 / 3.0 и C #. Потоки были очень просты, но рамки в настоящее время очень ограничены. Мне пришлось создать свой собственный парсер HTTP и создать грубые веб-службы RESTful. Существует модель Web-сервиса устройств, но я хотел чистый HTTP. Я также должен был создать свои собственные уровни протокола SNTP и SMTP. Новая версия (4.0) должна быть выпущена в ближайшее время, и она может заполнить некоторые из этих недостатков.