Quelles sont les langues interactives disponibles qui fonctionnent dans une mémoire minuscule?
Je cherche des langages de programmation à usage général qui
- avoir une invite interactive (codage en direct)
- travailler dans 32 Ko de RAM par lui-même ou 8 Ko lorsque le compilateur est hébergé sur une machine séparée
- exécuter sur un microcontrôleur avec aussi peu que 8-32 Ko RAM au total (sans une MMU).
Ci-dessous, ma liste à ce jour, que me manque-t-il?
- Python: Le PyMite VM nécessite 64 Ko de mémoire flash, 8K de RAM. Cible LPC, SAM7 et ATmegas avec 8K ou plus. Hébergé.
- Lua: Le eLua FAQ recommande une mémoire flash de 256 Ko et 64 Ko de RAM.
- À VENIR: amforth nécessite 8K de mémoire flash, 150 octets de RAM, 30 octets d'EEPROM sur un ATmega.
- Scheme: aisselle Scheme La plus petite cible est le LPC2103 avec 32K Flash, 4K SRAM.
- C: Interactive C fonctionne sur 68HC11 sans mémoire flash ni mémoire SRAM 32K. Hébergé.
- C: picoc un système C open source, à compilation croisée, interactif. Une fois compilé pour AVR, cela prend 63K flash, 8K RAM. La RAM pourrait être réduite en essayant de garder les tableaux en flash.
- C++: AngelScript est un langage de script de type C/C++ à code source libre, basé sur des octets, avec des appels natifs simples.
- Tcl: TinyTCL fonctionne sous DOS, en binaire 60K. Semble facile à mettre en communication.
- BASIC: TinyBasic : Initialise avec un segment de mémoire de 64 Ko, peut être ajustable.
- LISP
- PostScript: (Je n'ai pas encore trouvé d'implémentation FOSS pour peu de mémoire)
- Shell: bitlash : Un shell de commande interactif pour Arduino (ATmega). Voir aussi AVRSH .
Un runtime homebrew Forth peut être implémenté avec très peu de mémoire. Je connais quelqu'un qui en a fabriqué un sur un Cosmac dans les années 1970. Le noyau d'exécution était juste 30 octets.
J'entends dire que CHIP-8, XPL0, PicoC et Objective Caml ont été portés sur des calculatrices graphiques… .. L’article Wikipedia «Lego Mindstorms» répertorie un ensemble de langages de programmation qui fonctionneraient prétendument sur la plateforme Lego RCX ou Lego NXT Certains d’entre eux répondent-ils à vos critères de "codage en direct"?
Vous voudrez peut-être consulter l’autre Forths sur le microcontrôleur sur le wiki Forth. Il répertorie au moins 4 Forth pour l'Atmel AVR: amforth (que vous avez déjà mentionné), PFAVR, avrforth et ByteForth.
(Des liens vers ces interprètes, ainsi que cette question de StackOverflow, sont inclus dans le wikibook " Systèmes intégrés ").
Je recommanderais LUA (ou eLUA http://www.eluaproject.net/ ). J'ai "porté" LUA sur un Cortex-M3 il y a quelque temps. Du haut de ma tête, il avait une taille de flash de 60 ~ 100 Ko et nécessitait environ 20 Ko RAM pour fonctionner. Je me suis concentré sur l'essentiel, mais selon votre candidature, cela pourrait suffire. Il y a encore de la place pour l'optimisation, en particulier sur les exigences de RAM, mais je doute que vous puissiez l'exécuter à l'aise dans 8 Ko.
Wren correspond à vos critères - par défaut, il est configuré pour utiliser seulement 4 ko de RAM. Autant que je sache, il n’a pas été utilisé, puisque le gars pour qui je l’ai écrit a décidé qu’il n’avait pas besoin d’un interprète fonctionnant entièrement sur le système cible.
La langue est influencée le plus évidemment par ML et Forth.
Quelques interprètes/VMs AVR:
- http://www.cqham.ru/tbcgroup/index_eng.htm
- http://www.jcwolfram.de/projekte/avr/chipbasic2/main.php
- http://www.jcwolfram.de/projekte/avr/chipbasic8/main.php
- http://www.jcwolfram.de/projekte/avr/main.php
- http://code.google.com/p/python-on-a-chip/
- http://www.avrfreaks.net/index.php?module=Freaks%20Academy&func=viewItem&item_id=688&item_type=project
- http://www.avrfreaks.net/index.php?module=Freaks%20Academy&func=viewItem&item_id=626&item_type=project
- http://www.avrfreaks.net/index.php?module=Freaks%20Academy&func=viewItem&item_id=460&item_type=project
- http://www.harbaum.org/till/nanovm/index.shtml
Vous pouvez jeter un coup d'œil au très puissant AvrCo Multitasking Pascal for AVR. Vous pouvez l'essayer sur http://www.e-lab.de . La version MEGA8/88 est gratuite. Il existe une multitude de pilotes et de simulateurs avec le débogueur JTAG et des visualisations sympas en direct ou simulées de tous les appareils standard (LCDCHAR, LCDGRAPH, 7SEG, 14SEG, LEDDOT, KEYBOARD, RC5, SERVO, STEPPER ...).
Avez-vous envisagé un port en C de Tiny Basic ? Ou peut-être réécrivez-vous le UCSD Pascal p-machine sur votre architecture à partir de Z-80?
Sérieusement, JavaScript constituerait un bon langage de script intégré, mais je n’ai aucune idée de la mémoire minimum requise pour la VM + GC, ni de la difficulté à supprimer les dépendances du système d’exploitation. J'ai joué avec NJS il y a quelque temps, ce qui pourrait éventuellement répondre à vos besoins. Celui-ci est intéressant en ce que le compilateur est écrit en JavaScript (hébergement autonome).
Il y a aussi JavaScript, via Espruino .
Ceci est spécialement conçu pour les microcontrôleurs et il existe des versions pour différentes puces (principalement des STM32) qui s'adaptent à un système complet avec une mémoire RAM de 8 Ko seulement.
EmbedVM, homepage ici , svn repo ici . N'oubliez pas de regarder les deux vidéos [ 1 , 2 ] en première page;)
De la page d'accueil:
EmbedVM est une petite machine virtuelle intégrable pour les microcontrôleurs avec une interface en langage C-like. Il a été testé avec GCC et AVR microcontrôleurs. Mais comme la machine virtuelle est assez simple, il devrait être facile à porter sur d'autres architectures.
Le VM simule un processeur 16 bits pouvant accéder à 64 Ko de mémoire. Il ne peut fonctionner que sur des valeurs 16 bits et des tableaux de valeurs 16 bits et 8 bits . Il n'y a pas de support pour les structures de données complexes (struct, objets, Etc.). Une fonction peut avoir un maximum de 32 variables locales et 32 arguments.
Outre la mémoire de la machine virtuelle, une petite structure contenant l’état VM et la quantité de mémoire raisonnable dont les fonctions EmbedVM ont besoin sur le pile, il n’ya pas de mémoire supplémentaire requise pour la machine virtuelle . En particulier, le VM ne dépend d'aucune gestion de mémoire dynamique.
EmbedVM est optimisé pour la taille et la simplicité, pas pour la vitesse d'exécution. Le VM occupe environ 3 Ko de mémoire programme sur un AVR microcontrôleur. Sur un AVR ATmega168 fonctionnant à 16 MHz, le VM can exécuter environ 75 VM - instructions par milliseconde.
Tous les accès à la mémoire effectués par VM sont parformés à l'aide du rappel utilisateur les fonctions. Il est donc possible d’avoir tout ou partie de la mémoire VM sur dispositifs de mémoire externe, mémoire flash, etc. ou matériel "memory-map" fonctions à la VM.
Le compilateur est un outil de ligne de commande UNIX/Linux qui lit dans un fichier * .evm file et génère du bytecode dans différents formats (fichier binaire, intel hex, initialiseurs de tableaux C et un format de sortie de débogage spécial). Ça aussi génère un fichier de symboles pouvant être utilisé pour accéder aux données de la VM mémoire de l'application hôte.
Le langage C ressemble à ceci: http://svn.clifford.at/embedvm/trunk/examples/numberquizz/vmcode.evm
Je recommande MY-BASIC , fonctionne avec au moins 8 Ko de RAM et est facile à porter.
Prolog - http://www.gprolog.org/
Selon une recherche google "prolog small", la taille de l'exécutable peut être réduite en évitant de lier les prédicats intégrés.
Je suggérerais d'utiliser python. Mais maintenant, le seul problème est la surcharge de mémoire, non? J'ai donc une excellente idée pour les personnes qui pourraient être bloquées plus tard dans ce problème.
Commencez par écrire un interpréteur bf (ou obtenez simplement le code source de quelque part). L'interprète sera vraiment petit. Aussi bf est un langage complet de Turing. Vous devez maintenant écrire votre code en python, puis le transpiler en bf à l'aide de bfpy ( https://github.com/felko/bfpy/blob/master/README.md ). Je vous ai donné la solution avec le moins de frais généraux et je suis à peu près sûr qu'un interprète bf conservera facilement moins de 10 Ko de mémoire vive.
Aucune des langues de la liste dans la question ou dans les réponses ne s'est avérée satisfaisante pour l'exigence de compilation et d'intégration ultra-facile dans un projet de micro-contrôleur existant (divulgation: je n'ai pas réellement essayé chacune des suggestions).
J'ai trouvé à la place tinyscript qui correspond à un seul fichier .c + .h compilé avec le reste des fichiers source de mon projet avec la seule configuration supplémentaire requise pour fournir une fonction void outchar(int c) qui peut être vide si vous n'avez pas besoin de sortie. à partir des scripts.
Pour moi, la rapidité d'exécution est beaucoup moins importante que la facilité de construction, d'intégration et d'interopérabilité avec C, car mon cas d'utilisation consiste principalement à appeler certaines fonctions C dans l'ordre.
Avez-vous envisagé d'utiliser simplement le /bin/sh fourni par busybox ? Ou sur l'un des plus petits langages de script qu'ils recommandent?
J'utilisais dans mon travail précédent busybox sur un BlackFin.
nous avons compilé Perl + php pour cela, après avoir changé s/fork/vfork/g cela fonctionnait plutôt bien ... plus ou moins Ne pas avoir un MMU n'est pas une bonne idée. La fragmentation de la mémoire va tuer le serveur assez facilement. Tout ce que j'ai fait était:
for i in `seq 1 100`; do wget http://black-fin-ip/test.php; done
Il est mort pendant que je marchais vers mon patron et que je lui disais que le serveur allait mourir en production :)