Hallo,
ich suche eine möglichst ausgereifte Version einer Fat16/32
implementierung.
Zudem wäre es interessant die spec der Fat8 12 16 und wenn möglich infos
zur Fat32 zu bekommen, speziell die einteilung des speichers, beginn von
Fat und Root tabellen und des datenbereichs auf dem tragenden medium.
Vielleicht hat ja auch noch jemand eine schöne zusammenfassung über die
initialisierung und ansteuerung von sd und cf karten.
Ich weiß es gibt unmengen an links und zusammenfassungen, genau das ist
mein problem.
ich suche einen möglichst ausgereiften code für eine fat, mit read/write
funktionen, funktionen um dateien/verzeichnisse anzulegen und zu
löschen, um das medium zu formatieren, um einen kompletten dateinamen
auszulesen, um die fat auf dem medium selbst eigenständig zu erkennen,
möglichts prozessor und medium unabhängig um ihn dann für meine zwecke
anzupassen. Vielleicht existieren in der richtung ja ansätze und
überlegungen, in bezug auf die gestaltung einer hardwareunabhängigen
schnittstelle usw...
specs über sd karten und cf karten habe ich bereits, hierzu wäre
speziell eine struktur bei der ansteuerung der karte interessant...
welche kommandos müssen in welcher reihenfolge gesendet werden
usw....also ein paar hardwareerfahrungen...
vielleicht gibts ja so etwas, wäre aber warscheinlich einfach zu schön
um war zu sein :-)
freue mich auf eure antworten...
Dennis
> 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?
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
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
