Hallo zusammen
Ich möchte in meiner Anwendung ein FLASH-IC verwenden.
Der Speicherbaustein hat 4Mbyte * 8bit = (32MBit)
Angesprochen wird dieser Seriell.
Damit ich nun ohne gross zu überlegen und möglichst effizient, Daten wie
z.B. kleine Grafiken etc darauf ablegen kann,
dachte ich es wäre eventuell sinnvoll, ein Dateisystem darauf laufen zu
lassen.
Ich dachte dabei an die petitFAT Library von elmchan
Was denkt ihr dazu?
Gibt es bessere wege oder ist dies die optimale lösung?
Bei 4 MByte wird es auf FAT12 hinauslaufen, mit etwas über 8000 Clustern
à 512 Byte (1 Sektor pro Cluster). Damit ist eine FAT knapp 13 kByte
groß, was, je nach verwendetem Controller und Arbeitsspeicher, Du
komplett im RAM cachen kannst, was sich recht positiv auf die
Performance auswirkt - beim Schreiben solltest Du allerdings die FAT im
Flash-ROM aktualisieren, sonst gibt's Datensalat.
Bei FAT12 ist allerdings die Verwaltung einzelner FAT-Einträge lästig,
da diese eben nur 12 Bit groß sind.
Wenn Du stattdessen FAT16 verwendest, steigt aber der Speicherbedarf pro
FAT auf 16 kByte.
Rufus Τ. Firefly schrieb:> Wenn Du stattdessen FAT16 verwendest, steigt aber der Speicherbedarf pro> FAT auf 16 kByte.
Damit meinst du dass ich im gegensatz zu FAT12 mit 13kb nun halt etwa
3kb mehr platz "opfern" muss richtig?
Aber ansonsten müsste das ja mit der FAT Lib von elmChan funktionieren
oder?
Flashes können sektorweise beschrieben werden. Löschen kann man aber nur
in deutlich größeren Blöcken. Wenn ein Block größer als ein Cluster ist,
wird es nicht mehr so einfach. Das ist ein Punkt, wo Du aufpassen musst.
Wie häufig wird geschrieben? Flashes haben nur eine endliche Zahl an
Löschzyklen pro Block, und die FAT wird extrem häufig geschrieben.
möglicherweise ist es sinnvoll, für die FAT ein extra FRAM vorzuhalten.
Das ist nichtflüchtig wie Flash, aber schnell wie RAM und hat quasi
unbegrenzt Schreibzyklen, und vorher Löschen brauchst Du auch nicht.
Sind aber recht teuer und nur in kleinen Kapazitäten verfügbar.
Was für ein Flash ist es denn genau?
Tim schrieb:> Damit meinst du dass ich im gegensatz zu FAT12 mit 13kb nun halt etwa> 3kb mehr platz "opfern" muss richtig?
Exakt.
Den von fchk angesprochenen Punkt der vom Flash verwendeten Blockgröße
solltest Du allerdings auch berücksichtigen - und zusätzlich bedenken,
daß Dein Flash-Baustein ein controllerloser Flash-Baustein sein dürfte,
also kein Wear-Leveling durchführt.
Sofern Du mehr als nur einige ganz wenige Schreiboperationen vorhast,
solltest Du Deine Strategie noch mal überdenken, und als Alternative die
Verwendung einer (micro-)SD-Karte vorsehen.
Die hätte den Vorteil, daß ein Datenaustausch mit einem PC ganz simpel
ist, daß die Kapazität in ganz anderen Größenordnungen lieg, daß es
dafür ausreichend viele ausreichend gut getestete Code-Beispiele gibt
und daß der da verbaute Controller sich auch um das Wear-Leveling
kümmert.
Und preislich wird sich das vermutlich auch nicht auswirken.
fchk schrieb:> Wie häufig wird geschrieben?
Nicht sehr oft.
Es geht darum kleine grafiken für ein Display zu speichern.
Eventuell auch mal eine konfiguration.
Aber sowas wird ja nicht ständig geändert.
Vielleicht ein paar hunder mal im schlimmsten fall über den gesamten
lebenszyklus des prduktes gesehen.
Rufus Τ. Firefly schrieb:> und zusätzlich bedenken,> daß Dein Flash-Baustein ein controllerloser Flash-Baustein sein dürfte,> also kein Wear-Leveling durchführt.
Deshalb habe ich kein NAND sondern ein NOR Flash gewählt.
Nach meinen Recherchen, braucht ein NOR grundsätzlich kein Wear Leveling
und Bit-Korrektur.
Rufus Τ. Firefly schrieb:> Sofern Du mehr als nur einige ganz wenige Schreiboperationen vorhast
Habe nicht sehr viele vor...
fchk schrieb:> Was für ein Flash ist es denn genau?
N25Q032A13ESE40G
http://www.farnell.com/datasheets/1674439.pdf
Tim schrieb:> Deshalb habe ich kein NAND sondern ein NOR Flash gewählt.> Nach meinen Recherchen, braucht ein NOR grundsätzlich kein Wear Leveling> und Bit-Korrektur.
Auch NOR-Flash kann wear-leveling nötig haben, nämlich um (wie das Wort
schon sagt), die "Abnutzung" durch Schreibzugriffe gleichmäßig über den
ganzen Chip zu verteilen und damit die nutzbare Lebensdauer zu steigern.
Wenn man ein Dateisystem verwendet, bei dem nach jedem Schreibzugriff
auf egalwelche Datei nochmal eine zentrale Stelle (z.B. FAT) beschrieben
werden muß, dann ist klar, welcher Sektor des Flashs zuerst ausfällt und
wann. Wenn man das ein bißchen verteilt, hält der Chip deutlich länger,
jedenfalls bei typischer Nutzung.
Der Vorteil bei NOR-Flash ist, daß die Zusammenhänge noch überschaubar
sind; ein Filesystem für eine bestimmte Anwendung, das auf die
Eigenheiten des Flashs Rücksicht nimmt, kann sich jeder nach etwas
Datenblattlesen selbst ausdenken. Bei NAND-Flash wird es komplizierter:
Lesen führt auch zu Abnutzung, so daß gelegentlich "refresh" nötig ist,
Schreiben beeinträchtigt auch benachbarte Sektoren, und überhaupt
rechnet niemand damit, daß man die Daten fehlerfrei zurücklesen kann,
weshalb für jeden Sektor auch gleich Platz für Fehlerkorrekturcodes
eingebaut ist. NAND-Flash zu betüdeln überläßt man deshalb lieber
Spezialisten.
Nosnibor schrieb:> NAND-Flash zu betüdeln überläßt man deshalb lieber> Spezialisten.
Danke für eure Antworten.
Also wenn ich das richtig lese, spricht nichts gegen die Verwendung
eines NOR Flashes zusammen mit FAT16.
Solange sich die Zugriffe im Rahmen halten.
Tim schrieb:> Nosnibor schrieb:>> NAND-Flash zu betüdeln überläßt man deshalb lieber>> Spezialisten.>> Danke für eure Antworten.>> Also wenn ich das richtig lese, spricht nichts gegen die Verwendung> eines NOR Flashes zusammen mit FAT16.>> Solange sich die Zugriffe im Rahmen halten.
Nein. Achte nur darauf, dass alles auf 4k-Blöcke ausgerichtet ist, denn
das ist die Organisation Deines Flashes. Würdest Du dieses am PC
formatieren, wäre das nicht unbedingt der Fall. Überlege Dir also, ob Du
nicht gleich mit einer Sektorgröße von 4k statt 512 Byte arbeiten
willst. Das muss Deine FAT-Library auch können!
fchk
