mikrocontroller.net

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


Autor: Christian Berger (casandro) Flattr this
Datum:
Angehängte Dateien:

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

Autor: Simon K. (simon) Benutzerseite
Datum:

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

Autor: Christian Berger (casandro) Flattr this
Datum:

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

Autor: Karl (Gast)
Datum:

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

Autor: Christian Berger (casandro) Flattr this
Datum:

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

Autor: Simon K. (simon) Benutzerseite
Datum:

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

Autor: Christian Berger (casandro) Flattr this
Datum:

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

Autor: Läubi .. (laeubi) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: Simon K. (simon) Benutzerseite
Datum:

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

Autor: Christian Berger (casandro) Flattr this
Datum:

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

Autor: Christian Berger (casandro) Flattr this
Datum:

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

Autor: Siggi (Gast)
Datum:

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

Autor: Simon K. (simon) Benutzerseite
Datum:

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

Aah. Geschickt! Sehr interessant das Ganze!

Autor: Simon K. (simon) Benutzerseite
Datum:

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

Autor: Simon K. (simon) Benutzerseite
Datum:

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

Autor: Christian Berger (casandro) Flattr this
Datum:

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

Autor: Christian Berger (casandro) Flattr this
Datum:

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

Autor: Christian Berger (casandro) Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Simon K. wrote:

> Aah. Geschickt! Sehr interessant das Ganze!

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

Autor: Siggi (Gast)
Datum:

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

Autor: Christian Berger (casandro) Flattr this
Datum:

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

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.