Hallo Zusammen,
ich würde gerne tracken, wie lange mein System seit dem ersten mal
einschalten insgesamt gelaufen ist (Hauptsächlich für Loggingzwecke).
Der Microcontroller soll ein STM32F4 werden.
Der Plan wäre gewesen, nach jedem Einschalten des Systems die bisherige
Systemlaufzeit zu laden und alle 1ms diesen Wert um eins zu
inkrementieren (1ms reicht für meine Zwecke dicke). Der Knackpunkt an
der Geschichte ist das Speichern der aktuellen Systemlaufzeit, so dass
ich sie auch wieder Laden kann. Vor allem vor dem Hintergrund, dass die
Spannungsversorgung jederzeit abbrechen kann ("Ausschalten").
Wie wird sowas denn typischerweise realisiert?
Vielen Dank und Grüße!
hp-freund schrieb:> Mit einer backup Batterie, dem backup SRAM und backup RTC Registern ist> eine Variante.
Der Prozessor hat extra Register die den Inhalt nicht verlieren solange
die Backup Domain unter Spannung steht.
Alternativen dazu wenn keine Spannung mehr anliegt: Im internen EEPROM
speichern (wenn vorhanden, ich denke die F4 haben das noch nicht), in
einem externen EERPOM speichern oder im internen Flash.
Beim Speichern im EERPOM oder FLASH das Thema "Wear Levelling" beachten.
rgds
Mein Vorschlag als Alternative zum SRAM wäre FRAM, das braucht keine
Backupbatterie. Ein ganz kleines mit 4k oder so reicht da ja. Giebts mit
I2C.
Das hat mehr als ausreichend Schreibzyklen dafür.
Du musst allerdings immer irgendwie sicherstellen, dass du beim
Schreiben nicht unterbrochen wirst, z.B. durch das Ausschalten der
Stromversorgung. Hier ist kapazitive Pufferung und eine
Vorausfallsmeldung angesagt. Hierfür gehen z.B. Resetcontroller oder
ähnliches.
Wenn man z.B. 10ms zur Vollendung des Schreibvorgangs braucht (weil das
erst über I2C raus muss), ist das noch gut mit normalen Elkos oder sogar
nur mit den normalen Pufferkondensatoren realisierbar, wenn der
Stromverbrauch im unteren mA Bereich liegt. Man hat ja oft 3V3, aber die
Kisten rennen laut Spec bis 1V8 runter.
Starseed schrieb:> Wie wird sowas denn typischerweise realisiert?
Kommt auf die Anforderungen drauf an.
Folgende Faktoren würde ich berücksichtigen:
- Muss es manipulationssicher ausgeführt sein?
- Welche zeitliche Auflösung brauchst du?
- Wie oft wird ein/aus geschaltet, wie lange ist die erwartete
durchschnittliche Betriebsdauer?
- Externe Bauteile möglich?
- Produkt, Bastelei oder Labortest/Forschung&Entwicklung?
Da geht die Lösung von (interne) RTC mit Batteriepuffer über internes
Flash/EEPROM bis hin zu externes FRAM/MRAM/Flash.
WehOhWeh schrieb:> Mein Vorschlag als Alternative zum SRAM wäre FRAM, das braucht keine> Backupbatterie. Ein ganz kleines mit 4k oder so reicht da ja. Giebts mit> I2C.
Interessant :)
Danke!
rgds
Hallo,
vielen Dank für die hilfreichen Antworten.
Ein so großer Kasten als Zähler kommt nicht in Frage, es muss eine
embedded Lösung (im wahrsten Sinne des Wortes) sein.
Aus regulatorischen Gründen sind Batterien leider auch nicht drin
(obwohl mit Sicherheit die beste Lösung).
Eine Abschaltdetektion + Verzögerung durch Kondensatoren oder der FRAM
scheinen mir die schönsten Lösungen zu sein.
Wie kritisch ist ein Speicherabbruch (Stromausfall) während des
Schreibens beim:
- Internen Flash
- EEPROM
- FRAM
?
Vielen Dank und Grüße!
Starseed schrieb:> - EEPROM
Da ist die Zelle halt noch nicht geschrieben. Wenn Du allerdings mehrere
Zellen in einem Rutsch schreibst kann Dir das dazwischen unterbrochen
werden und dann hast Du u.U. illegale Zustände Deines Inhaltes (z.B.
32bit auf 4x8bit aufgeteilt, aber nur 2x8bit geschrieben.
Kommt halt darauf an wie schnell Du bist, was Du wie schreiben
möchstest. Das wird aber bei allen Systemen so sein.
rgds
Hallo,
also kann ich theoretisch folgendes machen:
Ich schreibe regelmäßig in den Flash (mit einem simplen
Speicheralgorithmus, welcher einen Flashbereich linear beschreibt bis
dieser voll ist und dann wieder von vorne beginnt) die aktuelle
Systemzeit + Checksumme.
Sollte mir die Spannung während des Schreibens abhauen, habe ich
schlimmstenfalls einen Schreibzyklus verloren (erkenne ich anhand der
fehlerhaften Checksumme). Stelle ich so einen Fehler fest, stelle ich
einfach den letzten gültigen Wert wieder her und mache weiter als wäre
nichts gewesen.
Wichtig wäre halt, dass mir nicht der ganze Flashblock flöten geht, in
dem ich gerade die Schreiboperation durchführe, während mir der µC
ausgeht.
Viele Grüße!
Starseed schrieb:> Ich schreibe regelmäßig in den Flash (mit einem simplen> Speicheralgorithmus, welcher einen Flashbereich linear beschreibt bis> dieser voll ist und dann wieder von vorne beginnt) die aktuelle> Systemzeit + Checksumme.
[...]
> Wichtig wäre halt, dass mir nicht der ganze Flashblock flöten geht, in> dem ich gerade die Schreiboperation durchführe, während mir der µC> ausgeht.
Bei Flash-Speicher hast Du halt das Problem, daß Du immer nur einen
ganzen Block am Stück löschen kannst und das dann auch noch ne Weile
dauert. Wenn in dem Augenblick der Stecker gezogen wird, dann ist das
Flash danach in irgendeinem undefinierten Zustand.
Flash würde ich daher nicht ohne Lösung mit sauberer Spannungspufferung
(z.B. Kondensator) verwenden.
Ohne Kondensatorpufferung würde ich eher FRAM nehmen und dort das oben
von Dir beschriebene Prinzip anwenden.
Hallo Gerd,
FRAM ist leider relativ teuer, der Flash kostenlos dabei. Es wäre also
schön irgendwie den Flash nutzen zu können.
Ich hätte gemeint, dass man den Flash Block nur einmal initial löschen
muss (=> jedes byte auf 0xFF), und ihn dann beliebig umschreiben kann
solange man dadurch nur Bits vom Zustand 1 auf 0 setzt.
Sprich ich würde so vorgehen (stark vereinfacht):
Löschen 4 byte block, Speicherzustand: 0xFF 0xFF 0xFF 0xFF
1. Schreibzyklus: 0x01 0xFF 0xFF 0xFF
2. Schreibzyklus: 0x01 0x02 0xFF 0xFF
3. Schreibzyklus: 0x01 0x02 0x03 0xFF
4. Schreibzyklus: 0x01 0x02 0x03 0x04
5. Schreibzyklus, wieder löschen des 4 byte block + 1. byte schreiben:
0x05 0xFF 0xFF 0xFF
usw.usf...
Oder habe ich hier jetzt einen größeren Denkfehler drin?
Einen schönen Elko + Eingangsspannungsüberwachung ist aber durchaus
realisierbar.
Viele Grüße!
(PS: Checksumme etc.pp. der Einfachheit weg gelassen)
Starseed schrieb:> FRAM ist leider relativ teuer, der Flash kostenlos dabei. Es wäre also> schön irgendwie den Flash nutzen zu können.
Naja, nicht mal 90 Cent:
https://octopart.com/search?q=FM24CL04B
Dafür sparst Du halt den dicken Kondensator den Du bei der Flash-Lösung
brauchst.
> Ich hätte gemeint, dass man den Flash Block nur einmal initial löschen> muss (=> jedes byte auf 0xFF), und ihn dann beliebig umschreiben kann> solange man dadurch nur Bits vom Zustand 1 auf 0 setzt.
klar, das ist schon richtig.
Aber irgendwann bist Du am Ende von Deinem Flash-Block angekommen und
musst den nächsten Löschen. Und genau dieser Löschvorgang ist der
kritische Moment. Wenn da der Saft abgedreht wird, ist der hinterher in
nem undefinierten Zustand.
Sowas ist durchaus ernst zu nehmen, ich erinnere mich noch an Atmegas
bei denen danach das ganze EEPROM durcheinander war. Das ist natürlich
ein ganz anderer Hersteller und µC, aber ich glaube nicht daß ST Dir
garantiert daß das alles sauber abgefangen wird.
Also musst Du Dir aus dem Datenblatt von Deinem Controller die maximale
Löschdauer für ne Flash-Page holen, den worst-case Stromverbrauch den
Controllers berechnen und den Kondensator dann so dimensionieren, daß
der Löschvorgang immer sauber abgeschlossen werden kann.
Starseed schrieb:> Löschen 4 byte block, Speicherzustand: 0xFF 0xFF 0xFF 0xFF> 1. Schreibzyklus: 0x01 0xFF 0xFF 0xFF> 2. Schreibzyklus: 0x01 0x02 0xFF 0xFF
Überflashen ist hier nicht erlaubt. Ob sich dies auf die jeweilige
Schreibbreite oder auf das ganze Word bezieht, bin ich mit im Moment
unsicher.
Starseed schrieb:> Sollte mir die Spannung während des Schreibens abhauen, habe ich> schlimmstenfalls einen Schreibzyklus verloren
Hier bekommt man wenig Infos. Das löschen und Schreiben ins Flash ist
kein simpler Vorgang. Es werden Spannungen angehoben ...
Daher kannst Du nur vom Hersteller gesicherte Informationen bekommen,
wie sich eine Spannungsunterbrechung in dieser Situation auswirkt. Mit
etwas Pech wird die gesamte Bank in Mitleidenschaft gezogen.
Woher bekommst Du denn die neue Zeit, wenn die Stromversorgung
einbricht?
Falls Du eine batteriegepufferte RTC benutzt, dann schau mal, ob da
nicht ein paar Bytes EEPROM verfügbar sind.
