ch weiss schon, wenn ich hier unspezifisch die Frage stellen würde "Welche AVR-GCC Bibliothek zur Ansteuerung von SD-Karten als Massespeicher ist die beste?" dann würde ich ganz sicher mit der einen oder anderen Antwort virtuell Haue bekommen. Womöglich sogar zu Recht... Daher werd ich mir Mühe geben so genau wie möglich zu spezifizieren, wonach ich suche. Ich verwende eine per Atmega/SPI-Interface gesteuerte SD-Card als Massespeicher für einen selbstgebastelten CP/M-Rechner. Wobei es für mich wichtig ist, dass die Karte nicht im raw-Modus (direkter Zugriff auf Sektoren) verwendet wird, sondern in einem Format, dass den Datenaustausch mit dem PC einfach macht - da kommen eigentlich nur FAT16/32 in Frage. Die CP/M "Laufwerke" liegen dann als Dateien mit fixer Größe auf der SD-Card vor, typische Dateigröße im Bereich 1 bis 8 Megabyte. Die für mich spannendste Frage: welche Library mit FAT-Unterstützung hat ein flottes SEEK für so einen Fall zu bieten, mit dem man in so einem Dateicontainer schnell einen Sektor findet, sowohl für schreiben als auch für lesen? Die simple Alternative, zusammenhängende Dateicontainer direkt nach Formatierung anzulegen, von denen man voraussetzt dass sie fortlaufend im Sinne von LBA sind, find ich persönlich garnicht gut. Dann lieber etwas weniger performant aber ordentlich programmiert... Ich schreib hier mal meine Wünsche an so eine AVR-GCC Library für SD-Card Ansteuerung (SPI) auf, geordnet nach Prioritäten: 0) Die Library sollte einen guten Ruf bzgl. Code-Qualität haben 1) Ansteuerung einer SD-Card per SPI, in AVR-GCC geschrieben, muss FAT in irgendeiner Form können 2) In vorhandenen Dateien, die ggf. zerclustert sind, muss ein Sektor-SEEK vorwärts und rückwärts möglichst flott funktionieren (nicht jedesmal am Dateianfang beginnen mit der Suche) 3) Wenn nur SD-Cards bis 2MB und FAT16 unterstützt werden ist das ausreichend, zusätzliche "nice to have's" wären Unterstützung von SDHC-Karten und FAT32. Mit der hier auf mikrocontroller,net als Lehrbeispiel geposteten FAT32 Library hab ich durchwachsene Erfahrungen gemacht - man muss eben auch sagen dass es seitens des Entwicklers "Abandon-Ware" ist. Wenn ich nix bessere Empfehlungen bekomme, werd ich als nächstes die Library von Holger Klabunde ausprobieren, die Beschreibung der SEEK-Funktion erscheint mir rel. vielversprechend. Falls jemand eine Empfehlung für mich hat - immer raus damit! Bin dankbar für jegliche Empfehlung die auf Fakten bzw. Erfahrung beruht.
>Wenn ich nix >bessere Empfehlungen bekomme, werd ich als nächstes die Library von >Holger Klabunde ausprobieren, die Beschreibung der SEEK-Funktion >erscheint mir rel. vielversprechend. Das wird nix. Rückwärts durch die FAT ist da auch nicht vorgesehen. Wozu musst du eigentlich massiv hin und herseeken?
Micha schrieb: > Falls jemand eine Empfehlung für mich hat - immer raus damit! Bin > dankbar für jegliche Empfehlung die auf Fakten bzw. Erfahrung beruht. Ich würde mal da: http://elm-chan.org/fsw/ff/en/lseek.html reinschauen. Die Library benutze ich mit guten Erfahrungen selbst, allerdings nicht mit AVR.
:
Bearbeitet durch User
holger schrieb: > Wozu musst du eigentlich massiv hin und herseeken? Naja ich missbrauche das FAT System in dem Fall für eine *sehr spezielle* Anwendung: um Container-Dateien zu beherbergen für ein anderes Dateisystem, konkret CP/M. Diese Container-Dateien sind in ihrer Größe unveränderlich, sie enthalten Disk-Images mit einer Größe bis max. 8MB. Seitens CP/M ist die Verwendung so eines Containers extrem einfach gestrickt - da kommen vom BIOS immer die Informationen Drive# (entspricht der FAT-Datei), Track#, Sector#, und die Anforderung, von dort pro Aktion 512 Byte entweder zu lesen oder zu schreiben (es sind immer genau 512 Byte am Stück). Mehr isses nicht von dem Ende aus gesehen. Wenn ich sicherstelle, dass so eine Container-Datei lückenlos auf dem FAT-formatierten Datenträger vorliegt, wird das Ganze trivial - dann brauch ich nur einmal den physischen Anfangssektor der Datei zu ermitteln und kann daraus die Adresse jedes anderen Sektors innerhalb der Datei ganz simpel als Offset berechnen. Wenn ich aber die Annahme zulasse, dass ich mit einem bereits "zerclusterten" Datenträger arbeite, wird es ein wenig komplizierter. Genau das versuche ich. Die Firmware, mit der ich momentan arbeite, sucht ganz stupide jeden Sektor immer wieder ab Dateianfang per FAT-Verkettung. Nun ist es aber nicht untypisch, dass innerhalb CP/M fortlaufende Sektoren gelesen werden sollen, um z.B. eine größere Datei, die aus solchen 512Byte Happen besteht, zu lesen. Das erzeugt dann schon ganz schön Overhead. Nur mal als Beispiel: In CP/M kann man mit dem Dienstprogramm POWER, mit dessen Kommando TEST ein ganzes Laufwerk prüfen. Für ein CP/M Drive der max. möglichen Größe von 8MB benötigt mein Bastel-System mit SD-Card für so ein TEST Kommando: * ca. 2 Minuten im raw-Modus bzw bei einfacher FAT-Adressrechnung * ca. 18 Minuten bei FAT mittels seek. Ist eigentlich auch keine Überraschung - der Overhead fürs Suchen nimmt überproportional zu, je weiter nach hinten in der Datei gesucht werden muss. Alles was ich suche ist eine FAT-Bibliothek die solche Suchvorgänge intelligenter handhabt, als sich jedes Mal von Anfang an durch die Linkliste der FAT-Cluster zu hangeln.
Micha schrieb: > Naja ich missbrauche das FAT System in dem Fall für eine *sehr > spezielle* Anwendung: um Container-Dateien zu beherbergen für ein > anderes Dateisystem, konkret CP/M. Diese Container-Dateien sind in ihrer > Größe unveränderlich, sie enthalten Disk-Images mit einer Größe bis max. > 8MB. Wenn sie eine fixe Größe haben, warum dann überhaupt ein übergeordnetes FAT-Dateisystem? Warum nicht gleich am Stück direkt an feste Adressen auf die Karte packen?
Stefan Ernst schrieb: > Micha schrieb: >> Naja ich missbrauche das FAT System in dem Fall für eine *sehr >> spezielle* Anwendung: um Container-Dateien zu beherbergen für ein >> anderes Dateisystem, konkret CP/M. Diese Container-Dateien sind in ihrer >> Größe unveränderlich, sie enthalten Disk-Images mit einer Größe bis max. >> 8MB. > > Wenn sie eine fixe Größe haben, warum dann überhaupt ein übergeordnetes > FAT-Dateisystem? Warum nicht gleich am Stück direkt an feste Adressen > auf die Karte packen? So hab ich am Anfang auch gedacht, und in einer ersten Version die SD-Card im raw Modus benutzt. Ist die Variante mit der größtmöglichen Performance überhaupt. Aber um Daten mit dem Rest der Welt auszutauschen muss man dann schon genau wissen was man tut. Bzw, wie oder womit man es tut. Unter Linux beispielsweise mit dd. Im Lauf der Zeit bin ich dann dahin gekommen, eine zumindest unter Windows direkt kopierbare Container-Datei pro CP/M Disk zu haben. Gibt unter Windows paar ganz brauchbare Tools für solche Disk Images.
Du kannst ja auch Dateien fester Größe an fixe Stellen innerhalb eines FAT-Filesystems legen. Am einfachsten indem die Dateien zusammenhängend abgelegt werden. Dann mach das AVR-CPM-Drive Zugriffe auf den Block, dessen Anfang sich über DIR/FAT ermitteln läßt, aufsteigen in der Gesamtlänge aus DIR. Der PC sieht ein normales FAT Laufwerk und im Änderungsfall (auf PC Seite) braucht's ein Disk-Optimizer, um die SD wieder für AVR vorzubereiten.
Hallo Micha, offtopic, da ich Dir die FAT-Routinen vom AVR CP/M-System natürlich nicht empfehlen möchte (Assembler). Aber da PM nicht geht... Micha schrieb: > Nur mal als Beispiel: In CP/M kann man mit dem Dienstprogramm POWER, mit > dessen Kommando TEST ein ganzes Laufwerk prüfen. > Für ein CP/M Drive der max. möglichen Größe von 8MB benötigt mein > Bastel-System mit SD-Card für so ein TEST Kommando: > * ca. 2 Minuten im raw-Modus bzw bei einfacher FAT-Adressrechnung > * ca. 18 Minuten bei FAT mittels seek. Welche Version von POWER nimst Du, und wie ist das CP/M-Drive formatiert (STAT DSK:)? Ich würde das gerne auf AVR CP/M nachvolziehen, da ich mir nicht vorstellen kann das der Unterschied dort auch so groß ist.
Micha schrieb: > Aber um Daten mit dem Rest der Welt auszutauschen muss man dann schon > genau wissen was man tut. Bzw, wie oder womit man es tut. Unter Linux > beispielsweise mit dd. Du wirst es sicher schon wissen, aber der Vollständigkeit halber sei es doch nochmals erwähnt: Es gibt die CPMtools, die Dateioperationen wie Kopieren und Löschen direkt auf einem CP/M formatierten Datenträger ermöglichen. Unter Linux habe ich das vor Jahren mal selbst probiert, funktionierte sehr gut. Eine Windows-Version existiert wohl auch. Es war ursprünglich für Floppies gedacht, geht aber auch auf Image-Files und ich sehe keinen Grund, warum SD-Karten nicht gehen sollten. (OK, außer vielleicht der Größe, Floppies im Gb Bereich dürfte CP/M wohl eher nicht unterstützen :-)
Thread beobachten
Seitenaufteilung abschaltenBitte 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.