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

Gast #4592960
Lesenswert?
• ▲
▼
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.
1
while(1)
2
    {
3
    if(SBUS_Flags.New_Frame_received==1){
4
        SBUS_Frame_to_Channels();
5
        send_Channels_over_UART();
6
        SBUS_Flags.New_Frame_received=0;
7
     }
8
}


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??
1
      if(SBUS_Flags.New_Frame_received==1){
2
00000207  LDS R24,0x0130    Load direct from data space 
3
00000209  ANDI R24,0x40    Logical AND with immediate 
4
0000020A  TST R24    Test for Zero or Minus 
5
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
Angehängte Dateien:
#4592975
Lesenswert?
• ▲
▼
Das hier:
1
  struct abc {
2
    unsigned Endbyte_received:1;
3
    unsigned SBUS_synced:1;
4
    unsigned SBUS_Channel_17:1;
5
    unsigned SBUS_Channel_16:1;
6
    unsigned Frame_valid:1;
7
    unsigned Failsave_activated:1;
8
    unsigned New_Frame_received:1;
9
  } SBUS_Flags;

sieht komisch aus (warum sollte eine Datentyp "abc" heißen?).
Da sollte wohl ein typedef struct hin.
Gast #4592992
Lesenswert?
• ▲
▼
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)
Gast #4593103
Lesenswert?
• ▲
▼
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?

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

oder

Mit Google-Account einloggen

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren