mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Virtual machine zur "Harvard-Umgehung"


Autor: wiesi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Andreas K. (a-k)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Philipp Karbach (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 :).

Autor: wiesi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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....

Autor: Philipp Karbach (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Frank (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Philipp Burch (philipp_burch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: wiesi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Wolfgang Horn (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Zeusi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Andreas Schwarz (andreas) (Admin) Benutzerseite Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: wiesi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Jens (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.