avrlib: eeprom.h Funktionen, inline?

[Apollo M. (Firma: @home) (majortom)]

Innerhalb einer ISR muss eeprom_read/write_byte() aufgerufen werden und 
das gesamte Timing ist problematisch ...

Frage, gibt es eine gcc Möglichkeit den Funktionaufruf der asm 
eeprom_read/write_byte() zu inline zu zwingen.
Attribute "ISR_FLATTEN" wäre wohl dazu da, bewirkt aber nichts?!

Die Funtionen neu zu schreiben wäre natürlich am Schluss eine Lösung ...

[Jörg W. (dl8dtl) (Moderator)]

Da die Funktionen aus einer Bibliothek kommen, so erstmal nicht, und 
zwingen schon gar nicht. Du könntest gucken, ob er sie bei -flto ggf. 
inlinen kann.

Ansonsten in der Tat, selbst schreiben.

Aber zeitkritisch und ISR? Hmm. EEPROMs brauchen ziemlich lange zum 
Schreiben (Lesen geht schnell).

[c-hater (Gast)]

Apollo M. schrieb:

> Innerhalb einer ISR muss eeprom_read/write_byte() aufgerufen werden und
> das gesamte Timing ist problematisch ...

Das ist definitiv keine gute Idee, zumindest nicht bezüglich 
eeprom_write(). Das dauert quasi endlos (jedenfalls aus der Sicht einer 
ISR).

Sprich: das Design der Software muss dringendst überdacht werden. Es 
darf nicht sein, dass es nötig wird, in einer ISR in den EEPROM zu 
schreiben. Jedenfalls nicht, wenn der normale Betrieb laufen soll.
In der ISR eines "Vor-Brownout-Detectors" sieht das anders aus. Da 
kommt's nicht mehr darauf an, ob und wie der Rest des Systems 
weiterläuft, da hat das erfolgreiche Wegschreiben der Daten in den 
EEPROM die absolute Priorität.

> Frage, gibt es eine gcc Möglichkeit den Funktionaufruf der asm
> eeprom_read/write_byte() zu inline zu zwingen.

Was soll das bringen, selbst wen nes möglich sein sollte? Das sind doch 
nur ein paar verschissene Takte. Im Verhältnis zu der Zeit, die 
Schreibzugriffe auf den EEPROM dauern, kann man das völlig in den Skat 
drücken.

[Oliver S. (oliverso)]

Jörg W. schrieb:
> Du könntest gucken, ob er sie bei -flto ggf.
> inlinen kann.

Können könnte er vermutlich, machen macht er es aber nicht. Also read 
per inline-Assembler selber in die ISR schreiben.

Wenn in der ISR auch ein write vorkommt, kann man sich das aber auch 
schenken. Das dauert mehrere (!!!) ms, da kommt es auf die paar Takte 
eines call/ret wirklich nicht an.

Oliver

[Oliver S. (oliverso)]

Oliver S. schrieb:
> Können könnte er vermutlich,

Das nehme ich dann doch zurück: Da das Assembler ist, kriegt das der 
LTO-Compiler nie zu sehen.

Oliver

[Apollo M. (Firma: @home) (majortom)]

Jörg W. schrieb:
> Aber zeitkritisch und ISR? Hmm. EEPROMs brauchen ziemlich lange zum
> Schreiben (Lesen geht schnell).

c-hater schrieb:
> Das ist definitiv keine gute Idee, zumindest nicht bezüglich
> eeprom_write(). Das dauert quasi endlos (jedenfalls aus der Sicht einer
> ISR).

Das Projekt soll ein RAM-Modul für den ICOM IC-751A emulieren und 
bedacht wurde bis jetzt nur die Laufzeit des Programs. ABER das EEPROM 
access timing kommt ja noch dazu.
Also muss ich wohl am uC uPD7801 die Wait Line benutzen und das Timing 
beliebig entschärfen!

Kritisch ist nur die read Funktion, da das write erstmal ins RAM 
schreibt und dann im Hinergrund ins EEPROM schreiben kann.

RAM wc write 850+500ns, read 600+500ns

Andere Lösung wäre ein Raspi Pico, der wäre in Echtzeit dazu fähig, das 
RAM worst case Timing zu erfüllen. ABER uPD7801 und daneben ein Paspi 
Pico das tut irgendwie weh.
Ich habe mir 3 Raspi Pico für 10€ von der HAM-Radio mitgebracht und 
spiele viel mit Micropython rum - was mir immer richtig viel Spass 
macht!

[...(...)... (Gast)]

Apollo M. schrieb:
> Kritisch ist nur die read Funktion, da das write erstmal ins RAM
> schreibt und dann im Hinergrund ins EEPROM schreiben kann.

Warum sollte die Lesefunktion nicht aus einem Abbild im RAM lesen, in 
das beim Start das gesamte EEPROM kopiert wird?

Dann ist auch da nix kritisch. Beim Schreiben wird auch ins RAM 
geschrieben und, wenn der Wert siich tatsächlich ändert, dies irgendwo 
vermerkt, um dann außerhalb der ISR ins EEPROM geschrieben zu werden.

[c-hater (Gast)]

...(...)... schrieb:

> Warum sollte die Lesefunktion nicht aus einem Abbild im RAM lesen, in
> das beim Start das gesamte EEPROM kopiert wird?

Bei aktuellen AVR8 wäre das nichtmal nötig, da der EEPROM in den 
SRAM-Bereich gemapped ist. Sprich: da kann man lesend(!!!) genauso drauf 
zugreifen wie auf RAM und auch genauso schnell. Der Zugriff kostet zwei 
Takte, so oder so...

[Apollo M. (Firma: @home) (majortom)]

c-hater schrieb:
> Bei aktuellen AVR8 wäre das nichtmal nötig, da der EEPROM in den
> SRAM-Bereich gemapped ist.

Ja ..., ich werde mal das Timing mit einem AVR128DA28 oder so anschauen, 
die liegen auch nur rum und wurden mir immer als Sample geschenkt - vor 
der Krise, jetzt kommt da auch nichts mehr rüber.

[Apollo M. (Firma: @home) (majortom)]

... und auch die RAM read Emulation kann aus dem uC SRAM laufen. Das 
EEPROM/RAM Image wird zum Start einfach in den uC SRAM kopiert ...

[c-hater (Gast)]

Apollo M. schrieb:
> ... und auch die RAM read Emulation kann aus dem uC SRAM laufen. Das
> EEPROM/RAM Image wird zum Start einfach in den uC SRAM kopiert ...

Tolle Idee. Hatte  ...(...)... (Gast)

schon hier:
Beitrag "Re: avrlib: eeprom.h Funktionen, inline?"

[Apollo M. (Firma: @home) (majortom)]

c-hater schrieb:
> olle Idee. Hatte  ...(...)... (Gast)

Genau, das Timing wird dann auch problemlos erfüllt - passt also!