Hallo liebe Leute,
ich hätte eine kleine Frage an die Community:
Ich würde für einen ATmega gerne eine art minimal "OS" schreiben mit dem
ich Applikationen von einer SD laden und ausführen kann. Ich habe leider
schon lesen müssen dass die ATmegas zumeist RISC sind, heißt nicht von
einem externen Medium bootbar ist. Eine Idee wäre jetzt ein
interpretieren von Zahlen als befehle...das ist aber recht mühsam und
außerdem hätte es dann einen sehr kleinen "Wortschatz".
Kennt ihr eventuell ATmegas bzw. ähnlich leicht zu programmierende MCUs
mit dem das möglich werden?
Oder hat jemand eine Möglichkeit die RISC-Architektur "auszutricksen"
und die Werte in den Programm-Memory zu laden
Herzlichen Dank und Alles Liebe,
Paul
Andreasp. schrieb:> zumeist RISC sind, heißt nicht von> einem externen Medium bootbar ist.
Was hat das eine mit dem anderen zu tun.
Wer hat Dir diesen Bockmist erzählt?
Dass die Atmegas nicht von Hause aus booten, dürft doch klar sein, oder?
Andreasp. schrieb:> Ich würde für einen ATmega gerne eine art minimal "OS" schreibe
Das passt nicht zusammen, wenn Du eine OS schreiben willst, dann sollte
Dir klar sein, wie so ein Atmega wirklich funktioniert.
Ein Atmega ist kein Rpi.
Erst denken, dann posten!
Der AVR kann architekturbedingt nur Code vom internen Flash ausführen.
Es gibt daher - meines Wissens - nur zwei Möglichkeiten, wenn man
Programme von einer SD-Karte laden und ausführen möchte:
1) Der Mikrocontroller beherbergt nur einen Bootloader, der das Programm
von der SD-Karte einliest und dann in den Anwendungsbereich des
Flash-Speichers schreibt. Problem dabei ist die relativ begrenzte
Lebensdauer des Flash (etwa 10.000 Zyklen garantiert).
2) Der Mikrocontroller beinhaltet einen Interpreter, der die Programme
von der SD-Karte lädt und die nativen Instruktionen softwaremäßig auf
den AVR übersetzt. Problem dabei: langsam und ineffizient. SRAM ist ja
nur sehr begrenzt verfügbar. Es gibt aber Leute, die z.B. einen
Z80-Interpreter auf einem AVR zum laufen gebracht haben und damit CP/M
ausführen...
Interessant.
Ich hab mich in das datasheet eingelesen:
Es gibt einen Bootloader der das Sketch aus dem Flash lädt. BOOTEN geht
von SD auch aber ich will nicht booten ich will eine Application in den
SRAM laden und von dort ausführen. In einem 3d-Array werden die
Programmdaten gespeichert und ein entsprechender Dispatchersystemen
sorgt für ein vernünftiges scheduling. Es sollen maximal 16 Tasks
gleichzeitig ausführbar sein und wenn es geschlossen wird wieder auf
mein System zurückfallen.
Ob ich von wo anders booten kann war nicht die Frage sondern ob ich von
wo anders ein Programm LADEN kann, das ist ja so allgemein der sinn
eines OS sonst wäre es ja nur ein bootloader...
Hast du dafür einen eventuell Vorschlag ich häng damit leider irgendwie
;(
Erst lesen, denken dann posten bitte ;)+
Lg
Ein AVR ist für die Anwendung recht ungünstig, da er keinen Code aus dem
RAM ausführen kann.
Wenn Du einen anderen µC verwendest, der Code aus dem RAM ausführen kann
(und nicht allzuwenig davon hat), dann kannst Du Deine Idee umsetzen -
der im Flash-ROM untergebrachte Bootlader lädt eine Datei von der
SD-Karte ins RAM und springt dann eine festgelegte Adresse im RAM an ...
wenn alles klappt, läuft dann schon Dein von der Karte geladenes
Programm.
Umsetzen lässt sich das z.B. mit einem ARM, oder auch (eher theoretisch)
mit einem MSP430 (die haben halt eher ziemlich wenig RAM), oder rein
prinzipiell sogar mit einem MCS-51.
Wie genau würde so ein Interpret laufen?
Würde es nur die basics können oder könnte ich z.B.: auch einen Driver
für etwas an der IC2 laden(und wäre das schnell genug)?
Andreasp. schrieb:> ich will eine Application in den> SRAM laden und von dort ausführen.
Geht halt nicht bei AVR.
Mit dem STM32F103 wäre es zum Beispiel machbar. Der führt Code aus dem
RAM sogar etwas schneller aus, als aus dem Flash.
http://stefanfrings.de/stm32/index.html
Andreasp. schrieb:> Wie genau würde so ein Interpret laufen?> Würde es nur die basics können oder könnte ich z.B.: auch einen Driver> für etwas an der IC2 laden(und wäre das schnell genug)?
Ein Interpreter würde genau das können was du ihm als Teil deines "OS"
beibringst. Der Code der vom Interpreter verarbeitet wird, wird i.d.R.
ja kein Nativer Code sein der auch direkt auf dem Prozessor laufen würde
(Basic, Java, etc). Insofern kannst du dem Interpreter natürlich Befehle
beibringen die einen I2C-Transfer durchführen. Das geht auch schnell
genug denn die Kommunikation mit Bus macht der Interpreter. Im Programm
hast du nur ein paar Befehle die die Kommunikation auslösen.
Sascha
Hallo,
auf CP/M auf einem Mega88 wurde ja oben schon hingewiesen:
Beitrag "CP/M auf ATmega88"
Das zeigt einerseits die Möglichkeiten und andererseits die Grenzen.
Du kannst auf diese Art sicher auch ein eigens OS bauen, Du brauchts
eben nur viel Geduld, weil vermutlich die effektive Taktrate ziemlich
gering werden wird.
Das eine Havard-Architektur wie der AVR eben keinen Programmcode direkt
im Ram ausführen kann, wurde ja auch schon gesagt.
Gruß aus Berlin
Michael
Andreasp. schrieb:> Eine Idee wäre jetzt ein interpretieren von Zahlen als befehle...das> ist aber recht mühsam und außerdem hätte es dann einen sehr> kleinen "Wortschatz".
Soetwas war schon 1978 mit einem 6502 möglich. Der Basic-Interpreter
beim Superboard II benötigte inkl. Monitorprogramm (I/O über
Tastatur/Bildschirm und Magnetband) 8kByte im ROM, heutzutage dann
Flash.
Andreasp. schrieb:> Eine Idee wäre jetzt ein> interpretieren von Zahlen als befehle...das ist aber recht mühsam und> außerdem hätte es dann einen sehr kleinen "Wortschatz
Eigentlich garnicht. Sowas hat man früher an der Uni in
Compilerbau-Vorlesungen gerne als Übung gemacht...
Zuerst den "Taschenrechner" mit Klammern, Punkt-vor-Strich usw. als
rekursiver Top-Down-Parser, dann den "echten Compiler" mit Code-Ausgabe
für eine simple Stack-Maschine. Die kriegt man auch problemlos auf den
AVR, der Compiler bleibt am PC.
Genau wie Forth am AVR in der Praxis eher weniger Sinnvoll, aber man
lernt viel.
