Cache Strategie für I2C EEPROM

[Christian J. (Gast)]

Hallo,

ich habe 512 kb E2PROM in meiner Bastelei, aufgeteilt auf 2 Steine aber 
nur 20 kb RAM im STM32F103, meinem Lieblings-uC. Für die vielen Daten 
die ich in meiner Wetterstation verwursteln möchte denke ich darüber 
nach dem EE einen Cache zu verpassen, der die Schreibzyklen reduziert 
und die Lesezyklen beschleunigt. Mehr als 1 Mio kommen ja fix zusammen. 
Natürlich soll geschrieben werden aber eben deutlich weniger und 
möglichst zusammenhängend.
Ich greife immer struct weise auf das EE zu, eine kleine 
selbstgebastelte FAT organisiert die Daten. Vorne sind also die meisten 
Zugriffe, um die FAT ständig aktuell zu halten.

Kennt jemand Cache Strategien so etwas zu lösen? Ich würde dafür 4kb RAM 
des uC reservieren. Das kann gerne auch in einer INT Routine eines 
Timers passieren, habe ich ja genug von. zeit spielt keine Rolle, so 
schnell ändert sich das Wetter ja nicht, der UC wacht nur einmal die 
Minute derzeit auf.

Mir gehts in dieser Frage um Software, die Hardware besteht ja schon. 
Software, ich ich über die Basisroutinen des EE setzen kann, die bisher 
bestens funktionieren.

Grüße,
Christian

[Baldrian (Gast)]

> ... aufgeteilt auf 2 Steine ...

Backsteine?

[Max G. (l0wside)]

Kannst du mal spezifizieren, was du in etwa schreiben willst (welche 
Daten und wie oft)? Das würde die Strategieberatung ;) enorm 
vereinfachen.

[Christian J. (Gast)]

Max G. schrieb:
> Kannst du mal spezifizieren, was du in etwa schreiben willst (welche
> Daten und wie oft)? Das würde die Strategieberatung ;) enorm
> vereinfachen.

Es werden immer Datensätze weggeschrieben von 64 Bytes als Ganzes, ich 
bleibe da bei einer fixen Blockgröße, macht weniger Probleme.
Sätze können gelöscht werden, Lücken werden dann aufgefüllt. Blöcke sind 
über Zeiger miteinander verknüpft. Also eine ganze einfache Verwaltung, 
viel simpler als ein echtes FAT.

Es werden allerdings tausendmal mehr Lesezugriffe sein als Schreib, neue 
Daten kommen maximal alle 30 Minuten rein.

[Max G. (l0wside)]

Kein Grund für Stress.

Wenn du 10 Jahre lang alle 30min in den Speicher schreibst, sind das 
175.200 Zugriffe (10*365*24*2). Du kannst also alle 30 min den ganzen 
Speicher vollschreiben und kommst trotzdem nicht mal in die Nähe des 
EEPROM-Tods.

[Christian J. (Gast)]

Max G. schrieb:
> Du kannst also alle 30 min den ganzen
> Speicher vollschreiben und kommst trotzdem nicht mal in die Nähe des
> EEPROM-Tods.

Hat das überhaupt schon mal jemand ausprobiert? Habe die Steine von AVR 
hier drauf. Ist ja nicht so schwer mit 400khz zu tackern und gucken, 
wann die Zelle sterben. Dauert vielleicht nur etwas, da ich zwischen 
2-3ms gemessen habe bis die wieder ansprechbar sind nach einem 
Schreibzugriff.

[Johnny B. (johnnyb)]

Nimm statt des EEPROMs doch einfach ein FRAM, dann kannst Du Dir alles 
schenken, denn das hat eine praktisch unlimitierte Zahl an 
Lese-/Schreibzyklen.
Zudem ist es wahrscheinlich sogar kompatibel zu Deinem bisherigen EEPROM 
und 1:1 austauschbar.

Für I2C das Cypress FM24V05:
http://www.cypress.com/file/141321/download

Für SPI das Cypress FM25V05:
http://www.cypress.com/file/41686/download

[Christian J. (Gast)]

Johnny B. schrieb:
> Nimm statt des EEPROMs doch einfach ein FRAM, dann kannst Du Dir alles
> schenken, denn das hat eine praktisch unlimitierte Zahl an

Danke, wusste ich gar nicht dass es sowas überhaupt gibt. Gucken wo ich 
den bestellen kann in Einzelstücken...

PS.Vergessen wir es, das Teil kostet zwischen 12 und 25 Euro einzeln 
....

[Falk B. (falk)]

@ Christian J. (Firma: Hobbywerkstatt) (hobel)

>Es werden immer Datensätze weggeschrieben von 64 Bytes als Ganzes, ich
>bleibe da bei einer fixen Blockgröße, macht weniger Probleme.

Das ist gut.

>Sätze können gelöscht werden, Lücken werden dann aufgefüllt.

Das weniger. Mach lieber einen Ringpuffer, wo fortlaufend der nächste 
Block geschrieben wird. Dadurch werden die Schreibzyklen gleichmäßig auf 
deinen EEPROM verteilt. Eine 32 Bit Seriennummer im Datenblock hilft bei 
der Verwaltung