Forum: Projekte & Code Atmel OS (Speicherverwaltung, Flash-Dateisystem, IO) unvollständig


von Christian B. (casandro)


Angehängte Dateien:

Lesenswert?

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.

von Simon K. (simon) Benutzerseite


Lesenswert?

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.

von Christian B. (casandro)


Lesenswert?

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.

von Karl (Gast)


Lesenswert?

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 ;)

von Christian B. (casandro)


Lesenswert?

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.

von Simon K. (simon) Benutzerseite


Lesenswert?

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 :-)

von Christian B. (casandro)


Lesenswert?

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.

von Läubi .. (laeubi) Benutzerseite


Lesenswert?


von Simon K. (simon) Benutzerseite


Lesenswert?

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.

von Christian B. (casandro)


Lesenswert?

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.

von Christian B. (casandro)


Lesenswert?

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.

von Siggi (Gast)


Lesenswert?

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).

von Simon K. (simon) Benutzerseite


Lesenswert?

Christian Berger wrote:
> Richtig, deshalb hat jede Datei nur einen "Block". Es gibt keine
> Fragmentierung.

Aah. Geschickt! Sehr interessant das Ganze!

von Simon K. (simon) Benutzerseite


Lesenswert?

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 ;)

von Simon K. (simon) Benutzerseite


Lesenswert?

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.

von Christian B. (casandro)


Lesenswert?

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.

von Christian B. (casandro)


Lesenswert?

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.

von Christian B. (casandro)


Lesenswert?

Simon K. wrote:

> Aah. Geschickt! Sehr interessant das Ganze!

Genau, im Prinzip ist das genau das selbe was malloc und free machen.

von Siggi (Gast)


Lesenswert?

@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

von Christian B. (casandro)


Lesenswert?

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
Noch kein Account? Hier anmelden.