AVR: Kleines Dateisystem für SRAM, EEPROM, i2c/spi Speicher etc.

[Michael F. (mifritscher)]

Es ist noch nicht ganz fertig (v.a. stehen noch einige Tests an), aber 
ich möchte trotzdem schon mein Dateisystem unter 
http://www.roboter.cc/index.php?option=com_nicaiwci&view=project&Itemid=41&projectid=1872 
vorstellen. Lizenz ist GPLv3.

Das ist v.a. nützlich, wenn man dynamische Daten hat, deren Größen sich 
ändern - seien es Logdaten, Wegpunktlisten oder auch 
Interpreterprogramme, man aber keine "große" Lösungen wie SD-Karten etc. 
verwenden möchte. Gerade die größeren AVRs haben schon recht viel 
internen Speicher, wo es nur noch an Verwaltung fehlt.

Features:
* lesen/schreiben/überschreiben/verkleinern/löschen/formatieren
* FAT-artig (aber mit wesentlich kleinerem Verwaltungsoverhead für 
Bootsektor, Dateiverwaltung etc.)
* deswegen: Keine Dateinamen, nur Nummern
* auf kleine Dateien und Speicher ausgelegt, deswegen (fast) keine 
Buffer, keine Dateihandles etc.
* Zwischen FAT8(tiny) und FAT16 zur Kompilezeit umschaltbar
* FAT8: max. 256 Byte Sektoren, max. 256 Sektoren, max. 256 Dateien, 
max. Datei/Dateisystemgröße von 64 KB
* FAT16: max. 2^16 Byte Sektoren, max 2^16 Sektoren, max. 2^16 Dateien, 
max. Datei/Dateisystemgröße von 4 GB
* tiny: 3KB Maschinencode, normal; 4,3KB Maschinencode
* "Treiber" für RAM und EEPROM

TODO:
* Treiber für Flash
* Weitere Tests (größere Dateisysteme, truncate etc.)

Falls ihr euch über die #ifdef AVR wundert: auf diese Art & Weise kann 
ich es erstmal leicht nativ auf meinem Notebook testen.

Ich hab versucht es möglichst klein zu halten.
Für Tipps, Anregungen, Fragen, Hinweise etc. bin ich immer dankbar ;-)

[Rainer S. (rsonline)]

Hört sich sehr gut an, ohne jetzt den Quellcode gesehen zu haben.

Eigentlich braucht man ja auch nur eine Datei zur gleichen Zeit.

Oder kann das Dateisystem mehrere Dateien gleichzeitig 
öffnen/beschreiben?

Man bräuchte dann ja im Prinzip gar kein Handle.

[Michael F. (mifritscher)]

Das Dateisystem kann mehrere Dateien gleichzeitig bearbeiten, ja. Also 
gleichzeitig im Sinne von lesen auf Datei 1, danach schreiben auf Datei 
2 etc. - während Datei 1 gelesen wird sollte nicht eine ISR o.ä. 
versuchen Datei 2 zu schreiben. Das Dateisystem dürfte man sogar noch 
recht einfach threadsafe machen, das Problem sind eher die Treiber fürs 
eeprom, i2c etc.

[Dennis S. (dspo)]

Michael F. schrieb:
> Also
> gleichzeitig im Sinne von lesen auf Datei 1, danach schreiben

Diese Definition von gleichzeitig ist mir neu :-)
Möchte Deinen Programmierspass ja nicht bremsen aber so recht will sich 
mir der Sinn Deiner "Treiber" nicht erschließen. Der Verwaltungsaufwand 
dürfte den Nutzen in den meisten Fällen bei weitem übertreffen. Bei den 
kleinen AVR Speichergrößen mit wenigen KB... Für größere Speicher auf 
SD-Karten ja- aber davon war ja ausdrücklich keine Rede.
Vielleicht kannst Du den Sinn Deiner immerhin 3-4 KB Code hier noch ein 
wenig genauer erläutern?

Dennis

[Michael F. (mifritscher)]

@gleichzeitig: naja, man muss die Datei nicht erst schließen, wenn man 
auf eine andere Datei zugreifen will, wie bei einigen anderen 
Dateisystemen. Das meinte ich mit Gleichzeitigkeit.

@Sinn: Naja, man hat halt oft "dynamisch" wachsende Speichersachen, wie 
Logsachen, Codes zum Interpretieren (siehe 
Beitrag "AVR: Interpreter für Assemblerartige Sprache"), Textdateien, die man 
ausgeben möchte, Wegpunktlisten,  selbst Konfigurationsdateien wachsen 
gerne mal zur Laufzeit. Für solche Sachen ist es gedacht. Man könnte es 
sich auch als Art malloc, wo man den Speicherbereich immer vergrößern 
kann, vorstellen (Minus, dass man einen Zeiger bekommt, mit dem man 
direkt arbeiten kann).

Naja, die großen AVRs haben schon einiges an Speicher (256 KB Flash, 16 
KB RAM, 4 KB EEPROM), außerdem gibt es recht günstige I2C EEPROMs wo 
einiges reinpasst. Da ist eine halbwegs vernünftige Datenverwaltung 
schon hilfreich ;-) Ich habe mehr als genug Programm-flash, da fallen 
die 2,8 KB für die kleine und 4 KBfür die große Fassung nicht weiter auf 
;)