AVR: Overhead struct

[Walter T. (nicolas)]

Hallo zusammen,

ich bin gerade mal wieder bei einer eher theoretischen Frage (denn mein 
Programm ist schnell genug): Ich habe momentan alle Prozeßparameter in 
zwei großen structs, nämlich eines für alle Nicht-flüchtigen 
Einstellungen und eines für die aktuellen Parameter.

Beim ersten Teil ist der Grund klar: Ein struct läßt sich sehr einfach 
ins EEPROM schieben, und wenn man das EEPROM ausliest, kann man die 
Werte sogar deuten.

Beim zweiten Teil mit den aktuellen Parametern ist der Grund lediglich, 
daß ich so meinen Überblick über die globalen Variablen nie verlieren 
kann, weil alle an derselben Stelle definiert sind. Könnte ich den AVR 
debuggen, wäre ein schöner Nebeneffekt ist auch hier, daß alle globalen 
Variablen sehr gut lesbar wären.

Aber insbesondere Werte aus dem EEPROM-struct werden oft in einem 
Interrupt ausgelesen und in den "aktuelle-Werte-struct" wird von quasi 
jedem Interrupt geschrieben (hauptsächlich Flags und ADC-Werte).

Kann ich den aus dem struct resultierenden Overhead vernachlässigen oder 
ist es (wenn das Programm nicht schnell genug ist) sinnvoll, ein struct 
noch einmal als globale Variable zu cachen (EEPROM) bzw. direkt als 
viele globalen Variablen anzulegen (Prozeßparameter)?

Viele Grüße
W.T.

[(prx) A. K. (prx)]

Welcher Overhead??

[Oliver S. (oliverso)]

Ich sach mal so: wenn sich die Werte im EEProm so häufig ändern, daß du 
die "oft" in einer ISR auslesen musst, dann hält das EEProm nicht lange.

Wenn aber nicht, dann braucht sie du die auch nicht häufig auslesen...

Oliver

[Walter T. (nicolas)]

A. K. schrieb:
> Welcher Overhead??

Ist der Compiler so artig, Zugriffe auf Variablen in globalen structs 
einfach zu Zugriff auf eine konstante Adresse zu ersetzen? Ist der 
Offset zur Laufzeit irrelevant?

Oliver S. schrieb:
> Ich sach mal so: wenn sich die Werte im EEProm so häufig ändern, daß du
> die "oft" in einer ISR auslesen musst, dann hält das EEProm nicht lange.

Ich sach mal so: Natürlich ist das struct eine Kopie des EEPROM-Inhalts, 
sonst bräuchte ist das struct ja gar nicht.

[(prx) A. K. (prx)]

Walter T. schrieb:
>> Welcher Overhead??
>
> Ist der Compiler so artig, Zugriffe auf Variablen in globalen structs
> einfach zu Zugriff auf eine konstante Adresse zu ersetzen?

Der Zugriff auf ein Strukt-Member besteht aus der Basisadresse und dem 
Offset. Da in diesem Fall beide konstant sind, werden sie bereits zur 
Übersetzungszeit zur fertigen Zieladresse addiert.

[Uwe (de0508)]

Hallo Walter,

wäre es nicht einfacher, ein Beispiel mit deinem Compiler zu übersetzen 
und den erzeugten Assemblercode zu besprechen ?

Denn ich habe bisher auch verschiedene "Optimierungen" gesehen und es 
kann sich so oder so verhalten.

Ich stimme dir auch bei der Umsetzung, bzgl. fast konstanten Daten im 
EEprom zu, ich mache das auch nicht anders.

[Rolf M. (rmagnus)]

Walter T. schrieb:
> A. K. schrieb:
>> Welcher Overhead??
>
> Ist der Compiler so artig, Zugriffe auf Variablen in globalen structs
> einfach zu Zugriff auf eine konstante Adresse zu ersetzen? Ist der
> Offset zur Laufzeit irrelevant?

Wieviele Nanosekunden darf der Zugriff denn dauern? Oder mit anderen 
Worten: Ist dein Programm überhaupt so zeitkritisch, dass es eine Rolle 
spielen kann?

> Oliver S. schrieb:
>> Ich sach mal so: wenn sich die Werte im EEProm so häufig ändern, daß du
>> die "oft" in einer ISR auslesen musst, dann hält das EEProm nicht lange.
>
> Ich sach mal so: Natürlich ist das struct eine Kopie des EEPROM-Inhalts,
> sonst bräuchte ist das struct ja gar nicht.

Aber warum musst du dann ständig aus dem EEPROM lesen? Und warum in 
einem Interrupt? Es sollte doch reichen, einmal bei der Initialisierung 
alles auszulesen und in deine RAM-Struktur zu kopieren.