Programa de escritura para el microcontrolador Atmega con C # [cerrado]

Esto no es técnicamente una respuesta válida a la pregunta publicada, pero no está muy lejos.

enlace

No es un ATMega pero admite al menos un chip ARM de la marca Atmel (y también algunos chips STMicro). Utiliza VS2013 y algunos complementos.

No sé nada acerca de esta plataforma, así que no puedo guiarte más. Espero que esto sea lo suficientemente cercano a sus requisitos, pero me doy cuenta de que un ARM es bastante diferente a la familia ATMega.

La documentación de .Net Micro framework puede tener más información sobre cómo transferir a otros chips.

Esta tecnología me llamó la atención hace unos años, pero nunca la investigué, podría tener otra mirada ...

C # requiere .NET. NO se compila directamente en código de ensamblaje o máquina. Se dirige al CLR o uno de sus subconjuntos. La mayoría de los programadores de C # también esperan un nivel mínimo de soporte de biblioteca.

Si escribe una capa .NET por su cuenta (y el código fuente está disponible) o si encuentra a alguien más que ya lo haya hecho, entonces probablemente podría usar C #.

Ya existe C # para algunos usos incrustados, ahora. Sin embargo, no tengo idea de los dispositivos ATmega ni del uso de Atmel Studio. Si estuviera considerando esto, simplemente usaría Visual Studio y terminaría con él.

Recomendaría, al principio, que estudie el .NET Micro Framework 4.1 y el .NET Micro Framework Platform SDK como punto de partida. Por ejemplo, aquí están las vistas generales de Microsoft .NET Framework de Microsoft como una buena página para leer. Entonces probablemente buscaré para ver si alguien ha intentado una implementación que pueda estar lo suficientemente cerca para su interés. No esperaría mucho, dado que pareces enfocado en el ATmega. Probablemente .NET es más fácil de implementar y está mejor orientado a dispositivos integrados más como el ARM7TDMI, ARM9 y quizás el Blackfin de Analog Devices.

Sin embargo, si encuentra algo bueno, puede que no resulte doloroso proporcionar su propia respuesta aquí y avisarnos a todos.

Puedo ver por qué alguien podría estar interesado, proveniente de un fondo de Microsoft VS y acostumbrado a usar máquinas de estaciones de trabajo extremadamente potentes, grandes cantidades de memoria y almacenamiento persistente casi ilimitado para respaldarlo. Los widgets de software extremadamente potentes reducen las tareas complejas a unas pocas operaciones simples. Pero un ATmega no tiene acceso a recursos tan vastos o potencia de CPU sin procesar.

Por ejemplo, .NET permite el uso de archivos de memoria a través de objetos .NET que envuelven un soporte subyacente encontrado en la API de Win32. Eso requiere la funcionalidad subyacente de NT. Los métodos .NET deben pasar de la memoria administrada a los recursos de memoria Win32 no administrados, y las tesis se administran posteriormente en el micro kernel de NT. (Win32 es solo otro envoltorio para él). Los archivos de memoria son realmente buenos para ciertas necesidades. Y con la potencia casi infinita y la memoria infinita para jugar, muchos sienten que el enfoque de .NET es el camino a seguir para mantenerlo "limpio" y "fácil". Por supuesto, pierdes mucho rendimiento en el camino. Pero, ¿quién puede decirlo?

En la ATmega, podrías decirlo.

El manejo de funciones anónimas, lambdas, cierres, vinculación temprana y tardía, reflexión, excepciones, conteo de referencias y recolección de basura, y ... bueno ... estas son cosas maravillosas para tener acceso. Pero también hay un precio. Más que la mayoría estaría dispuesto a pagar con un ATmega que intenta manejar algunos pines para alguna aplicación simple.

No quiere decir que no se puede hacer. No lo he intentado, así que estoy abierto a la idea de que se puede hacer de alguna manera y tal vez incluso lo suficientemente bien con un subconjunto razonado de que la gente podría incluso gustarle y usarlo. Pero parece que me llega mucha sangre, sudor y lágrimas.

Mira a tu alrededor sin embargo. Algún grupo realmente impresionante podría haber llegado allí. Si es así, hágamelo saber!

Por no hablar del tiempo de ejecución .NET, C # tiene características que son prohibitivas para MCU pequeñas como ATmega. Por ejemplo, los tipos primitivos en C # son imprácticamente grandes para los controladores de 8 bits: int es de 32 bits y char es de 16 bits. Además, C # no tiene medios para liberar explícitamente la memoria, confiando completamente en la recolección de basura. La asignación de variables GC internas probablemente llenará la memoria RAM disponible antes de que incluso tenga la oportunidad de colocar una sola variable útil allí.

No hay implementaciones de C # de 8 bits enumeradas en Wikipedia , y dudo seriamente que dichas implementaciones puedan aparecer en el futuro.