Daten von dynamischen Variabel vor Stromausfall schützen

[Anja S. (anjaneu)]

Hallo Zusammen,

wie kann ich meine Daten von dynamischen Variabel vor einem Stromausfall 
im laufenden Betrieb schützen. Gibt es Möglichkeiten sowas auf dem 
LK-RTC abzulegen. Schließlich ist dort eine Versorgungseinheit mit 
angeschlossen.

Viele Grüße

Ergänzung zur Platform: Arduino Mega 2560 und ca. 20 int Variabeln sind 
zu speichern (2-3 Stellig)

[R. F. (rfr)]

Ein batteriegepuffertes RAM könnte gehen.

RFr

[user (Gast)]

Anja S. schrieb:
> Hallo Zusammen,
>
> wie kann ich meine Daten von dynamischen Variabel vor einem Stromausfall
> im laufenden Betrieb schützen. Gibt es Möglichkeiten sowas auf dem
> LK-RTC abzulegen. Schließlich ist dort eine Versorgungseinheit mit
> angeschlossen.
>
> Viele Grüße

Stellt sich die Frage welches System du verwendest? Ist das ein µC, PC, 
FPGA oder was ganz anderes?

[S. R. (svenska)]

Viele RTCs haben ein paar nutzerdefinierte Bytes, die ebenfalls 
batteriegepuffert sind. Oder du nutzt direkt batteriegepufferten, 
externen RAM.

Je nach Mikrocontrollerschaltung kann es auch möglich sein, den 
eigentlichen Controller als Ganzes zu puffern, obowhl die Peripherie tot 
ist. Im Schlafmodus sind aktuelle Controller extrem sparsam.

Wenn es nicht um eine bestimmte Variable geht, sondern eher um die 
Daten, dann kann man die möglicherweise auch im EEPROM ablegen.

Hängt vom Anwendungsfall ab, was überhaupt möglich ist, was geeignet ist 
und was eher doof wäre.

[(prx) A. K. (prx)]

Anja S. schrieb:
> Gibt es Möglichkeiten sowas auf dem LK-RTC abzulegen.

Wenn der den DS1307 drauf hat: Da sind 56 Bytes gepuffertes RAM drin.

[Anja S. (anjaneu)]

R. F. schrieb:
> batteriegepuffertes RAM

Das LK-RTC scheint sowas zu haben.
Es kann Uhrzeit Datum Wochentag speicher.
(56 bytes of NV SRAM) Allerdings stellt sich mir die Frage wieviel ich 
da ablegen kann?

Ansonsten habe ich nur diesen gefunden allerdings blanko ohne 
Stromversorgung. 
https://www.ebay.de/itm/Serieller-SRAM-23K256-SPI-32-kByte-RAM-Speicher-fur-Arduino-PIC-Teensy-SOIC-8/282258087494

Was hälst du von der Variante ... schreiben auf SD-Karte und beim 
Stromausfall als ersten die SD karte auslesen.

[(prx) A. K. (prx)]

Anja S. schrieb:
> (56 bytes of NV SRAM) Allerdings stellt sich mir die Frage wieviel ich
> da ablegen kann?

448 Bits

[S. R. (svenska)]

Anja S. schrieb:
> Allerdings stellt sich mir die Frage wieviel ich
> da ablegen kann?

Ein DS1307 hat 64 Bytes gepufferten RAM, davon sind 56 Bytes frei 
nutzbar. Du kannst also 56 Bytes darin ablegen.

Anja S. schrieb:
> Was hälst du von der Variante ... schreiben auf SD-Karte und beim
> Stromausfall als ersten die SD karte auslesen.

Dazu gibt es hier schon mehrere Threads.

Ständig auf die SD-Karte schreiben tut der SD-Karte nicht gut, kostet 
Zeit und die Daten sind nicht direkt zugreifbar wie bei einer Variable. 
Bei Stromausfall verlierst du die Daten seit dem letzten Schreibzugriff. 
Manche SD-Karten vertragen keine richtigen Stromausfälle (im Gegensatz 
zu Hotplug, wo die Karte noch genug Zeit hat, zu reagieren). Nach einem 
Stromausfall dauert das Einlesen relativ lange. Bei einem Defekt der 
SD-Karte sind die Daten weg.

Hängt vom Wert der Daten ab.

[Anja S. (anjaneu)]

S. R. schrieb:
> Ein DS1307 hat 64 Bytes gepufferten RAM, davon sind 56 Bytes frei
> nutzbar.
> Du kannst also 56 Bytes darin ablegen.

Allerdings soll das Datum trotzdem da gespeichert bleiben.

Es handelt sich um ein Arduino Mega 2560 und ca. 20 int Variabeln sind
zu speichern (2-3 Stellig)

S. R. schrieb:
> Dazu gibt es hier schon mehrere Threads.
>
> Ständig auf die SD-Karte schreiben tut der SD-Karte nicht gut, kostet
> Zeit und die Daten sind nicht direkt zugreifbar wie bei einer Variable.
> Bei Stromausfall verlierst du die Daten seit dem letzten Schreibzugriff.
> Manche SD-Karten vertragen keine richtigen Stromausfälle (im Gegensatz
> zu Hotplug, wo die Versorgung der Karte genug Zeit gibt zu reagieren).
> Nach einem Stromausfall dauert das Einlesen relativ lange. Bei einem
> Defekt der SD-Karte sind die Daten weg.

Interessant dann fällt die SD schonmal flach, oder nicht?
Im dauerhaften Betrieb ist der Schreib- und Lesezugriff alle 24h 1mal.
Allerdings sollen die Grundparameter nicht immer wieder komplett neu 
eingegeben werden.

Bei einem Stromausfall gibt das Netzteil 12V doch auch noch einen Moment 
Strom ab.

[Bernd K. (prof7bit)]

Einmal pro Tag?

Warum nimmst du nicht das eingebaute eeprom? Das ist haltbarer als 
Flash, du kannst die Schreibzugriffe der Reihe nach auf alle Zellen 
verteilen und bei 1 Mal schreiben pro Tag wird das länger leben als der 
Kunde. Und länger als dessen Kinder und Enkelkinder auch.

[Anja S. (anjaneu)]

Bernd K. schrieb:
> Warum nimmst du nicht das eingebaute eeprom?

Hallo Bernd K.,

das ist ne super Sache, merkwürdig das ich da nicht früher drauf 
gestossen bin.
Bedeutet das dass ich diese Werte bei jedem Neustart des Systems 
auslesen kann? Nach dem Neustart entscheide ich ob ich sie neu definiere 
oder übernehme! YES :)

Dann ist das das was ich gesucht habe.

Das habe ich erstmal dazu gefunden: 
https://www.arduino.cc/en/Reference/EEPROM

[Einer K. (Gast)]

Anja S. schrieb:
> Ansonsten habe ich nur diesen gefunden allerdings blanko ohne
> Stromversorgung.
> Ebay-Artikel Nr. 282258087494

Den Arduino möchte/kann 5V
Und bei Stromausfall ist das auch leer.

Damit hast du also Probleme mit deiner Anforderungsliste.
(Hast du eine?)


Gegenvorschlag:
23LCV1024

Oder ein I2C FRAM

Anja S. schrieb:
> Das habe ich erstmal dazu gefunden:
> https://www.arduino.cc/en/Reference/EEPROM
Gut gefunden.
100000 Schreibzyklen soll es wohl halten.

[Anja S. (anjaneu)]

Hier eine weitere kleine Linksamlung für andere User,

https://forum.arduino.cc/index.php?topic=100231.0

http://shelvin.de/eine-integer-zahl-in-das-arduiono-eeprom-schreiben/

Beitrag "int in Arduino-EEPROM speichern / lesen"

https://www.arduinoforum.de/arduino-Thread-Mehrere-Werte-in-Eeprom-schreiben-und-auslesen

http://www.netzmafia.de/skripten/hardware/Arduino/EEPROM.html

Abschließend mit einem Video zum Thema.
https://www.video2brain.com/de/tutorial/werte-speichern-im-eeprom

[Εrnst B. (ernst)]

Arduino Fanboy D. schrieb:
> 100000 Schreibzyklen soll es wohl halten.

Worst-Case, z.B. bei 85° Umgebungstemperatur. Bei Zimmertemperatur geht 
da viel viel mehr.

[NichtWichtig (Gast)]

Dazu bietet sich das interne EPROM geradezu an.
Ich verwende dieses bei einer Schaltung an mehreren KFZs wo jedesmal bei 
Zündung AUS aktuelle Daten abgelegt werden. (ca 30Bytes)

ADC als Spannungsmessung der 12V Seite, ( ca. 20 mal / sec)
Nach der 5V Regelung ein GoldCap der genug Zeit verschafft die Daten bei 
Unterspannung (<8V) zu Speichern und drauf wartet das die Spannung 
wieder >9V wird.

Datensatz mit CRC bestücken und 4 Blöcke der Reihe nach beschreiben.
Also bei jedem Speichern wird der nächste Block genommen.
Somit ist eine kurze Historie vorhanden und im Falle eines Falles das 
Datenverlust in einem Schreibvorgang passiert besteht die Hoffnung der 
der Vorletzte noch da ist. Zudem verteilt sich das Schreiben, gut für 
die Lebensdauer

Beim Einlesen CRC prüfen und wenn gut dann benutzen, wenn nicht anderen 
datensatz probieren.
Wenn nur Schrott im FLASH dann default-Werte benutzen, Meldung an 
beutzer, Reaktion wie angemessen...

Läuft auf einem ATTiny24 in mehreren Installationen, Software in C mit 
AVRStudio geschrieben.

[TestX (Gast)]

bei häufigen schreibzugriffen bietet sich ein externer fram an

[(prx) A. K. (prx)]

Man kann auch ein FRAM verwenden (I2C oder SPI). Im Unterschied zu Flash 
und EEPROM müssen diese Teile nicht gelöscht werden und schreiben 
verzögerungsfrei, so dass man keinen Puffer für die Versorgungsspannung 
benötigt, die Unterspannungserkennung des Controllers ausreicht und in 
der Software der Aufwand für mehrfache Speicherung entfällt.

[Anja S. (anjaneu)]

NichtWichtig schrieb:
> Datensatz mit CRC bestücken und 4 Blöcke der Reihe nach beschreiben.
> Also bei jedem Speichern wird der nächste Block genommen.
> Somit ist eine kurze Historie vorhanden und im Falle eines Falles das
> Datenverlust in einem Schreibvorgang passiert besteht die Hoffnung der
> der Vorletzte noch da ist. Zudem verteilt sich das Schreiben, gut für
> die Lebensdauer
>
> Beim Einlesen CRC prüfen und wenn gut dann benutzen, wenn nicht anderen
> datensatz probieren.
> Wenn nur Schrott im FLASH dann default-Werte benutzen, Meldung an
> beutzer, Reaktion wie angemessen...
>
> Läuft auf einem ATTiny24 in mehreren Installationen, Software in C mit
> AVRStudio geschrieben.

Hallo NichtWichtig,

Diese Lösung gefällt mir sehr gut, da ich gern so wenig wie möglich und 
nur so viele zusätzliche Bauteile wie nötige anschließßen möchte. Das 
CRC ist mir gleich anfänglich aufgefallen als ich die ref gelesen hab. 
Diese Möglichleit mit einer Art Historie ist auch ne super Sache. 
Default-Werte nur im Norfall ist genau das was ich suche.

Hast du bitte dazu mal das eine oder andere Beispiel für mich?

Viele Grüße

[Anja S. (anjaneu)]

Arduino Fanboy D. schrieb:
> Den Arduino möchte/kann 5V
> Und bei Stromausfall ist das auch leer.
>
> Damit hast du also Probleme mit deiner Anforderungsliste.
> (Hast du eine?)
>
> Gegenvorschlag:
> 23LCV1024
>
> Oder ein I2C FRAM

Adafruit I2C Non-Volatile FRAM Breakout - 256Kbit / 32KByte AF1895
Adafruit SPI Non-Volatile FRAM Breakout Board, 64Kbit / 8KByte

Liest sich interessant, ist allerdings nicht 100% nötig da die Daten am 
Anfang geschrieben werden und nicht erst bei einer Stromunterbrechnung. 
Die Anforderung lautet, auf default-Werte nur im Notfall zugreifen da 
ich sonst nach jeder Stromunterbrechnung Grunddaten neu festlegen muss. 
Allerdings hast du vielleicht noch das eine oder andere Argument was ich 
übersehen habe.

FRAM
+ Schneller Zugriff
+ 10.000.000.000.000
+ 8-32 KB
+- 27 Mill. Jahre einsetztbar bei 1xschreiben/Tag
- extra Platz für PIN und bautechnischer Natur
- SDA & SDL wird bereits von LK-RTC benutzt

EEPROM
+ kein extra Platz für PIN und bautechnischer Natur
+ 273 Jahre einsetztbar bei 1xschreiben/Tag reicht aus
+ 4 KB (ca. 20 x 2Byte = 40 Byte) recht also aus
+ speichert dauerhaft
+ speichert Historie
- muss gelöscht werden vor dem neubeschreiben


Hab ich was vergessen?
Vielen Dank Arduino Fanboy D.

[S. R. (svenska)]

Ein FRAM (oder I2C-/SPI-EEPROM) erfordert extra Schaltungsaufwand, 
braucht Platz und verursacht Kosten. Der AVR hat das EEPROM schon fertig 
eingebaut, die RTC hat ebenfalls frei verfügbaren RAM.

So ein Datum lässt sich ziemlich effizient speichern (16 Bit: Tag 0..30, 
Monat 0..11, Jahr 0..127 ab Stichtag), von den 56 Bytes blieben dann 
immernoch einfach zugreifbare 54 Bytes übrig.

Wenn du nur 1x/Tag schreibst, dann verlierst du bei einem Stromausfall 
im Mittel einen halben Tagesdatensatz. Unabhängig von der Technologie.

Vielleicht wäre eine Kombination sinnvoll (der aktuelle Datensatz steht 
mit Prüfsumme in der RTC, wird aber täglich ins EEPROM gesichert). Das 
hängt vom Anwendungsfall ab, den du nicht sagen willst.

Nachtrag: Für wirkliche Grunddaten (ich vermute mal sowas wie 
IP-Adresse, Seriennummer, Eigentümername, Wunschklingelton oder 
ähnliches) ist das EEPROM wie geschaffen.

Für mich wäre das jedenfalls ein Ohnehirnler.

[Anja S. (anjaneu)]

S. R. schrieb:
> So ein Datum lässt sich ziemlich effizient speichern (16 Bit: Tag 0..30,
> Monat 0..11, Jahr 0..127 ab Stichtag), von den 56 Bytes blieben dann
> immernoch einfach zugreifbare 54 Bytes übrig.

Sorry ich meinte Jahr, Monat, Tag, Wochentag, Stunde, Minute und 
Sekunde.
In der Tat wäre es wohl bei einem Julianischen Datumsformat nur 4 Byte.
Heute 24.09.2018 um 21:24 Uhr hätten wir das Julianische Datum 
2458386.39167. Ich dachte immer das es einen Standartart für 
Datensicherung auf einem RTC gibt. ... hmm ... Ich bin jetzt irritiert!

S. R. schrieb:
> Wenn du nur 1x/Tag schreibst, dann verlierst du bei einem Stromausfall
> im Mittel einen halben Tagesdatensatz. Unabhängig von der Technologie.

Es ist sehr unwarscheinlich das ich das Stromkabel abziehe in der Zeit 
wo ich die Daten kontrolliere und bestätige. Selbst das Bestätigen auf 
dem Keypad und anschliessende Kabelentfernen wird wohl länger als 0,18 
Sekunden dauern.
Das jeden Tag die Daten geändert werden ist sehr unwarscheinlich aber 
Möglich. Warscheinlicher ist es ein mal im Monat, aber rein rechnerisch 
möchte ich da gern auf Nummer sicher gehen und erhebe das 30-Fache und 
habe damit einen ordentlichen Puffer!

S. R. schrieb:
> Vielleicht wäre eine Kombination sinnvoll (der aktuelle Datensatz steht
> mit Prüfsumme in der RTC, wird aber täglich ins EEPROM gesichert). Das
> hängt vom Anwendungsfall ab, den du nicht sagen willst.

Anwendungsfall ist 20 x int (0-999) meist 2-3 Stellig = 40 Byte

[S. R. (svenska)]

Anja S. schrieb:
> Sorry ich meinte Jahr, Monat, Tag, Wochentag, Stunde, Minute und
> Sekunde.

Die RTC hat 64 Bytes, davon sind 8 Bytes für Datum und Uhrzeit 
reserviert. Daher kommen die 56 verfügbaren Bytes. Da die RTC 
selbstständig mit dem Datum umgehen kann, brauchst du das nicht 
anderweitig speichern.

Den Wochentag brauchst du nicht speichern, der ergibt sich aus dem Datum 
und lässt sich jederzeit berechnen.

Anja S. schrieb:
> Julianischen Datumsformat

Ich empfehle ja den gregorianischen Kalender. :-)

Theoretisch lässt sich jeder Zeitpunkt als "Anzahl von Ticks seit der 
Epoche" angeben (z.B. Unix-Zeit). Je nach Anwendungsfall ist aber die 
gebrochene Zeit (also Sekunde-Minute-Stunde-Tag-Monat-Jahr) sinnvoller. 
Hängt vom Anwendungsfall ab.

Anja S. schrieb:
> Ich dachte immer das es einen Standartart für
> Datensicherung auf einem RTC gibt.

Die RTC muss nur die Datenfelder kennen, die sie selbst aktualisiert 
(nicht alle RTCs hantieren das Datum). Der restliche RAM ist erstmal nur 
batteriegepufferter Speicher, dessen Format und Inhalt du frei wählen 
kannst. Ein Beispiel wären z.B. die BIOS-Einstellungen, die früher mit 
im Uhrenchip gespeichert wurden.

Anja S. schrieb:
>> Wenn du nur 1x/Tag schreibst, dann verlierst du bei einem Stromausfall
>> im Mittel einen halben Tagesdatensatz. Unabhängig von der Technologie.
>
> Es ist sehr unwarscheinlich das ich das Stromkabel abziehe in der Zeit
> wo ich die Daten kontrolliere und bestätige.

Ich hab keine Ahnung, was du vorhast und um was für Daten es geht.
Wenn du jeden Tag den Temperaturmittelwert speicherst, dann verlierst du 
bei einem zufälligen Stromausfall im Schnitt einen halben Tagesdatensatz 
(je nachdem, ob der Stromausfall vor oder nach dem Speichern eintritt).

Von einem Stromkabel, einem Keypad oder einem "eigentlich sind die Daten 
über Monate konstant" hast du nie gesprochen.

Salamitaktik macht keinen Spaß.

Wenn sich die Daten effektiv nicht ändern, dann nimm das EEPROM und gut 
ist. Wenn der Stromausfall nur vom Nutzer ausgelöst werden kann, dann 
ist der Nutzer auch schlau genug, nach eigener Dummheit die Uhrzeit neu 
einzugeben.

Ich bin dann mal raus, es wurde alles gesagt, der Rest ergibt sich durch 
unbekannte Anforderungen.

[Anja S. (anjaneu)]

S. R. schrieb:
> Ich hab keine Ahnung, was du vorhast und um was für Daten es geht.
> Wenn du jeden Tag den Temperaturmittelwert speicherst, dann verlierst du
> bei einem zufälligen Stromausfall im Schnitt einen halben Tagesdatensatz
> (je nachdem, ob der Stromausfall vor oder nach dem Speichern eintritt).

Keine Ahnung, kommt wohl von ... ich dachte was die da denkt ... 
Merkwürdig!

>>>>> DARUM GEHT ES [20 x int (0-999) meist 2-3 Stellig = 40 Byte]

Es geht nicht um eine Laufzeit oder um einen Mittelwert eines Tages.
Das werden wohl Grunddaten bzw. Grundeinstellungen sein. Es erschließt 
sich ja aus dem Kontext.

S. R. schrieb:
> Von einem Stromkabel, einem Keypad oder einem "eigentlich sind die Daten
> über Monate konstant" hast du nie gesprochen.

Wenn ich in eiem laufenden Betrieb das Kabel abziehe ist es für das 
System wie ein Stromausfall.

Das einzige von dem ich nicht geschrieben habe ist: "eigentlich sind die 
Daten über Monate konstant" BITTE NICHTS DAZUERFINDEN

> Salamitaktik macht keinen Spaß.

Richtig sehe ich auch so. Statt nur viel zu schreiben würde mal ein 
Quellcode Beispiel für deinen dualen Weg Sinn machen. Dann könntest du 
dir die eine oder andere Anzüglichkeit sparen und wirkliche Hilfe 
leisten.

>  Wenn der Stromausfall nur vom Nutzer ausgelöst werden kann, dann
> ist der Nutzer auch schlau genug, nach eigener Dummheit die Uhrzeit neu
> einzugeben.
>
> Ich bin dann mal raus, es wurde alles gesagt, der Rest ergibt sich durch
> unbekannte Anforderungen.

Die LK-RTC ist mit einer Batterie gesichert, mal so nebenbei.

Ich hab keine Ahnung was du eigentlich für ein Problem hast. Ist mir 
auch wirklich egal. Nur weil du den 100% Sinn des Projektes nicht 
verstehst brauchst du hier nicht mich für Dumm oder Ohnehirnler zu 
beschimpfen. Ich finde es unzumutbar wie du hier mit mir schreibst.

Mit deinen 2422 Beiträgen solltest du ehr vorbildlich agieren und nicht 
so den Ruf des Forums in den Dreck ziehen.

Danke

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Anja S. schrieb:
> brauchst du hier nicht mich für Dumm oder Ohnehirnler zu beschimpfen.
Warum beziehst du diese Aussagen auf dich? Da ging es wohl eher um den 
DAU..

> Statt nur viel zu schreiben würde mal ein Quellcode Beispiel für deinen
> dualen Weg Sinn machen.
Ja, mach das: schreib du mal Code und stell den hier zur Diskussion. 
Denn dass viele Andere hier das Problem lösen könnten oder schon gelöst 
haben im Sinne von "Pufferkondensator, Spannungsmessung, Werte speichern 
bei Spannungseinbruch", das ist klar. Aber dir würde auch irgendein 
Code, der genau das macht, nicht helfen, weil du eine komplett andere 
Hardware hast. Ansonsten gebe ich mal diesen Code als Grundgerüst:

 if (Neustart())
   LadeWerteVonEEPROM();

 if (Powerfail()) {
   SpeichereWerteInEEPROM();
   delay(500);
 }

Jetzt musst du nur noch die 4 Funktionen mit Leben füllen...

> Mit deinen 2422 Beiträgen solltest du ehr vorbildlich agieren und nicht
> so den Ruf des Forums in den Dreck ziehen.
Anja, klapp den erhobenen Zeigefinger wieder ein und mach dir um den Ruf 
des Forums keine Sorgen. Sondern bringe einfach alle nötigen 
Informationen, die uns helfen, DEIN PROBLEM zu lösen (denn das ist ja, 
was du eigentlich willst). Es ist höchst beschwerlich und 
fehlerträchtig, zu raten, was das wohl für Daten sein könnten:
> Das werden wohl Grunddaten bzw. Grundeinstellungen sein. Es erschließt
> sich ja aus dem Kontext.
Wenn das nur weitgehend statische Daten sind, dann speichere sie einfach 
gleich nach dem Eingeben ins EEPROM und fertig. Dann musst du dir um den 
Spannungsausfall keine Gedanken machen. Und einfach beim nächsten 
Neustart die Daten wieder aus dem EEPROM lesen.

[Marc V. (Firma: Vescomp) (logarithmus)]

Anja S. schrieb:
> auch wirklich egal. Nur weil du den 100% Sinn des Projektes nicht
> verstehst brauchst du hier nicht mich für Dumm oder Ohnehirnler zu
> beschimpfen. Ich finde es unzumutbar wie du hier mit mir schreibst.
 Genau.
 Unerhört.
 Mich hat er neulich auch so beschimpft, ich bin jetzt noch
 ausser mir. Pfui.

Anja S. schrieb:
> Richtig sehe ich auch so. Statt nur viel zu schreiben würde mal ein
> Quellcode Beispiel für deinen dualen Weg Sinn machen. Dann könntest du
> dir die eine oder andere Anzüglichkeit sparen und wirkliche Hilfe
> leisten.

 Genau.
 Hier ist ein einfaches Beispiel wie man aktuelle Zeit in BlipRam
 speichert.

main() {
 while(true) {
   if(quark != blimp) {
     f0(uhrzeit);
   } else explode(quark);
 }
}

f0(bits32 x) {
bits32 y;
 y = 0;
 if (y >= bits32[foo+8]) {
 y = y + 1;
 return (y);
} else {
 x = x - 1;
 if x != 0 {
 y = y + 2;
 }
 return (y + f3());
 }
}

f3 () {
 stackdata {
 beep: bits8[64];
 }
f3_label:
 bits64[beep] = 18::bits64;
 bits64[beep+4*8] = bits64[beep];
 if (%zx32(bits8[beep+4*8]) == 18) { return; }
 goto f3_label;
}

explode(bits32) {
 boom(333);

 Das ist es doch, wonach du gesucht hast, oder ?
 Falls nicht, schreibe bitte was nicht funktioniert und wir
 beide kriegen das schon hin.

[Marc V. (Firma: Vescomp) (logarithmus)]

Anja S. schrieb:
> Ich hab keine Ahnung was du eigentlich für ein Problem hast. Ist mir
> auch wirklich egal. Nur weil du den 100% Sinn des Projektes nicht
> verstehst brauchst du hier nicht mich für Dumm oder Ohnehirnler zu
> beschimpfen. Ich finde es unzumutbar wie du hier mit mir schreibst.

 Übrigens, ich verstehe den Sinn des Projektes auch nicht so 100%-ig,
 eigentlich verstehe ich es nicht mal 0,1%, weil:

Lothar M. schrieb:
> Wenn das nur weitgehend statische Daten sind, dann speichere sie einfach
> gleich nach dem Eingeben ins EEPROM und fertig. Dann musst du dir um den
> Spannungsausfall keine Gedanken machen. Und einfach beim nächsten
> Neustart die Daten wieder aus dem EEPROM lesen.

 ich es genauso machen würde.

 Du kannst es natürlich so machen (oder es versuchen), wie es dir
 beliebt...

[Anja S. (anjaneu)]

Marc V. schrieb:
> Übrigens, ich verstehe den Sinn des Projektes auch nicht so 100%-ig,
>  eigentlich verstehe ich es nicht mal 0,1%, weil:

int EINSTELLUNG01 = 10;
int EINSTELLUNG02 = 250;
int EINSTELLUNG03 = 789;
int EINSTELLUNG04 = 180;
int EINSTELLUNG05 = 450;
int EINSTELLUNG07 = 8;
.
.
.
int EINSTELLUNG20 = 0;

boolean Count = true; 


CountdownZEITauslesen() {
EINSTELLUNG01                         // EEPROM Ergebnis auf Variabeln legen
}  



Countdown() {

CountdownZEITauslesen();             

1                                    // Countdown läuft eine gewisse Zeit (EINSTELLUNG01)
2
.
.
.
10
Count = false;
}


void Einstellung() {
.
.                                    // Einstellung vornehmen
.                                    // Einstellung in EEPROM schreiben
}



void LeseVARIABLENausEEPROM() {
.                                    // EEPROM auslesen
EINSTELLUNG01                        // EEPROM Ergebnis auf Variabele EINSTELLUNG01 legen
.
.
.
EINSTELLUNG19                        // EEPROM Ergebnis auf Variabele EINSTELLUNG19 legen
EINSTELLUNG20                        // EEPROM Ergebnis auf Variabele EINSTELLUNG20 legen

}

EinstellungPerKeyPad() {
.
.
.
}



void Menue() {

if (EINSTELLUNG20 = 0) 
   {
   EinstellungPerKeyPad();

   if      (EINSTELLUNG20 = 1) 
           {
           Programm1; 
           }
   else if (EINSTELLUNG20 = 2) 
           {
           Programm2; 
           }
   else if (EINSTELLUNG20 = 3) 
           {
           Programm3; }
   .
   .
   .
   }
  
}


void setup() {

while (Count == true)
      {
       Countdown();                 // Frage ob frühere Einstellunge angepasst oder Kontroliert werden sollen
       if (button == 1) 
          {
          Einstellung();
          }
          .
          .
       }

LeseVARIABLENausEEPROM();

}



void loop() { 
menue();
}

So sieht der Plan der Struktur aus!

Da sind Fehler in meiner Idee drin sein, also bitte nicht so hard sein. 
Ist mal kurz runtergeschrieben. Positive Kritik ist gern gesehen.

[Einer K. (Gast)]

"Einstellungen" durchzunummerieren, finde ich nicht schön.

Besser:
Gleichartige, in ein Array und verschiedenartige in eine Struktur...

> void LeseVARIABLENausEEPROM()
Du kannst auch größere Bereiche in einem Rumms lesen und schreiben.

[Axel S. (a-za-z0-9)]

Arduino Fanboy D. schrieb:
> "Einstellungen" durchzunummerieren, finde ich nicht schön.

200% ACK

> Gleichartige, in ein Array und verschiedenartige in eine Struktur...

Ich würde die prinzipiell alle in eine struct packen. Nicht nur, weil 
der Compiler dann kürzeren Code für den Zugriff erzeugen kann 
(Basisadresse + Offset) sondern vor allem auch, weil man dann die ganze 
struct in einem Rutsch in den EEPROM sichern bzw. von da lesen kann.

[S. R. (svenska)]

Anja S. schrieb:
> Es geht nicht um eine Laufzeit oder um einen Mittelwert eines Tages.
> Das werden wohl Grunddaten bzw. Grundeinstellungen sein. Es erschließt
> sich ja aus dem Kontext.

Der Begriff "Grunddaten" ist mir nicht geläufig. Ein Beispiel, was ich 
darunter verstehe, schrieb ich. Dein Lösungsansatz (zu der Zeit) war für 
solcherlei Daten ungeeignet.

> Wenn ich in eiem laufenden Betrieb das Kabel abziehe ist es für das
> System wie ein Stromausfall.

Nicht in jedem System ist "Kabel ziehen" der Hauptgrund für einen 
Stromausfall.

>> Salamitaktik macht keinen Spaß.
>
> Richtig sehe ich auch so. Statt nur viel zu schreiben würde mal ein
> Quellcode Beispiel für deinen dualen Weg Sinn machen.

Och weißt du... du wolltest was wissen. Ich bin nicht in der 
Bringepflicht.

> Die LK-RTC ist mit einer Batterie gesichert, mal so nebenbei.

Ja. Bin ich mehrfach drauf eingegangen.

> brauchst du hier nicht mich für Dumm oder Ohnehirnler zu beschimpfen.

Habe ich nicht. In jedem Fall nicht absichtlich.

Mit "Ohnhirnler" meinte ich einen "No-Brainer". Also eine Entscheidung, 
für die man nicht nachdenken muss, weil sie offensichtlich nicht falsch 
ist.

Ich kann mich nicht daran erinnern, dich jemals als dumm bezeichnet zu 
haben.

> Mit deinen 2422 Beiträgen solltest du ehr vorbildlich agieren und nicht
> so den Ruf des Forums in den Dreck ziehen.

Och weißt du... das ist mir relativ egal. Wenn ich mich hinreichend 
danebenbenehme, werde ich von Leuten rausgeschmissen, die das zu 
entscheiden haben. Ich bemühe mich, im Allgemeinen wesentlich mehr 
hilfreich als trollend zu sein.

Aber man muss ja nicht mit jedem Menschen agieren.

Anja S. schrieb:
> Positive Kritik ist gern gesehen.

Positive Kritik ist in der Form "das hast du aber fein gemacht". Die 
kann ich leider nicht liefern.

Negative Kritik, also was ich an deinem Beispiel unzureichend/schlecht 
finde bzw. was meiner Meinung nach besser gemacht werden könnte, hast du 
ja explizit ausgeschlossen. Smart.

In jedem Fall ist dein Beispiel ungefähr genauso hilfreich, wie deine 
Ursprungsanfrage. Nämlich genau garnicht.

[Einer K. (Gast)]

S. R. schrieb:
> Positive Kritik ist in der Form "das hast du aber fein gemacht". Die
> kann ich leider nicht liefern.

Oh!

Das kann ich schon!

Der pseudo Quelltext, ist messerscharf formatiert.
Rechteckige Struktur.
Klar.

Fein gemacht!
Wenn ich es besser könnte, dann würde ich loben, aber so bleibt mir nur 
die Bewunderung.

Im Ernst:
Ich mag diese klare Struktur.
Schreibe und lese sie gerne.
Bin allerdings ein Feind von Wiederholungen.

Frei nach dem Motto:
Was du drei mal auf die gleiche Art tust, mache eine Klasse draus.
(oder stopfe es zumindest in ein Array)

[Anja S. (anjaneu)]

Arduino Fanboy D. schrieb:
> Gleichartige, in ein Array und verschiedenartige in eine Struktur...

Macht Sinn

Axel S. schrieb:
> Ich würde die prinzipiell alle in eine struct packen. Nicht nur, weil
> der Compiler dann kürzeren Code für den Zugriff erzeugen kann
> (Basisadresse + Offset) sondern vor allem auch, weil man dann die ganze
> struct in einem Rutsch in den EEPROM sichern bzw. von da lesen kann.

Noch interessanter finde ich den kürzeren Code nach dem compilieren.
Da die Einstellungen in 3 Blöcken aufgeteilt sein müssen wegen den 
unterschiedlichen Abfragezeitpunkten bleibt so aber bestehen Axel S. 
oder ist das Quatsch? (Countdown, Einstellungsparameter, ProgrammWahl) 
Diese sind ja auf einander aufbauend.
Mit struct habe ich schon kleinere Sache gemacht, allerdings ging es 
da ehr um char und int Ausgabe in Verbindung mit einer 
Entscheidungsfrage. Sprich eine Frage wird beantwortet und die damit in 
Verbindung gebrachten Informationen ob Text oder Zahl wurden ausgegeben. 
Wie das mit der Gruppierung der Variablen verlaufen soll, ist mir noch 
nicht ganz klar. Wäre aber über eine Beispiel Quellcode anhand des 
oberen Beispiels sehr froh und dankbar, auch zum Thema und besonders zum 
Thema Speichern auf dem EEPROM.
Danke Axel S. im Voraus.


@ ALLE
Ich fange grad mit der Programmierung an und da muss sich erst das ganze 
setzten.
Klar wird es immer Menschen geben die das besser können als andere, 
solange die KI nicht soweit ist den Menschen in der Programmierung zu 
schlagen. Ich bin hier im Forum um neue Kniffe, Anreize und Sichtweisen 
zu erfahren. Nicht um aus Langeweile hin und her zu schreiben und hole 
Sprüche von Leuten zu lesen die nur etwas schreiben um mehr Beiträge zu 
haben. Ich brauch Hilfe, in der TAT. Geschwafel



@ Niemand
Das Systeme mit USV auch für eine gewisse Zeit funktionieren, wenn es 
Stromschankungen bis Totalausfall gibt, weiß ein jedes Kind.
Das eine Uhr im PC ohne Internetzugang nicht NEU eingestellt werden 
muss, weil man mit dem PC von einem Raum in den nächsten umzieht 
(mainboard batterie) ist auch logisch. Fang bitte nicht mit 
unterschiedlichen UTC Sommer oder Winterzeit an.
@ Niemand ENDE




DEFAKTO geht es um das abspeichern von Einstellungsdaten auf nicht 
flüchtigen Speichern, möglichst auf dem Hauptsystem. Das spart Platz und 
zusätzliche Wärme.
SORRY das ich den Trade nicht umbenennen kann!


Arduino Fanboy D. schrieb:
> Bin allerdings ein Feind von Wiederholungen.
Achte mal auf PC Anschalten, Essen & Trinken, deine Atmung ...

Witz lass nach!
Ja ja lach nur. Wenn du schläfst hole ich meinen Edding. ;)

[Einer K. (Gast)]

Anja S. schrieb:
> deine Ahtmung
Auch dieses Ritual wird enden!

Nachtrag:
https://www.youtube.com/watch?v=U7-60tyLQhA

[S. R. (svenska)]

Anja S. schrieb:
> Ich fange grad mit der Programmierung an
> und da muss sich erst das ganze setzten.

Dafür pflaumst du Leute, die dir helfen wollen, aber ganz gewaltig an.

Protipp: Man kann Strukturen auch in Strukturen verpacken.

[Axel S. (a-za-z0-9)]

Anja S. schrieb:
> Axel S. schrieb:
>> Ich würde die prinzipiell alle in eine struct packen. Nicht nur, weil
>> der Compiler dann kürzeren Code für den Zugriff erzeugen kann
>> (Basisadresse + Offset) sondern vor allem auch, weil man dann die ganze
>> struct in einem Rutsch in den EEPROM sichern bzw. von da lesen kann.
>
> Noch interessanter finde ich den kürzeren Code nach dem compilieren.

Es ist viel zu früh, sich ausgerechnet darüber Gedanken zu machen.

> Da die Einstellungen in 3 Blöcken aufgeteilt sein müssen wegen den
> unterschiedlichen Abfragezeitpunkten bleibt so aber bestehen Axel S.
> oder ist das Quatsch? (Countdown, Einstellungsparameter, ProgrammWahl)
> Diese sind ja auf einander aufbauend.

Wenn drei Sätze von Einstellungen zu unterschiedlichen Zeitpunkten ins 
EEPROM gehen sollen, ist es natürlich sinnvoll, sie in getrennte structs 
zu packen. Andererseits kann man structs auch verschachteln.

> Wie das mit der Gruppierung der Variablen verlaufen soll, ist mir noch
> nicht ganz klar. Wäre aber über eine Beispiel Quellcode anhand des
> oberen Beispiels sehr froh und dankbar, auch zum Thema und besonders zum
> Thema Speichern auf dem EEPROM.
> Danke Axel S. im Voraus.

Ich enttäusche dich nur ungern [1], aber wir sind hier nicht der 
"Einsteigerkurs C-Programmierung". Was C-structs sind und wie man sie 
benutzt, mußt du schon selber lernen.

Zum Zugriff auf den EEPROM solltest du die Dokumentation der avr-libc 
lesen: 
https://www.nongnu.org/avr-libc/user-manual/group__avr__eeprom.html

Und die freundliche Tange Gugel findet für "eeprom_read_block struct" 
gleich als erstes einen Thread nebenan bei den AVR-Freaks:

https://www.avrfreaks.net/comment/1229801#comment-1229801


[1] das war eine rhetorische Figur. Natürlich habe ich überhaupt kein 
Problem damit, dir diese spezielle Enttäuschung zu bereiten.

> @ ALLE
> Ich fange grad mit der Programmierung an und da muss sich erst das
> ganze setzten.
> Klar wird es immer Menschen geben die das besser können als andere

Albern. Ich sehe hier vor allem, daß es einerseits Menschen gibt, die 
fähig und vor allem auch willens sind, Dinge eigenständig zu lernen. Und 
dann wieder andere, die ohne Vorkenntnisse in irgendwelche Foren 
platzen, halbgare Problembescheibungen ablassen und dann Leute dafür 
anranzen, daß sie ihnen keinen Programmcode mit der Lösung gegeben 
haben.

[Einer K. (Gast)]

Axel S. schrieb:
> Zum Zugriff auf den EEPROM solltest du die Dokumentation der avr-libc
> lesen:
Sie befindet sich in der Arduino Welt...
Da gibts schon einiges, schön vorgekaut.
(natürlich basierend auf der AVR Libc)

z.B. hier https://forum.arduino.cc/index.php?topic=526491.0