Programación de experiencias con .NET Micro Framework

Question

Una empresa a la que consulto está buscando, bajo mi impulso, cambiar a dispositivos con tecnología de .NET Micro Framework, de modo que podamos llevar los dispositivos al mercado más rápido. La idea, al menos en teoría, es que codificar en C# en lugar de C o ensamblar será mucho más rápido y menos propenso a errores. Como dije, esta es toda la teoría, ya que nunca he programado un dispositivo integrado.

Mis preguntas son las siguientes:

1. Es .NET Micro Framework hasta la tarea?
2. ¿Cuáles son algunas de las cosas que .NET Micro Framework no puede hacer?
3. ¿Cuáles son algunos de los problemas?
4. ¿Existe un mercado de terceros viable para los dispositivos con complementos? No vi mucho en el sitio de Microsoft.
5. ¿Alguien puede apuntar a un dispositivo comercial que se ha desarrollado con el Marco de MF.

Gracias.

Answer 1

Sin conocer su aplicación y la capacidad actual del dispositivo incrustado, me resultará difícil dar una opinión definitiva si .NET MF está a la altura. Si el dispositivo integrado es una CPU de 8 bits de baja potencia con 2K de RAM y 32K de ROM, entonces .NET MF no sería adecuado para ese diseño.

En una gran cantidad de casos, el cambio a .NET MF implicaría cambios de hardware en un chipset favorecido por muchos proveedores que normalmente apuntan a núcleos ARM7 o ARM9. La razón principal de esto es aprovechar el trabajo ya hecho en portar el HAL y compilar de forma cruzada el PAL & TinyCLR con el código nativo para el procesador en cuestión. Luego, si su aplicación se ajusta al modelo .NET MF, solo necesita desarrollar un código administrado.

Una comparación de development boards puede ayudarlo a seleccionar una plataforma para un nuevo diseño. La ventaja de GHI products es que puede comprar los conjuntos de chips desnudos con el firmware que han desarrollado para integrarse con su diseño de hardware.

Respuesta a la pregunta 1: ¿Está el .NET Micro Framework a la altura de la tarea?

Lo siento, no puedo responder esto sin necesidad de más información.

Respuesta a la pregunta 2: ¿Cuáles son algunas de las cosas que .NET Micro Framework no puede hacer?

El micro-framework no es en tiempo real como muchos de los productos de la competencia. El programador es bastante simple y no está optimizado para sistemas que requieren un tiempo determinista.
El TinyCL interpreta el IL desde el siguiente "hilo" de espera durante 20 ms. Los subprocesos pueden producir su segmento de tiempo asignado llamando al Thread.Sleep(0). SÓLO entre cada segmento de tiempo de subprocesos, la marca de verificación del intérprete de ejecución del host se mostrará desde el hardware y enviará los eventos al código administrado o al despertar los subprocesos si están bloqueados en espera de hardware. Por lo que yo entiendo, no hay forma de que un hilo sea desbloqueado desde las rutinas de servicio de interrupción de código nativo (ISR) o para un hilo de prioridad más alta que interrumpa preventivamente un hilo de menor prioridad.

Respuesta a la pregunta 3: ¿Cuáles son algunos de los problemas?

Todo parece estar funcionando, se ha entendido la forma en que el tiempo de ejecución de las obras interperter bucle (la programación de hilos y reaccionar a eventos de hardware) y luego olvidarse de RECOLECCIÓN DE BASURA !!
Lo mejor es minimizar la cantidad de vibración de la memoria (revise cuidadosamente cada vez que new un objeto). En lugar de crear y destruir objetos de uso común, considere la posibilidad de mantener un grupo de objetos generalmente GC y reciclarlos cuando sea necesario nuevamente.

Respuesta a la pregunta 4: ¿Existe un mercado de terceros viable para los dispositivos con complementos?

La participación de terceros se encuentra principalmente en las juntas de desarrollo y diseños de referencia en el lado del hardware. Desde el punto de vista del software, este code-share link podría ser de su interés. Como una cuestión secundaria, no hay que olvidar que la mayoría de las herramientas de desarrollo VS2008 también funcionan en .NET MF (por ejemplo, ReSharper y VisualSVN)

Lo sentimos, no tienen una respuesta a la pregunta 5 como no sigo este tipo de cosas El landing page for .NET MF en Microsoft parece tener imágenes de dispositivos comerciales, pero nunca he seguido los enlaces.

Answer 2

.Net Micro Framework es muy fácil de usar en comparación con muchas de las otras plataformas integradas con las que he trabajado. Pero actualmente tiene varios inconvenientes, como la falta de soporte en tiempo real. Además, algunos de los kits de SDK tienen problemas debido a la contención de hardware de todos los dispositivos adicionales que usan los mismos buses. Si necesita toneladas de dispositivos colgando de su controlador, en su lugar miraría la plataforma de Windows CE. La selección actual de hardware para Micro Framework es muy limitada.

Gran plataforma y para proyectos pequeños sería genial. Pero cuando tratas de cumplir con los requisitos de tiempo casi real, es posible que comiences a experimentar topetones.

Como mucho más en esta industria, depende. Pero por el hecho de que puede obtener un kit de desarrollo por menos de $ 100 dólares, podría valer la pena registrarse.

---

he utilizado la Tahoe-II de DeviceSolutions.Net con .Net Micro Framework 2.0/3.0 y C#. Enhebrar era muy simple, pero el marco actualmente es muy limitado. Tuve que crear mi propio analizador HTTP y crear servidores web RESTful crudos. Hay un modelo de servicio web de dispositivo pero quería HTTP puro. También tuve que crear mis propias capas de protocolo SNTP y SMTP. Una nueva versión (4.0) debería publicarse en breve y podría completar algunas de estas caídas breves.