Hallo zusammen Ich würde gerne meinem bestehenden Projekt zusätzliche Funktionalitäten durch kleine Scripts geben. Dazu würde ich gerne Lua verwenden. Ich habe folgendes Projekt im Netz gefunden: https://github.com/deemess/uLua Grundsätzlich genau dass, wonach ich gesucht habe. Leider ist es mir nicht ganz klar, wie ich dies nun benutzen soll. Ich möchte das Script auf einer SD-Karte ablegen. Die SD-Karten Anbindung läuft problemlos. Ich kann auf Dateien Zugreifen etc. Nun die frage an euch, wird später die Datei xyz.lua oder die Datei xyz.luc verarbeitet auf dem uC? Kennt jemand das Projekt und kann mir tipps für dessen verwendung geben? Ich möchte dem Benutzer zudem die möglichkeit geben, auf Firmware interne funktionen wie z.b. create_xy zuzugreifen. Danke schonmal
> https://github.com/deemess/uLua >[...] > Leider ist es mir nicht ganz klar, wie ich dies nun benutzen soll. Gar nicht - das ist eine Baustelle, noch nicht fertig. Und nachdem im letzten halben Jahr nichts mehr passiert ist, schätze ich, dass der Autor aufgegeben hat. Ist auch nicht verwunderlich - Lua ist für den typischen Mikrocontroller (ein paar Dutzend KB Flash, ein paar KB RAM) nicht geeignet - frag mal die NodeMCU-Leute ;-)
asdfasd schrieb: > Lua ist für den > typischen Mikrocontroller (ein paar Dutzend KB Flash, ein paar KB RAM) > nicht geeignet - frag mal die NodeMCU-Leute Wobei bei NodeMCU der Compiler mit auf dem µC läuft, das ist schon eine ganze Größenordnung mehr Aufwand. Für den AVR/µLUA ist der Compiler auf den PC ausgelagert, auf dem AVR läuft rein die VM, die vorgekauten Bytecode vorgesetzt kriegt.
Holger K. schrieb: > Nun die frage an euch, wird später die Datei xyz.lua oder die Datei > xyz.luc verarbeitet auf dem uC? Nachtrag, um konstruktiv zu bleiben: Die .luc. Wenn LUA nicht in Stein gemeisselt ist: Forth ist evtl. kleiner und eher µC-Tauglich.
Planlos schrieb: > Wobei bei NodeMCU der Compiler mit auf dem µC läuft, das ist schon > eine ganze Größenordnung mehr Aufwand. Das Problem bei NodeMCU ist das RAM (<30k) während der Laufzeit der Lua-Scripte. Dabei ist fast egal, ob Lua direkt oder als Bytecode ausgeführt wird. > Für den AVR/µLUA ist der Compiler auf den PC ausgelagert, auf dem AVR > läuft rein die VM, die vorgekauten Bytecode vorgesetzt kriegt. Spiel wie gesagt kaum eine Rolle. Die Lua-Tabellen brauchen sehr viel RAM und lassen sich nur massiven Einschränkungen spürbar verkleinern. Wenn der ESP da mit eLua schon massive Probleme hat, würde ich mal vermuten, daß selbst ein 1284p mit seinen 16k RAM mit uLua für nicht viel mehr als ein blink.luc taugt. Aber wozu auch, es gibt des ESP für unter 3 Euro, mit mehr Ports für 5, und Tiva-Boards in ähnlichen Bereichen, alle DEUTLICH leistungsfähiger als ein teurerer 1284p.
> Das Problem bei NodeMCU ist das RAM (<30k) während der Laufzeit der > Lua-Scripte. Dabei ist fast egal, ob Lua direkt oder als Bytecode > ausgeführt wird. Aktuell sind es bei mir 34 KBytes. Trotz HTTP-Server, NTP-Client, I2C ( Temperatur-, Feuchte-, Helligkeits-, Luftdrucksensor) und kleineren Funktionen (ls, cat, etc.) sind noch ca. 14 KBytes frei. Das eigentliche Problem ist nicht LUA* oder die Implementierung. Das Problem ist der ESP8266, der ohne Datenblatt kommt und für den der Hersteller seit einem Jahr Informationen nur häppchenweise herausrückt. Der Bytecode (*.lc) ist Dank eines Strippers für den Quellcode sehr schlank.
> Das eigentliche Problem ist nicht LUA* oder die Implementierung. Nein, das RAM :) Mit ~14k frei* bin ich auch unterwegs, mit einigen Tricks (viele Funktionen in dofile() ausgelagert) läuft auch alles stabil, solange keine Probleme auftreten, z.B. WLAN-Störungen, amoklaufender Browser versucht dutzendfach gleichzeitig favicon.ico zu holen - dann ist es wieder da, das RAM-Problem, und man verbringt schnell mal 90% der Entwicklungszeit mit Workarounds. > Das Problem ist der ESP8266 Der ist eigentlich recht gutmütig, wenn man ihn mit C/C++ bespaßt, was zum Beispiel mit der Arduino-IDE plus ESP8266-Plugin auch ohne jegliches Gefummel und sehr schnell möglich ist. Von kleineren Konfigurations-#ifdefs abgesehen ist das Zeug dann auch sourcekompatibel z.B. mit dem TM4C1294XL plus Energia. Sage ich als Ex-Arduino-Hasser und immer-noch-Lua-Fan .... *mit dem neusten NodeMCU Dev 4k mehr, dafür ist das Connection-Handling kaputt :(
Holger K. schrieb: > Ich würde den code mit einem stm32 mit 64k ram verwenden. Das liegt sogar schon im brauchbaren Bereich für eLua. Das ist "fertiger" und vollständiger als uLua. http://wiki.eluaproject.net/Boards
Vielen Dank für eure Antworten Bei eLua sehe ich hauptsächlich fertige HEX-Files. bzw habe ich das gefühl, das eLua als Standalone gedacht ist. Ich möchte dem Benutzer einfach die möglichkeit geben, von mir in der Firmware geschriebene Funktionen mit einfachsten Mitteln selbst verwenden zu können und ein kleineres Programm zu schreiben. Dabei muss meine Firmware im Hintergrund jedoch weiterhin laufen. Ist eLua für sowas geeignet? Also quasi als Add-On? Meine idee war, dass nach dem Start der Controller auf der SD-Karte zb. nach main.luc sucht und diese wenn gefunden ausführt. Wenn der Benutzer in Lua dann z.B. eine Funktion wie xyz()... aufruft, soll im hintergund in meiner Firmware die Funktion xyz() aufgerufen werden. Is sowas überhaupt machbar mit eLua? Alternativ müsste ich wohl einen eigenen Interpreter schreiben. Das möchte ich jedoch wenns irgendwie geht vermeiden. Denn ich möchte nicht nur funktionen sondern auch schleifen, variablen etc. ermöglichen.
Holger K. schrieb: > Ich möchte dem Benutzer einfach die möglichkeit geben, von mir in der > Firmware geschriebene Funktionen mit einfachsten Mitteln selbst > verwenden zu können und ein kleineres Programm zu schreiben. > > Dabei muss meine Firmware im Hintergrund jedoch weiterhin laufen. > Ist eLua für sowas geeignet? Genau mit der Frage habe ich mich die letzten Tage beschäftigt. Lua an sich ist dafür geeignet. eLua ist wohl wie du schon sagst eher als standlone Lösung auf dem uC gedacht. Den Quelltext kann man runterladen. Im eLua Verzeichnis elua-master\src\lua befindet sich eine nicht mehr ganz aktuelle Lua-version (ich glaube 5.1.4) die mit dem "LTR-Patch" und einigen anderen Änderungen versehen ist. Siehe auch http://www.eluaproject.net/doc/v0.9/en_arch_overview.html. Der LTR-Patch reduziert den Mindest-RAM-Verbrauch von etwa 17K auf etwa 6K. Außerdem sind verschiedene Funktionen zur dynamischen Speicherverwaltung (alloc) hinzugefügt worden und Code der das Crosscompilieren der Lua-Skripte ermöglicht (PC <-> uC). Um eLua sinnvoll nutzen zu können, sollte man angeblich 32-64 KB RAM haben. Holger K. schrieb: > Meine idee war, dass nach dem Start der Controller auf der SD-Karte zb. > nach main.luc sucht und diese wenn gefunden ausführt. So wird das bei eLua gemacht. Holger K. schrieb: > Wenn der Benutzer in Lua dann z.B. eine Funktion wie xyz()... aufruft, > soll im hintergund in meiner Firmware die Funktion xyz() aufgerufen > werden. Das ist die Stärke von Lua an sich. "Lua is a powerful, fast, lightweight, embeddable scripting language." Mit "embeddable" ist gemeint, dass sich Lua in C-Programme einbetten lässt. Um embedded devices geht es primär nicht. Lua erwartet eine dynamische Speicherverwaltung und ein Dateisystem. Das mit dem "fast" (schnell) bezieht sich auf "scripting language". Gegenüber C ist Lua sehr sehr langsam. Jedenfalls ist mir in dem eLua Paket zu viel drin was ich gar nicht haben will, z.B. das Dateisystem. Heute ist es mir gelungen, den regulären Lua-Quellecode (www.lua.org) in meine Firmware zu integrieren. Der Mikrocontroller ist ein STM32F407 und die IDE ist EmBlocks mit gcc-none-eabi. Mit luaL_dostring() kann ich nun kleine Skripte ausführen. Große Skripte habe ich noch nicht getestet. Mir ist auch noch nicht ganz klar warum das so einfach funktioniert. Die notwendigen Funktionen zur Verwaltung des heap memory im RAM, nämlich realloc() und sbrk() sind anscheinend in der <stdlib.h> vom compiler enthalten. Hier hatte ich größere Probleme erwartet. Ansonsten musste ich nur fwrite() von stdout auf die serielle Schnittstelle umbiegen und die lib-math via Linker-Option "-lm" fest einbinden. Hat hier im Forum noch jemand Erfahrung mit "normalem" Lua direkt auf dem Mikrocontroller?
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.