mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Fat16/32 Dateisystem Übersicht / Code / SD spec


Autor: Dennis (Gast)
Datum:

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

Autor: Olaf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

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

Autor: Name (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Welcher Prozessor?
Im Linux-Kernel ist das alles drin.

Autor: Olaf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

> 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

Autor: arc (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: arc (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Achso, die CF-Specifikation
http://www.compactflash.org/specdl1.htm
die "vereinfachte" SDCard Spezifikation gibt's hier
http://www.sdcard.org/sd_memorycard/Simplified%20P...

Autor: JojoS (Gast)
Datum:

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

Autor: Dennis (Gast)
Datum:
Angehängte Dateien:

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


Autor: Dennis (Gast)
Datum:

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

Autor: Olaf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

> 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


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.