################################################################################################
# FAT Anwendung und Probleme
################################################################################################

hk@holger-klabunde.de
http://www.holger-klabunde.de

Stand: 26.09.2006

Dinge die man wissen sollte
===========================
Ich stelle hier in hoffentlich verstndlicher Form ein paar
wichtige Informationen zu Problemen mit FAT, SD/MMC/CF Medien
zusammen die man auf jeden Fall mal gelesen haben sollte.
Ich benutze CF hier fr ALLE Flash Medien, also auch fr SD/MMC.

Falls ich hier etwas falsches schreibe berichtige mich bitte SOFORT !!

Weitere Abhandlungen von mir zu FAT ;)
FAT_Format_HOWTO.txt   
FAT_mit_wenig_RAM.txt   

BIG_ENDIAN und LITTLE_ENDIAN
============================
Alle Daten bei FAT werden im LITTLE_ENDIAN Format abgelegt.
Mein ATMega-DOS benutzt LITTLE_ENDIAN. Wer einen Compiler hat
der BIG_ENDIAN benutzt mu da eine Menge ndern. Jeder Wert
der mehr als ein Byte gro ist mu umgerechnet werden.

Compiler die das LITTLE_ENDIAN Format benutzen:
AVR-GCC / WINAVR fr Atmel AVR/ATMega Prozessoren
MCC18 fr Microchip PIC18Fxxx Prozessoren
WinARM fr ARM Prozessoren 

Compiler die das BIG_ENDIAN Format benutzen:
Keil-C fr 8051 Prozessoren (laut einer E-Mail)
Compiler fr MSP430 16Bit Prozessoren (laut Fundstellen in Newsgroups)

FAT12 und FAT16 Probleme bei langen Dateinamen
==============================================
Im Root-Verzeichnis kann es sehr schnell eng werden wenn
lange Dateinamen verwendet werden. Das Root-Verzeichnis hat
normalerweise 32 Sektoren. Ein Verzeichniseintrag ist 32 Byte gro.
Pro Sektor knnen also  512 / 32 = 16 Verzeichniseintrge angelegt
werden. Maximal haben also 32 * 16 = 512 Eintrge im Root-Verzeichnis
Platz. Ein langer Dateiname belegt mindestens zwei dieser Eintrge.
Einmal den DOS 8.3 Eintrag und einen oder mehr Eintrge fr den
langen Dateinamen. Ein Eintrag fr lange Dateinamen nimmt nur 13
Bytes auf. Wenn der lange Dateiname z.B. 256 Bytes gro ist werden
ganze 19 Verzeichniseintrge dafr bentigt. Die Gre des
Root-Verzeichnisses ist bei FAT12 und FAT16 nicht vernderbar !
Man knnte ein eigenes Formatierprogramm schreiben um zum Beispiel
64 Sektoren fr das Root-Verzeichnis zu erzwingen. Aber kann der
PC das dann auch lesen ?

Wenn FAT12 oder FAT16 und lange Dateinamen verwendet werden, ist
es besser in einem UNTERVERZEICHNIS zu arbeiten. Unterverzeichnisse
reservieren Speicher in der FAT und knnen ber die FAT vergrert
werden.

Bei FAT32 kann das Root-Verzeichnis durch neue Eintrge in der FAT
vergrert werden. Bei FAT32 ist das Root-Verzeichnis Bestandteil
der FAT.

Hardware Timing und Schreib-/Lesegeschwindigkeiten
==================================================
Man kann von CF keinerlei KONSTANTE Reaktionszeiten erwarten !
Das gilt fr Antworten auf Kommandos (z.B. Statusabfragen), genauso wie
fr die Schreib-/Lesezeiten einzelner Sektoren. Selbst von Sektor
zu Sektor kann es unterschiedliche Schreib-/Lesezeiten geben.
Diese Zeiten sind sehr stark abhngig vom Hersteller. Neuere CF sind in
der Regel schneller als ltere Modelle. Aber auch darauf kann man sich
nicht verlassen. Wie lange es dauert steht im Datenblatt. Wenn man ein
Datenblatt zum CF findet ! Das ist in der Regel nicht der Fall.
Dort stehen meist nur Mittelwerte. Wenn man Glck hat zumindest
Maximalwerte. Ohne Datenblatt ist AUSPROBIEREN angesagt.

Die Schreibzeiten sind auch davon abhngig wie OFT ein Sektor beschrieben
wurde. Je fter, desto lnger dauert es diesen Sektor neu zu beschreiben.
Irgendwann ist der Sektor nicht mehr beschreibbar. Zu oft geflasht.
Wie oft ein Sektor beschrieben werden kann hngt wieder vom Hersteller ab.
ltere Modelle bis zu 10000 mal, neuere bis zu 100000 mal. Aktuelle
Modelle ? Auf jeden Fall mehr als 100000 mal. Alle CF haben eine
versteckte Sektorreserve (z.B. 2% von 32MB) die dazu benutzt wird
hufig benutzte, VERBRAUCHTE Sektoren (z.B. in der FAT) AUTOMATISCH
und fr den Anwender unbemerkt durch einen neuen Sektor zu ersetzen.
Wenn diese Sektorreserve aufgebraucht ist, ist der CF ganz einfach defekt.

Worst Case Beispiel: 10000 Schreibzyklen maximal, 32MB und 2% Reserve
                     2ms Schreibzeit. Sektor dauernd beschreiben.

Der Sektor ist nach 10000 * 2ms = 20s defekt und wird ersetzt.
Die Sektorreserve ist nach ca. 670000 * 20s aufgebraucht. Bei 86400s pro
Tag sind das 155 Tage.

Es knnte u.U. vorkommen das ein CF AUTOMATISCH in den Sleep Modus geht
um Strom zu sparen wenn lngere Zeit nicht auf ihn zugegriffen wurde.
Dann dauert es mehrere Millisekunden bis er beim nchsten Zugriff wieder
aufgewacht ist.

Wenn die Schaltung eingeschaltet wird braucht der Controller auf der
CF sicher auch einige Zeit bis er einsatzbereit ist. Das sollte man
auf jeden Fall bercksichtigen.

FAT Timing
==========
Zustzlich zum Hardware Timing kommen noch Zeiten hinzu die vom FAT
Dateisystem verursacht werden. Beim Lesen ist das nicht so kritisch.
Zwischendurch muss immer mal wieder ein FAT Sektor gelesen werden um
die nchste Clusternummer zu bestimmen. Dabei ist es relativ egal wie
fragmentiert die FAT ist. Ein FAT Buffer bringt nicht einmal 5% mehr
Tempo. Wie hufig ein neuer FAT Sektor gelesen werden muss hngt davon
ab aus wie vielen Sektoren ein Cluster besteht. Je grer die Cluster
desto schneller geht das lesen.

Beim schreiben kann es bei fragmentierter FAT dazu kommen das im schlimmsten
Fall die gesamte FAT nach einem neuen freien Cluster durchsucht werden muss.
Das kann je nach Anzahl der Cluster in der FAT und maximaler Geschwindigkeit
des verwendeten Microcontrollers mehrere SEKUNDEN dauern ! Bei einer 80GB
Festplatte mglicherweise sogar mehrere Minuten. Ein FAT Buffer kann die
Schreibgeschwindigkeit bei fragmentierter FAT mehr als verdoppeln und ist
unbedingt empfehlenswert.

Eine nicht fragmentierte FAT bekommt man wenn man alle Dateien auf der CF
lscht oder besser sie formatiert. Dann kann man oft auf den FAT Buffer
verzichten.

Schreiben ohne FAT Buffer
=========================
Schreiben ohne FAT Buffer ist keine gute Idee. Erstens kommt
man nicht richtig auf Geschwindigkeit wenn die FAT fragmentiert
ist, zweitens wird die FAT zu oft beschrieben. Das verkrzt die
Lebensdauer des CF um einiges.

Beispiele CF mit unfragmentierter FAT ganz vollschreiben:

16 MB CF mit FAT12 3900 Cluster
Schreiben mit FAT-Buffer 39 FAT Schreibzyklen.
Schreiben ohne FAT-Buffer 7815 FAT Schreibzyklen.

32 MB CF mit FAT16 15569 Cluster
Schreiben mit FAT-Buffer 121 FAT Schreibzyklen.
Schreiben ohne FAT-Buffer 31137 FAT Schreibzyklen.

Ein 32MB CF hat z.B. 61 FAT Sektoren. Jeder Sektor wird ohne FAT Buffer
also ca. 510 mal beschrieben. Es gibt CF wo jeder Sektor nur 10000
mal beschrieben werden darf ! Das heit aber nicht das der CF nach
20 Versuchen kaputt ist. CF haben eine Sektorreserve fr hufig
beschriebene Sektoren. Sektoren werden AUTOMATISCH ersetzt wenn sie
nicht mehr beschreibbar sind. Der CF ist erst kaputt wenn diese Reserve
verbraucht ist. Moderne CF haben >100000 garantierte Schreibzyklen
pro Sektor. Mu man mal ins Datenblatt sehen. Fr solche CF kann man
wenn es nicht auf Geschwindigkeit ankommt auf den FAT Buffer verzichten.

Stromausfall !
==============
Alles was ab hier beschrieben wird gilt auch dann wenn die CF bei
laufender Schaltung einfach aus dem Sockel gezogen wird !

Das ist das grte Problem bei FAT wenn auch geschrieben werden soll.
Wie oben bereits erwhnt haben CF nur eine bestimmte Anzahl von
Schreibzyklen pro Sektor. Um die CF nicht zu sehr zu stressen benutzen
meine Routinen bis zu drei Sektorbuffer im RAM des uC. Diese Sektorbuffer
werden nur geschrieben wenn es unbedingt ntig ist, wenn die Datei mit
fclose() geschlossen wird oder fflush() aufgerufen wird.

Bei Stromausfall gehen diese Sektorbuffer verloren ! Was bedeutet das ?
Beim Datenbuffer knnen bis zu 512 Bytes verloren gehen. Beim Verzeichnisbuffer
kann es passieren das die Dateilnge nicht stimmt (zu klein). Beim FAT Buffer
fehlen dann Teile der Cluster Chain oder sogar die gesamte Cluster Chain fr
eine Datei oder mehrere Dateien. Das Dateisystem ist dann beschdigt.

Mit ein bichen Pech erkennt der CF die Sektornummer nicht mehr, hat aber
noch genug Energie um einen Sektor zu schreiben. Da knnten dann der Bootsektor
oder die Partitionstabelle berschrieben werden. In dem Fall sind ALLE Daten weg.

Was kann man tun um bei einem Stromausfall die Daten zu retten ?
================================================================
Eine Notstromversorgung vorsehen. Wenn ein Stromausfall erkannt wird werden
alle Dateien geschlossen und damit die Sektorbuffer geschrieben.

Was kann man tun wenn fr eine Notstromversorgung kein Platz ist
================================================================ 
fflush() regelmig aufrufen. Wie lange die CF dann arbeitet hngt davon
ab wie viele Schreibzyklen pro Sektor die CF verkraftet und wie hufig fflush()
aufgerufen wird. Wenn die Daten schnell gespeichert werden mssen kann
fflush() auch stren ! fflush() ist aber keine Garantie dafr das alle Daten
erhalten bleiben. Ohne Notstromversorgung kann man auch MIT fflush() ALLE
Daten verlieren.


 