Forum: Mikrocontroller und Digitale Elektronik FatFS, Serial Flash und Sektor Size


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von User M. (user_41)


Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen,
ich möchte in einem Projekt ein SPI NOR Flash benutzen, um darauf 
Dateien zu sichern. Bisher wurde hierfür eine SD-Karte benutzt 
(funktioniert einwandfrei), jedoch ist dies zu teuer, da 2-4 MB Speicher 
bereits reichen.
Jetzt geht es darum, FatFS mit einem NOR Flash zu betreiben.
Man kann im FatFS die Sektorgröße einstellen. Bei der SD-Karte war 
dieser Wert auf 512 Byte eingestellt. Jedoch haben sogut wie alle Flash 
Speicher eine Größe von 4 kB. Stellt man FatFS jedoch auf diesen Wert 
ein, wird mein RAM gesprengt (da außerdem noch LwIP mit Webserver auf 
dem Controller läuft und noch andere kleinere Dinge). Daher muss ich den 
Wert auf 1024 oder 512 (was mir lieber wäre) lassen.

Lesen vom Speicher ist überhaupt kein Problem.
Jedoch habe ich eine Verständnisfrage bzgl. dem Schreiben bzw. Löschen.

Wenn ich bei FatFS eine Sektorgröße von 512 Byte einstelle, die Sektoren 
jedoch 4 kB haben, dann kann dies nicht funktionieren. Ich könnte von 
jedem Sektor vom Flash nur die ersten 512 Byte nutzen, jedoch verliere 
ich damit ja dann 7/8 von meinem Speicher.
Wenn ich aber den ganzen Sektor vom Flash nutze (bspw. Datei A nutzt 768 
Byte, Datei B beginnt dann im selben Sektor bei Byte Nr. 1024 und belegt 
500 Byte) habe ich Probleme beim Löschen. Denn wenn ich bspw. Datei A 
gelöscht habe, ist der Sektor wieder frei (er ist jedoch noch nicht auf 
0xFF gelöscht, da nur der Index aus der FAT Tabelle gelöscht wurde). 
Schreiben kann ich in den Sektor jetzt aber nicht, da eben nicht 0xFF 
drinnen steht. Dazu muss ich zunächst den Sektor löschen, damit verliere 
ich dann aber auch wieder Datei B.

Ich hoffe man versteht was ich meine.

Also wie könnte ich das Problem lösen?

Danke!

von Jim M. (turboj)


Bewertung
1 lesenswert
nicht lesenswert
User M. schrieb:
> Also wie könnte ich das Problem lösen?

SPI Flash durch eine MicroSDHC ersetzen. Kommt preislich ungefähr aufs 
Gleiche raus, und die SD(HC) Karten arbeiten mit 512 Byte Sektoren.

Ansonsten nehme man den nächstgrößeren µC mit ausreichend RAM.

Falls Schreiben extrem lahm sein darf: FRAM oder MRAM mit an den SPI 
hängen, und dort die 4kB (oder ggf. entsprechend mehr) puffern.

von Falk B. (falk)


Bewertung
0 lesenswert
nicht lesenswert
@User M. (user_41)

>Wenn ich aber den ganzen Sektor vom Flash nutze (bspw. Datei A nutzt 768
>Byte, Datei B beginnt dann im selben Sektor bei Byte Nr. 1024

Das geht bei FAT nicht, die Dateien werden clusterweise gespeichert. 
Damit kommen sich Dateiinhalte auch nicht zu nahe.

>Schreiben kann ich in den Sektor jetzt aber nicht, da eben nicht 0xFF
>drinnen steht. Dazu muss ich zunächst den Sektor löschen, damit verliere
>ich dann aber auch wieder Datei B.

Nein. Du mußt bei der Zuweisung eines neuen Clusters an eine Datei eben 
diesen löschen. Der Cluster ist im Normalfall 32kB, also ein Mehrfaches 
deiner Sektoren. Dann paßt das. Man kann hier die Cluster auch auf 4kB 
runterschrauben, dann verliert man vor allem bei vielen kleinen Dateien 
nicht soviel Speicher.

Eine nette Fingerübung, wenn gleich eine SD-Karte bei heutigen Preise 
die einfachere und ökonomischere Variante ist.

von Michael U. (amiga)


Bewertung
0 lesenswert
nicht lesenswert
Hallo,

schau Dir mal https://github.com/pellepl/spiffs ab.
SPIFFS wird auf den ESP8266/ESP32 benutzt und macht keine Probleme.
ich weiß allerdings nicht, wie weit die ESP-Versionen inzwischen von 
obiger Source abweichen. Aber da kann man reinschauen bzw. diese Version 
nutzen.
https://github.com/esp8266/Arduino/tree/master/cores/esp8266/spiffs

Auf dem ESP32 hat es zumindest noch eine einfache Directory-Verwaltung 
bekommen, obwohl ich meine, daß man die in solchen Anwendungen nicht 
unbedingt braucht.

Gruß aus Berlin
Michael

: Bearbeitet durch User
von Dr. Sommer (Gast)


Bewertung
0 lesenswert
nicht lesenswert
User M. schrieb:
> Jetzt geht es darum, FatFS mit einem NOR Flash zu betreiben

Ist NAND-Flash nicht viel billiger? Konnte man NOR-Flash nicht sowieso 
Byteweise löschen? Verwirrend.

von Peter M. (r2d3)


Bewertung
1 lesenswert
nicht lesenswert
Hallo User M.,

User M. schrieb:
> Ich hoffe man versteht was ich meine.

Ich verstehe perfekt, was Du meinst.

> Also wie könnte ich das Problem lösen?

Dein Problem hat die Firmware jeder modernen Festplatte mit nativen 
4k-Sektoren, die nach außen hin 512 Byte emuliert.

Algorithmisch ist das kein Problem.

Dein Dateisystem muss die Möglichkeit bieten, Clustergrößen zu wählen, 
die kleiner sind als die physikalische Sektorgröße von 4k.

Es muss einfach nur zwischen physikalischer und logischer Sektorgröße 
unterscheiden.

Ist die logische Sektorgröße kleiner als die physikalische, ändert sich 
bei Lesevorgängen kaum etwas.

Bei Schreibvorgängen muss der physikalische Sektor von 4k in einen 
Puffer gelesen werden, der Bereich, der zu dem überschreibenden Sektor 
gehört mit 512 Bytes überschrieben werden und dann der physikalische 
Sektor komplett wieder weggeschrieben werden.

Das Ganze ist ein simples "Mapping"-Problem.

von User M. (user_41)


Bewertung
0 lesenswert
nicht lesenswert
Jim M. schrieb:
> SPI Flash durch eine MicroSDHC ersetzen. Kommt preislich ungefähr aufs
> Gleiche raus, und die SD(HC) Karten arbeiten mit 512 Byte Sektoren.

Wo bekomme ich MicroSD oder MicroSDHC Karten inkl. einem Halter für 
unter 2 €/Stück?

Jim M. schrieb:
> Ansonsten nehme man den nächstgrößeren µC mit ausreichend RAM.

Nö.

Jim M. schrieb:
> Falls Schreiben extrem lahm sein darf: FRAM oder MRAM mit an den SPI
> hängen, und dort die 4kB (oder ggf. entsprechend mehr) puffern.

Das wäre möglich, aber eigentlich auch nicht so sinnvoll.


Ich habe jetzt nicht im Detail nachverfolgt wie viel Puffer FatFS mit 
der Sektorgröße anlegt. Jedenfalls bekomme ich beim Versuch den Code mit 
eingesteller Sektorengröße von 4096 Byte eine Overflow Meldung von über 
20 kB. Das heißt für mich das mind. 5 Puffer in der Größe angelegt 
werden. Und da ist dann klar das der RAM sehr schnell gesprengt wird.

Michael U. schrieb:
> schau Dir mal https://github.com/pellepl/spiffs ab.
> SPIFFS wird auf den ESP8266/ESP32 benutzt und macht keine Probleme.
> ich weiß allerdings nicht, wie weit die ESP-Versionen inzwischen von
> obiger Source abweichen. Aber da kann man reinschauen bzw. diese Version
> nutzen.

Das klingt auch interessant. Würde aber nur ungern weg von FatFS, da 
dieses bereits voll integriert ist in die Applikation. Dennoch danke für 
den Vorschlag.

Dr. Sommer schrieb:
> Ist NAND-Flash nicht viel billiger? Konnte man NOR-Flash nicht sowieso
> Byteweise löschen? Verwirrend.

NAND-Speicher gehen bei ca. 2€ los, NOR-Speicher hingegen gibts schon ab 
0,16€. Nein, nicht das ich wüsste. Habe mehrere Datenblätter von 
verschiedenen NOR-Speichern da, und alle kann man nur Sektorweise (fast 
immer 4kB) löschen.

Peter M. schrieb:
> Bei Schreibvorgängen muss der physikalische Sektor von 4k in einen
> Puffer gelesen werden, der Bereich, der zu dem überschreibenden Sektor
> gehört mit 512 Bytes überschrieben werden und dann der physikalische
> Sektor komplett wieder weggeschrieben werden.
>
> Das Ganze ist ein simples "Mapping"-Problem.

Manchmal sieht man den Walt vor lauter Bäumen nicht. Eigentlich total 
simpel. Und einen Puffer mit 4kB anzulegen ist vom RAM Verbrauch kein 
Problem.
Vielen Dank für den Vorschlag!

von Peter M. (r2d3)


Bewertung
0 lesenswert
nicht lesenswert
Hallo User M.

User M. schrieb:
> Peter M. schrieb:
>> Bei Schreibvorgängen muss der physikalische Sektor von 4k in einen
>> Puffer gelesen werden, der Bereich, der zu dem überschreibenden Sektor
>> gehört mit 512 Bytes überschrieben werden und dann der physikalische
>> Sektor komplett wieder weggeschrieben werden.
>>
>> Das Ganze ist ein simples "Mapping"-Problem.
>
> Manchmal sieht man den Walt vor lauter Bäumen nicht. Eigentlich total

Geht mir genauso.

> simpel. Und einen Puffer mit 4kB anzulegen ist vom RAM Verbrauch kein
> Problem.
> Vielen Dank für den Vorschlag!

Ich freue mich über Deinen Dank!

von Falk B. (falk)


Bewertung
0 lesenswert
nicht lesenswert
@ User M. (user_41)

>Wo bekomme ich MicroSD oder MicroSDHC Karten inkl. einem Halter für
>unter 2 €/Stück?

Warum 2 Euro? Wieviele willst du davon kaufen bzw. verkaufen? Für 
Einzelstücke, Bastelprojekte etc. spielt das gar keine Rolle.

>Ich habe jetzt nicht im Detail nachverfolgt wie viel Puffer FatFS mit
>der Sektorgröße anlegt.

Einen Sektor.

> Jedenfalls bekomme ich beim Versuch den Code mit
>eingesteller Sektorengröße von 4096 Byte eine Overflow Meldung von über
>20 kB. Das heißt für mich das mind. 5 Puffer in der Größe angelegt
>werden.

Nö, da ist was faul. Es wird neben dem Sektorpuffer nur das Files System 
Objekt und Dateiobjekt angelegt, die sind aber unabhängig von der 
Sektorgröße. Es kann sein, daß noch ein 2. Puffer angelegt witrd, weiß 
ich im Moment nicht. 5 sind es aber mal sicher nicht.

>NAND-Speicher gehen bei ca. 2€ los, NOR-Speicher hingegen gibts schon ab
>0,16€.

Ahhh, der Pfennigfuchser.

> Nein, nicht das ich wüsste. Habe mehrere Datenblätter von
>verschiedenen NOR-Speichern da, und alle kann man nur Sektorweise (fast
>immer 4kB) löschen.

Logisch. Wir reden ja von FLASH, nicht EEPROM!

von Horst M. (horst)


Bewertung
0 lesenswert
nicht lesenswert
User M. schrieb:
> Jetzt geht es darum, FatFS mit einem NOR Flash zu betreiben.

Hm, ja.
Und FatFS bringt ein eigenes Wear Leveling mit?
100000 Löschzyklen pro Flash-Block klingen erstmal viel, aber die Blöcke 
mit der FAT werden ja doch ziemlich häufig überschrieben, umso mehr, 
wenn

Peter M. schrieb:
> Bei Schreibvorgängen muss der physikalische Sektor von 4k in einen
> Puffer gelesen werden, der Bereich, der zu dem überschreibenden Sektor
> gehört mit 512 Bytes überschrieben werden und dann der physikalische
> Sektor komplett wieder weggeschrieben werden.

so vorgegangen wird.
WIMRE kümmern sich die SD(HC)-Karten um exakt dieses Thema selbst.

von Michael U. (amiga)


Bewertung
0 lesenswert
nicht lesenswert
Hallo,

Horst M. schrieb:
> Und FatFS bringt ein eigenes Wear Leveling mit?

auch deshalb hatte ich auf SPIFFS verwiesen...
Fat ist so ziemlich das undankbarste für Flash.

Gruß aus Berlin
Michael

von Leo C. (rapid)


Bewertung
0 lesenswert
nicht lesenswert
User M. schrieb:
> Ich habe jetzt nicht im Detail nachverfolgt wie viel Puffer FatFS mit
> der Sektorgröße anlegt. Jedenfalls bekomme ich beim Versuch den Code mit

Solltest Du aber.

> eingesteller Sektorengröße von 4096 Byte eine Overflow Meldung von über
> 20 kB. Das heißt für mich das mind. 5 Puffer in der Größe angelegt
> werden. Und da ist dann klar das der RAM sehr schnell gesprengt wird.

FF_FS_TINY schon versucht?
1
#define FF_FS_TINY    1
2
/* This option switches tiny buffer configuration. (0:Normal or 1:Tiny)
3
/  At the tiny configuration, size of file object (FIL) is shrinked FF_MAX_SS bytes.
4
/  Instead of private sector buffer eliminated from the file object, common sector
5
/  buffer in the filesystem object (FATFS) is used for the file data transfer. */

von User M. (user_41)


Bewertung
0 lesenswert
nicht lesenswert
Horst M. schrieb:
> Hm, ja.
> Und FatFS bringt ein eigenes Wear Leveling mit?
> 100000 Löschzyklen pro Flash-Block klingen erstmal viel, aber die Blöcke
> mit der FAT werden ja doch ziemlich häufig überschrieben, umso mehr,
> wenn

Damit hast du schon Recht. Jedoch wird in diesem Fall eigentlich nur 
einmal mehrere Dateien auf den Speicher geschrieben. Danach nur noch 
gelesen. Allerhöchstens ein bis zweimal im Jahr wird ein Schreibzugriff 
erfolgen. Daher wird kein Wear Leveling benötigt.

Leo C. schrieb:
> FF_FS_TINY schon versucht?

Nein noch nicht. Jedoch ist mir beim durchlesen deiner Antwort 
eingefallen, warum der RAM Verbrauch so explodiert, sobald ich die 
Sektorgröße auf 4KB einstelle. Dies liegt nicht an FatFS, sondern an 
meiner Applikation. Nach einem Umbau dieser sollten die 4KB Sektorgröße 
kein Problem mehr sein.

von Mike J. (linuxmint_user)


Bewertung
0 lesenswert
nicht lesenswert
User M. schrieb:
> ich möchte in einem Projekt ein SPI NOR Flash benutzen, um darauf
> Dateien zu sichern. Bisher wurde hierfür eine SD-Karte benutzt
> (funktioniert einwandfrei), jedoch ist dies zu teuer, da 2-4 MB Speicher
> bereits reichen.

Ich bin auch gerade dabei NOR-Flash Speicher anzusteuern.

Siehe: Beitrag "MICRON MT25TL01 SPI FLASH"

Wie sehen die Daten welche du speichern und übertragen möchtest 
eigentlich aus? Wie willst du die Daten eigentlich übertragen?

Bei mir füllt sich der Speicher mit einer bestimmten Geschwindigkeit und 
ich schreibe die Daten einfach hintereinander in den Speicher den ich 
als Ringbuffer nutze. Auslesen dann über Bluetooth.

von User M. (user_41)


Bewertung
0 lesenswert
nicht lesenswert
Mike J. schrieb:
> Wie sehen die Daten welche du speichern und übertragen möchtest
> eigentlich aus? Wie willst du die Daten eigentlich übertragen?

Bei mir handelt es sich um eine kleine Webseite sowie ein Handbuch, 
welches auf dem Speicher hinterlegt wird. Die Daten werden über TFTP an 
den Controller geschickt, welcher dann die Daten an das NOR Flash 
weiterleitet.

von Mike J. (linuxmint_user)


Bewertung
0 lesenswert
nicht lesenswert
User M. schrieb:
> Mike J. schrieb:
>> Wie sehen die Daten welche du speichern und übertragen möchtest
>> eigentlich aus? Wie willst du die Daten eigentlich übertragen?
>
> Bei mir handelt es sich um eine kleine Webseite sowie ein Handbuch,
> welches auf dem Speicher hinterlegt wird. Die Daten werden über TFTP an
> den Controller geschickt, welcher dann die Daten an das NOR Flash
> weiterleitet.

Naja, man könnte auch einfach alles löschen und dann alle Daten neu 
schreiben wenn du die Daten auf dem Flash "updaten" möchtest. Dann 
umgeht man das Problem mit der 4kByte Cluster-Löschung.

Schreiben von 512Byte Blöcken ist ja kein Problem.

Wie oft werden denn die Daten erneuert oder verändert?

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.