Wie bekannt, dann ein AVR (und viele andere 8Bitter in Harvard Architektur) keinen Code aus dem int. SRAM ausführen. Immer wenn man ein zusätzliches Speichermedium angeschlossen hat, wie z.B. eine SD-Karte mit Unmengen Speicher, ärgert mich das. Außerdem fände ich es praktisch, wenn ich dem Kunden sagen könnte: "Für ein Firmware Upgrade oder Feature bla und muh laden sie die Datei foo.bin von der Webseite und speichern sie sie auf die SD-Karte" Gut, ich weiß, dass man das mit einem Bootloader machen könnte. Ich überlege aber, ob ich nicht eine kleine virtual machine schreibe, um so etwas zu ermöglichen. Bei könnte der "RAM" und "ROM" zugriff auch gleich komplett abstrahiert sein, sodass man ein Programm z.B. direkt von der SD-Karte ausführen kann. Ich denke da nicht an eine "Komplettlösung" wie NanoVM, die eine Menge Programmspeicher braucht sondern quasi als Plugin-Schnittstelle. (Ich hab auch schon mal eine VM für was anderes geschrieben, das ist also nicht das Problem. Der Assembler dafür schon eher, ein richtiger Compiler wäre natürlich super, der Aufwand explodiert aber.) Was denkt ihr so dazu? Bzw. welche Features (im Sinn von Instruktionen, Registern) würdet ihr begrüßen?
Da sich das ganze ja sinnvollerweise mit einem Compiler vertragen sollte, und du wohl keine Lust hast einen selber zu schreiben, liegt es nahe, eine Architektur zu emulieren, für es einen Compiler in gewünschter Qualität und Preislage schon gibt.
wie wäre es mit einer scriptsprache? hab noch nie sowas probiert und weiß auhc nicht ob sich ein lexer und parser auf der speichergröße implementieren lassen. Aber zum beispiel perl oder ähnliches? die CPU treibt nur die SD karte, den lexer und parser für das script und führt dieses aus. Ganz grobe idee also bitte nicht umbringen :).
@Philipp Also eigentlich wäre es schon so gedacht gewesen, dass lexer/parsen nicht auf dem uC laufen, sondern wirklich nur die VM. Sonst bin ich gleich wieder weite weg von klein....
du hast recht. naja ich hab auch schon mehrfach über sowas nachgedacht aber VM und skriptsprache scheinen die einzig guten lösungen zu sein. Ein bootloader gefällt mir auch nicht besonders. Ich hatte mal vor einen mini Computer auf avr basis zu designen aber das scheiterte genau an dieser geschichte. Die von Neumann rechner haben da klar ihre vorteile, für mich zumindest.
Dann ist das wohl der Zeitpunkt, an dem man sich einen Prozessor mit von Neumann-Architektur auswählen sollte. Mir ist durchaus klar, dass ein AVR für viele Dinge ausreicht, aber solche Klimmzüge? Nein. Das schreit z.B. nach MSP430 oder ARM. Oder eben auf dieses Feature verzichten, weil ein AVR dafür einfach nicht ausgelegt ist.
Wie dynamisch gedenkst du das alles denn zu erstellen? Ich persönliche würde für einen Mikrocontroller ja eher die Variante bevorzugen, das Programm jeweils mit dem Inhalt einer Datei überschreiben zu lassen und dieses dann nativ ausführen zu lassen. Also so wie du es oben beschrieben hast. Das muss ja nicht auf Firmware-Upgrades beschränkt sein, bei etwa 10'000 Erase/Write-Zyklen vom Flash lässt sich das Programm ja schon einige Male ändern. Eine komplette VM zu implementieren, die den Code nur interpretiert halte ich für weniger sinnvoll, das wird auf einem Mikrocontroller dieser Grösse doch einfach zu langsam. Ausser man will etwas in der Art einer SPS oder so.
Im Moment siehts eher so aus, als ob es doch ein Bootloader werden würde. Erstens, weil es interpretiert erheblich langsamer wird (das lezte mal als ich sowas gemacht hatte, hatte ich ca 1:50. War aber auch nicht sehr optimiert.) und 2. weil der Aufwand enorm ist.
Hi, wiesi, wie bewertest Du Forth in dieser Sache? Ich spiele für meine Projekte immer wieder mal mit dem Gedanken, Forth einzusetzen, zumal sich die Geschwindigkeiten in Grenzen halten. Aber jedesmal entscheide ich mich dann doch, mit den alten Sourcen Puzzle zu spielen und setze sie neu zusammen. Meine Anwendungen programmiere ich mkit JTAG-ICE, aber in Deiner Situation (Kunden, große Programme, nachladbar), da wachsen die Chancen einer Interpretersprache wie Forth gegenüber einer Compilersprache. Cioa Wolfgang Horn
Hi, man kann schon einen Source interpreter fürn avr basteln, (bzw. eine virtual machine) der interpretiert halt den source und führt diesen aus, ein anängliches projekt ist in dem beitrag Beitrag "AVR bootloader kernel ATmega32 *nix" weiter unten zu finden,.. es ist leider nicht komplett, und ca 40 bis 100 clock cycles langsamer als eine real machine,... grüüüüße
Schau dir mal Lua an. Ob der AVR reicht weiß ich jetzt nicht auswendig, aber auf kleinen ARMs wurde das schon erfolgreich implementiert. Wenn man die Highlevel-Funktionen des Interpreters nutzt und nicht alles zu Fuß macht muss das Programm nicht viel langsamer sein als ein kompiliertes, und man kann auch einfach eigene C-Funktionen einbinden. Für ein Firmware-Update, wo ja i.d.R "alles" austauschbar sein soll, ist ein Bootloader aber die bessere Wahl.
An das habe ich auch schon gedacht. Das Problem ist, dass laut ARM-Lager der Lua interpreter (ohne bytecode compiler) ca. 25-60k braucht. Ok. Auf den größeren AVRs wäre das drin, aber da ist man auch schon wieder weit weg von "klein". Das größere Problem scheint RAM zu sein. @Wolfgang ich kenne zwar Forth ganz grob, muss es mir bei Gelegenheit mal näher ansehen. Im Moment ist das Ganze so realisiert: Das Gerät ist quasi eine Ablaufsteuerung. Momentan ist da schon ein "Interpreter" drauf, der aber nur ganz einfachen linearen Code der Reihe nach durchsteppt. Wahrscheinlich wird das auch genügen. Für den Fall, dass es nicht genügen sollte, habe ich mir eben den Kopf zerbrochen, weil ich gerade Zeit habe. Ich bin zum Schluss gekommen, dass es, wenn die Momentane Lösung nicht ausreicht wahrscheinlich ein abgespeckter PIC14 Befehlssatz+Assembler werden wird. Das werde ich aber erst bei Bedarf machen. Soweit danke für Eure Vorschläge.
Ich habe auch mal eine Anwendung mit AVR gehabt, die eine programmierbare Ablaufsteuerung beinhaltete. Der Code für die Ablaufsteuerung sollte über die serielle Schnittstelle nachzuladen sein. Ich habe dazu eine virtuelle Maschine programmiert. Als Assembler für die VM benutze ich den IAR Assembler, der selbstdefinerte Makros in Binärcode übersetzt. So kann man sich auch komfortable Befehle definieren. Dieses Verfahren hat sich gut bewährt.
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.