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.
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.
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.
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).
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.
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.
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.