programming-languages embedded microcontroller interactive

programming languages - ¿Cuáles son los idiomas interactivos disponibles que se ejecutan en la memoria pequeña?



programming-languages embedded (16)

Estoy buscando lenguajes de programación de propósito general que

  • tener un aviso interactivo (codificación en vivo)
  • trabajar en 32 KB de RAM por sí mismo o 8 KB cuando el compilador está alojado en una máquina separada
  • ejecutar en un microcontrolador con tan solo 8-32 KB de RAM en total (sin una MMU).

Debajo está mi lista hasta ahora, ¿qué me estoy perdiendo?

  • Python : PyMite VM necesita 64K de flash, 8K de RAM. Se dirige a LPC, SAM7 y ATmegas con 8K o más. Hospedado
  • Lua : Las http://www.eluaproject.net/ frecuentes de http://www.eluaproject.net/ recomiendan 256K flash, 64K RAM.
  • ADELANTE : de ahora en amforth necesita 8K flash, 150 bytes de RAM, 30 bytes EEPROM en un ATmega.
  • Esquema : Esquema de la axila El objetivo más pequeño es el LPC2103 con 32K Flash, 4K SRAM.
  • C : Interactive C se ejecuta en 68HC11 sin flash y 32K SRAM. Hospedado
  • C : picoc un sistema C interactivo, de compilación cruzada, de fuente abierta. Cuando se compila para AVR, toma 63K de flash, 8K de RAM. La memoria RAM podría reducirse con el esfuerzo de mantener las tablas en flash.
  • C ++ : AngelScript un código abierto, basado en código de bytes, C / C ++ como el lenguaje de scripting con llamadas nativas sencillas.
  • Tcl : TinyTCL ejecuta en DOS, 60K binario. Parece fácil de portar.
  • BÁSICO : TinyBasic : Inicializa con un montón de 64K, puede ser ajustable.
  • Ceceo
  • PostScript : (Todavía no he encontrado una implementación de FOSS para poca memoria)
  • Shell : bitlash : un shell de comando interactivo para Arduino (ATmega). Ver también AVRSH .

¿Has considerado un puerto en C de Tiny Basic ? O, ¿quizás reescribiendo la p-machine UCSD Pascal a su arquitectura desde Z-80?

En serio, sin embargo, JavaScript sería un buen lenguaje de scripts incorporado, pero no tengo idea de cuáles son los requisitos mínimos de memoria para VM + GC, ni cuán difícil es eliminar las dependencias del sistema operativo. NJS con NJS un tiempo, lo que posiblemente podría satisfacer tus necesidades. Este es interesante porque el compilador está escrito en JavaScript (self hosting).

Escuché que CHIP-8, XPL0, PicoC y Objective Caml han sido portados a calculadoras gráficas. El artículo de Wikipedia "Lego Mindstorms" enumera una serie de lenguajes de programación que supuestamente se ejecutan en la plataforma Lego RCX o Lego NXT. ¿Alguno de ellos cumple con su criterio de "codificación en vivo"?

Es posible que desee comprobar el otro microcontrolador Forths en la wiki de Forth. Enumera al menos 4 adelante para el Atmel AVR: en adelante (que ya mencionas), PFAVR, avrforth y ByteForth.
(Los enlaces a esos intérpretes, así como a esta pregunta de , se incluyen en el wikibook de " Embedded Systems ").

He estado usando en mi trabajo anterior busybox en un BlackFin.

compilamos perl + php para él, después de cambiar s / fork / vfork / g funcionó bastante bien ... más o menos. No tener una MMU no es una buena idea. La fragmentación de la memoria matará al servidor con bastante facilidad. Todo lo que hice fue:

for i in `seq 1 100`; do wget http://black-fin-ip/test.php; done

Murió mientras caminaba hacia mi jefe y le dije que el servidor iba a morir en producción :)

Prolog - http://www.gprolog.org/

De acuerdo con una búsqueda en google "prólogo pequeño", el tamaño del ejecutable puede reducirse bastante al evitar enlazar los predicados incorporados.

Puede echar un vistazo a AvrCo Multitasking Pascal muy potente para AVR. Puedes intentarlo en http://www.e-lab.de . La versión MEGA8 / 88 es gratis. Hay toneladas de controladores y simulador con depurador JTAG y agradables visualizaciones en vivo o simuladas de todos los dispositivos estándar (LCDCHAR, LCDGRAPH, 7SEG, 14SEG, LEDDOT, KEYBOARD, RC5, SERVO, STEPPER ...).

Recomendaría MY-BASIC , se ejecuta con un mínimo de 8 KB de RAM y es fácil de portar.

Sugeriría usar Python. Pero ahora el único problema es la sobrecarga de memoria ¿no? Así que tengo una gran idea para las personas que pueden estar atrapadas en este problema más adelante.

Lo primero es lo primero, escribir un intérprete de bf (o simplemente obtener el código fuente de algún lugar). El intérprete será realmente pequeño. También bf es un lenguaje completo de Turing. Ahora necesita escribir su código en python y luego transpilerlo a bf usando bfpy ( https://github.com/felko/bfpy/blob/master/README.md ). Te he dado la solución con la menor sobrecarga y estoy bastante seguro de que un intérprete de bf se mantendrá fácilmente por debajo de 10 KB de uso de ram.

También hay JavaScript, a través de Espruino .

Esto está diseñado específicamente para microcontroladores y hay compilaciones para varios chips diferentes (principalmente STM32) que se ajustan a un sistema completo en tan solo 8kB de RAM.

Te estás perdiendo EmbedVM, página de inicio here , svn repo here . Recuerde revisar ambos videos [ 1 , 2 ] en la página principal;)

Desde la página de inicio:

EmbedVM es una pequeña máquina virtual incrustable para microcontroladores con un frontend de lenguaje tipo C. Ha sido probado con microcontroladores GCC y AVR. Pero como la máquina virtual es bastante simple, debería ser fácil trasladarla a otras arquitecturas.

La VM simula una CPU de 16 bits que puede acceder a hasta 64 kB de memoria. Solo puede operar con valores de 16 bits y matrices de valores de 16 y 8 bits. No hay soporte para estructuras de datos complejas (estructura, objetos, etc.). Una función puede tener un máximo de 32 variables locales y 32 argumentos.

Además de la memoria para la máquina virtual, una pequeña estructura que contiene el estado de la máquina virtual y la cantidad razonable de memoria que necesitan las funciones EmbedVM en la pila, no hay requisitos de memoria adicionales para la máquina virtual. Especialmente, la VM no depende de ninguna gestión de memoria dinámica.

EmbedVM está optimizado para el tamaño y la simplicidad, no para la velocidad de ejecución. La VM ocupa aproximadamente 3kB de memoria de programa en un microcontrolador AVR. En un AVR ATmega168 corriendo a 16MHz, la VM puede ejecutar alrededor de 75 instrucciones de VM por milisegundo.

Todos los accesos de memoria realizados por la VM se modifican utilizando funciones de devolución de llamada del usuario. Por lo tanto, es posible tener una parte o la totalidad de la memoria de VM en dispositivos de memoria externos, memoria flash, etc. o funciones de hardware "memory-map" en la VM.

El compilador es una herramienta de línea de comandos de UNIX / Linux que lee en un archivo * .evm y genera bytecode en varios formatos (archivo binario, intel hex, inicializadores de matriz C y un formato especial de salida de depuración). También genera un archivo de símbolos que se puede usar para acceder a datos en la memoria de VM desde la aplicación de host.

El lenguaje similar a C se ve así: http://svn.clifford.at/embedvm/trunk/examples/numberquizz/vmcode.evm

Un home run Forth tiempo de ejecución se puede implementar en muy poca memoria de hecho. Conozco a alguien que hizo uno en un Cosmac en la década de 1970. El tiempo de ejecución del núcleo era de solo 30 bytes.

Yo recomendaría LUA (o eLUA http://www.eluaproject.net/ ). He "portado" LUA a un Cortex-M3 hace un tiempo. Desde lo alto de mi cabeza tenía un tamaño de flash de 60 ~ 100KB y necesitaba alrededor de 20KB de RAM para ejecutar. Me deshice de lo esencial, pero dependiendo de su aplicación, eso podría ser suficiente. Todavía hay espacio para la optimización, especialmente sobre los requisitos de RAM, pero dudo que pueda ejecutarlo cómodamente en 8 KB.

Wren ajusta a tus criterios: de manera predeterminada está configurado para usar solo 4k de RAM. AFAIK no ha visto ningún uso real, ya que el chico para el que lo escribí decidió que no necesitaba un intérprete ejecutándose por completo en el sistema de destino después de todo.

El lenguaje está influenciado más obviamente por ML y Forth.