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