Interpeter für einfache Programme gesucht

Ich glaub für Forth gibt es wohl die einfachsten Interpreter.

Wenn es nicht so viele Befehle sind - selber schreiben
So ne Art Light-Basic

Hallo,

wir haben für einige unserer Produkte eine pForth-basierte 
Laufzeitumgebung in einen STM32 eingebaut. Hinzu kommt dann noch ein 
passendes "Dateisystem" für Flash-Speicher, um das Speichern und Laden 
von Skripten zu ermöglichen. Bis das ganze dann ordentlich lief, war 
noch einiges an Arbeit erforderlich. Entscheidend ist dabei, eine 
sinnvolle Aufteilung zwischen Laufzeitumgebung, Forth Dictionary und 
Anwendungsskript vorzunehmen.

Für die Erzeugung des Forth-Codes haben wir einen Codegenerator 
entwickelt, der die mit Hilfe eines GUIs definierten Konfigurationsdaten 
umsetzt.

Schau Dir mal LUA an. Hat den Ruf extrem schlank zu sein.
Z.B. gibt es LUA fuer den ESP8266 - der ziemlich klein ist.

Ich selber schrieb:
> Was würde eine solche Skriptsprache in Bezug auf die Verwendung von
> Standard "C" Code  und Firmewareupdate verbessern??

Man kann verhindern, dass Speicherzugriffe außerhalb des für Skripte 
zulässigen Bereichs erfolgen. Es ist auch möglich, eine Laufzeit- und 
Stackkontrolle zu realisieren.

Winne Z. schrieb:
> So ne Art Light-Basic

...wie das z.B.: https://www.mikrocontroller.net/articles/AVR_BASIC

Grüße Uwe

Ich habe uJ (Java) gefunden

http://dmitry.gr/index.php?r=05.Projects&proj=12.%20uJ%20-%20a%20micro%20JVM

Scheint auf den ersten Blick genau richtig zu sein.
Doch wie verwendet man dies?

Hat das schonmal jemand benutzt?

Holger K. schrieb:
> Ich habe uJ (Java) gefunden
>
> http://dmitry.gr/index.php?r=05.Projects&proj=12.%20uJ%20-%20a%20micro%20JVM
>
> Scheint auf den ersten Blick genau richtig zu sein.
> Doch wie verwendet man dies?

Gar nicht.
Du brauchst einen Java Compiler dafür, den du nicht hast.

Das ist nur die Runtime. Also quasi die gedachte Maschine, die 
compilierte Java Programme ausführt.

Entweder du investiert ein bischen in Compilerbau (so schwer ist das 
auch wieder nicht einen Interpreter nach den Regeln der Kunst zu machen, 
wenn man nicht auf jedes Byte achten muss) oder du suchst dir zb einen 
Basic-Interpreter der zb in C geschrieben ist und den du modifizieren 
kannst.

Wenn du in Richtung Compilerbau gehen willst (keine Angst, du baust 
keinen kompletten Compiler, sondern benutzt davon nur einen Teil), dann 
gibt es vom Nikolaus Wirth ein kleines Büchlein über Compilerbau und 
welche Techniken man da verwendet. Nur das wichtigste und so viel, dass 
man fundiert an die Sache rangehen kann. Das lohnt sich auch insofern, 
als man dann plötzlich viele Dinge in seiner eigenen Leib und Magen 
Programmiersprache besser versteht, wenn man die Hintergründe kennt. 
Oder zb am eigenen Leib erfährt das die Generierung von aussagekräftigen 
Fehlermeldungen eigentlich ziemlich schwierig ist und warum und wie es 
da manchmal zu völligen Rohrkrepierern kommt.

Edit:
Man kann dafür zb auch recht effizient Compilerbau Tools einsetzen, die 
den ganzen stupiden Teil der Grammatik Implementierung übernehmen. 
Persönlich mag ich LEX/YACC nicht so gerne, weil ich es schwierig finde 
mit den beiden zu debuggen, mein Favorit ist nach wie vor COCO/R, der 
einen rekursiven Abstieg erzeugt, den ich wesentlich einfacher debuggen 
kann (auch wenn ein rekursiver Abstieg nicht so universell und wohl auch 
ein wenig langsamer ist). Auch weil COCO/R an meiner Alma Mater 
entstanden ist :-)
Wenn man da ein wenig Übung hat, dann kann man einfache Interpreter in 1 
bis 2 Tagen aus dem Boden stampfen (hab ich schon gemacht). Aber wie 
immer gilt natürlich: man muss wissen was man tut und eine gewisses 
Hintergrundwissen haben.

Vielen Dank für deine Ausfühliche Antwort.

Ich werde mir dein empfohlenes Büchlein beschaffen und mich mal 
einlesen.
Ob ich es dann brauche oder nicht ist was anderes.
Aber Verloren ist die Zeit bestimmt nicht!

Ich habe mich nun für uBasic entschieden.
Leider konnte ich die Sourcen nicht compilieren.

Ich habe dazu einen neuen Thread eröffnet.

Holger K. schrieb:

> Ich habe mich nun für uBasic entschieden.
> Leider konnte ich die Sourcen nicht compilieren.

compilieren konntest du sie schon.
Du konntest sie nicht linken

Das ist ein kleiner Unterschied!

Im übrigen:
Du willst doch das Teil sowieso in die Firmware integrieren. Darf ich 
einen Vorschlag machen: Compilier und linke das Teil erst mal auf einem 
PC und bring es dort zum laufen. Dann studierst du den Code. Wie er 
arbeitet, wie er funktioniert. Und dann überlegst du, wie du diesen 
Codebaustein in deine vorhandene Firmware integrieren kannst.

Das ist eine Technik, die bei mir eigentlich immer gut funktioniert hat. 
Erst mal einen Überblick bekommen, was man sich da runtergeladen hat. 
Dazu reicht es, erst mal auf dem PC das ganze zum Laufen zu kriegen. 
Wenn man sich dann ein wenig sicherer ist, wie und was man sich da 
eigentlich geholt hat, dann hat man auch einen viel besseren Überblick, 
welche Optionen man hat um das Teil dann in die Produktion zu 
übernehmen.


NB: schöner kleiner Interpreter, den du da hast. So richtig gut 
geeignet, um in die Technik des rekursiven Abstiegs einzusteigen.
Wenn du den auf Source Code Ebene komplett verstehst, dann hast du schon 
viel gewonnen. Aber erst mal musst du ihn verstehen. Und das geht auf 
einem PC genausogut (wenn nicht sogar besser) als auf einem STM. 
Verstehen musst du ihn aber, wenn du ihn erweitern willst. Womit wir 
wieder beim Compilerbau und den Grundlagen formaler Sprachen angelangt 
sind. Informatik ist eben ein Teufelskreis, bei dem die Dinge 
miteinander vernetzt sind und immer wieder auftauchen.

Hallo

Ich verstehe nicht worum es in dieser thread geht.
Kann mir jemand erklären was ein Inter Peter ist?

Dardan

Inter p r eter

schau doch mal bei wiki

Stefan U. schrieb:
> Ich schätze, den kann man relativ einfach auf STM32 portieren.

Das habe ich bereits versucht.
Leider klappte dies nicht wirklich gut.

Stefan U. schrieb:
> Gibts auch schon für STM32:
> 
http://www.st.com/web/en/catalog/tools/FM147/CL1794/SC961/SS1533/PF255416?sc=stm32-java

Danke für den Link. Leider bekomme ich nur eine leere Seite.
Auch durch ergurgeln des Links, nur eine leere Seite.

Stefan U. schrieb:
> Es gibt einen Java Interpreter für AVR Mikrocontroller.
>
> Um Missverständnissen vorzubeugen: Er interpretert Java Bytecode, also
> *.class Dateien. Nicht die Quelltexte *.java.
>
> http://www.harbaum.org/till/nanovm/index.shtml
>
> Ich schätze, den kann man relativ einfach auf STM32 portieren.

Beitrag "NanoVM auf den STM32 Portieren"

Ich bin mir da nicht sicher, was angepasst werden muss.
Zudem fragt er immer nach einer config.h welche nirgends im verzeichnis 
zu finden ist.

Luis Lua schrieb:
> Es gibt eine Portierung von Lua auf STM32 und andere...
> Nennt sich eLua:
>
> http://www.eluaproject.net/

Danke für den Hinweis

Ich kenne dieses Projekt. Leider ist dieses nicht wirklich leicht zu 
integrieren und sprengt wohl den Rahmen des benötigten.

Eine Java NanoVM wäre das eleganteste.
Die nanoVM gefällt mir eigentlich sehr gut.

Andreas R. schrieb:
> Ich glaub für Forth gibt es wohl die einfachsten Interpreter.

grins, aber wer kann schon upn

Jay schrieb:
> Stephan G. schrieb:
>> Andreas R. schrieb:
>>> Ich glaub für Forth gibt es wohl die einfachsten Interpreter.
>>
>> grins, aber wer kann schon upn
>
> Gegenfrage: Welcher echte Embedded-Programmierer kann es nicht?

es wird ja nur in forth benötigt, ansonsten könne es ja noch einige 
taschenrechner :)

http://ficl.sourceforge.net/

MoinMoin,

Holger K. schrieb:
> Ich kenne dieses Projekt. Leider ist dieses nicht wirklich leicht zu
> integrieren und sprengt wohl den Rahmen des benötigten.

...also irgendwie werde ich das Gefühl nicht los, dass du eine 
Komplettlösung suchst, bei der du nichts mehr machen musst... Aber die 
wirst du nicht finden!

Dir ist schon bewusst, dass alle hier genannten Lösungen nur von 
allgemeiner Natur sind und du sie auf deine Belange anpassen musst. 
Einfach mal runterladen, übersetzen und funktioniert, ist nicht! Keines 
der hier genannten Beispiele kennt deine Programmierumgebung, deine 
Hardware, deine bisherige Programmstruktur etc.. Aber genau diese Dinge 
musst du anpassen! Und dabei ist es eine Grundvoraussetzung, dass du in 
Lage bist mit deiner Programmierumgebung umzugehen und das jeweilige 
Quelltextpaket an deine Belange anpassen kannst.

Es ist völlige egal, ob du nun NanoVM, Forth, Dunkels uBasic bzw. eines 
der erwähnten uBasic-Derivate, Lua oder sonst irgendwas verwenden 
möchtest. Das ist alles nur ein Ausgangspunkt, ab dem du dann deine ganz 
speziellen Dinge einbauen musst.

Nebenbei, ich würde mein uBasic-Derivat (siehe oben) benutzen, bin ja 
auch dessen Autor und habe es genau für solche Anwendungsfälle 
geschrieben :-). Vor allem habe ich dort ein paar Mechanismen 
implementiert, mit denen man relativ einfach auf bestehende Variablen 
und Funktionen der umgebenden Firmware zugreifen kann (...man will ja 
das Rad nicht zweimal erfinden). Aber dazu muss man schon etwas in den 
Quelltext abtauchen, um zu verstehen wie das funktioniert und an seine 
Belange anpassen kann... Und ja, das Ding ist mal für AVR-MCUs 
geschrieben worden, aber mit ein paar kleineren Anpassungen sollte es 
auch auf anderer Hardware laufen. Ein Großteil der Entwicklungen habe 
ich gar nicht auf einer solchen MCU ausgetestet, sondern als "nativen" 
Interpreter auf einer Linux-Kiste, die überhaupt nicht mit der 
angedachten Zielplattform vergleichbar ist...

Grüße Uwe

Vielen Dank euch allen und auch besonder dem Uwe für die ausführlichen 
Beiträge.

Ich konnte nun das uBasic übersetzen und es läuft wie angedacht auf dem 
STM.

Das Problem war die exit(1) funktion, welche zu einer undefined 
reference _fini in fini.c geführt hatte.

Nach dem auskommentieren von exit(1) läuft es nun.


Jetzt wäre es noch schön, einen angenehmen basic editor zu haben.
Kann Eclipse mit BASIC umgehen bzw. gibt es ein Plugin oder ähnliches um 
das Codehighlighting zu machen?

Danke schonmal