Warnung in IAR

[Owen S. (senmeis)]

Hi,

eine Methode zur Initialisierung vom Timer2 im Atmega169 sieht so aus:

void RTC_init(void)
{
    Delay(1000);            // wait for 1 sec to let the Xtal stabilize after a power-on,

    __disable_interrupt();  // disabel global interrupt

    cbi(TIMSK2, TOIE2);             // disable OCIE2A and TOIE2

    //ASSR = (1<<AS2);        // select asynchronous operation of Timer2

    TCNT2 = 0;              // clear TCNT2A
    TCCR2A |= (1<<CS22) | (1<<CS20);             // select precaler: 32.768 kHz / 128 = 1 sec between each overflow

    while((ASSR & 0x01) | (ASSR & 0x04));       // wait for TCN2UB and TCR2UB to be cleared

    TIFR2 = 0xFF;           // clear interrupt-flags
    sbi(TIMSK2, TOIE2);     // enable Timer2 overflow interrupt

    OCR2A = 200;    // set timer2 compare value
    
    __enable_interrupt();                 // enable global interrupt
}

Der IAR Compiler gibt eine Warung für „while((ASSR & 0x01) | (ASSR & 
0x04));“ aus:

Warning[Pa082]: undefined behavior: the order of volatile accesses is 
undefined in this statement

Was bedeutet das?

Gruss
Owen

[Arne (Gast)]

> Was bedeutet das?
Steht doch in der Warning!

Der Compiler muss die beiden Lesezugriffe auf ASSR serialisieren und 
macht Dich darauf aufmerksam, daß die Reihenfolge bei volatile-Reads 
eine Auswirkung auf Dein Programm haben kann.

[lusch (Gast)]

while((ASSR & 0x01) | (ASSR & 0x04));

sicher, dass das nur EIN senkrechter Strich stehen soll ?

ansonsten mach das:
while((ASSR & (0x01 | 0x04)) ); // bzw 0x05

[Willi (Gast)]

Owen Senmeis schrieb:
> Warning[Pa082]:

Bei den Compileroptionen kann man diese Warnung unter 'Diagnostics' 
unterdrücken lassen, wenn sie zu sehr nervt.
Den Interrupt global zu sperren, wie es im obigen Beispiel der Fall ist, 
ist keine gute Idee und nicht notwendig. Wenn man Pech hat, kann die 
'while()'-Schleife das Timing total 'versauen'.

[Rolf M. (rmagnus)]

Willi schrieb:
> Owen Senmeis schrieb:
>> Warning[Pa082]:
>
> Bei den Compileroptionen kann man diese Warnung unter 'Diagnostics'
> unterdrücken lassen, wenn sie zu sehr nervt.

Statt die Warnung zu unterdrücken, könnte man aber auch die Ursache 
beheben.

[Willi (Gast)]

Rolf Magnus schrieb:
> Statt die Warnung zu unterdrücken, könnte man aber auch die Ursache
> beheben.

Wie, den Rechner ausschalten?

Beispiel:
volatile int a,b;
...
  a = a+b; //gibt Warnung
...
Wenn MISRAtener Code geprüft werden soll, nun ja, sonst nervt es.

GCC meckert nicht, oder?

[Karl H. (kbuchegg)]

Willi schrieb:
> Rolf Magnus schrieb:
>> Statt die Warnung zu unterdrücken, könnte man aber auch die Ursache
>> beheben.
>
> Wie, den Rechner ausschalten?

In diesem Fall gibt es aber eine einfache Möglichkeit, wie man das 
umschreiben kann.

>
> Beispiel:
> volatile int a,b;
> ...
>   a = a+b; //gibt Warnung

Das ist aber eine andere Situation. Und auch die kann man so 
umschreiben, dass man dem Compiler, der freundlicherweise sagt 
"Möglicherweise implementiere ich da jetzt etwas anderes als du 
erwartest, check das bitte noch mal" keine Chance für Missverständnisse 
gibt. Die meisten Warnungen sind dergestalt, dass es keine gute Idee 
ist, sie zu ignorieren.

[Willi (Gast)]

Karl Heinz Buchegger schrieb:
> Die meisten Warnungen sind dergestalt, dass es keine gute Idee
> ist, sie zu ignorieren.

Das sehe ich im Grunde auch so, aber beispielsweise war bei einem 
AVR-GCC Quellcode (scheinbar) alles in Ordnung und erst IAR gab 
Warnungen aus. IAR ist da ein bißchen strikter, wobei wohl schon 
MISRA-Regeln angewendet werden. Und wie beseitigt man Warnungen? Man 
schaltet sie ab :-)

Die Warnung kann man dadurch umgehen, dass man eine nicht volatile - 
Hilfsvariable einfügt, was aber bei einem Ausdruck "a += b;" recht 
lästig ist. Oben müßte man wohl ASSR in 'temp' kopieren und dann testen, 
oder besser formuliert: da muß man es so machen.