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!
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.
@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.
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
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.
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.
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!
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!
@ 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!
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.
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
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. */ |
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.
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.
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.
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?
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.