Hallo,
Ich muss in einen Flash-Speicher mit Daten beschreiben (Als Rollpuffer,
geschrieben wird
Einmal pro Minute). Dazu habe ich einen Lese und einen Schreibzeiger,
welche immer die entsprechenden Flash-Adresse enthalten. Leider sind
diese im RAM abgelegt, d.h. wenn ich mein System ausschalte, sind sie
weg. Wenn ich das System wieder einschalte möchte ich an der gleichen
Stelle weiter lesen/schreiben an der ich vorher aufgehört habe.
Nun habe ich mir schon drei Wege ausgedacht, wie man dies realisieren
kann:
1. Ich lege meinen Lese und Schreibzeiger immer auf einer Adresse im
Flash ab.
Vorteil: Ich weiß genau wo sie stehen, muss sie nur auslesen und
kann weitermachen
wo ich aufgehört habe
Nachteil: Die maximal möglichen Schreibzyklen sind schnell
aufgebraucht.
2. Ich erstelle sowas ähnliches wie eine verkettete Liste, indem ich
die Speicheradresse des
nächsten Elements im mit im Flash ablege und das Ende mit einem
Wert markiere,
welcher einzigartig ( z.B. eine ungültige Flash-Adresse) ist.
2.1 Ich markiere jeweils die nächste zu schreibende Adresse mit einem
einzigartigen Wert.
Nachteil: Ich halbiere die Anzahl der Schreibzyklen, da ich jede
Zelle zweimal anfassen
muss (einmaliger Zeiger raus, neuer Zeiger rein)
Funktioniert nur für Schreiben
3. Ich messe mit einem ADU meine Versorgungsspannung (24 VDC, vor dem
Netzteil) und baue einen großen Kondensator ein. Wenn die
Versorgungsspannung sinkt speichere ich meine Lese- und Schreibzeiger
weg.
Gibt es noch andere komfortablere Möglichkeiten? Wie macht das zum
Beispiel ein Handy? Das muss ja auch wissen an welchem Speicherort die
Dateien des Benutzers liegen.
:
Verschoben durch User
Erik K. schrieb: > Wie macht das zum Beispiel ein Handy? Wenn du dein Handy ausschaltest ist es noch lange nicht ausgeschaltet. Erst wenn du gewaltsam den Akku vom Handy trennst.
@Mitlesa: Ja schon, aber selbst wenn ich den Akku rausnehme weiß es noch wo was zu finden ist ;)
Ich verstehe dein Problem nicht. Sagen wir, Du hast 8 Segmente je 64k Am Anfang alle leer (ff) Jetzt schreibst Du eines nach dem anderen voll. Beim nächsten Mal machst Du am ersten leeren Eintrag weiter. Bevor das letzte Segment voll ist, löscht Du das erste. Es reicht also aus, wenn jeder Eintrag zwingend ungleich alles ff ist. Das Suchen der aktuellen schreibstelle erfordert beim Neustart etwa ein Dutzend lesevorgänge, ist also unrelevant.
Ist die Hardware selber festgelegt/vorgegeben, oder kannst Du die frei wählen? Wie groß ist Dein Flashbereich? Ist der zu schreibende Block immer gleich groß? Je nach Randbedingungen gibt es vielfältige Möglichkeiten: 1. Du könntest batteriegepuffertes SRAM oder auch FRAM (das braucht keine Batteriepufferung, aber die Anzahl der zulässigen Schreibzyklen sind so hoch, dass das keine wirkliche Begrenzung darstellt) verwenden. Gibts parallel und seriell/SPI und ist erprobte Technik. Die Puffer-Knopfzelle reicht 10 Jahre in so einer Anwendung, wenn man es richtig macht. 2. Du schreibst einen Block und löschst im gleichen Zyklus den nächsten Block. Beim einem Systemstart musst du einmalig nur alle Blöcke von Anfang an durchgehen, bis Du den nächsten freien Block gefunden hast. 3. Du schreibst immer einen Sequenzzähler mit in Deinen Block. Bei einem Neustart gehst Du die Zählereinträge aller Blöcke durch, und da, wo Du einen Sprung hast, ist quasi das Ende der geschriebenen Daten. Insbesondere bei den flash-basierten Methoden musst Du damit rechnen, dass der Rechner während eines Schreib- oder Löschvorgangs ausgeschaltet oder resettet wird. Dazu kommt, dass die chipinternen Schreib- und Löschvorgänge teilweise viele, viele 10 oder 100ms dauern können, vor allem, wenn der Block schon viele Schreib-/Löschzyklen hinter sich hat. Diese Zeit ist nicht konstant, sondern steigt stetig an. Du musst also zwingend defekte Blöcke erkennen können, sonst knallt es bei Dir irgendwann einmal richtig. CRC-Prüfsummen und Fehlerkorrekturalgorithmen sind also Pflicht, da wirst Du nicht drumrum kommen. Und wenn das Flash, in das Du schreiben willst, das gleiche ist, in dem Dein Code abläuft, dann muss Dir bewusst sein, dass der Prozessor während eines Schreib- oder Löschzyklus eben steht. Und wenn der Löschzyklus 10ms dauert, weil der Block fast am Ende ist, dann steht der gesamte Prozessor eben für diese 10ms komplett still. Datenblatt lesen! Oft ist das interne Flash geteilt, d.h. wenn die Schreibroutine im Bootblock steht, kannst Du trotzdem den Hauptbereich beschreiben, ohne den Zugriff auf den Bootblock zu blockieren. Mit externem Flash hast Du diese Probleme nicht. Bei SRAM/FRAM Medien ist das alles nicht so kritisch, weil Du da ja wahlfrei schreiben kannst und die Zugriffe um Zehnerpotenzen schneller sind. Heißt also: Der erste Schreibvorgang macht den Block ungültig, dann werden die Daten geschrieben, dann CRC, um eventuelle Bitkipper bei halbleerer Batterie zu erkennen, und als letztes wird der Block als gültig markiert. Damit ist der jeweilige Block immer in einem definierten Zustand. Und wenn die einfachen Lösungen nicht zum Ziel führen, nimmst Du Dir den Linux-Kernel und schaust nach, wie die das dort bei yaffs, jffs und wie sie alle heißen machen. fchk
Guten Morgen, Erst einmal Danke für eure Antworten. @Achim S. Ist auf jeden Fall eine Möglichkeit die ich in Betracht ziehen werde. @Frank K. > Ist die Hardware selber festgelegt/vorgegeben, oder kannst Du die frei wählen? Die Hardware kann ich theoretisch frei wählen, allerdings bin ich durch die Belegung meiner MCU etwas eingeschränkt, da diese nur ein SPI-Interface für den Flash übrig hat. Weiterhin muss ich auf die Kosten des Projekts achten. > Wie groß ist Dein Flashbereich? Momentan ist mein Flash 16 Mbit groß. > Ist der zu schreibende Block immer gleich groß? Ja, der zu schreibende Block ist immer gleich groß (64 Byte). Geschrieben werden soll übrigens einmal pro Minunte . 1. Eine Batterie habe ich leider nicht zur Verfügung und ich kann auch keine vorsehen, da dies die Einsatzbedingungen der Anwendung nicht hergeben. 2. Ja kann man machen. 3. Da ich sowieso noch freien Speicher in meinem 64 Byte Block habe werde ich diese Variante bevorzugen. > Du musst also zwingend defekte Blöcke erkennen können, sonst knallt es bei Dir >irgendwann einmal richtig. CRC-Prüfsummen und Fehlerkorrekturalgorithmen sind >also Pflicht, da wirst Du nicht drumrum kommen. Das war mir bis jetzt noch nicht direkt bewusst, danke für den Hinweis.
:
Bearbeitet durch User
Vielleicht ganz hilfreich: http://www.st.com/content/ccc/resource/technical/document/application_note/ee/ef/d7/87/cb/b7/48/52/CD00165693.pdf/files/CD00165693.pdf/jcr:content/translations/en.CD00165693.pdf Ev kannst Du einige Prinzipien daraus übernehmen. Gruß, Stefan
Erik K. schrieb: > Ich muss in einen Flash-Speicher mit Daten beschreiben (Als Rollpuffer, > geschrieben wird Was für ein Flash? NOR-Flash, wie µC-Programm/Datenspeicher, Dataflash-Chips. MB-Bereich. NAND-Flash, z.B. SD-Card, eMMC (Handy), GB-Bereich. Diese beiden Techniken sind so verschieden, dass man sie nicht gemeinsam betrachten sollte.
:
Bearbeitet durch User
Du kannst auch ein freies oder (besser weil funktionierendes) kommerzielles file system mit Flashtreiber einsetzen. Die besseren können sogar (im gewissen Rahmen) Fail Safe Operation betreiben, also Datenkohärenz garantieren. Dafür hast Du natürlich durch die Clusterverwaltung overhead, d.h. Dir stehen nicht die gesamten 16M zur Verfügung. Win some, lose some. Wichtig ist auch zu bedenken, welche Blockgrösse dein Flashbaustein hast. Deine Grösse von 64 byte ist nicht unbedingt relevant für die Betrachtung, weil die Lebensdauerbegrenzung für flashes von der physikalischen Blockgrösse abhängt. Die maximal garantierte Löschzyklenanzahl pro Block liegt bei NOR flashes z.B. typischerweise um die 100000. Wenn ein physikalischer Block sagen wir mal 192k gross ist, musst Du im Laufenden Betrieb für jeden Block von 64k, den Du beschreibst, die gesamten 192k löschen, in denen deine zu ändernden 64k liegen (Sonderfälle wie Erstbeschreibung akademisch). Wenn Du also pro Minute einen 64k Block umbeschreibst, wird ein Block innerhalb von 3 Minuten 3 mal gelöscht, und dann 253 Minuten nicht mehr (16M Flash), also in 4,2 Minuten 3 Löschzyklen. Wenn meine Mathematik nicht völlig daneben ist, reichen die 1000 Zyklen damit für ca. 8333 Minuten ~ 347 Tage. ach weniger als einem Jahr darfst Du dann also mit den ersten Ausfällen rechnen. Kannst Du Dir das leisten? Filesysteme haben u.A. auch den Vorteil, dass sie für Dich Load Balancing übernehmen, also Löschzyklen minimieren. Das tun z.B. auch die Controller in SD Karten (weswegen es im Sinne der Lebensdauer auch vorteilhaft ist, grössere Bausteine als gebraucht zu wählen).
A. K. schrieb: > Erik K. schrieb: >> Ich muss in einen Flash-Speicher mit Daten beschreiben (Als Rollpuffer, >> geschrieben wird > > Was für ein Flash? > NOR-Flash, wie µC-Programm/Datenspeicher, Dataflash-Chips. MB-Bereich. > NAND-Flash, z.B. SD-Card, eMMC (Handy), GB-Bereich. > > Diese beiden Techniken sind so verschieden, dass man sie nicht gemeinsam > betrachten sollte. Hat er doch geschrieben. 16 MBit SPI. Also NOR, vermutlich mit 4k-Sektoren und 256 Byte Pages. 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.