avr-gcc Bug, oder weshalb Behandlung als signed?

[ein Gast (Gast)]

Ich habe eine Schleife geschrieben, welche, falls die normale 
Ausführungsbedingung innerhalb einer bestimmten Zeit nicht false wird, 
durch ein Timeout beendet werden soll. Diese ist folgendermaßen 
realisiert:

...
uint16_t timeout = 0;
...  
while ((!(TWCR & (1<<TWINT)))&&(timeout<65000U)){timeout++;}      
...

Beim Debugging in Assembler sieht dies folgenermaßen aus:

00000296  ADIW R24,0x01    Add immediate to word 
00000297  LDD R18,Z+0    Load indirect with displacement 
--- C:\Users\User\Desktop\Firmware\Debug/.././i2c_functions.c 
00000298  TST R18    Test for Zero or Minus 
00000299  BRLT PC+0x06    Branch if less than, signed 
--- Keine Quelldatei -----------------------------------------------------------
0000029A  CPI R24,0xE8    Compare with immediate 
0000029B  LDI R18,0xFD    Load immediate 
0000029C  CPC R25,R18    Compare with carry 
0000029D  BRNE PC-0x07    Branch if not equal 
0000029E  RJMP PC+0x0004    Relative jump

Die Schleife wird offenbar nicht beendet, wenn timeout>=65000 ist.
So ich den Assembler Code richtig interpretiere zeigt sich mir als Grund 
hierfür, dass die Überprüfung ob timeout<65000 ist als signed 
durchgeführt wird, obwohl beide Werte 16-Bit unsigned sein sollten. Da 
der Wertebereicht bei 16-Bit signed Zahlen nur bis 32767 reicht, 
erscheint es mir plausiebel dass timeout immer kleiner als 65000 ist.

Relativiert sich dies wieder da eventuell beide Zahlen als signed 
behandelt werden?
Ich habe wenig Erfahrung mit Assembler, jedoch iritiert mich diese 
Codestelle in Verbindung mit dem Verhalten beim Debugging.
Vielleicht könnte jemand mit etwas mehr Erfahrung in Assembler eine 
Einschätzung geben ob dies eine korrekte Optimierung des Compilers ist 
oder ob hier wirklich etwas faul ist oder Fehler meinerseits auffallen.

Ich verende Atmel Studio 6.1.

[Jörg W. (dl8dtl) (Moderator)]

ein Gast schrieb:
> So ich den Assembler Code richtig interpretiere

Ich denke nicht, dass du ihn richtig interpretierst.

Gib aber bitte mal ein vollständiges, compilierbares Beispiel.

[Oliver (Gast)]

ein Gast schrieb:
> 0000029A  CPI R24,0xE8    Compare with immediate
> 0000029B  LDI R18,0xFD    Load immediate
> 0000029C  CPC R25,R18    Compare with carry
> 0000029D  BRNE PC-0x07    Branch if not equal
> 0000029E  RJMP PC+0x0004    Relative jump
> [/avrasm]
>
> Die Schleife wird offenbar nicht beendet,

offenbar doch.
doc0856.pdf RTFM...


Oliver

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

ein Gast schrieb:
> So ich den Assembler Code richtig interpretiere zeigt sich mir als Grund
> hierfür, dass die Überprüfung ob timeout<65000 ist als signed
> durchgeführt wird,

Nein. Der BRLT Befehl testet TWINT von TWCR. Ist nämlich Bit 7.

timeout wird dahinter mit BRNE getestet, weil der Compiler merkt, dass 
dieser Test hier äquivalent zu U< ist.

[ein Gast (Gast)]

>Gib aber bitte mal ein vollständiges, compilierbares Beispiel.
Ich habe zusammenkopiert, was ich für relevant halte.
Der Timeout in in den weiteren I²C-Funktionen identisch realisiert.

#include <avr/io.h>
#define I2C_PORT  PORTC
#define SDA      PC1
#define SCL      PC0

char i2c_init(void)
{
  I2C_PORT |= (1<<SDA)|(1<<SCL);          //use internal pullup resistors instead of external ones. In external ones are present this line has to be removed / commented out.
  TWBR  = 100;                  //set SCL speed to F_CPU/(16+2*TWBR)
  TWSR  = TWSR & 252;                //make sure prescaler bits are cleared to keep the additional prescaler out of the equation above.
  return 0;
}

char i2c_start(void)
{
  uint16_t timeout = 0;
  TWCR = (1<<TWINT)|(1<<TWSTA)|(1<<TWEN);    //generate START condition (TWINT ~ do command, TWSTA ~ command for Startcondition, TWEN ~ enable I2C unit)
  while ((!(TWCR & (1<<TWINT)))&&(timeout<65000U)){timeout++;}    //wait as long as I2C unit is busy   
  if(timeout >= 65000U)
  {
    TWCR |=(1<<TWSTO) | (1<<TWINT);
    TWCR =(1<<TWEA) | (1<<TWINT) | (1<<TWEN); 
  }
  if (!(TWSR & 0x18)) return 1;        //check if start condition actually occurred, otherwise return 1          
  return 0;                  //if everything is allright return 0
}

int main(void)
{
    i2c_init();
  while(1)
    {
        i2c_start();
    }
}

[Jörg W. (dl8dtl) (Moderator)]

ein Gast schrieb:
> Der Timeout in in den weiteren I²C-Funktionen identisch realisiert.

Der funktioniert aber auch, wie dir andere schon erklärt haben.

Hier mal der generierte Assemblercode, den ich für -mmcu=atmega16
bekomme.  Ich habe mal ein paar Kommentare eingefügt.

i2c_start:
/* prologue: function */
/* frame size = 0 */
/* stack size = 0 */
.L__stack_usage = 0
        ldi r24,lo8(-92)
        out 0x36,r24     ; TWCR = ...
        ldi r24,0        ; timeout = 0 // timeout liegt in r[25:24]
        ldi r25,0
        rjmp .L3
.L5:
        adiw r24,1       ; timeout++
.L3:
        in __tmp_reg__,0x36  ; Test von TWINT in TWCR
        sbrc __tmp_reg__,7   ; sieht hier etwas anders aus als bei
                             ; deiner Version, funktioniert aber genauso
        rjmp .L4             ; wenn TWINT nicht (mehr) gesetzt, dann
                             ; springe nach .L4
        cpi r24,-24          ; -3 => 0xFD, -24 => 0xE8; 0xFDE8 = 65000
        ldi r18,-3
        cpc r25,r18
        brne .L5             ; solange timeout ungleich 65000, zurück nach .L5
        rjmp .L6             ; wenn timeout erreicht, nach .L6 (Fehlerbehandlung)
.L4:
        cpi r24,-24          ; nochmal Test auf 65000
        sbci r25,-3
        brne .L7
.L6:
        in r24,0x36
        ori r24,lo8(-112)
        out 0x36,r24
        ldi r24,lo8(-60)
        out 0x36,r24
.L7:
        in r25,0x1
        andi r25,lo8(24)
        ldi r24,lo8(1)
        breq .L8
        ldi r24,0
.L8:
        ret

[ein Gast (Gast)]

Danke, ich kann es jetzt nachvollziehen.
Es hatte vermutlich das Dragon nur wieder Probleme beim Debugging.