Das ist alles noch im Fluss, aber vielleicht will ja jemand mitmachen. Ich hab keine Ahnung ob ich demnächst noch Zeit für dieses Projekt finde, deshalb möchte ich hier mal etwas abklären, was ihr davon hält, und ob vielleicht jemand an dem Projekt mitmachen will. Was es hier schon gibt: Speicherverwaltung (malloc, free, beides getestet) Serielles IO Dateisystem (ungetestet, funktioniert über doppelt verkettete Listen) Die Idee dahinter ist die: Man hat einen kleinen Rechner mit einer Shell und einem Dateisystem. Man kann darauf Dateien hochladen und diese dann ausführen. Programme können auch Dateien lesen und schreiben. Somit hat man so eine Art DOS. Speicherverwaltung und Dateisystem funktionieren über doppelt verkettete Listen. Dadurch ist es relativ einfach möglich neue Bereiche zu reservieren und freizugeben. Im RAM hat jeder Block einen 4 Byte header, der ausdrückt wo der vorherige und nachfolgende Block ist, sowie ob dieser Block frei ist. Im Dateisystem hat jeder Block (=Datei) einen 16 Byte header, der die Adressen des vorherigen, und des nächsten Blockes, sowie den Dateinamen und die Dateigröße enthält. Es gibt kein Inhaltsverzeichnis, somit gibt auch keine Stellen, die prinzipbedingt besonders häufig beschrieben werden müssen. Natürlich gibts bei dem Dateisystem ein paar Probleme. Die Dateigröße sollte schon beim Anlegen der Datei bekannt sein, es gibt keine Unterverzeichnisse, und es gibt keine Möglichkeit zur Fragmentierung. Programme im Dateisystem sollten nur relozierbaren Code haben, sprich die dürfen keine absoluten Adressen verwenden. Das ist im Moment in Assembler geschrieben und, wie schon gesagt, eher ein Haufen von Fragmenten als irgendwas nützliches. C als Sprache für das Betriebssystem wäre im Prinzip auch denkbar, nur bei den Anwendungen müsste man es halt irgendwie schaffen, dass nicht jede Anwendung immer den selben Code reinlinkt.
Für was für Prozessoren ist das denn? AVR? Werden die Programme zuerst ins Flash geschrieben und dann gestartet? Oh ich sollte ins Bett.
Simon K. wrote: > Für was für Prozessoren ist das denn? AVR? Werden die Programme zuerst > ins Flash geschrieben und dann gestartet? Ohh, Entschuldigung das hätte ich noch hinschreiben sollen. Ja, das ist im Moment auf den ATMega32 ausgelegt. Das Dateisystem ist komplett im Flash, man kann somit die Programme direkt ausführen. Somit kann man Programme ausführen, die großer sind, als der verfügbare Arbeitsspeicher.
Ich bin jetz nicht wirklich DER AVR Experte, aber die können doch eh nur Programme aus dem Flash ausführen, oder? Das mit dem Arbeitsspeicher zählt also irgendwie nicht so ganz ;)
Richtig, aber man könnte ja das konventionelle Verfahren verwenden und dann den Code interpretieren. Ein Z80 Emulator könnte auf so einem Controller schneller laufen als das Original. Ich hab mir auch schon überlegt, ob ich nicht einfach einen Z80 emuliere und darauf dann CP/M laufen lasse. Aber dafür bräuchte ich mindestens 20kByte.
Ah! Darauf bin ich ja noch gar nicht gekommen. ein Filesystem im internen Flash... Irgendwie ne tolle Idee. Wenn man dann noch nen AVR mit 256kiB Flash nimmt hat man auch genug Luft für sowas.. Oder nachher direkt einen XMega mit 512kiB Flash (wenn ich mich gerade nicht irre). Das muss ich auch mal irgendwann machen. Rein als Proof of Concept :-)
Ja, die Idee die ich hatte ist ungefähr so. 1. Dateisystem auf dem man Programme ausführen kann 2. kleine Shell mit Umleitung von Aus- und Eingabe 3. ein kleines Textverarbeitungsprogramm (z.Bsp wie vi) 4. ein Compiler (z.Bsp Basic) der auf der Kiste läuft 5. andere Anwendungsprogramme, z.Bsp. ein Satzprogramm Die Vision ist, einen kleinen Rechner im Chip zu haben.
Läubi Mail@laeubi.de wrote: > Beitrag "AVR-ChipBasic2 - BASIC-Computer mit ATMega 644" sowas? :) Das ist nur ein Interpreter. Mal ne andere Frage: dein Filesystem ist doch in Blöcken aufgeteilt, die als Kette verlinkt sind. Wenn du jetzt eine ausführbare Datei im Filesystem hast, die du ausführen möchtest, springst du zum Anfang der Datei. Aber musst du nicht am Ende jeden Blockes noch ein jmp zum nächsten Block einfügen? Sonst läuft der AVR ja amok.
Läubi Mail@laeubi.de wrote:
> Beitrag "AVR-ChipBasic2 - BASIC-Computer mit ATMega 644" sowas? :)
Ich mag das Projekt nicht ganz. Es wurde da zwar tolle Arbeit geleistet,
aber die haben beispielsweise sehr merkwürdige Beschränkungen drin.
Simon K. wrote: > Mal ne andere Frage: dein Filesystem ist doch in Blöcken aufgeteilt, die > als Kette verlinkt sind. Jeder Block ist eine Datei. Im Flash kann ich problemlos auf einzelne Bytes zugreifen. Somit habe ich keine feste Blockgröße. Der Ausdruck Block ist etwas ungünstig. > Wenn du jetzt eine ausführbare Datei im > Filesystem hast, die du ausführen möchtest, springst du zum Anfang der > Datei. Aber musst du nicht am Ende jeden Blockes noch ein jmp zum > nächsten Block einfügen? Sonst läuft der AVR ja amok. Richtig, deshalb hat jede Datei nur einen "Block". Es gibt keine Fragmentierung. Der große Unterschied vom Flash zu einer "Platte" liegt darin, dass ich hier einzelne Bytes ändern kann. Man müsste dafür nur eventuell eine Art Cache machen, damit man den Flash-Speicher nicht so oft löschen muss. Vielleicht schreib ist das nochmal in C.
Schön & gut das Ganze: aber als Speicher für Programme ziehe ich eine SD-Card vor. Die Programme dann entweder in den Flashspeicher laden oder gleich auf einen Controller zurückgreifen, der Programme im RAM ausführt (z. B. AT91SAMS64 - AT91SAMS256).
Christian Berger wrote: > Richtig, deshalb hat jede Datei nur einen "Block". Es gibt keine > Fragmentierung. Aah. Geschickt! Sehr interessant das Ganze!
Siggi wrote: > Schön & gut das Ganze: aber als Speicher für Programme ziehe ich eine > SD-Card vor. Die Programme dann entweder in den Flashspeicher laden Und was soll das für einen Vorteil haben? Okay, machbar ist es. Der einzige Vorteil der mir aber einfällt ist, dass man mehr Speicherkapazität zur Verfügung hat. Aber trotzdem ist die maximale Größe der ausführbaren Datei beschränkt. > oder > gleich auf einen Controller zurückgreifen, der Programme im RAM ausführt > (z. B. AT91SAMS64 - AT91SAMS256). Dann wäre der ganze "Witz" ja wieder weg ;)
Mir kommt gerade noch eine Idee. Eventuell wäre es doch möglich, Executables unbestimmter Größe auszuführen. Und zwar in dem man zu Anfang eine bestimmte Anzahl Bytes in den internen Flash kopiert (von der SD Karte bspw.). Und nebenbei einen Timer-Interrupt einrichtet. Nach X Zyklen springt der Timer ein, überprüft den Program Counter, lädt die Daten nach, bis der Puffer wieder voll ist und lässt das Programm weiterlaufen, indem der Interrupt beendet wird. Hehe.
Siggi wrote: > Schön & gut das Ganze: aber als Speicher für Programme ziehe ich eine > SD-Card vor. Die Programme dann entweder in den Flashspeicher laden oder > gleich auf einen Controller zurückgreifen, der Programme im RAM ausführt > (z. B. AT91SAMS64 - AT91SAMS256). Ja, aber RAM ist extrem kostbar. Du hast selten mehr als ein paar Kilobyte in leicht lötbaren Controllern. Außerdem wird dann die Hardware so aufwändig. Die Idee ist ja, einen Einchiprechner zu haben. Sonst könnte ich ja auch gleich einen fertigen PC nehmen, oder mir was Z80-basierendes bauen.
Simon K. wrote: > Und zwar in dem man zu Anfang eine bestimmte Anzahl Bytes in den > internen Flash kopiert (von der SD Karte bspw.). Und nebenbei einen > Timer-Interrupt einrichtet. ... Hmm, erstmal wird das Programm wohl nur selten linear ablaufen. Zweitens glaube ich nicht, dass der Flash-Speicher das ständige reinkopieren so lange mitmacht. Auf Mikrocontrollern mit MMU geht das aber natürlich. Da überprüft die MMU jeden Speicherzugriff, und kann dann einen Interrupt auslösen.
Simon K. wrote:
> Aah. Geschickt! Sehr interessant das Ganze!
Genau, im Prinzip ist das genau das selbe was malloc und free machen.
@Simon Eine SD-Card hat den Vorteil, dass sie nicht so schnell erschöpft (Stichwort: wear levelling). Und sie kann entsprechende Datenmenhen aufnehmen. Zum "Witz" kann ich nichts sagen :) @Christian Der AT91SAM7S64 ist ein Einchipcontroller und verfügt u. a. über 64 KByte Flash & 16 KByte RAM. Das RAM sollte für Dein Betriebssystem und die Programme ausreichen. Mit etwas Übung kann er gut gelötet werden (QFP64-Gehäuse). Sonniges Wochenende Siggi
Siggi wrote: > Der AT91SAM7S64 ist ein Einchipcontroller und verfügt u. a. über 64 > KByte Flash & 16 KByte RAM. Das RAM sollte für Dein Betriebssystem und > die Programme ausreichen. Klar, aber mit SD-Karte bräuchte man dann zusätzliche Hardware. > Mit etwas Übung kann er gut gelötet werden (QFP64-Gehäuse). Klar, aber die Idee ist auch, dass das Betriebssystem so einfach mal zusätzlich auf einen Mikrocontroller passt.
Bitte 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.