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

Question

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

Мои вопросы заключаются в следующем:

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

Спасибо.

Answer 1

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

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

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

Ответ на вопрос 1: Подходит ли .NET Micro Framework к задаче?

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

Ответ на вопрос 2: Каковы некоторые из особенностей, которые не может сделать .NET Micro Framework?

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

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

Все, кажется, работает, вы понял, как среда выполнение interperter цикла работ (планирование потоков и реагирование на аппаратные события), а затем вы забыли о СБОРЕ МУСОРА !!
Лучшее, чтобы свести к минимуму количество измельчения памяти (внимательно просмотрите каждый раз, когда вы new объект). Вместо того, чтобы создавать и уничтожать обычно используемые объекты, подумайте о том, чтобы держать пул объектов, обычно GC'd, и повторно использовать их при необходимости снова.

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

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

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

Answer 2

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

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

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

---

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