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.
