Probleme mit AVR Studio Optimierung bei uint32_t

[Stefan H. (zero-cool)]

hi all ich habe ein Problem mit folgenem Code:

uint32_t read_R (void)
{
  uint32_t Wert = 0;  

  ADMUX &= ~(1<<MUX0);            
  ADCSRA |= (1<<ADSC);            
  while ( !(ADCSRA & (1<<ADIF))) {}
  Wert += ADCL;
  Wert += (ADCH * 0x100);

        ....
}

(ist jetz nur ein ausschnitt)

(Optimierung: -0s)
Wenn ich diese stelle mit dem AVR Studio simuliere und die variable Wert 
beobachte, so wird sie nicht auf 0 gesetzt, obwohl das in der 
deklaration geschieht. Das aufaddieren der Werte von ADCL und ADCH 
funktioniert ebenfalls nicht...

(Optimierung: -00)
Hier funktioniert alles einwandfrei, da die deklarationszeile nicht 
wegoptimiert wurde. auch die Ausgaben des ADC werden aufaddiert, wie ich 
es will (nur so ist der code halt doppelt so groß wie oben...)

Gibt es da abhilfe?
Was haltet ihr vom AVR Studio als Programmieroberfläche und compiler?
Gibt es eine möglichkeit meinen µC Code mit µVision3 (Keil) zu schreiben 
und zu kompilieren?
Finde ihn dort nämlich nicht bei der Device Auswahl...
geht übrigends um nen Atmel Atmega 8535.


Vielen Dank schonmal für eure Antworten!

Gruß
Stefan

[Sven P. (Gast)]

Stefan Hopf schrieb:
> hi all ich habe ein Problem mit folgenem Code:
> (ist jetz nur ein ausschnitt)
Das ist immer ungünstig.

> (Optimierung: -0s)
Wenn du optimierst, kannst du dich nicht mehr auf den Debugger 
verlassen. Schau lieber ins Assembler-Listing, eventuell wurde aus 
anderen Gründen etwas wegoptimiert.

> Was haltet ihr vom AVR Studio als Programmieroberfläche und compiler?
AVR Studio kenne ich nicht mehr (zu lange her), der C-Compiler ist der 
AVR-GCC, und von dem halte ich nicht soooooo besonders viel.

[Stefan H. (zero-cool)]

hi Sven
erstmal danke für die schnelle antwort!

ok wenn es sinnvoller ist, dann poste ich das komplette modul:

uint32_t read_R (void)
{
  uint32_t Wert = 0;  

  ADMUX &= ~(1<<MUX0);            
  ADCSRA |= (1<<ADSC);            
  while ( !(ADCSRA & (1<<ADIF))) {}
  Wert += ADCL;
  Wert += (ADCH * 0x100);

  ADMUX |= (1<<MUX0);
  ADCSRA |= (1<<ADSC);
  while ( !(ADCSRA & (1<<ADIF))) {}
  Wert += ADCL;
  Wert += (ADCH * 0x100);
    
  Wert *= 488281;  
  Wert /= 14;
  Wert /= 100000;
  Wert += 900;
  
  Wert = gerundet (Wert);  
  
  
  return Wert;
}

> Wenn du optimierst, kannst du dich nicht mehr auf den Debugger
> verlassen. Schau lieber ins Assembler-Listing, eventuell wurde aus
> anderen Gründen etwas wegoptimiert.

Ja also das rücksezten auf NULL der Variable entfällt auch laut 
Assembler listing.
Was meinst du mit anderen Gründen?

[Anja (Gast)]

>Ja also das rücksezten auf NULL der Variable entfällt auch laut
>Assembler listing.
Warum soll der Compiler auch erst die Variable auf null setzen wenn 
anschließend der ADC-Wert addiert wird? Da ist es doch einfacher statt 
der Addition eine einfache Zuweisung zu machen.
Wenn du haben willst daß tatsächlich eine Addition durchgeführt wird 
mußt Du die Wert-Variable als "volatile" deklarieren.

Also:
volatile uint32_t Wert = 0;

Übrigens:
>  Wert += ADCL;
>  Wert += (ADCH * 0x100);

kann man kürzer schreiben als
   Wert += ADCW;

[Stefan H. (zero-cool)]

hi Anja
cool das mit dem ADCW Register hab ich in meinem headerfile wohl 
überlesen (habs nun gesehn) =)

warum volatile?
Es lässt sich zwar damit simulieren und funktioniert, aber warum, ich 
verwende doch im mom noch keine Interrupts!
Ist bis jetzt ja bloß n test code.

Achja weiß jemand, warum das Variablen beaobachtem beim AVR Studio 
manchmal funktioniert, und manchmal nicht (not in scope, location not 
valid)?

Gruß
Stefan

[Karl H. (kbuchegg)]

Stefan Hopf schrieb:

> warum volatile?

Damit der Compiler daran gehindert wird, an dieser Variablen 
Optimierungen durchzuführen, wie zb

Die Variabel wird komplett wegoptimiert ...

> Achja weiß jemand, warum das Variablen beaobachtem beim AVR Studio
> manchmal funktioniert, und manchmal nicht (not in scope, location not
> valid)?

... wie zb hier

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

Diese Optimierung hat aber in diesem Fall nur Einfluss auf das im 
Debugger/Simulator beobachtete Verhalten. Das Ergebnis stimmt obwohl der 
Debugger die Variable falsch anzeigt.

Im Prinzip gilt deshalb, dass man nur bei abgeschalteter Optimierung 
debuggen sollte. Was bei AVRs leider nicht ganz praktikabel ist. Sei es 
weil der Code dann nicht ins Flash passt, sei es weil die _delay_xx 
Funktionen dann nicht funktionieren.

[Stefan H. (zero-cool)]

ah ok dann ist mir das jetz auch klar...
denn im controller funktionierts ja wies soll... bloß beim debuggen eben 
ned, aber wenn ich das weiß, dann muss ich halt die optimierung 
ausschalten, wenn ich debugge.

Vielen Dank für eure Hilfe!