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
:
Bearbeitet durch User
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?
dotm schrieb: > Bemerkenswert ist dass die Routinen der Implementation von ST > tatsächlich mindestens 2k RAM brauchen, siehe schau dir mal die Implementation für einen STM32F4 an : "Application note AN3969" http://www.st.com/st-web-ui/static/active/en/resource/technical/document/application_note/DM00036065.pdf die kommt mit sehr viel weniger RAM aus
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.