Fat16/32 Dateisystem Übersicht / Code / SD spec

> ich suche eine möglichst ausgereifte Version einer Fat16/32
> implementierung.

Wenn dir Bastelloessungen nicht gefallen, wieviel kEur bist du denn 
bereit fuer eine professionelle Lizenz auszugeben? Geben tut es sowas 
ja, wie man an jeder Digitalkamera sehen kann.

Olaf

p.s: FAT8 gibt es aber nicht .-)

Welcher Prozessor?
Im Linux-Kernel ist das alles drin.

> Welcher Prozessor?

Sollte egal sein da man sowas sowieso in C oder einer anderen 
Hochsprache
macht.

> Im Linux-Kernel ist das alles drin.

Stimmt. :-) Aber die meisten hier basteln ja mit irgendwelchen
kleinen Microcontrollern rum und dafuer ist FAT eigentlich schon
eine Nummer zu gross. Sowas ist nur dann sinnvoll wenn man nur
einen Teil der Funktionalitaet unterstuetzt und Kompromisse mit
der Leistungsfaehigkeit eingeht.
Und aus genau diesem Grunde ist es auch sinnvoll sich seine eigene
Implementation zu schreiben weil man die auf seine Beduerfnisse
anpassen kann.
Aber das macht es natuerlich schwer wenn man alles anderen
abschreiben will da die eigenen Beduerfnisse oft anders sind als
die des Autors. So unterstuetzt z.B meine eigene Implementation
nur immer maximal ein geoeffnetes Files und auch keine 
Unterverzeichnisse.
Mir reicht das, anderen wahrscheinlich nicht. Dafuer leiste ich mir
den Luxus das Direktory komplett im Ram zu halten. Das koennte wiederum
kleinen AVRs den Schweiss auf die Bits treiben.

Olaf

FAT32
http://www.microsoft.com/whdc/system/platform/firmware/fatgendown.mspx?
http://www.win.tue.nl/~aeb/linux/fs/fat/fat-1.html
http://en.wikipedia.org/wiki/FAT32

Achso, die CF-Specifikation
http://www.compactflash.org/specdl1.htm
die "vereinfachte" SDCard Spezifikation gibt's hier
http://www.sdcard.org/sd_memorycard/Simplified%20Physical%20Layer%20Specification.PDF

in dem EFSL Projekt ist doch schon eine ganze Menge drin, auch für 
verschiedene Prozessoren: http://www.efsl.be/
Aber alle denkbaren Features per Compilerschalter wählbar einzubauen 
wird wohl ein Lebenswerk werden. Irgendeine Anwendung/Prozessor hat mit 
Sicherheit wieder andere Anforderungen und erfordert Codeänderungen.

Hallo Olaf,

natürlich gibt es das alles zu kaufen, im anhang befindet sich eine 
grobe schnittstellengliederung. Ist von einer Fat der Firma Segger.

...mein interesse ist dem bastelwesen gewidmet. es gibt leider nur so 
viele unterscheidlich ausgeprägte versionen,

-die einen müssen die karte im rechner vorvormatieren und schreiben dann 
wohl NUR einfach in den datenbereich der fat...

-die nächste gruppe kann in zwischen dateien unterscheiden, aber die 
nicht anlegen oder löschen,müssen vorhanden sein...

-dann gibts welche die lesen den namen der dateien, aber nur die ersten 
8 zeichen, die nächsten suchen sich noch den rest aus der fat..

.... klar, mann kannn das beliebig tief aufziehen, also z.B. auch beim 
schreiben der datei die "lücken" in der fat, die duch zuvoriges löschen 
entstanden sind, wieder auffüllen usw... ich dachte nur, das geradei in 
dem bereich, in dem wirklich viel gemacht wird, rein basteltechnischer 
natur, auch komplexere software existieren müsste.... und ansonsten 
könnte man diese hier langsam mal ansammeln und in die codesammlung 
stellen..

alle 2-3 tage sind fragen zur fat und zu den aktuellen speichermedien, 
doch in der codesammlung habe ich noch nichts vergleichbares gefunden, 
oder irre ich mich.

ich wollte für mich vermeiden das rad ganz neu zu erfinden, und bin 
überzeugt das es da auch einen anderen weg geben wird - "c" ist wirklich 
nicht umsonst erfunden worden.. :-)

Hallo Name,

du brauchst keine angst zu haben, aber deinen namen kannst du hier ruhig 
verraten :-))

...über die möglichkeit habe ich auch schon nachgedacht. würdest du mir 
den entsprechenden code aus dem linux kernel zusammenstellen und 
erklären? ich denke das ist eine gute sache...da wird ja auch die fat 32 
unterstützt :-)

Dennis

hmm... das mit der teilimplementierung mag ja sein, und vielleicht hast 
du recht und die fat mit all ihren implementierungen ist einfach zu 
"umfangreich" um sie strukturiert und möglichst flexibel zu 
implemntieren... den "weitblick" habe ich momentan leider noch nicht...

@ arc - danke für die links..

@ jojo - mag sein das das so ist...

die kleine übersicht die ich eingestellt habe, zeigt zumindest eine 
denkbare unabhängige struktur...

meine intension ist es nicht etwas abzuschreiben, vielmehr mir einen 
möglichst weitläufigen überblick zu verschaffen, bevor ich mich daran 
setze und in die tasten haue....

etwas ähnliches habe ich schonmal mit einer möglichst flexiblen pixel 
grafik "codesammlung" versucht - ist nicht so einfach das alles unter 
einen hut zu bringen, da es meist so ist wie olaf schon sagt - die 
bedürfnisse müssen den "beschränkten" leistungen der controller 
angepasst werden, und das erlaubt meist nicht diesen weitblick, der bei 
so vielen projekten doch so vieles einfacher machen könnte...

dennis

> etwas ähnliches habe ich schonmal mit einer möglichst flexiblen pixel
> grafik "codesammlung" versucht - ist nicht so einfach das alles unter

Sowas geht aber eigentlich noch. Ich habe das so geloest das ich mir 
fuer des Display eine function schrieb welches dort ein beliebiges Pixel 
setzen kann, alles andere setzt dann darauf auf.
Das ist natuerlich extrem ineffizient, vor allem wenn man mal an die 
Ausgabe eines Zeichens denkt das so Pixelweise gemahlt wird. Oder gar 
das loeschens eines Bildschirms. Aber da man an den kleinen Controllern 
meist auch nur kleine Displays verwendet und auch immer nur wenig auf 
dem Bildschirm aendert, ist das normalerweise kein Problem.

Der groesste Engpass bei FAT dagegen ist Ram. Hinzu kommt noch das man 
sicher gerade bei FAT auch nur schlecht auf bestimmte Groessen verlassen 
kann. Je nachdem wer da formatiert, kann z.B die FAT bei einem Medium 
derselben groesse durchaus unterschiedlich gross sein. Und genauso ihre 
Position. Also dann Speicher dynamisch allozieren? Bei Anwendungen unter
den beengten Verhaeltnissen eines Controllers auch nicht gerade eine 
Garant fuer Zuverlaessigkeit.

Sinnvoll waeren vermutlich zwei Implementationen. Eine minimalistische 
welche mit 512Byte Buffer fuer einen Sektor und etwa 100Byte als Merker 
auskommt, dafuer aber nicht viel mehr kann als ein File schreiben und 
lesen und das auch noch grottenlahm.
Und eine weitere Sache die etwas Dicker ist, sagen wir mal 5-10kRam und 
20-30k Flash wo man sich dann mehr erlauben kann.

Olaf