Best Practice für die Implementierung von Bare-Metal- oder Lightweight-OS-Flash-Dateisystemen?

Ich betrachte Flash-Geräte, die für wiederbeschreibbare Datenspeicherung verfügbar sind, und es ist klar, dass sie entweder eine Art Übersetzungsschicht für ein darüber liegendes Dateisystem (z. B. FAT) oder einen bestimmten Typ von Dateisystem benötigen, der für sie entwickelt wurde (z. B. JFFS2). .

Beispiele:

Dies scheint eine so häufige Sache zu sein, aber ich sehe nicht viele Ressourcen (insbesondere auf der stm32-Plattform) für den Umgang mit den Flash-Problemen des Nur-Schreibens pro Seite, Wear-Leveling und Bad-Block-Überwachung.

Es scheint, als würde ein System wie JFFS2 vieles davon erledigen, aber es scheint nicht wirklich viel außerhalb des Linux-Ökosystems verwendet zu werden. Was sind einige der gängigeren Methoden, um damit in einer schlankeren Betriebssystemumgebung umzugehen?

Eine höchst wünschenswerte Eigenschaft ist die Fehlertoleranz. Wenn beispielsweise während bestimmter Vorgänge die Stromversorgung unterbrochen wird, kann FAT beschädigt werden. Eine gute Lösung sollte protokolliert werden oder etwas Ähnliches.

(Hinweis: "Write your own" ist eine sehr offensichtliche und unerwünschte Antwort.)

Einige Marken haben eine milde Reihe von Beispielen oder sogar einige kanonische Routinen. Die meisten nicht. Abgesehen davon haben Sie mir gerade gesagt, ich solle nicht die Antwort geben, die immer die Antwort ist, also werde ich es nicht tun.
Windows CE verwendet das FAT-Dateisystem für eingebettetes Flash – mit einer eigenen Flash-Abstraktionsschicht. Ich bin überrascht, dass es dafür keine Standard-Codebasis gibt. Vielleicht sind die Schlüsselalgorithmen patentiert?
Stellen Sie sicher, dass die Hardware nicht bereits Wear Leveling für Sie durchführt. Dies kann es noch schlimmer machen, wenn Sie versuchen, etwas zu tragen, das bereits Wear Leveling ist.
Linux-Dinge sind im Allgemeinen Open Source, Sie können es "einfach" auf Bare Metal portieren und müssen nicht alles selbst schreiben.
Wenn es wirklich keine Open-Source-Lösungen gibt, kann es einen Grund geben ... vielleicht ist es einfach nicht erforderlich ...
Haben wir darauf eine Antwort? @Daniel konnten Sie ein Dateisystem für Ihr Projekt auswählen? Welches hast du gewählt - SPIFF, YAFFS, FAT, irgendein anderes?
Das Projekt, an dem ich arbeitete, bewegte sich in eine andere Richtung, sodass ich es am Ende nicht brauchte, aber SPIFFS scheint eine sehr gute Option für die Unterstützung von leichtgewichtigen Dateisystemen zu sein. Es wird häufig im Arduino-Projekt ESP8266 verwendet.

Antworten (4)

Obwohl Sie auf einen seriellen 1-MB-SPI-Flash-Chip verweisen, ist es meiner Meinung nach viel häufiger, dass Dateisysteme auf entfernbaren SD-Karten implementiert sind. Das hat zwei Vorteile: viel größerer Speicherplatz (GB statt MB) und man kann die SD-Karten entnehmen und auf einem PC lesen/schreiben.

Ein zusätzlicher Vorteil ist, dass die Hersteller von Marken-SD-Karten wie Kingston und SanDisk Wear-Leveling als Teil der SD-Kartenarchitektur anbieten (aber verlassen Sie sich nicht darauf von weniger teuren SD-Kartenherstellern).

Microchip (und ich bin sicher, dass andere Anbieter) über eine Bibliothek verfügen, mit der Sie entweder ein FAT16- oder ein FAT32-Dateisystem auf einer SD-Karte implementieren können. Es wird in diesem Anwendungshinweis AN1045 , "Implementing File I/O Functions Using Microchip's Memory Disk Drive File System Library" beschrieben. Offensichtlich wird dies auf PIC-Mikrocontroller abzielen.

Die Low-Level-Lese-/Schreib-Sektorroutinen für SD-Karten in dieser Bibliothek könnten wahrscheinlich so modifiziert werden, dass sie mit einem seriellen SPI-Flash funktionieren, aber Sie müssten Ihr eigenes Wear-Leveling und die Markierung fehlerhafter Sektoren durchführen, was eine Menge Komplexität hinzufügen würde.

Dies ist ein Weg, den ich in der Vergangenheit gegangen bin. Leider hatte ich auch den SD-Karten-Kompatibilitäts-Albtraum. Ehrlich gesagt braucht das, was ich tue, ein paar hundert KiB mehr, nicht GB, und hat Platz für eine SO-8, aber nicht wirklich für einen Kartensteckplatz. Danke für deine Antwort! Für manche ist das sicher das Richtige.

Hier ist eine Option, die ich während der Suche gefunden habe: ein leichtes Dateisystem für SPI-Flash-Speicher: SPIFFS

Es hat keine schlechte Blockverwaltungsunterstützung, aber es scheint ansonsten ziemlich vollständig zu sein, was eine wirklich einfache Möglichkeit zum Lesen und Schreiben von Dateien angeht!

SPIFFS scheint eine gute (wenn nicht die einzige) Lösung zu sein, die für ein eingebettetes Ziel geeignet ist. Ich konnte keine andere offen lizenzierte Bibliothek finden, die nicht viele Ressourcen verwendet
@Daniel Konnten Sie SPIFFS mit S25FL0 zum Laufen bringen? Ich habe es für AT45DB, aber es ist ein $ 2-Flash und S25FL0 ist < $ 1.

Sie können RL-FlashFS verwenden , aber wie Sie wissen, ist dies keine kostenlose Option und Sie müssen MDK-KEIL als Ihre IDE verwenden, vielleicht ist dies auch mit FAT-FS möglich .

Ich habe es nie in meinen Projekten verwendet, aber schauen Sie sich bitte Fat FS lib an.

Ich habe - es würde eine Flash-Übersetzungsschicht (ftl) erfordern, um richtig zu funktionieren
Best Practice für die Implementierung von Bare-Metal- oder Lightweight-OS-Flash-Dateisystemen?
AntwortenHierDatenschutz-Bestimmungen1y, 0v