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
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.