Diese Routinen erlauben dem Benutzer, im Flash eines STM32 Bausteins
einen nichtflüchtigen Speicher zu erstellen, wenn z.B. aus
Platz-/Preisgründen auf externe IC's verzichtet möchte. Abgelegt werden
die nichtflüchtigen Daten im oberen Bereich des Flashes.
Zu beachten:
- geeignet für Anwendungen zum Abspeichern von Werten, die nach Reset zu
Verfügung stehen sollen. Ungeeignet für Anwendungen, die den Speicher
oft beschreiben.
- Zum Speichern je Byte wird im Flash ein Word belegt. Somit hat man die
Hälfte der Flash-Kapazität die als EEPROM zu Verfügung steht.
- Beim Re-Programmieren des Controllers, sollte man darauf achten, dass
nur betroffene Pages des Programms gelöscht werden und nicht der gesamte
Flash. Im anderen Fall sind nach dem Re-Programmieren die
nichtflüchtigen Daten auch weg.
Artur Funk schrieb:> - Zum Speichern je Byte wird im Flash ein Word belegt. Somit hat man die> Hälfte der Flash-Kapazität die als EEPROM zu Verfügung steht.
Warum wird nicht das ganze Word genutzt?
Hi Artur,
so wie ich deinen Code verstanden habe,
wird jedesmal wenn ein Byte an einer schon beschriebenen Adresse
geschrieben werden soll der komplette Flash-Block umkopiert
...das finde ich nicht sehr elegant
(gerade wegen der begrenzten Schreibzyklen vom Flash)
von STM gibt es ein Beispiel für das erzeugen eines virtuellen EEProm
per internem Flash
dort landet jedes Byte bei jedem Write (egal in welche Adresse)
im ersten Flash-Block...und erst wenn dieser Block komplett gefüllt ist,
wird er in den zweiten Block umkopiert und gelöscht
für den STM32F4 hab ich hier ein Beispiel dazu :
http://mikrocontroller.bplaced.net/wordpress/?page_id=2335
Gruss Uwe
Flugit schrieb:> Warum wird nicht das ganze Word genutzt?
Weil Flash sich wordweise beschreiben lässt, byteweise schreiben würde
das die Anzahl der Schreibzyklen noch weiter reduzieren.
Uwe B. schrieb:> Hi Artur,>> so wie ich deinen Code verstanden habe,> wird jedesmal wenn ein Byte an einer schon beschriebenen Adresse> geschrieben werden soll der komplette Flash-Block umkopiert> ...das finde ich nicht sehr elegant> (gerade wegen der begrenzten Schreibzyklen vom Flash)
Ja das ist so, deshalb die Bemerkung wann die Lösung geeignet ist :)
Im Allgemeinen ist man in der Kreativität wenig "eingeschränkt", da das
Löschen nur Pageweise geht.
> von STM gibt es ein Beispiel für das erzeugen eines virtuellen EEProm> per internem Flash> dort landet jedes Byte bei jedem Write (egal in welche Adresse)> im ersten Flash-Block...und erst wenn dieser Block komplett gefüllt ist,> wird er in den zweiten Block umkopiert und gelöscht
Ja ST hat es elegant gelöst, für meinen Fall jedoch ein wenig
überdimensioniert gewesen, deshalb die Lösung.
Artur Funk schrieb:> Ja ST hat es elegant gelöst, für meinen Fall jedoch ein wenig> überdimensioniert gewesen, deshalb die Lösung.
ok...das ist ein Argument, es sollte auch keine Kritik von meiner Seite
aus sein, sondern nur ein Hinweis
Gruss
Hi,
habe mich auch mit EEPROM Simulation die Tage beschäftigt (STM32F103)
Dabei ist mir aufgefallen, das bei zu speichernden 16bit Werten mit der
Funktion "FLASH_ProgramHalfWord(Address, Data)" wenn diese zufällig
0xFFFF, also einer gelöschten Zelle entsprechen, das Programm in der
Fault-Loop landet.
Gruß Ingo
Ethernut kennt dazu NutNvMemSave und NutNvMemLoad. In Ethernut SVN wird
diese Api für STM32F1/2/3/4 mit Flash emuliert. Fuer F1/2/3/4 ist ein
einfachen Wear-leveling implementiert. Ein Beispiel ist unter
apps/flashtest zu finden, dass man z.b. für das F3Discovery Board bauen
kann.
Hallo
nette Sache
allerdings hat das ST-Beispiel ZWEI Features implementiert:
a) es werden zwei Blöcke benutzt und ein Block wird erst umkopiert wenn
er voll ist (minimiert flash erases)(aber ermöglicht auch Punkt b)
b) es wird ein StatusWord gespeichert an dem erkannt wird ob ein Vorgang
(löschen,schreiben,kopieren) erfolgreich ausgeführt wurde
In dem Beispiel ist weder (a) noch (b) berücksichtigt. Punkt (a) finde
ich ebenfalls für Hobbiesten-Zwecke völlig überdimensioniert und
unpraktisch... wer schafft schon 10000 Konfigurationsänderungen...,
allerdings finde ich die Argumente für Punkt (b) doch ziemlich
bedenkenswert um eine Datenkonsistenz zu erreichen.
Ich habe das daher so gemacht, dass ich auch zwei Pages benutze, und ein
StatusWord, wobei Page0 sozusagen die Master-Page ist, und Page1 immer
eine Kopie. Gelesen wird ähnlich wie oben immer von Page0, geschrieben
wird sowohl in Page0 und Page1, und beim Programstart wird anhand der
Statuswords gecheckt ob die Pages ok sind und wenn nicht was man tun
kann. So hat man es ähnlich knapp und bündig, aber die deutlich erhöhte
Datensicherheit aufgrund der Doppelpages.
Olli
Ich denke jeder weiss worum es geht wenn von EEPROM Emulator die Rede
ist...
Und warum die Daten noch da sein sollten wenn man das komplette Flash
löscht(was je nach Flasher Tool durchaus die Standardeinstellung ist)
weisst du sicherlich auch?! Von daher ist die Warnung doch völlig
berechtigt.
Mit dem Byte/Word schreiben darüber kann man sicherlich streiten, aber
dafür um wenige Konfigdaten abspeichern zu können ist das doch super Mr.
Meckerquatschkopp.
Quatsch^3 schrieb im Beitrag #3368471:
> Artur Funk schrieb:>> Diese Routinen erlauben dem Benutzer, im Flash eines STM32 Bausteins>> einen nichtflüchtigen Speicher zu erstellen, wenn z.B. aus>> Platz-/Preisgründen auf externe IC's verzichtet möchte. Abgelegt werden>> die nichtflüchtigen Daten im oberen Bereich des Flashes.>> Was hat die ganze Angelegenheit mit einem EEProm zu tun? Willst du die> Allgemeinheit mit deinen Flash-Schreibroutinen beglücken?
Da oben steht es doch, dass es sich um einen "Emulator" handelt
>> Zu beachten:>> - geeignet für Anwendungen zum Abspeichern von Werten, die nach Reset zu>> Verfügung stehen sollen. Ungeeignet für Anwendungen, die den Speicher>> oft beschreiben.>> Warum?
Weil ein Flash im Gegensatz zum EEPROM/FRAM nicht so oft beschrieben
werden kann. ST garantiert 100k Zyklen.
>> - Zum Speichern je Byte wird im Flash ein Word belegt. Somit hat man die>> Hälfte der Flash-Kapazität die als EEPROM zu Verfügung steht.>> Was für ein Quatsch.
Quatsch ist es nicht, es ist aus der Tatsache entstanden, dass die Daten
im Flash nur Word weise beschrieben werden können. Würde man in einem
Word zwei Byte unterbringen, müsste man die Pages doppelt so oft
löschen. Dementsprechend hätte man noch weniger Schreibzyklen.
>> - Beim Re-Programmieren des Controllers, sollte man darauf achten, dass>> nur betroffene Pages des Programms gelöscht werden und nicht der gesamte>> Flash. Im anderen Fall sind nach dem Re-Programmieren die>> nichtflüchtigen Daten auch weg.>> Aha, das will ich ja mal sehen.
Grundlagen muss ich hier nicht erläutern oder?
Hallo Artur und Forum.
Ich muss dieses Thema nochmal aufgreifen weil ich auf der Suche nach
einer alternativen Eeprom- Emulation bin.
Bemerkenswert ist dass die Routinen der Implementation von ST
tatsächlich mindestens 2k RAM brauchen, siehe
http://www.bdtic.com/DownLoad/ST/AN4056.pdf
auf Seite 12.
Ich hab mir dazu die Firmware angesehen:
http://www.st.com/web/catalog/tools/FM147/CL1794/SC961/SS1743/PF258153#
Und leider kann ich ihm nicht den Speicherplatz im RAM zuteilen in dem
er arbeiten soll.
Mein Hauptproblem ist nämlich dass ich mit dem RAM schon völlig am Ende
bin. Ich mache Signalverarbeitung im MCU und da wird es sehr eng.
Anderen RAM-intensiven Bibliotheken wie z.B. SSL kann ich den zu
verwendenden Speicherplatz zuteilen, dadurch kann ich meine
Samplespeicher kurzzeitig anderweitig verwenden nur ich befürchte 2k
kann ich nicht guten Gewissens aufbringen.
Ich denke ST verwendet den RAM um eine Page zwischenzuspeichern. Das ist
bei mir nicht notwendig.
Genauso brauch ich kein wear-levelling und ich muss auch nicht auf die
Datenintegrität im Falle eines Stromausfalles achten.
Deswegen meine Frage an Artur: wie siehts denn mit den Anforderungen ans
Ram aus? Sind deine Routinen für mich eine Alternative?
