Flash Filesystem

smxFFS für NAND und NOR Flash

Features:

  • Unterstützt alle Größen von Flash Speichern
  • Standard C library file API
  • Power fail safe
  • Integrierbar mit smxNAND und smxNOR
  • Multitasking Unterstützung
  • Optimiert für SMX RTOS
  • Sehr einfach portierbar, funktioniert auch ohne RTOS
  • Kann parallel zu smxFS und smxFLog benutzt werden
  • incl. vollständigem Source Code
  • PC Emulator

smxFFS ist ein spezielles Flash Filesystem (Dateisystem für NAND und NOR Flash Speicher). Es hat eine zur Standard C Library kompatible API und kann mit plötzlichem Spannungsverlust umgehen (power fail-safe).


Merkmale

smxFFS unterstützt den smxNAND Flash Treiber. Es stellt ein Standard C API zur Verfügung (fopen(), fread(), fwrite(), fseek(), fclose() etc.). Anders als z.B. smxFS ist smxFFS nicht dazu gedacht auf anderen Medien als NAND Flashes betrieben zu werden. Es unterstützt keine Medien wie SD oder Compact Flash Karten. Ebenso ist seine Dateisystemstruktur nicht kompatibel mit DOS oder Windows und es unterstützt keine Unterverzeichnisse. smxFFS ist speziell für die Benutzung mit NAND Flash Speicher ausgelegt. Um andere Medientypen zu verwenden sollte smxFS verwendet werden. Für einfache Protokollierungs- oder Loggingaufgaben in NAND oder NOR Flashes empfehlen wir smxFLog.

Funktionsweise

smxFFS geht von einer linearen Adressierung für den Flash Speicher aus. Des weiteren wird davon ausgegangen, dass das Speicher Medium nur über Sektoren (z.B. 512 Byte pro Zugriff) angesprochen wird. Die Struktur des Flash Adressraums sieht wie folgt aus:

  • Der reservierte Bereich besteht aus 2 Teilen. Der erste Teil wird von smxNAND verwendet, der zweite Teil kann einen Bootsektor oder andere Daten speichern.
  • Die File System Signature Area speichert einen Text über den das Flash Dateisystem identifiziert wird. Die FileSystem Signature Area liegt im Folgeblock des reservierten Bereichs.
  • Der File Control Block (FCB) Bereich funktioniert wie ein Root Verzeichnis. Jeder FCB repräsentiert eine Datei und enthält Informationen wie Status, Dateiname, Index des ersten Clusters und die Datei Länge. Die Größe des FCB Bereichs hängt davon ab, wie viele Dateien in dem Dateisystem abgelegt werden sollen. Jeder FCB benötigt 20 Bytes. Der FCB Bereich muss insgesamt die vielfache Größe der Flash Block Größe haben. z.B. können bei einer 16kB Blockgröße bis zu 400 Dateien verwaltet werden.
  • Der File Allocation Table (FAT) Bereich enthält FAT Nodes. Jede Node repräsentiert einen Data Cluster. Es werden 16-bit und 32-bit FAT Nodes unterstützt. Die Größe der FAT kann durch eine Vergrößerung der Clustergröße verkleinert werden. Auch die Größe des FAT Bereich muss ein Vielfaches der Blockgröße sein.
  • Die File Data Area enthält die eigentlich Nutzdaten. Sie ist aligned an den Flash Block Grenzen.

Der erste Cluster Index in dem FCB einer Datei ist der Index auf die erste FAT Node der Datei. Wenn sie END_CLUSTER enthält, dann handelt es sich um eine leere Datei. Jede FAT Node repräsentiert anhand ihrer Position in der FAT, einen Daten Cluster im linearen Adressraum der Flash Data Area. Jede FAT Node enthält einen Zeiger auf die nächste FAT Node der Datei. Der END_CLUSTER Marker kennzeichnet die letzte Node und den letzten Daten Cluster aus.

Die Größe einer FAT Node ist im Normalfall ist 16 Bit lang. Daher kann smxFFS bis zu (65534 * SectorsPerCluster * BytesPerSector) Daten Bytes verwalten. z.B. könnte man mit 16-bit FAT Nodes, bei 8 Sektoren pro Cluster und 512bytes pro Sektor bis zu 256MB an Daten adressieren. In diesem Fall benötigt die FAT Tabelle 32kB an Flash und RAM. Mit einer Verdoppelung der Clustergröße ließe sich die Größe der FAT halbieren (bei gleicher Mediengröße).

Um größere Medien zu unterstützen, kann man entweder die Anzahl der Sektoren pro Cluster erhöhen oder die Größe der FAT Nodes auf 32 Bit vergrößern. Z.B. lässt sich mit FAT32 bei 16 Sektoren pro Cluster eine Mediengröße von 1GB verwalten.

Wenn ein Dateisystem gemounted wird, werden der FCB und der FAT Bereich aus Geschwindigkeitsgründen ins RAM geladen. Für jede geöffnete Datei wird zusätzlich noch der Cluster, welcher gerade gelesen oder geschrieben wird ins RAM geladen.

Wenn auf weitere Cluster zugegriffen wird, wird der zuvor geänderte Cluster zuerst in den Flash zurück geschrieben, bevor der neue Cluster ins RAM geladen wird. Geänderte Cluster werden auch zurück geschrieben, wenn fclose() für das zur Datei gehörende Handle aufgerufen wird.

Power Fail-Safe

Wie bereits erwähnt, werden FCB und FAT ins RAM kopiert, wenn eine Datei geöffnet wird. Lesende und schreibende Zugriffe erfolgen dann auf diese Kopien im RAM. Wenn eine Datei geschlossen wird, werden alle Daten Sektoren und die veränderten FCB und FAT zurück ins Flash geschrieben. Wenn dieser Vorgang beendet ist ruft smxFFS die Cache Writeback Funktion des Flash Treibers auf, welcher dann die Block Tabelle im Flash aktualisiert und die alte Block Tabelle verwirft. An diesem Punkt sind die neue FAT und FCB sicher im Flash gespeichert. Tritt dann eine Unterbrechung der Versorgungsspannung auf, gehen keine Daten verloren.

Wenn eine Unterbrechung der Spannungsversorgung allerdings auftritt, bevor der oben erwähnte Prozess vollständig abgeschlossen ist, benutzt smxFFS nach der Rückkehr der Versorgungsspannung wieder die alten Daten. Die neuen Daten sind dann zwar verloren, dafür bleibt die Integrität des Dateisystems allerdings erhalten.

Porting Layer

smxFFS ist dank eines Portierungslayers sehr einfach zu portieren und zu integrieren. Zwei Dateien, ffsport.h und ffsport.c enthalten Definitionen, Makros und Funktionen um smxFFS auf jedes OS, Compiler oder Prozessor zu portieren. Momentan werden SMX und Windows unterstützt. Unter Windows gibt es einen NAND Flash Emulator, welcher die Festplatte benutzt um smxFFS zu testen. Die erwähnten Dateien enthalten unter anderem eine Semaphor-Schutz-Implementation für die smxFFS API um den Einsatz von smxFFS auch in Multitasking Umgebungen zu ermöglichen. Diese müsste dann z.B. an die spezifischen Locking Mechanismen des unterliegenden Betriebssystems angepasst werden.

Speicherbedarf

Code Größe (ohne smxNAND)

Die Code Größe hängt stark von der eingesetzten CPU, dem Compiler und dem Grad der Optimierung des Compilers ab. Hier finden Sie einige Beispiele. Die Mini Library enthält nur die Basisfunktionalität.

CPU und CompilerFull Library (kB)Mini Library (kB)
Coldfire, CodeWarrior 6.3127
ARM, IAR 5.1112.57.5
x86, Borland C++ 32-bit11

7

Daten Größe

Die Daten Größe die im RAM benötigt wird, hängt von der Flash Größe, der maximalen Anzahl an Dateien und der Cluster Größe ab. In Zahlen in dem folgenden Beispiel beziehen sich auf einen 16MB Flash Chip mit einer Blockgröße von 16kB.

DateienCluster Größe (kB)RAM (Bytes)
100409620398
100102451886
1024512116971

>>> Preise anfragen

Embedded Tools GmbH
Fon: +49 251 98729-0 / Fax: -20
E-Mail info(at)embedded-tools.de


Firma:
Titel:
Vorname:
Nachname: *
Straße:
PLZ:
Ort:
Land:
E-Mail: *
Telefon:
Nachricht:
Target-Prozessor(en):
Wie haben Sie von uns erfahren: