I2C Eeprom AT24C512 Lib für Pagewrite in C

[Peter (Gast)]

Hallo zusammen,

habe letztens eine Lib in C für ein Pagewrite und Random Read / 
Sequential Read für die I2C Lib von Peter Fleury gesucht und nichts 
richtiges gefunden.
Da ich noch am lernen bin wollte ich hier mal nachfragen ob das so sinn 
macht oder ob ich noch etwas verbessern kann. Freue mich über alle Tips.

[N. G. (newgeneration)]

Hallo,

ich habe nur kurz drübergeschaut. Dabei ist mir allerdings das Folgende 
aufgefallen:

Lass die i2c_init() Aufrufe innerhalb der Funktionen weg. Der Aufruf 
gehört einmal an den Anfang des Programms. Sonst kostet das nur 
(zugegebenermaßen ein wenig) Zeit.

Ohne ins Datenblatt von verwendeten EEPROM zu schauen: Nachdem eine Page 
beschrieben wurde: warum i2c_stop() und dann wieder i2c_start()? Wäre da 
i2c_rep_start() nicht angebracht. Hat Vorteile, denn erstens geht es 
minimal schneller (aber wirklich nur einige Takte). Zweitens: wenn du 
I2C als Multimaster betreibst, dann kann es so zu Arbitrierungsfehlern 
während der Übertragung kommen.

Generell wären Kommentare (mehr als READ und WRITE) schön. Weil mir als 
unbedarftem Leser wird nicht überall klar, warum etwas gemacht wird.

So was wie 0b10100000 sollte man noch in ein aussagekräftiges Define 
verpacken.

Ich hoffe dir hilft das ein bisschen :-)

Mit freundlichen Grüßen,
N.G.

[Oliver J. (skriptkiddy)]

Hi,

Für die 24C-EEPROMs braucht es nach dem Schreiben einer Page in der 
Regel Acknwoledgepolling, um zu wissen, wann die nächste Page 
geschrieben werden kann. Das Übertragen der Page über I2C erfolgt immer 
erst in einen Puffer. Nach dem I2C-Stop wird der Pufferinhalt dann 
tatsächlich persistent geschrieben. Während dieser Zeit ist das EEPROM 
nicht ansprechbar. Sowas ist in der Fleury-Lib nicht abgedeckt. Man muss 
also selbst im EEPROM-Treiber immer wieder Start+Write (wenn kein Ack 
kommt STOP) schicken bis ein ACK kommt. Dauert so 5ms (Größenordnung). 
Das gleiche gilt, wenn man unmittelbar nach dem Schreiben was lesen 
will.

Grüße Oliver

[Peter D. (peda)]

N. G. schrieb:
> Ohne ins Datenblatt von verwendeten EEPROM zu schauen: Nachdem eine Page
> beschrieben wurde: warum i2c_stop() und dann wieder i2c_start()? Wäre da
> i2c_rep_start() nicht angebracht.

Hättest Du mal reingeschaut, wüßtest du es.
Das Schreiben erfolgt erst nach dem Stop. Ein Repeat-Start bricht das 
Schreiben ab, alle Bytes im Schreibpuffer werden verworfen.

[N. G. (newgeneration)]

Peter D. schrieb:
> N. G. schrieb:
>> Ohne ins Datenblatt von verwendeten EEPROM zu schauen: ...
>
> Hättest Du mal reingeschaut, wüßtest du es.

Deswegen hab ich es ja dazu geschrieben. Den Hinweis dann bitte 
ignorieren.
Aus Erfahrung mit Sensoren hab ich es halt mal in die Runde geworfen.

Nichtsdestotrotz habe ich noch mehr als nur das geschrieben :-)

Mit freundlichen Grüßen,
N.G.

[Peter D. (peda)]

Anbei eine einfache Lib.
Wichtig ist beim Schreiben, den Block in Pages zu zerlegen und auf die 
Pagegrenzen zu testen.

[H.Joachim S. (crazyhorse)]

Oder gleich auf FRAM ausweichen, dann hat man keinerlei Probleme.
Man braucht sich nicht um page-Grenzen zu kümmern, keine Schreibzeiten 
beachten,  kein ack-polling, kein Verschleiss. Man spart sich dann auch 
das evtl. verteilte Schreiben für häufig benutzte Zellen bzw. muss sich 
gar nicht erst Gedanken drüber machen.

Ein Nachteil natürlich - teurer.