EEPROM update Funktion?

[H. G. (ledi)]

Hallo,

ich habe eine Frage zur update-Funktion des EEPROM. In der Library gibt 
es z.B für den Datentypen Byte die folgende Funktion:

void eeprom_update_byte ( uint8_t *addr , uint8_t value )

Kann mir bitte jemand erklären, wofür ich diese Funktion brauche und was 
sie macht?

[Eumel (Gast)]

H. G. schrieb:
> In der Library

Ach in DER Libary.

[Karl H. (kbuchegg)]

H. G. schrieb:

> void eeprom_update_byte ( uint8_t *addr , uint8_t value )
>
> Kann mir bitte jemand erklären, wofür ich diese Funktion brauche und was
> sie macht?


Sie schreibt 1 Byte an die Stelle addr ins EEPROM.
Aber im Gegensatz zur simplen _write_ Funktion, überprüft sie vorher, 
ob nicht der zu schreibende Wert sowieso schon an dieser Stelle im 
EEPROM steht.

Grund: Das EEPROM hat eine begrenzte Anzahl an Schreibzyklen. Dabei 
spielt es keine Rolle, was geschrieben wird. Schreibst du 10000 mal 
immer dasselbe an immer dieselbe Adresse, dann sind das 10000 
Schreibzyklen. Überpüfst du aber vorher, ob das zu schreibende nicht 
schon dort steht, dann ist es nur einer. D.h. du sparst in so einem Fall 
Schreibzyklen ein.

[H. G. (ledi)]

Das bedeutet, dass die update-Funktion der write-Funktion immer 
vorzuziehen ist?

Somit ist die write-Funktion ja eigentlich unsinnig oder?

[c-hater (Gast)]

H. G. schrieb:

> Das bedeutet, dass die update-Funktion der write-Funktion immer
> vorzuziehen ist?
>
> Somit ist die write-Funktion ja eigentlich unsinnig oder?

Clever erkannt.

Eigentlich ist es aber noch anders: Eine wirklich sinnvolle 
write-Funktion würde hier schon genau das machen, was diese 
update-Funktion macht. Überflüssig ist also eigentlich die 
update-Funktion.

[katastrophenheinz (Gast)]

>Somit ist die write-Funktion ja eigentlich unsinnig oder?
Eigentlich nicht. EEPROM-Schreiben dauert verglichen mit SRAM schreiben 
verdammt lange ( mehrere ms ), der Prozessor muss aber nicht drauf 
warten, sondern kann in der Zeit was anderes machen ( außer EEPROM lesen 
oder schreiben ). Auch EEPROM lesen dauert wg. des notwendigen 
Rumgemaches mit den EEPROM-Registern deutlich länger als SRAM-Lesen. 
Daher ist es bei häufigem Zugriff auf EEPROM-Inhalte und verfügbarem 
SRAM effizienter, häufig genutzte persistente Daten aus dem EEPROM 
einmal zu Programmstart aus dem EEPROM ins SRAM zu kopieren und nur 
Änderungen ins EEPROM zurückzuschreiben. Da du in diesem Fall weißt, daß 
sich was geändert hat, kannst du dann auch gleich ..write.. nehmen. 
Spart ggü ..update.. etwas Code und Zeit.

Gruss, Heinz

[c-hater (Gast)]

katastrophenheinz schrieb:

> Auch EEPROM lesen dauert wg. des notwendigen
> Rumgemaches mit den EEPROM-Registern deutlich länger als SRAM-Lesen.

Jain. Zwar dauert Lesen aus dem EEPROM tatsächlich länger als Lesen aus 
dem SRAM, aber das sind im Vergleich zum Schreiben in das EEPROM 
trotzdem nur Peanuts. Deswegen ist ein sinnvolles EEPROM-Write nur eins, 
was zuvor prüft, ob das Schreiben überhaupt nötig ist.

> Daher ist es bei häufigem Zugriff auf EEPROM-Inhalte und verfügbarem
> SRAM effizienter, häufig genutzte persistente Daten aus dem EEPROM
> einmal zu Programmstart aus dem EEPROM ins SRAM zu kopieren und nur
> Änderungen ins EEPROM zurückzuschreiben.

Ja, die Cache-Idee hat was für sich. Blöd bloß, daß man sich damit auch 
immer die Cache-Probleme einhandelt. Beim EEPROM lohnt es definitiv 
NICHT, sich diese Probleme einzuhandeln. Schon garnicht, wenn (wie 
üblich) der RAM sowieso knapp ist.