Hallo zusammen Ich habe hier eine Hardware mit Display. Gesteuert wird dies von einem STM32 mit 128k Flash und 64k Ram in der Firmware habe ich einige Funktionen implementiert welche es z.B. ermöglichen, einen Button auf dem Display darzustellen oder Text auszugeben etc. Nun möchte ich einem Benutzer die möglichkeit bieten, diese Funktionen mittels eines Scripts zu benutzen. Er sollte die möglichkeit haben, sein Script auf einer SD-Karte abzulegen welches dann ausgeführt wird. Innerhalb des Scripts sollte er die üblichen dinge wie schleifen, variablen, eigene funktionen etc. verwenden können. Zudem sollte er die möglichkeit haben, die Firmware internen Funktionen wie beispielsweise einen Button darzustellen, verwenden zu können. Der Interpreter sollte also Co-Existent zur bestehenden Firmware sein. Ich habe bereits viel Zeit mit google verbracht. Leider habe ich bisher nichts vernünftiges gefunden. Hat jemand von euch eine Idee, womit man dies am besten realisieren kann? Danke schonmal!
Ich glaub für Forth gibt es wohl die einfachsten Interpreter.
Was würde eine solche Skriptsprache in Bezug auf die Verwendung von Standard "C" Code und Firmewareupdate verbessern?? Gegenvorschlag: Sehen Sie mal nach, wie das Uploaden einer neuen Firmware funktioniert. Hierzu finden Sie auf der Homepage weitreichende Informationen. Alternative: Es gibt auch die Möglichkeit JAVA Code auf dem STM32 laufen zu lassen. Ob das für Ihre Zwecke passend ist müssen Sie prüfen.
Wenn es nicht so viele Befehle sind - selber schreiben So ne Art Light-Basic
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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. ...und dann wagt sich so ein mutiger Held an eine derartige Aufgabe. O je. W.S.
Guest schrieb: > Nimm einfach Lua ...hmm, dann kommt wohl der nächste neue Thread --> "wie portiere ich Lua auf STM32" o.ä.
.. und der übernächste --> "wie und wozu kann ich LUA überhaupt benutzen?" mal ganz im Ernst: Ohne ganz intime Kenntnisse darüber, was man denn mittels LUA quasi "anreichern" will und wie man mit LUA überhaupt umgehen kann, ist es völlig zwecklos, LUA runterzuladen. Nix mit copy+paste. W.S.
Es gäbe noch so etwas wir eine SEHR einfache virtuelle Maschine. So etwas wurde damals z.B. beim Kosmos CP1 gemacht. Dazu gibt es auch Nachbauten auf AVR Basis. http://www.g-heinrichs.de/minipc/ http://www.rigert.com/ee-forum/viewtopic.php?t=450 (Weil ich mich damit gerade beschäftige) Ob das hierfür passt..? Peter
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.
:
Bearbeitet durch User
Hallo Ich verstehe nicht worum es in dieser thread geht. Kann mir jemand erklären was ein Inter Peter ist? Dardan
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.
Gibts auch schon für STM32: http://www.st.com/web/en/catalog/tools/FM147/CL1794/SC961/SS1533/PF255416?sc=stm32-java
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.
Es gibt eine Portierung von Lua auf STM32 und andere... Nennt sich eLua: http://www.eluaproject.net/
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.
da ich mich mal mit dem gleichen Thema beschäftigt hatte, das uBasic von AdamDunkels gibt es schon als 32bit Port : XMC1100 : http://www.mikrocontroller.net/articles/UPlay_Basic_Interpreter_per_XMC2Go STM32F429 : http://mikrocontroller.bplaced.net/wordpress/?page_id=4243 beide vom gleichen Autor...kannst ihm ja eine eMail schreiben
Andreas R. schrieb: > Ich glaub für Forth gibt es wohl die einfachsten Interpreter. grins, aber wer kann schon upn
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?
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 :)
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
>Ich verstehe nicht worum es in dieser thread geht. >Kann mir jemand erklären was ein Inter Peter ist? Du meinst sicher den Inder Peter :-)
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.