Durch volatile explodiert der Speicherbedarf des AVR

[Michael N. (much)]

Hallo Leute,

ich bin gerade dabei ein Programm zu schreiben welches das Taktsignal 
für einen Schrittmotor alla Atmel Application Note AVR446 erzeugt. Ich 
verwende also den 16bit timer eines AVR (attiny2313).
Der Wert des Output Compare Registers des Timers wird in der ISR 
berechnet und gesetzt. dazu benötige ich einige Variablen aus der 
Berechnung des vorangegangenen Timer Interrupts. Daher hab ich jetzt 
globale Variablen für diese Werte (Datentyp = uint16_t) angelegt. Wenn 
ich dies variablen jetzt aber volatile mache explodiert mein Program- 
und Data-Speicher.

ohne volatile:

AVR Memory Usage
----------------
Device: attiny2313

Program:    1494 bytes (72.9% Full)
(.text + .data + .bootloader)

Data:         97 bytes (75.8% Full)
(.data + .bss + .noinit)

EINE variable als volatile

AVR Memory Usage
----------------
Device: attiny2313

Program:    4862 bytes (237.4% Full)
(.text + .data + .bootloader)

Data:        361 bytes (282.0% Full)
(.data + .bss + .noinit)

Zum einen kann ich nicht ganz nachvollziehen weshalb eine uint8_t 
Variable plötzlich so viel speicher verbraucht. Kann mir das evtl. 
jemand erklähren?
Zum zweiten möchte ich natürlich gerne wissen ob man das irgendwie 
optimieren kann.

PS: hier noch die betrefende Codestelle:

//================================================================= globals ===
uint16_t accelerationStop; //volatile uint16_t accelerationStop;
uint16_t decelerationStart;
uint16_t goal;
uint16_t currentStep; //volatile uint16_t currentStep;
uint16_t counterValue; //volatile uint16_t counterValue;
uint8_t refreshCounterValue; //volatile uint8_t refreshCounterValue;
uint8_t busy; //volatile uint8_t busy;

//===================================================================== isr ===
ISR(TIMER1_COMPA_vect) {

  if (refreshCounterValue) {
    if (currentStep <= accelerationStop) { //acceleration mode
      counterValue = counterValue  - ((2 * counterValue) / (4 * (currentStep + 1) + 1));
      counterValue = counterValue / 2;
    } else if ((currentStep) >= decelerationStart) { //deceleration mode
      accelerationStop++;
      counterValue = ((4 * accelerationStop * counterValue + counterValue) / (4 * accelerationStop - 1));
      counterValue = counterValue / 2;
      accelerationStop -= 2;
    }

    OCR1AH = (uint8_t) (counterValue >> 8);
    OCR1AL = (uint8_t) (counterValue & 0xFF);

    currentStep++;
    if (currentStep >= goal) {
      TIMSK &= ~(1 << OCIE1A);
      busy = 0;
    }
    refreshCounterValue = 0;
    PORTB &= ~(1 << PB3);
  } else {
    refreshCounterValue = 1;
    PORTB |= (1 << PB3);
  }
}

[Falk B. (falk)]

Dein Problem liegt woanders. Poste VOLLSTÄNDIGEN Code als Anhang.

[Εrnst B. (ernst)]

Michael N. schrieb:
> ich dies variablen jetzt aber volatile mache explodiert mein Program-
> und Data-Speicher.

Dann mach sie nicht volatile.

Volatile brauchst du nur, wenn du sowohl in der ISR als auch übers 
main() auf die Variable zugreifen willst. (Ansonsten: "static" in der 
ISR definieren)

Und auch da kann es helfen, nur einzelne Zugriffe "volatile" 
auszuführen, anstatt die Variable immer und generell dem Optimierer zu 
entziehen.

[Ingo (Gast)]

accelerationStop * counterValue

ohne Cast nach 32Bit ganz schön mutig...
Am volatile liegt es wohl nicht, obwohl es natürlich den Code etwas 
größer macht...


Ingo

[Frank M. (ukw) (Moderator)]

Michael N. schrieb:
> Wenn
> ich dies variablen jetzt aber volatile mache explodiert mein Program-
> und Data-Speicher.

Alle globalen Variablen, die Du ausschließlich in der ISR (und sonst 
nirgendwo) benutzt, solltest Du in der ISR mit static statt volatile 
deklarieren. Alle volatile-Variablen, die Du tatsächlich global 
benötigst, solltest Du bei mehrfacher Verwendung innerhalb der ISR einer 
lokalen Variablen zu Beginn der Funktion zuweisen und dann mit dieser in 
der ISR arbeiten. Am Ende der ISR kannst Du den Wert der lokalen 
Variablen wieder zurüspeichern.

Aber das kann nicht alles sein. Poste bitte den vollständigen Code.

[Yvonne J. (laserlight)]

schau mal nach einem "inline"... das wäre für mich eher ein Grund...

[Michael N. (much)]

Hab jetzt mal den Code gezippt (siehe Anhang).

Ingo schrieb:
> ohne Cast nach 32Bit ganz schön mutig...

Stimmt. Hab das jetzt nur so schnell runterprogrammiert. Das Sollte ich 
auch noch mal an anderen Stellen im Code kontrollieren.

[Peter D. (peda)]

Michael N. schrieb:
> EINE variable als volatileAVR Memory Usage
> ----------------
> Device: attiny2313
>
> Program:    4862 bytes (237.4% Full)
> (.text + .data + .bootloader)
>
> Data:        361 bytes (282.0% Full)
> (.data + .bss + .noinit)

Da wird die unopimierte Float-Lib hinzugelinkt, die braucht viel Flash 
und 264 Byte SRAM (361 - 97 = 264).
Du hast irgendwo float drin, was aber der Compiler schon ausrechnen kann 
(Konstante).
Das volatile verhindert das Ausrechnen.
Volatile nicht mit der Gießkanne verteilen, sondern nur dort, wo nötig.
Z.B. nicht bei Konstanten.


Peter

[Michael N. (much)]

Hab jetzt wie vorgeschlagen auch mal an anderer Stelle gesucht und bin 
glaub ich fündig geworden. Der Übeltäter scheint folgender 
Codeausschnitt zu sein:

counterValue = counterValue * 0.676;

Die Formeln hab ich wohl zu sorglos heruntergetippt. Werd noch mal alle 
genau unter die Lupe nehmen müssen.

Frank M. schrieb:
> Alle globalen Variablen, die Du ausschließlich in der ISR (und sonst
> nirgendwo) benutzt, solltest Du in der ISR mit static statt volatile
> deklarieren.

Das kann ich aber nur machen wenn ich die Variablen nach dem verlassen 
der ISR nicht mehr benötige, was in meinem Fall ja nicht der Fall ist da 
ich sie ja beim nächsten Aufruf der ISR wieder verwende, oder hab ich da 
etwas falsch verstanden?

[Chris (Gast)]

Michael N. schrieb:
> Das kann ich aber nur machen wenn ich die Variablen nach dem verlassen
> der ISR nicht mehr benötige, was in meinem Fall ja nicht der Fall ist da
> ich sie ja beim nächsten Aufruf der ISR wieder verwende, oder hab ich da
> etwas falsch verstanden?

Dafür auch das static davor. Somit bleiben sie erhalten auch beim 
verlassen der ISR.

[Rolf Magnus (Gast)]

Es liegt daran:

  counterValue = (F_CNTR * sqrtf((2 * ALPHA) / WP_MAX));
  counterValue = counterValue / 2;

  //set counter
  OCR1AH = (uint8_t) (counterValue >> 8);
  OCR1AL = (uint8_t) (counterValue & 0xFF);

  //multiply first counter value with correction value
  counterValue = counterValue * 0.676;

Ohne volatile kann der Compiler die erste Zuweisung mit einer 
Konstanten, die Division und die float-Multiplikation zusammenfassen und 
zur Compilezeit ausrechnen. Für die Werte von OCR1AH/AL kann auch 
enstprechend gleich eine Konstante eingesetzt werden. Wenn du die 
Variable volatile machst, müssen aber alle Aktionen, die counterValue 
lesen, ändern und wieder schreiben, wirklich zur Laufzeit durchgeführt 
werden, insbesondere die float-Multiplikation, die dann ein Linken an 
die ganze float-Library nach sich zieht.

[Frank M. (ukw) (Moderator)]

Michael N. schrieb:
> Das kann ich aber nur machen wenn ich die Variablen nach dem verlassen
> der ISR nicht mehr benötige, was in meinem Fall ja nicht der Fall ist da
> ich sie ja beim nächsten Aufruf der ISR wieder verwende, oder hab ich da
> etwas falsch verstanden?

Ja, da hast Du was falsch verstanden. static-Variablen bleiben auch nach 
dem Return der Funktion am Leben, d.h. sie behalten ihren Wert - genauso 
wie globale Variablen.

Dafür ist static da: Lebenszeit "unendlich", aber nicht global 
zugreifbar.

Dir fehlt essentielles C-Wissen...

[Falk B. (falk)]

Da sind noch weitere Problemfälle drin, z.B. busy. Volatile will 
verstanden und richtig angewendet sein, siehe Interrupt. Und das 
Thema der Fließkommarechnung eliminiert man mit Festkommaarithmetik.