Kein Sprung in if-Anweisung (Compiler übersetzt falsch?)

[Philipp (Gast)]

Hallo zusammen,

ich bin gerade dabei, ein Programm zum Dekodieren des S-Bus Protokolls 
zu schreiben. Dieses soll auf einem Atmega 328P laufen.

Zum Debuggen verwende ich das debug-Wire Interface mit dem Atmel ICE.

Das korrekte Aufzeichnen des S-Bus Datenstroms über den UART des Atmega 
funktioniert bereits wunderbar.

Nun stehe ich aber vor folgedem Problem:
Nach dem korrekten Empfang eines Datenframes wird in der Empfangsroutine 
ein Flag ( SBUS_Flags.New_Frame_received ) gesetzt.
In der Hauptroutine wird dieses Flag in einer IF-Schleife gepollt, wenn 
es gesetzt ist, d.h. wenn ein neues Frame empfangen wurde, soll eine 
Funktion zur Umrechnung des Datenframes in Kanalwerte aufgerufen werden.

while(1)
    {
    if(SBUS_Flags.New_Frame_received==1){
        SBUS_Frame_to_Channels();
        send_Channels_over_UART();
        SBUS_Flags.New_Frame_received=0;
     }
}

Seltsamerweise springt das Programm aber auch bei gesetztem Flag nicht 
in die IF Anweisung. Dieses Verhalten kann ich sowohl beim Simulieren im 
AVR-Simulator als auch über debug-Wire beobachten.

Noch seltsamer ist, dass im zugehörigen Assembler-Code das Register R24 
mit TST auf 0 überprüft wird. Das Register R24 IST TATSÄCHLICH 0. 
Theoretisch soll dann der nächste Befehl übersprungen werden. Das 
geschicht jedoch nicht??

      if(SBUS_Flags.New_Frame_received==1){
00000207  LDS R24,0x0130    Load direct from data space 
00000209  ANDI R24,0x40    Logical AND with immediate 
0000020A  TST R24    Test for Zero or Minus 
0000020B  BREQ PC-0x01    Branch if equal

Bin echt ziemlich ratlos. Würde mich sehr freuen, wenn jemand sich die 
besagte Stelle kurz mal anschauen könnte (S-Bus_Serial_Converter.c , if 
Schleife ganz am Ende).

Vielen Dank schonmal für eure Hilfe,

Gruß Philipp

[Peter II (Gast)]

es fehlt das volatile bei den Variablen.

[Philipp (Gast)]

Hier nochmal die richtige S_Bus_Serial_Converter.c Datei angehäng.
Bitte die andere nicht beachten, dort hatte ich zum test das Flag vor 
der IF Schleife nochmal mit einem Befehl gesetzt. Falls es wichtig ist: 
Damit funktioniert die IF Schleife korrekt.

[Falk B. (falk)]

Es gibt keine If-Schleife!

[Falk B. (falk)]

https://www.mikrocontroller.net/articles/Interrupt#Volatile_Variablen

[Kaj (Gast)]

Philipp schrieb:
> Compiler übersetzt falsch?
Mit Sicherheit nicht.

Philipp schrieb:
> IF-Schleife
Es gibt keine if-Schleife!

Lies dir in deinem C-Buch mal die Kapitel zu
Interrupts, gloable Variablen, volatile, extern usw. durch...

[Mark B. (markbrandis)]

Das hier:

  struct abc {
    unsigned Endbyte_received:1;
    unsigned SBUS_synced:1;
    unsigned SBUS_Channel_17:1;
    unsigned SBUS_Channel_16:1;
    unsigned Frame_valid:1;
    unsigned Failsave_activated:1;
    unsigned New_Frame_received:1;
  } SBUS_Flags;

sieht komisch aus (warum sollte eine Datentyp "abc" heißen?).
Da sollte wohl ein typedef struct hin.

[Philipp (Gast)]

Genau,das volatile hat gefehlt. Jetzt funktioniert alles.

Vielen Dank für die großartige Hilfe!

@ Mark Brandis: Das abc kam noch vom Debuggen eines anderen Problems. 
Ich bekam erst noch Fehlermeldungen, als ich mit beiden c-Dateien auf 
das Struct zugreifen wollte. Habe es aber dann mit der Forensuche 
hinbekommen (das Struct brauchte nur einmal im Headerfile definiert 
werden und "extern" davorzusetzen war auch falsch)

[Johann L. (gjlayde)]

Kaj schrieb:
> Philipp schrieb:
>> Compiler übersetzt falsch?
> Mit Sicherheit nicht.

Mit Sicherheit hat avr-gcc 6.x ein Problem, das sich ähnlich auswirken 
kann :-/

[Kaj (Gast)]

Johann L. schrieb:
> Mit Sicherheit hat avr-gcc 6.x ein Problem, das sich ähnlich auswirken
> kann :-/
Okay, dann lass mich das anders Formulieren:
Mit an Sicherheit grenzender Wahrscheinlichkeit nicht. In 99,9% der 
Fälle ist es ein Layer 8 Problem :-)

Ich spekuliere aber mal das der TO Atmel Studio nutzt, und wenn er 
nichts an der Toolchain gemacht hat, ist da der 4.9.x bei (wenn es Atmel 
Studio 7 ist).

Magst du mehr zu dem Bug sagen, oder einen Link zu einem Bugreport 
posten?

[Johann L. (gjlayde)]

Kaj schrieb:
> Johann L. schrieb:
>> Mit Sicherheit hat avr-gcc 6.x ein Problem, das sich ähnlich auswirken
>> kann :-/
> Okay, dann lass mich das anders Formulieren:
> Mit an Sicherheit grenzender Wahrscheinlichkeit nicht.

Ja, meistens ist es ein vergessenes "volatile".  Fehler in 
volatile-Correctness ist z.B. PR71053.

[Kaj (Gast)]

Johann L. schrieb:
> Fehler in volatile-Correctness ist z.B. PR71053.
Danke.

Vielleicht interessierts ja nochmal Wen:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71053