¿Alguien tiene algunas ideas geniales para el uso de un lenguaje de secuencias de comandos en un sistema integrado? Estoy pensando en el proyecto eLua específicamente.
Básicamente, necesita un micro con al menos 64k de RAM, 256k de Flash, la biblioteca Newlib C y un compilador gcc (AVR32, ARM7, Cortex-M3 son compatibles en este momento, entre otros), y puede enviarlo ( o programarlo para cargar) scripts. No necesita un sistema operativo, pero le permite usar su micro (que es demasiado pequeño para Linux incorporado) mucho más como un dispositivo informático de propósito general, al permitir que se ejecuten programas que no están flasheados en la memoria del programa.
El proyecto actual tiene varias aplicaciones de ejemplo, pero ninguna de ellas parece hacer nada que no puedas hacer con un programa grabado en Flash. La gran diferencia que puedo ver es que puede enviar cada programa por separado y ejecutar diferentes programas sin reiniciar. Además, puede usarlo de forma interactiva (cambie el flujo de su programa con sus decisiones en el teclado, en lugar de tener que codificar todo).
¿Cómo usarías un dispositivo así? ¿Le daría un teclado y una pantalla LCD de caracteres y escribiría sus propios guiones mientras está en su escritorio? ¿Utilizaría simplemente el lenguaje de secuencias de comandos para simplificar la programación de aplicaciones más complejas? (¿Como los juegos disponibles actualmente en el sitio del proyecto?) ¿O harías algo completamente diferente? Estoy comenzando con esto y buscando ideas para proyectos.
Editar : puede enviar programas a través de cualquier protocolo que desee usar (UART, SPI/I2C, etc., USB, Ethernet), cargarlos desde una tarjeta SD, sea lo que sea que admita su chip. Solo quería aclarar que no tenía que estar en un entorno amigable para la reprogramación.
Edit2 : la mayoría de mis proyectos son para mi uso personal o para compartir con amigos de ideas afines, no a menudo para la venta al público en general. Espero que los usuarios de mis proyectos estén interesados y familiarizados con los sistemas integrados, y que sean capaces de captar el uso rudimentario de un lenguaje de secuencias de comandos sin demasiados problemas. Podría usarlos en la casa o en el automóvil, o más probablemente en el taller como ayuda para diseñar y depurar más proyectos nuevos. También podría proponérselo a mi jefe en el trabajo, donde fabricamos y diseñamos sistemas integrados. O podría usarlo en un proyecto de ingeniería para la escuela.
Estoy planeando incrustar un lenguaje de secuencias de comandos en mi pequeño dispositivo mamá-encuéntrame (finalmente progresando de nuevo, espero tener un prototipo funcional para la Detroit Maker Faire el próximo mes).
Es una pequeña plataforma con GPS, brújula, tarjeta SD y zigbee que está destinada a ayudarme a realizar un seguimiento de mis hijos más pequeños en los parques grandes y brindarles una forma de encontrarme fácilmente cuando me necesiten.
El lenguaje de secuencias de comandos incorporado proporcionará un espacio aislado protegido donde las aplicaciones simples, como juegos, mapas, programas de geocaching o juegos multijugador (varios niños, cada uno con una unidad, pueden jugar versiones mejoradas de capturar la bandera, esconderse y buscar, etiquetar, etc.) sin afectar la función base de poder rastrear a mis hijos. Estos irían en la tarjeta SD como archivos de texto para que puedan editarse y actualizarse fácilmente sin hardware o software especial.
Hay muchas otras formas y razones para usar un lenguaje de secuencias de comandos en sistemas integrados, pero para ver cómo o por qué podría adaptarse a sus necesidades, tendríamos que comprender más acerca de su sistema en particular.
Investigué eLua y también un intérprete de python incorporado para algunos proyectos en los que estoy trabajando en mi trabajo diario. Estamos desarrollando un sistema de control base, pero estos sistemas salen y se personalizan ampliamente en el campo. En lugar de requerir que el usuario final agregue módulos de procesamiento adicionales, les permitimos configurar nuestro sistema y, en algunos casos, escribir sus propias funciones. Dado que es prohibitivo que los usuarios finales vuelvan a flashear en el campo (podrían bloquear fácilmente las cosas), proporcionamos una interfaz de secuencias de comandos.
Actualmente, tenemos un lenguaje propietario que se compila en un código de bytes y el kernel lo procesa en orden, pero estamos tratando de hacer que las cosas cumplan con los estándares y sean más fáciles de mantener.
Aquí hay una comparación de diferentes lenguajes interpretados que pueden ejecutarse en 'bare metal': https://stackoverflow.com/questions/1082751/what-are-the-disponible-interactive-languages-that-run-in-tiny-memory
Generalmente, una vez que el dispositivo ha sido flasheado una vez en la fábrica, no queremos tener que volver a flashear. Es lento, propenso a errores y difícil para los usuarios finales. Para extender la funcionalidad después de la producción, algún tipo de extensión de secuencias de comandos es una buena solución.
Consulte http://en.wikibooks.org/wiki/Atmel_AVR#Firmware_Programming
Enumera muchos lenguajes de secuencias de comandos diferentes para Atmel AVR, incluida una llamada de Python mínima PyMite http://wiki.python.org/moin/PyMite y http://code.google.com/p/python-on-a-chip/
Algunos proyectos e ideas con eLua se mantienen en el wiki de eLua User Labs en http://wiki.eluaproject.net v0.8 saldrá del horno en algún momento de este mes (enero de 2011).
Rick_2047