Welche FAT lib ist die beste?

[Herr Bert (Gast)]

Gibt ja schon so viele FAT-Libs auf dem "Markt", da fällt es schwer sich 
zu entscheiden.

Ernsthafte libs sind z.B. die EFSL Lib, die Lib von Elm-Chan und die von 
Roland Riegel aus der Codesammlung.

Wichtig bei der Auswahl sind mir kompatibilität zu vielen SD-Karten und 
eine hohe Geschwindigkeit. RAM-Verbrauch ist egal.

Die Lib sollte flexibel einsetzbar sein (wie das dann aussieht bin ich 
mir nicht ganz sicher).

Hier hat bestimmt jeder mit unterschiedlichen Libs schon gute 
Erfahrungen gesammelt - vielleicht hat schonmal jemand verglichen und 
kann Stärken/Schwächen der einzelnen Libs benennen.

Target ist ein schneller µC mit DMA - es sollte also möglich sein die 
Lib mit DMA Funktionen zu versehen.

[Simon K. (simon)]

Guck dir die FAT Specs an und dann die Libraries.
Übrigens hat die FAT Lib nicht wirklich viel mit SD Karten 
Kompatibilität am Hut.

[Sven P. (Gast)]

Die 'FAT'-Bibliothekt hat mit DMA noch garnichts zu tun, das ist einzig 
und allein Sache des IDE/SD/ATA-Controllers/-Codes, aber ich denke, das 
hast du richtig erkannt.

Wenn ausreichend Resourcen zur Verfügung stehen, hätte ich auch keine 
Probleme damit, das FAT-Modul eines Linux-Kernels zu portieren, das wäre 
wohl am vollständigsten und besten getestet.

Auch würde ich ernsthaft überlegen, was außer der Einfachheit noch für 
FAT spricht -- mit ausreichend Resourcen wäre Ext2 auch machbar, das 
kann mitunter etwas leistungsfähiger sein.

[Herr Bert (Gast)]

Es geht um SD karten die an windows PCs beschrieben werden sollen (also 
FAT).

Um das DMA ein zu bauen kommt es ja auch drauf an in wie weit die FAT 
lib mit den Funktionen zur Ansteuerung des Datenträgers verknüpft ist 
(eventuell gibt es Situationen indem man durch Verarbeitung während des 
auslesens und verwerfen von nicht benötigten Informationen Zeit sparen 
kann, das würde bei einem DMA nicht so gut gehen).

[Route_66 (Gast)]

Die beste LIB ist immer die eigene. Nur da kann mann Universalität zu 
Gunsten z.B. Geschwindigkeit, Codegröße, RAM-Verbrauch usw. opfern oder 
an eigene Hardwarevorgaben (bei Dir DMA) anpassen.

[Martin T. (mthomas) (Moderator)]

EFSL wird kaum mehr weierentwickelt, bietet aber ein recht flexibles 
Cachingsystem, das man u.U. aber nicht braucht. Im FAT-code sollten 
keine dramatischen Fehler mehr drin sein. Die beiliegenden 
Hardwaretreiber sind etwas verbessungsbürftig, nicht zuletzt die von mir 
(mit-)verbrochenen.

Chans FAT-Module ist kompakt und recht übersichtlich. Teilweise aber 
etwas in "Stenno" programmiert. Man kann sich reinarbeiten, düfte aber 
eher selten notwendig sein.

Um libtat von devkitpro kümmert sich auch noch jemand. Ist einen Blick 
wert. Bietet bis auf fertige low-level-Treiber für "übliche" 
Mikrocontroller so ziemlich alles (FAT32, Cache-System, LFN), braucht 
aber mehr Resourcen.

Ein Kriterium für Auswahl in Bezug auf Geschwindigkeit kann auf sein, ob 
die Library schon multiblock read/write vorgesehen. Weitern: 
Vorbereitung für konkurierenden Zugriff bei Anwendung mit RTOS, kann man 
aber zu Not noch eine Ebene über dem FAT-code selbst dazubauen. Lizenz 
ist auch zu beachten.

Low-Level-Treiber für SPI/SD-CARD-Interface finden sich einige im Netz, 
oft in den Beispielsammlungen der Hersteller. Man muss diese dann nur an 
die Aufrufconventionen der benutzen Library anpassen (block_read/write 
evtl. multisektor). Wenn man für den Controller der Wahl garnichts 
findet, kann man recht einfach vorhandene Beispieltreiber für SPI (z.B. 
von Chan f. AVR) umbauen und gegebenenfalls später optimieren (z.B. DMA 
etc.). Hat wie schon geschrieben wenig mit dem FAT-code selbst zu tun 
und man kann aufgrund der detaillierten Angaben zum Target wenig 
Hinweise geben. Der Absatz "Um das DMA ein zu bauen..." kommt nicht 
durch meinen Bioparser.