EEprom schneller schreiben

Brecher schrieb:
> Das Lesen des EEPROMs ist sehr schnell.
> if (lese(x) != x) schreibe(x);

Statt einem eeprom_write_word kann man auch ein eeprom_update_word 
benutzen, dass schreibt nur wenn sich auch wirklich was geändert hat ;)

Ich arbeite nie direkt im EEPROM, sondern lege eine Kopie im SRAM an und 
bearbeite diese. Bei Bedarf erfolgt dann ein Rückspeichern in den EEPROM 
im Hintergrund.

1

struct

2

{

3

  uint8_t* src;

4

  uint16_t dst;

5

  uint16_t len;

6

  bool busy;

7

} eew;

8

9

void epp_wr_poll(void)                          // called by main loop

10

{

11

  if (eew.busy == false)                        // nothing to do

12

    return;

13

  if (EECR & 1 << EEWE)                         // not ready yet

14

    return;

15

  EEAR = eew.dst;

16

  EECR |= 1 << EERE;                            // read

17

  if (*eew.src != EEDR)

18

  {

19

    EEDR = *eew.src;

20

    ATOMIC_BLOCK(ATOMIC_RESTORESTATE)

21

    {

22

      EECR |= 1 << EEMWE;                       // Enable Write

23

      EECR |= 1 << EEWE;                        // write

24

    }

25

  }

26

  eew.src++;

27

  eew.dst++;

28

  if (--eew.len == 0)

29

    eew.busy = false;                           // all bytes written

30

}

31

32

static void eep_wr_start(uint8_t* src, uint16_t dst, uint16_t len)

33

{

34

  eew.src = src;

35

  eew.dst = dst;

36

  eew.len = len;

37

  eew.busy = true;

38

}

Nun, mit eep_wr_start() startet man das Blockwrite. Es wartet aber nicht 
auf das Ende, sondern kehrt sofort zurück.
Das Schreiben führt dann epp_wr_poll() aus, welches zyklisch aufgerufen 
werden muß, z.B. in der Mainloop.
Die Namen src, dst, len dürften selbsterklärend sein.

Lesca schrieb:
> Nutze dazu die Funktion eeprom_write_block.

Die ist blockierend, denn sie wartet auf das Ende des Schreibvorgangs.

> Wie könnte ich das schreiben beschleunigen?

Indem man es nichtblockierend als Statemachine schreibt und immer 
nur den Schreibvorgang startet, nicht aber direkt auf das Ende wartet. 
Dafür braucht es nicht mal einen Interrupt.

Das alles ändert aber nichts daran, daß ein Schreibzyklus ins EEPROM 
„endlos“ lange dauert. Und wenn die Daten schneller geschrieben werden 
müssen, als das Schreiben tatsächlich dauert, dann helfen auch die 
genialsten Programmiertipps nicht weiter.

Entweder über das „müssen“ nachdenken, oder andere Hardware einsetzen.

Oliver

Oliver S. schrieb:
> Das alles ändert aber nichts daran, daß ein Schreibzyklus ins EEPROM
> „endlos“ lange dauert.

Naja, um die 3-4ms pro Byte (Erase and Write).

> Und wenn die Daten schneller geschrieben werden
> müssen, als das Schreiben tatsächlich dauert, dann helfen auch die
> genialsten Programmiertipps nicht weiter.

Unsinn! Das Problem ist die Blockierung der CPU durch die einfache 
EEPROM-Schreibfunktion!

> Entweder über das „müssen“ nachdenken, oder andere Hardware einsetzen.

Erstmal das Problem WIRKLICH verstehen!

Falk B. schrieb:
> Erstmal das Problem WIRKLICH verstehen!

Eben. Und da außer der Angabe, daß je Block 80 Byte geschrieben werden 
müssen, die über CAn hereinkommen, nichts weiter bekannt ist, fehlen 
alle Fakten zum wirklichen Verstehen des Problems.

Oliver

MWS schrieb:
> Falk B. schrieb:
>> Naja, um die 3-4ms pro Byte (Erase and Write).
>
> Laut DB 8,5ms.

Ok, ich hab beim ATmega328 reingeschaut.

> Die Lösung ist schwieriger, denn obwohl eine interruptgesteuerte EEProm
> Schreibroutine die normale Programmausführung viel weniger belasten
> würde, so dauert es auch damit noch 680ms bis ein Block geschrieben ist.

Stimmt.

> Selbst wenn der Controller neue Can-Daten zwischenzeitlich empfangen
> konnte, so hilft das nichts, wenn die alten noch nicht im EEPRom
> abgelegt sind.

Jain. Dafür gibt es FIFOs oder andere Puffermethoden.

MWS schrieb:
> Die Lösung ist schwieriger

Nö, die Lösung so einfach, wie bereits beschrieben. Ich hätte es auch 
mit Interrupt machen können, aber das war nicht nötig.
Wenn die EEPROM-Daten mit im RAM liegen, kann man auch viel einfacher 
drauf zugreifen. Man merkt überhaupt keinen Unterschied zu echten 
Variablen. Sie werden nach dem Reset vom EEPROM geladen und bei Bedarf 
im Hintergrund dahin gesichert.
Zur Sicherheit speichere ich im EEPROM 2 Datensätze mit CRC16. Damit ist 
dann auch abgesichert, wenn vor dem Abschalten das Schreiben im 
Hintergrund noch nicht beendet ist.

Lesca schrieb:
> Nutze dazu die Funktion eeprom_write_block.

die meisten Routinen warten nach jedem Byte 5ms-10ms, das war für mich 
unerträglich, ich schrieb meine eigene write block Routine (mit Hilfe 
aus dem Netz), nach jedem Byte schreiben teste ich in einer Schleife ob 
das I2C EEPROM ansprechbar ist, wenn ja schreibe ich das nächste Byte, 
das hat meine Geschwindigkeit beim Schreiben mindestens verfünffacht.

1

#define readIIC() Wire.read()

2

3

void my_i2c_eeprom_wait_ready(void) { 

4

  Wire.setClock(I2C_LOW);

5

  // Wait until EEPROM gives ACK again.

6

  // this is a bit faster than the hardcoded 5 milli

7

  do { 

8

    Wire.beginTransmission(MY_I2C_EEPROM_ADDRESS); Wire.requestFrom(MY_I2C_EEPROM_ADDRESS, 1);

9

    readIIC();

10

  }while(Wire.endTransmission());

11

  Wire.setClock(I2C_HIGH);

12

} // void my_i2c_eeprom_wait_ready(void)

13

14

void my_i2c_eeprom_write_buffer( uint16_t eeaddress, char *data, uint16_t length ) { 

15

  uint16_t str_ptr = 0;

16

  while(length--) { 

17

    my_i2c_eeprom_wait_ready();

18

    my_i2c_eeprom_write_byte( (eeaddress+str_ptr++), *data++ );

19

    //DEBUG_PRINTLN(*data++);

20

  };

21

} // void my_i2c_eeprom_write_buffer( uint16_t eeaddress, char *data, uint16_t length )

bei internen EEPROMs kann das busy flag abgefragt werden!

Peter D. schrieb:
> Nö, die Lösung so einfach, wie bereits beschrieben. Ich hätte es auch
> mit Interrupt machen können

Mir ist wieder eingefallen, warum ich es nicht im EEPROM-Interrupt 
mache.
Wenn sich nur wenige Bytes geändert haben, wird der Interrupt ja sehr 
oft hintereinander aufgerufen. Das kann die Mainloop um mehrere ms 
verzögern und damit Seiteneffekte bewirken. Ein Aufruf im Timerinterrupt 
würde die nötige Updatezeit dagegen unnötig verlängern.
Daher ist der Aufruf in der Mainloop der optimale Platz. Er behindert 
nichts und beendet das Update so schnell wie möglich.

c-hater schrieb:
> Es ist völlig Ritze, wieviele Bytes sich geändert haben: Der Interrupt
> kann bei korrekter Programmierung natürlich maximal mit der Rate
> auftreten, die die Schreibzeit für ein Byte vorgibt. Also, irgendwas im
> einstelligen ms-Bereich.

Dann hast Du meinen Code nicht gelesen oder nicht verstanden.
Ich prüfe vor dem Schreiben, ob das Byte bereits stimmt. Dann wird 
nämlich nicht nochmal überschrieben. D.h. der Interrupt wird beendet, 
genau ein Befehl der Mainloop ausgeführt und wieder in den Interrupt 
gesprungen.

Es mag Wumpe sein, ob die Mainloop bei nur einem geänderten Byte von 
1024 Byte einige ms Däumchen dreht, aber wenn ich es vermeiden kann, ist 
es die bessere Lösung.
Seiteneffekte zu kennen ist gut, aber Seiteneffekte zu vermeiden, ist 
besser.

Mitlesa schrieb:
> Einfach und schon deshalb ein bisschen genial!

Danke für die Blumen.
Ich hatte ihn auch als Interrupt probiert. Der Code ist dadurch etwas 
angestiegen, da ja ein Interrupt alles sichern muß, die Mainloop aber 
Register zerstören darf (Call-used registers: r18-r27, r30-r31).
Dann ist mir aber der Seiteneffekt aufgefallen und ich habe die 
Interruptvariante wieder verworfen.

Peter D. schrieb:
> c-hater schrieb:
>> Es ist völlig Ritze, wieviele Bytes sich geändert haben: Der Interrupt
>> kann bei korrekter Programmierung natürlich maximal mit der Rate
>> auftreten, die die Schreibzeit für ein Byte vorgibt. Also, irgendwas im
>> einstelligen ms-Bereich.
>
> Dann hast Du meinen Code nicht gelesen oder nicht verstanden.
> Ich prüfe vor dem Schreiben, ob das Byte bereits stimmt. Dann wird
> nämlich nicht nochmal überschrieben. D.h. der Interrupt wird beendet,
> genau ein Befehl der Mainloop ausgeführt und wieder in den Interrupt
> gesprungen.

Und warum springst du dann nicht in der ISR weiter zum nächsten Byte, 
das sich geändert hat? Es ist natürlich nicht besonders sinnvoll, aus 
der ISR rauszuspringen, ohne den nächsten Schreibvorgang angestoßen zu 
haben.

Rolf M. schrieb:
> Und warum springst du dann nicht in der ISR weiter zum nächsten Byte,
> das sich geändert hat? Es ist natürlich nicht besonders sinnvoll, aus
> der ISR rauszuspringen, ohne den nächsten Schreibvorgang angestoßen zu
> haben.

gute Frage aber schrieb PeDa nicht das er es nicht in der ISR macht?

Da ein Schreibvorgang eh um ms dauert könnte man nach dem Anstossen auch 
raus weil keiner solange die ISR blockieren will bis das Byte 
geschrieben ist.

Joachim B. schrieb:
> Rolf M. schrieb:
>> Und warum springst du dann nicht in der ISR weiter zum nächsten Byte,
>> das sich geändert hat? Es ist natürlich nicht besonders sinnvoll, aus
>> der ISR rauszuspringen, ohne den nächsten Schreibvorgang angestoßen zu
>> haben.
>
> gute Frage aber schrieb PeDa nicht das er es nicht in der ISR macht?

Er schrieb, dass er die ISR-Variante verworfen hat, weil bei wenigen 
Änderungen die ISR mit sehr hoher Rate getriggert wird. Und das liegt 
eben daran, dass er aus ihr zurückspringt, ohne den nächsten 
Schreibvorgang zu starten.

> Da ein Schreibvorgang eh um ms dauert könnte man nach dem Anstossen auch
> raus weil keiner solange die ISR blockieren will bis das Byte
> geschrieben ist.

Ja selbstverständlich. Das ist ja der ganze Sinn davon, es 
interruptgesteuert zu machen. Ist ein Byte fertig geschrieben, wird der 
Interrupt ausgelöst, man stößt den nächsten Schreibvorgang an und geht 
sofort wieder raus.

Rolf M. schrieb:
> Ja selbstverständlich. Das ist ja der ganze Sinn davon, es
> interruptgesteuert zu machen

das musst du mal in Code umsetzen, ich verstehe es nicht wirklich

Rolf M. schrieb:
> Und warum springst du dann nicht in der ISR weiter zum nächsten Byte,
> das sich geändert hat?

?
das nächste Byte kann doch erst nach dem Schreiben vom Vorgänger 
angestoßen werden und das dauert.

also zeige doch wie du dir das vorstellst.

Ich lasse es lieber in der Mainloop, nehme aber mit das man in der 
Schreibroutine nicht warten muss bis fertig, das Prüfen vom Internen EEP 
kann in der ISR bleiben, für I2C busy und I2C EEP lohnt das nicht, der 
Zugriff auf I2C dauert eh länger.

Joachim B. schrieb:
> Rolf M. schrieb:
>> Ja selbstverständlich. Das ist ja der ganze Sinn davon, es
>> interruptgesteuert zu machen
>
> das musst du mal in Code umsetzen, ich verstehe es nicht wirklich

Hmm, der Code wäre doch ziemlich tivial…

> Rolf M. schrieb:
>> Und warum springst du dann nicht in der ISR weiter zum nächsten Byte,
>> das sich geändert hat?
>
> ?
> das nächste Byte kann doch erst nach dem Schreiben vom Vorgänger
> angestoßen werden und das dauert.

Weißt du, was ein Interrupt ist? Die ISR wird doch erst dadurch 
angetriggert, dass der Vorgänger fertig ist. Sie startet ihre Ausführung 
genau zu dem Zeitpunkt, zu dem das nächste Byte geschrieben werden kann. 
Die ISR muss dann nur das Schreiben anstoßen und zurückspringen. Wenn 
das Byte dann fertig ist, wird die ISR wieder getriggert, und sie kann 
den nächsten Schreibvorgang anstoßen. Warum soll man da irgendwo warten 
müssen?

> Ich lasse es lieber in der Mainloop, nehme aber mit das man in der
> Schreibroutine nicht warten muss bis fertig, das Prüfen vom Internen EEP
> kann in der ISR bleiben,

In der ISR muss man es gar nicht prüfen. Sie wird ja gerade deshalb 
aufgerufen, weil der EEPROM jetzt bereit ist für den nächsten 
Schreibvorgang. Oder was dachtest du, wie die ausgelöst wird?

Rolf M. schrieb:
> Hmm, der Code wäre doch ziemlich tivial…

ach prosa code liegt mir nicht, wenn es trivial ist, dann zeige bitte 
Code.

Rolf M. schrieb:

> Er schrieb, dass er die ISR-Variante verworfen hat, weil bei wenigen
> Änderungen die ISR mit sehr hoher Rate getriggert wird. Und das liegt
> eben daran, dass er aus ihr zurückspringt, ohne den nächsten
> Schreibvorgang zu starten.

Im Prinzip ja, aber natürlich muss man bei sowas auch den Fall vorsehen, 
daß keine oder wenige Änderungen vorliegen! Dann muss der Prozess 
pausieren, natürlich nicht in der ISR. Erst wenn wieder ein 
Schreibzugriff auf die EEPROM-Variablen erfolgte, darf die FSM zum 
Update wieder aktiv werden. Und erst dann gibt es wieder 
EEPROM-Interrupts. Ist doch das Gleiche wie beim interruptgesteuerten 
Senden per UART, dort schaltet sich die ISR auch selber ab, wenn keine 
Daten mehr zu senden sind.

Aber am Ende ist es es zweitrangig, ob man das mit einem Timer- oder 
EEPROM-Interrupt macht, die Wirkung ist gleich.

Joachim B. schrieb:

> Ich lasse es lieber in der Mainloop, nehme aber mit das man in der
> Schreibroutine nicht warten muss bis fertig,

Nicht warten DARF! Denn das wäre ein blockierendes Verhalten und somit 
wäre der Ganze Aufwand für die Katz!

Rolf M. schrieb:
> Und warum springst du dann nicht in der ISR weiter zum nächsten Byte,
> das sich geändert hat?

Weil das den Interrupt zu sehr verlängern könnte, z.B. müßte bei 
angenommener Größe der Daten im EEPROM von 1kB die Schleife bis zu 1023 
mal durchlaufen werden. Das könnten wiederum z.B. den UART-Interrupt bei 
115kBaud Daten verlieren lassen usw. Der AVR hat ja keine Prioritäten, 
um andere Interrupts zu unterbrechen.
KISS, Keep It Short and Simple.

Peter D. schrieb:
> Rolf M. schrieb:
>> Und warum springst du dann nicht in der ISR weiter zum nächsten Byte,
>> das sich geändert hat?
>
> Weil das den Interrupt zu sehr verlängern könnte, z.B. müßte bei
> angenommener Größe der Daten im EEPROM von 1kB die Schleife bis zu 1023
> mal durchlaufen werden. Das könnten wiederum z.B. den UART-Interrupt bei
> 115kBaud Daten verlieren lassen usw. Der AVR hat ja keine Prioritäten,
> um andere Interrupts zu unterbrechen.

Naja, man könnte schon die ISR nach der Prüfung eines einzigen Bytes 
verlassen, auch ohne einen neuen Schreibvorgang auszulösen. Dann hätten 
andere ISRs die Chance, bearbeitet zu werden, denn der EEPROM-Interrupt 
hat in der Interrupt-Liste eine relativ niedrige Priorität.

> KISS, Keep It Short and Simple.

In der Tat. So ein Update-Prozess muss ja keine Rekorde aufstellen, der 
kann mit ein paar Dutzend Hz im Hintergrund laufen.

c-hater schrieb:
> Also woher, zum Teufel,
> stammt dein Problem speziell bezüglich des EEPROM-Schreibens?

Na von Dir doch. Nur Du versuchst, uns ein Problem einzureden, was nicht 
existiert.
Die Pollingmethode funktioniert bestens und hat eindeutig Vorteile 
gegenüber der Interruptmethode.
Natürlich könnte man in die Interruptmethode nen Haufen Schnulli 
einbauen, um die möglichen Problempunkte zu entschärfen. In diesem Fall 
ist aber die einfachste Methode auch die beste. Niemand hat was davon, 
den Code unnötig aufzublähen.

c-hater schrieb:
> Die da im Detail wären?

Sie wurden alle bereits genannt (es sind 3), lies sie einfach.

c-hater schrieb:
> Und: warum, zum Teufel, hat der Spender der edlen Hardware diesen
> Interrupt überhaupt vorgesehen, wenn er denn so völlig nutzlos, ja sogar
> kontraproduktiv ist, wie du behauptest?

Ich weiß, Du bist Meister im Worte verdrehen. Es geht hier um einen 
konkreten Anwendungsfall. Niemand hat behauptet, daß der Interrupt 
generell nutzlos ist.

c-hater schrieb:
> Kanst du das? Nachdenken?

Ich schon, aber Du scheinst damit Probleme zu haben, da Du für andere 
Probleme erfinden mußt.

Lesca schrieb:
> Lass dich nicht von @ c-hater  ärgern.Er kann seinen code einfach
> auch veröffentlichen dann sehen wir ja sein können.

Ich denke, das wird nicht passieren. c-hater steht ja völlig über uns. 
Wir sollen sicher selbst nachdenken um auf die bessere Variante zu 
kommen.