Forum: Mikrocontroller und Digitale Elektronik Speicheradressverwaltung Flash-Speicher


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 Erik K. (Firma: miunske GmbH) (oleeiner)


Bewertung
0 lesenswert
nicht lesenswert
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 Moderator
von Mitlesa (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Erik K. (Firma: miunske GmbH) (oleeiner)


Bewertung
0 lesenswert
nicht lesenswert
@Mitlesa:
Ja schon, aber selbst wenn ich den Akku rausnehme weiß es noch wo was zu 
finden ist ;)

von A. S. (achs)


Bewertung
0 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
von Frank K. (fchk)


Bewertung
0 lesenswert
nicht lesenswert
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

von Erik K. (Firma: miunske GmbH) (oleeiner)


Bewertung
0 lesenswert
nicht lesenswert
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
von Stefan K. (stefan64)


Bewertung
0 lesenswert
nicht lesenswert

von (prx) A. K. (prx)


Bewertung
0 lesenswert
nicht lesenswert
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
von Adapter (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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).

von Frank K. (fchk)


Bewertung
0 lesenswert
nicht lesenswert
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

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.