EEPROM Daten wegen Zugriffszeit im RAM Spiegeln?

@ Zeitsparer

>ist es aus Zugriffszeitgründen ev. sinnvoll, die im EEPROM
>abgespeicherten Daten einer Sensorkennlinie eins zu eins ins RAM zu
>spiegeln und vom RAM aus zu operieren?

Wenn die Kennliniendaten oft und schnell gebraucht werden, dann ja.
Wenn sie nur selten gebraucht werden und Geschwindigkeit keine Rolle 
spielt, dann ist es egal.

>Das im EEPROM liegende Array könnte in der Ini ins RAM gespiegelt
>werden.

Ja.

>Welche Probleme bzw. Nachteile handelt man sich da ein? Bitkipper bei

Wenn in deinem RAM Bits kippen, hast du SO oder SO ein Problem. 
Kritische Anwendungen verwenden CRC Prüfsummen, die zyklisch geprüft 
werden (z.B. in Weltraumelektronik, Sicherheitstechnik, etc.).

>EMV o.ä.?
>Wie macht man das praktisch?

??
Wo ist das Problem? Daten aus dem EEPROM lesen und ins RAM schreiben.

MfG
Falk

.
war 'lesen' nicht doch viel schneller ....als schreiben ?
.

Die Daten müssen in jeder main gelesen und damit gerechnet werden. Es 
sind mindestens zehn Werte. Darunter komme ich nicht.

EEPROM Lesen ist natürlich schneller als Schreiben.

Ich dachte schon an zyklisches sukzessives updaten einer einzelnen 
Zellen einmal pro main.

@Läubi
So einfach ist das aber nciht.
Du musst erst das EEPROM ansprecehn, dann den Lesebefehl absetzten. 
Danach die Adresse und Anzahl der Byte(s) übertragen.
Diesen Protokolloverhead hast du bei EEPROM immer.



@Zeitsparer
Am schnellsten ist es wenn du die Daten im Ram spiegelst. Das heißt bei 
der Initialisierung die Daten von EEPROM ins Ram lesen, und beim 
Abschalten die eventuell geänderten Daten wieder ins EEPROM schreibst.

Das wird in professionellen Anwendungen übrigens genauso gemacht.

> ist es aus Zugriffszeitgründen ev. sinnvoll, die im EEPROM
> abgespeicherten Daten einer Sensorkennlinie eins zu eins ins RAM zu
> spiegeln und vom RAM aus zu operieren?

Das kommt auf die gewünschte Anwendung an. Wenn der Zugriff zu langsam 
für die Anforderung ist, wird's wohl sinnvoll sein, sonst nicht.

> Welche Probleme bzw. Nachteile handelt man sich da ein?

Längere Initialisierungszeit, etwas mehr Programmieraufwand, höherer 
RAM-Verbrauch. Falls Daten zurückgeschrieben werden müssen, ist bei 
einem Ausfall der Versorgung alles weg, was zwischenzeitilich nicht 
gesichert wurde.

> Bitkipper bei EMV o.ä.?

Wenn in deinem RAM Bits umkippen, ist ein sinnvoller Betrieb des Systems 
sowieso unmöglich.

@Läubi:
> Lesen aus dem SRAM 2 Takte
> Lesen aus dem EEPROM 2 Takt (sbi und in)

Von was für SRAM und EEPROM sprichst du?

@ Zeitsparer

>Die Daten müssen in jeder main gelesen und damit gerechnet werden. Es
>sind mindestens zehn Werte. Darunter komme ich nicht.

Graf-Zahl-Witz-mal-wieder-verkniffen

>EEPROM Lesen ist natürlich schneller als Schreiben.

A) WELCHES EEPROM? Ich habe unbewusst an ein exterenes, serielles EEPROM 
gedacht, meist per I2c oder SPI angeschlossen. I2C macht max. 400 
kbit/s, effektiv bissel weniger. SPI je nach EEPROM einige Mbit/s.

b) Die Aussage "Die Daten müssen in jeder main gelesen und damit 
gerechnet werden" ist so gut wie nichts wert. Wie oft wird den dein 
"main" pro Sekunde ausgeführt? 10mal? 1000mal?

>Ich dachte schon an zyklisches sukzessives updaten einer einzelnen
>Zellen einmal pro main.

Und wozu?

@ Rolf Magnus

>@Läubi:
>> Lesen aus dem SRAM 2 Takte
>> Lesen aus dem EEPROM 2 Takt (sbi und in)
>Von was für SRAM und EEPROM sprichst du?

Die internen vom AVR.

@ Läubi Mail@laeubi.de

>Und ich behaupte einfach mal das es sehr wenig Anwendungen gibt wo man
>eine Sensorkennlinie in soooo hoher Geschwindigkeit lesen muß als das es
>sich lohnt das ins RAM zu spiegeln...

Sehe ich ähnlich. Aber man sollte einfach mal ein paar brauchbare Zahlen 
auf den Tisch legen (an den OP gerichtet). Dann klappts auch mit den 
substanziellen Antworten . . . ;-)

MFG
Falk