Ist es möglich, eine SD-Karte ohne Dateisystem zu verwenden?

Ich mache ein Projekt auf PIC , das eine große Menge an Speicher zum Speichern von Daten benötigt. Ich möchte eine SD-Karte als Speicherelement verwenden. Ich möchte kein Dateisystem.

Ich habe die Schnittstelle von SD-Karten mit Mikrocontrollern gegoogelt. Ich habe festgestellt, dass alle eine Art Dateisystem verwenden. Ist es möglich, eine SD-Karte ohne Dateisystem wie ein serielles EEPROM anzuschließen ?

Ich habe das vor Jahren bei einem Projekt im MMC-Modus gemacht und es ist sicherlich möglich, obwohl viel einfacher, wenn Sie 512 Byte RAM frei haben, um einen Sektor zu halten. Hattest du so viel zur Verfügung?
Nein, ich möchte nur 8 Bit gleichzeitig lesen und schreiben.
Ja, das kannst du, aber bedenke, dass SD-Karten Flash-Geräte sind, sodass alle Daten, die du schreibst, einen Blockschreibvorgang auslösen. Wiederholtes kleines Schreiben wird einen Block unglaublich schnell abnutzen. Außerdem werden Sie wahrscheinlich sehr lange Pausen zwischen den Schreibvorgängen haben, da ein Block Lesen-Ändern-Schreiben bis zu 100 ms in einer beschissenen SD-Karte und immer noch etwa ein paar ms in einer guten Karte dauern kann. Und diese Zeitspanne ist variabel; hängt von der Garbage Collection und so ab.
Es ist zu lange her, als dass ich mich zuverlässig erinnern könnte, aber ich denke, Sie könnten damit stecken bleiben, dass Sie eine ganze Seite auf einmal programmieren müssen, im Gegensatz zu einigen anderen FLASH-Geräten, bei denen Sie eine Seite löschen und dann weiter Bytes hinzufügen können.
@ user36129: Ich wäre überrascht, wenn jemand jemals eine "Commodity" -SD-Karte hergestellt hat, bei der wiederholte Schreibvorgänge in denselben Sektor zu wiederholten Schreibvorgängen in denselben physischen Block führen würden. Während es für einen Flash-Chip mit 32-KB-Löschblöcken möglich sein könnte, einen Sektor zu schreiben, indem ein 32-KB-Block in den Speicher gelesen, gelöscht und dann 31,5 KB alte Daten und 512 Byte neue Daten geschrieben werden, wäre die Leistung selbst dann schrecklich Ausdauer waren unbegrenzt. Handelsübliche SD-Karten verwenden Wear Leveling; Ich bezweifle, dass jemals jemand eine herkömmliche SD-Karte verkauft hat, die dies nicht getan hat.
@supercat: bisschen Nekropost, aber während Sie wahrscheinlich für moderne (sehr große) SD-Karten richtig sind, habe ich mit eingebetteten Systemen gearbeitet, die direkt auf SD-Karten schreiben, und hatte genau dieses Problem. Diese Größen (128-512 MB) werden immer noch für den eingebetteten/industriellen Einsatz verkauft, daher kann ich mir vorstellen, dass sie auch vergleichbare Controller enthalten. Das war übrigens 2009-2010, also noch gar nicht so lange her.
@ user36129: Wirklich? Das scheint sehr seltsam. Die Verwendung eines solchen Ansatzes selbst auf einem 16-MB-Flash-Chip hätte das Schreiben um eine Größenordnung langsamer gemacht als bei Verwendung eines besseren Schemas (jeder Löschblock besteht aus 16 Seiten). Darüber hinaus ist und war das normale erwartete Nutzungsmuster für SD-Karten, dass die Sektoren, aus denen die FAT besteht, viel häufiger als alles andere beschrieben werden.
@ user36129: Es ist sicherlich möglich, dass einige SD-Karten ohne ein effektives Wear-Leveling-Schema implementiert wurden, aber ich finde das trotzdem überraschend.
@supercat: Ich weiß eigentlich nicht, was in diesen SD-Karten vor sich geht, ich weiß nur, dass ich nach nur ein paar hundert Schreibvorgängen (was die typische Lebensdauer der Zelle ist) die verräterischen Anzeichen von Zellzerfall bekommen habe - obwohl ich es nur war mit 64 KB der 128-512-MB-Karte. Es war definitiv kein Wear Leveling über den gesamten Speicherplatz. Ich musste definitiv etwas tricksen, damit es zuverlässig funktioniert. Übrigens eine lustige Geschichte; Dies war für eine Einweg-Raketennutzlast, der Fallschirm löste sich nicht aus und meine SD-Karte wurde beim Aufprall zerschmettert. All diese F&E umsonst...
@ user36129: Das scheint sehr seltsam. Wenn man mit einem leeren beginnt, würde das Erstellen und Löschen von 8 Dateien 16 Schreibvorgänge in den ersten Block des Verzeichnisbereichs nach sich ziehen. Eine erneute Durchführung des Vorgangs würde weitere 16 erfordern. Vielleicht hatte jemand die brillante Idee, Wear Leveling nur für das erste Dutzend Sektoren des Laufwerks durchzuführen?

Antworten (3)

Sie haben nicht erwähnt, welchen PIC Sie verwenden, aber vorausgesetzt, es ist einer der kleineren wie der PIC16, dann wäre es mit seinem begrenzten RAM (99% der PIC16s haben nicht mehr als 1 KB RAM) unmöglich, auch nur einen zu implementieren FAT16-Dateisystem, da mehrere 512-Byte-Puffer benötigt werden. (Microchip hat eine nützliche Bibliothek, um ein FAT16/FAT32-Dateisystem zu implementieren, aber sie gilt nur für PIC18, PIC24, dsPIC33 und PIC32.)

Sie haben erwähnt, dass Sie aufgrund des begrenzten RAM nur ein Byte auf einmal schreiben oder lesen möchten. Obwohl, wie andere gesagt haben, eine SD-Karte normalerweise in 512-Byte-Blöcke aufgeteilt ist, müssen Sie nicht alle Bytes verwenden. Im schlimmsten Fall könnten Sie nur ein Byte pro Block speichern und die anderen 511 verschwenden. Das erscheint absurd, aber aufgrund der enormen Größe der heute verfügbaren SD-Karten würde es tatsächlich funktionieren. Wenn Sie eine 8-GB-Karte haben, bedeutet dies, dass 16 MB Blöcke vorhanden sind, was bedeutet, dass Sie auf diese Weise 16 MB Daten speichern können.

Es wird jedoch sehr langsam sein , etwa 10 ms oder mehr pro Block von 512 Bytes, da Sie einen Befehl zum Löschen jedes Blocks erteilen müssen, bevor er geschrieben wird. (In dem unwahrscheinlichen Fall, dass Sie, wie oben erwähnt, nur ein Byte pro Block gespeichert haben, bedeutet dies, dass es 10 ms dauern würde, dieses eine Byte zu schreiben.)

Sie haben die Datenmenge, die in einem Ihrer Protokolleinträge enthalten ist, nicht erwähnt, aber es wäre viel besser, wenn Sie einen Eintrag (z. B. 25 Bytes oder was auch immer) puffern und in einen Block schreiben könnten. So wird jeder Block zu einem Protokolleintrag. Da die Zeit zum Schreiben der Bytes wiederum von der Zeit dominiert wird, die zum Löschen des Blocks benötigt wird, ist das Schreiben eines Eintragsprotokolleintrags so schnell wie das Schreiben eines einzelnen Bytes.

Da Sie dies im Wesentlichen als erweiterten Speicher verwenden, müssen Sie die Karte nicht entfernen und in einem PC lesen (was die Verwendung einer speziellen Software zum Ausgeben der Rohblöcke erfordern würde). Da Sie die Leseblockroutine sowieso bereits in Ihrem Code haben und vorausgesetzt, Sie haben einen UART, würde ich stattdessen die Protokolldaten seriell auf einen PC ausgeben; Sie könnten eine FTDI-UART-zu-USB-Brücke verwenden und die Daten würden auf Ihrem PC als COM-Port angezeigt.

@tcrosely bist du dir sicher, dass es ungefähr 10 ms oder mehr pro Byte sind? Hast du es wirklich gesehen oder ist es nur eine Ahnung? Sowohl bei SDSC- als auch bei SDXC-Karten beträgt die BLOCKLÄNGE 512 Bytes. Wie würde ein Dateisystem etwas ändern? Wenn Sie dieses eine Byte an das Dateisystem übergeben, geschieht derselbe Vorgang.
@ rjha94 Danke, das war ein Tippfehler - hätte 10 ms pro Block sein sollen. Korrigiert.
Kontrapunkt, durch spezielle Software, alles, was jemand zum Lesen braucht, ist dd, das in grep oder cut geleitet wird. ein paar einfache Skriptzeilen und grundlegende Linux/BSD-Tools. Verdammt, ich bin mir sicher, dass sogar Windows ein Tool zum Lesen von Raw-Geräten hat, auf die über eine bat-Datei zugegriffen werden kann
@Passerby Ich hatte den Eindruck, dass das OP versucht hat, die SD-Karte einfach als Speichererweiterung zu verwenden. Er würde es nicht aushängen und auf einem anderen Computer verwenden. Er erwähnte PIC, also verwendet er definitiv kein Linux.

Ja, jedeswriteBlock Dateisystem ruft Funktionen auf niedrigerer Ebene auf, die etwa wie und benannt werden könnten readBlock, die Sie direkt aufrufen würden. Da Sie einen Mikrocontroller verwenden, wird Ihnen die Schnittstelle zur Karte im SPI-Modus am besten gefallen, was für Protokollierungsanwendungen vollkommen in Ordnung ist - nicht so sehr für schnellere Anwendungen wie Videoaufzeichnung.

Ihre Blockgröße beträgt in der Regel 512 Byte, das ist also der minimale Datenblock, den Sie auf einmal schreiben/lesen. Single-Byte-Transaktionen werden nicht unterstützt (es gibt keinen Befehl, den Sie senden können, um so etwas zu bewirken).

Allerdings sollten Sie sich überlegen, wie Sie die Daten von der Karte bekommen, da es kein Dateisystem gibt. Das bedeutet, dass es keine Dateien gibt, die Sie einfach per Drag-and-Drop auf Ihren Desktop ziehen können, wenn Sie es an Ihren Computer anschließen (wenn Sie die Daten so abrufen), auf dem ein Mainstream-Betriebssystem ausgeführt wird. Sie müssen eine spezielle Anwendung schreiben, die auf die Rohdaten der SD-Karte zugreift.

Aus diesem einfachen Grund würde ich vorschlagen, ein Dateisystem wie FAT32 zu verwenden, das in Protokollierungsanwendungen sehr verbreitet ist, und Sie finden mehrere gebrauchsfertige Bibliotheken im Internet.

Ein alternativer Ansatz wäre zu verlangen, dass die Karte eine sehr große Datei enthält, die den gesamten Speicherplatz verwendet, den das eingebettete System verwenden sollte. Das würde die Menge an "Dateisystem"-Logik, die auf dem eingebetteten Gerät benötigt wird, stark reduzieren.
@supercat Ja, das habe ich tatsächlich getan, und sei es nur, um ein inkonsistentes Dateisystem zu vermeiden, wenn die Karte während der Aufnahme ausgeworfen wird.
Wenn eine Karte unerwartet ausgeworfen wird, können Sie möglicherweise nichts tun, da Karten im Rahmen ihrer Wear-Leveling-Algorithmen häufig Blöcke mit Daten verschieben, die eine Weile nicht geschrieben wurden. Theoretisch sollten sie dies so tun, dass selbst bei einem Stromausfall während des Prozesses keine Korruption entsteht. Leider ist es schwierig, solche Zusicherungen zu geben, wenn man bedenkt, dass viele NAND-Flash-Chips die richtige Sequenzierung einschränken.

Ich habe gerade die Spezifikation der physischen Schicht der SD-Karte gelesen und mit dem Lesen und Schreiben von Blöcken mit AVR experimentiert. Ich finde die vorherigen Antworten entmutigend, also werde ich meine eigenen Ansichten darlegen

(1) Es kann einfacher sein, Blöcke für Protokollierungsanwendungen zu lesen/schreiben, die nur Daten anhängen. Natürlich gibt es viele FAT-Bibliotheken im Netz, aber es erfordert nur Mühe, eine FAT-Bibliothek zu verdrahten. (zumindest wenn du verstehen willst was du tust). Zum Anhängen von Protokollen müssen Sie nur die letzte Blocknummer verfolgen.

(2) Die Blockschreibvorgänge sind nicht langsamer als FatFS-Schreibvorgänge. Jede FatFS-Bibliothek würde schließlich dieselben Befehle verwenden. Erstellen Sie einen unsigned char[512]-Puffer und schreiben Sie ihn in einen Block.

(3) Mit 4-GB-Karten haben Sie ca. 7 * 10 ^ 6 Blöcke und das sollte Ihnen 81 Tage Protokollierung mit jeder zweiten Protokollierung ohne Pufferung geben. Die Zahl sollte sich mit Pufferung verbessern.

Ich würde dringend empfehlen, Daten in einem Format zu schreiben, das FAT-kompatibel ist, auch wenn das einfach bedeutet, einen einzelnen Verzeichniseintrag für eine Datei zu schreiben, die im ersten Cluster beginnt, und eine FAT, die jeden Cluster mit dem darauffolgenden verknüpft, falls vorhanden. Dadurch wird eine Datenbeschädigung verhindert, wenn die SD-Karte in einen Computer eingesetzt wird, und es wird dem Computer auch ermöglicht, die Daten auf der SD-Karte zu lesen, ohne einen Zugriff auf Sektorebene verwenden zu müssen.
Ist es möglich, eine SD-Karte ohne Dateisystem zu verwenden?
AntwortenHierDatenschutz-Bestimmungen1y, 0v