Experiencias de programación con .NET Framework Micro

Question

Una empresa consulto de busca, a instancias mías, para alternar con los dispositivos alimentados por el .NET Micro Framework, por lo que podemos traer dispositivos al mercado más rápido. La idea, al menos en teoría, es que la codificación en C # en lugar de C o montaje será mucho más rápido y menos propenso a error. Como he dicho, todo esto teoría, ya que nunca he programado un dispositivo embebido.

Mis preguntas son las siguientes:

1. ¿Es .NET Micro Framework hasta la tarea?
2. ¿Cuáles son algunas de las cosas .NET Micro Framework no puede hacer?
3. ¿Cuáles son algunas de las trampas?
4. ¿Hay un mercado de 3 ª parte viable para dispositivos plug-in? No vi mucho en el sitio de Microsoft.
5. ¿Puede alguien apuntan a un dispositivo comercial que se ha desarrollado con el Marco de MF.

Gracias.

Answer 1

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

En un gran número de casos el paso a .NET MF implicaría cambios en el hardware a un conjunto de chips favorecido por muchos vendedores que normalmente se dirigen a ARM7 ARM9 o núcleos. La razón principal de esto es para aprovechar el trabajo ya realizado en portar la HAL y cross-compilar el PAL y TinyCLR al código nativo para el procesador en cuestión. Entonces, si la aplicación se ajusta al modelo MF .NET, sólo es necesario para el desarrollo de código administrado.

Una comparación de tarjetas de desarrollo podría ayudarle a seleccionar una plataforma para un nuevo diseño . La ventaja de la productos GHI es que se puede comprar los conjuntos de chips desnudos con el firmware que han desarrollado integrar con su diseño de hardware.

Respuesta a la pregunta 1: Es el .NET Micro Framework hasta la tarea

?

  

Lo siento, no puedo responder a esta acerca de su aplicación sin más información.

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

?

  

El micro-marco no es en tiempo real al igual que muchos de los productos de la competencia. El planificador es bastante simple y no optimizado para sistemas que requieren tiempo determinista.
  El TinyCLR interpreta la IL desde el de espera siguiente "hilo" por unos 20 ms. Los temas pueden ceder su intervalo de tiempo asignado llamando Thread.Sleep(0). Sólo entre cada segmento de tiempo de rosca se las banderas de verificación de tiempo de ejecución de interpretación de los eventos de hardware y despacho a código administrado o al despertar hilos si están bloqueados a la espera de hardware. Por lo que yo entiendo, no hay forma de un hilo que se desbloqueó de la rutina de servicio de interrupción de código nativo (ISR) o para un hilo de mayor prioridad preventivamente interrumpir un subproceso de menor prioridad.

Respuesta a la pregunta 3: ¿Cuáles son algunas de las trampas

  

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 !!
  Posible para minimizar la cantidad de golear de la memoria (revisión detallada cada vez que new un objeto). En lugar de crear y destruir objetos de uso común, considerar la realización de un conjunto de objetos generalmente GC'd y reciclarlos de nuevo cuando sea necesario.

respuesta a la pregunta 4: ¿Hay un mercado de 3 ª parte viable para dispositivos plug-in

  

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, esto código compartido de enlace 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, ya que no siguen este tipo de cosas. La página de destino rel="noreferrer"> de Microsoft parece tener unas imágenes de los dispositivos comerciales, pero nunca he seguido los enlaces.

Answer 2

El .NET Micro Framework es muy fácil de trabajar en comparación con muchas de las otras plataformas integradas que he trabajado. Pero tiene actualmente varias pegas, tales como la falta de apoyo en tiempo real. También algunos de los kits SDK tienen problemas debido a la contención de hardware de todos los dispositivos de complemento sobre el uso de los mismos buses. Si necesita un montón de dispositivos que cuelgan de su controlador Me gustaría ver en la plataforma Windows CE en su lugar. La selección actual de hardware para el Micro Framework es muy limitado.

Gran plataforma y para proyectos pequeños que sería genial. Pero cuando intenta entrar en requisitos en tiempo real cerca de usted puede ser que comience a funcionar en baches.

Como tantas otras cosas en esta industria depende. Pero por el hecho de que su puede conseguir un desarrollo kit por menos de $ 100 dólares podría valer la pena comprobar en.

---

I utilizado el Tahoe-II de DeviceSolutions.Net con .Net Framework Micro 2.0 / 3.0 y C#. Enhebrado era muy simple, pero el marco es actualmente muy limitada. Tuve que crear mi propio analizador HTTP y crear webservies REST crudo. Hay un modelo de servicio web Device pero quería HTTP pura. También tuve que crear mis propias capas SNTP y el protocolo SMTP. Una nueva versión (4.0) debe ser comunicado en breve y se puede llenar algunos de estos breves caídas.