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 ...
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).
Gast
#7117978
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.
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. 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
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
#7118007
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.
Gast
#7118028
...(...)... 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...
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.
... 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 ...
Gast
#7118150
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?"
c-hater schrieb: > olle Idee. Hatte ...(...)... (Gast) Genau, das Timing wird dann auch problemlos erfüllt - passt also!
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.