[AVR] _delay_ms() funktioniert nicht mehr (vom Compiler ignoriert?)

[Benedikt W. (whiteshampoo)]

Hallo liebe µC-Gemeinde,

ich habe ein kleines Problem mit der _delay_ms() Funktion. Ich hab das 
Problem schon etwas nachverfolgt, stehe aber mittlerweile nurnoch mit 
einem großen Fragezeichen über dem Kopf da. Wenn ich nach dem Fehler 
suche finde ich leider nur antworten in denen die Funktion falsch 
verwendet wird oder F_CPU nicht definiert ist.

Mein Problem ist, das mein Compiler scheinbar die _delay_ms() funktion 
nicht richtig behandelt. So kommt exakt die gleiche elf und somit auch 
die gleiche (i)hex datei heraus, egal ob ich z.B. _delay_ms(500) oder 
_delay_ms(1000) schreibe.

Aber erstmal ein paar infos zur Umgebung:

OS: Linux Mint (Auf Arch Linux und/oder anderen PCs ist das gleiche 
Problem)
IDE: Codeblocks 13.12-3
Compiler: avr-gcc 1:4.8-2.1
libc: avr-libc 1:1.8.0-4.1
binutils: binutils-avr 2.23.1-2.1
avr: attiny2313 (ist aber egal welcher)

Ich hab ein Programm mal auf das nötigste heruntergebrochen damit der 
Fehler schneller sehbar ist:

#define F_CPU 4000000UL

#include <avr/io.h>
#include <util/delay.h>

int main(void)
{
    while(1)
    {
    asm("nop");
    asm("nop");
    asm("nop");
    _delay_ms(1000);
    asm("nop");
    asm("nop");
    asm("nop");
    }

    return 0;
}

Dieses Programm hab ich mit verschiedenen Werten in _delay_ms(x) 
compiliert. 500, 1000, 10000. Alle Werte ergeben folgendes, wenn ich mit 
avr-objdump -d die elf-datei ansehe die compiliert wird.
Die jeweils 3x NOP sollen nur bewirken das man die stelle einfach im 
objdump findet.

delay_ms_test.elf:     Dateiformat elf32-avr


Disassembly of section .text:

00000000 <__vectors>:
   0:  12 c0         rjmp  .+36       ; 0x26 <__ctors_end>
   2:  17 c0         rjmp  .+46       ; 0x32 <__bad_interrupt>
   4:  16 c0         rjmp  .+44       ; 0x32 <__bad_interrupt>
   6:  15 c0         rjmp  .+42       ; 0x32 <__bad_interrupt>
   8:  14 c0         rjmp  .+40       ; 0x32 <__bad_interrupt>
   a:  13 c0         rjmp  .+38       ; 0x32 <__bad_interrupt>
   c:  12 c0         rjmp  .+36       ; 0x32 <__bad_interrupt>
   e:  11 c0         rjmp  .+34       ; 0x32 <__bad_interrupt>
  10:  10 c0         rjmp  .+32       ; 0x32 <__bad_interrupt>
  12:  0f c0         rjmp  .+30       ; 0x32 <__bad_interrupt>
  14:  0e c0         rjmp  .+28       ; 0x32 <__bad_interrupt>
  16:  0d c0         rjmp  .+26       ; 0x32 <__bad_interrupt>
  18:  0c c0         rjmp  .+24       ; 0x32 <__bad_interrupt>
  1a:  0b c0         rjmp  .+22       ; 0x32 <__bad_interrupt>
  1c:  0a c0         rjmp  .+20       ; 0x32 <__bad_interrupt>
  1e:  09 c0         rjmp  .+18       ; 0x32 <__bad_interrupt>
  20:  08 c0         rjmp  .+16       ; 0x32 <__bad_interrupt>
  22:  07 c0         rjmp  .+14       ; 0x32 <__bad_interrupt>
  24:  06 c0         rjmp  .+12       ; 0x32 <__bad_interrupt>

00000026 <__ctors_end>:
  26:  11 24         eor  r1, r1
  28:  1f be         out  0x3f, r1  ; 63
  2a:  cf ed         ldi  r28, 0xDF  ; 223
  2c:  cd bf         out  0x3d, r28  ; 61
  2e:  02 d0         rcall  .+4        ; 0x34 <main>
  30:  0d c0         rjmp  .+26       ; 0x4c <_exit>

00000032 <__bad_interrupt>:
  32:  e6 cf         rjmp  .-52       ; 0x0 <__vectors>

00000034 <main>:
  34:  00 00         nop
  36:  00 00         nop
  38:  00 00         nop
  3a:  8f ef         ldi  r24, 0xFF  ; 255
  3c:  9f e3         ldi  r25, 0x3F  ; 63
  3e:  01 97         sbiw  r24, 0x01  ; 1
  40:  f1 f7         brne  .-4        ; 0x3e <__SP_L__+0x1>
  42:  00 c0         rjmp  .+0        ; 0x44 <__SREG__+0x5>
  44:  00 00         nop
  46:  00 00         nop
  48:  00 00         nop
  4a:  f4 cf         rjmp  .-24       ; 0x34 <main>

0000004c <_exit>:
  4c:  f8 94         cli

0000004e <__stop_program>:
  4e:  ff cf         rjmp  .-2        ; 0x4e <__stop_program>

Um zu verhindern das ich irgendwas übersehe habe ich auch schon 
avr-objdump mit -d -x ausgeführt und für die jeweils verschiedenen Werte 
in _delay_ms in dateien geschrieben und mit diff verglichen. KEIN 
Unterschied. Und um zu verhindern das ich die falsche Datei untersuche 
habe ich versucht andere kleine Variablenmanipulationen ins Programm zu 
bringen. Hierbei entstehen durchaus änderungen in der elf-Datei.

Ich will _delay_ms eigentlich gar nicht verwenden, aber um schnell etwas 
zu testen ist es eben nützlich. Nur wenn einem so ein kleines Problem 
einen ganzen Abend aufhält ist das schon lästig.
Letzendlich ist es egal was ich eingebe, das delay ändert sich nicht, 
und so kann natürlich niemand arbeiten.
Was mich besonders stutzig macht ist das _delay_ms() vor wenigen 
Wochen/Monaten von mir ohne Probleme benutzt werden konnte. Also zu doof 
scheine ich auch nicht zu sein.

Ich hoffe das irgendjemand eine Lösung hat.

Danke für Eure Zeit und Lösungen!

[STK500-Besitzer (Gast)]

Benedikt W. schrieb:
> der _delay_ms() Funktion

Es ist ein Makro - keine Funktion.
Und es wird durch die Compiler-Optimierungseinstellung gerne 
wegoptimiert.

[Benedikt W. (whiteshampoo)]

Wenn ich dem Compiler sage "Bitte nicht optimieren" jammert _delay_ms 
aber herum das es nicht richtig funktionieren wird. :(

[Bitflüsterer (Gast)]

Benedikt W. schrieb:
> Wenn ich dem Compiler sage "Bitte nicht optimieren" jammert _delay_ms
> aber herum das es nicht richtig funktionieren wird. :(

Von STK500-Besitzer abgesehen, sagt ja niemand, das Du die Optimierung 
ausschalten sollst.

Das ist doch mal ein "RTFM" wert. 
http://www.groupes.polymtl.ca/inf1995/logiciel/progAvr/avr-libc-user-manual-1.8.0.pdf 
;-)

[Karl H. (kbuchegg)]

STK500-Besitzer schrieb:
> Benedikt W. schrieb:
>> der _delay_ms() Funktion
>
> Es ist ein Makro - keine Funktion.
> Und es wird durch die Compiler-Optimierungseinstellung gerne
> wegoptimiert.

Hatte ich zuerst auchgedacht, dass es wegoptimiert wurde.
Ist hier aber nicht der Fall, wie der Assembler Output zeigt.

[Bitflüsterer (Gast)]

Du hast vergessen, nachträglich zu editieren, Karl Heinz. Ich weiss zwar 
nicht, was Du noch ändern solltest, aber Du solltest es. :-)

[Jim M. (turboj)]

Versuche mal einen Wert kleiner als 60. Da war was mit Integer Überlauf 
in dem _delay_ms Makro.

[Karl H. (kbuchegg)]

Bitflüsterer schrieb:
> Du hast vergessen, nachträglich zu editieren, Karl Heinz. Ich weiss zwar
> nicht, was Du noch ändern solltest, aber Du solltest es. :-)

Hmm. Zwischen 'auch' und 'gedacht' fehlt ein Leerzeichen.
Könnte ich jetzt noch reineditieren, bin aber im Moment zu faul dazu :-)

[Karl H. (kbuchegg)]

Jim Meba schrieb:
> Versuche mal einen Wert kleiner als 60. Da war was mit Integer Überlauf
> in dem _delay_ms Makro.

Da müsste er schon eine sehr alte Version haben.
Seit einigen Jahren ist das kein Problem mehr.

[Karl H. (kbuchegg)]

Karl Heinz schrieb:
> Jim Meba schrieb:
>> Versuche mal einen Wert kleiner als 60. Da war was mit Integer Überlauf
>> in dem _delay_ms Makro.
>
> Da müsste er schon eine sehr alte Version haben.
> Seit einigen Jahren ist das kein Problem mehr.


Aber irgendwas stimmt da nicht
Denn das

  3a:  8f ef         ldi  r24, 0xFF  ; 255
  3c:  9f e3         ldi  r25, 0x3F  ; 63
  3e:  01 97         sbiw  r24, 0x01  ; 1
  40:  f1 f7         brne  .-4        ; 0x3e <__SP_L__+0x1>

ergibt bei aller Liebe niemals 1 Sekunde Laufzeit. Da brauch ich gar 
nicht nachrechnen, das geht sich nie aus.

[Marc V. (Firma: Vescomp) (logarithmus)]

Benedikt W. schrieb:
> Ich hoffe das irgendjemand eine Lösung hat.

 So sieht es bei mir aus:

00000034 <main>:
    milliseconds can be achieved.
 */
void
_delay_loop_2(uint16_t __count)
{
  __asm__ volatile (
  34:  24 e6         ldi  r18, 0x64  ; 100
  36:  30 e0         ldi  r19, 0x00  ; 0

int main(void)
{
    while(1)
    {
    asm("nop");
  38:  00 00         nop
    asm("nop");
  3a:  00 00         nop
    asm("nop");
  3c:  00 00         nop
  3e:  80 e1         ldi  r24, 0x10  ; 16
  40:  97 e2         ldi  r25, 0x27  ; 39
  42:  f9 01         movw  r30, r18
  44:  31 97         sbiw  r30, 0x01  ; 1
  46:  f1 f7         brne  .-4        ; 0x44 <__SREG__+0x5>
    __ticks = (uint16_t) (__ms * 10.0);
    while(__ticks)
    {
      // wait 1/10 ms
      _delay_loop_2(((F_CPU) / 4e3) / 10);
      __ticks --;
  48:  01 97         sbiw  r24, 0x01  ; 1
    __ticks = 1;
  else if (__tmp > 65535)
  {
    //  __ticks = requested delay in 1/10 ms
    __ticks = (uint16_t) (__ms * 10.0);
    while(__ticks)
  4a:  d9 f7         brne  .-10       ; 0x42 <__SREG__+0x3>
    _delay_ms(1000);
    asm("nop");
  4c:  00 00         nop
    asm("nop");
  4e:  00 00         nop
    asm("nop");
  50:  00 00         nop
  52:  f2 cf         rjmp  .-28       ; 0x38 <main+0x4>

00000054 <_exit>:
  54:  f8 94         cli

00000056 <__stop_program>:
  56:  ff cf         rjmp  .-2        ; 0x56 <__stop_program>

 Bei dir ist _delay irgendwie verschwunden, auch ist Wert fur _delay
 nicht as volatile deklariert, aber so schlau kann doch eigentlich kein
 Compiler sein - oder doch ?
 Versuchs mal mit irgendeiner Variable dahinter.

[Marco S (Gast)]

Bei mir kommt mit

avr-gcc (GCC) 4.8.2-2

avr-binutils 2.24-1

avr-libc 1.8.0-5

avr-gcc -Os -g3 -o main.elf -mmcu=attiny2313 main.c

unter ArchLinux folgendes heraus:

  while(1)
    {
    asm("nop");
  46:   00 00           nop
    asm("nop");
  48:   00 00           nop
    asm("nop");
  4a:   00 00           nop
        #else
                //round up by default
                __ticks_dc = (uint32_t)(ceil(fabs(__tmp)));
        #endif

        __builtin_avr_delay_cycles(__ticks_dc);
  4c:   2f ef           ldi     r18, 0xFF       ; 255
  4e:   84 e3           ldi     r24, 0x34       ; 52
  50:   9c e0           ldi     r25, 0x0C       ; 12
  52:   21 50           subi    r18, 0x01       ; 1
  54:   80 40           sbci    r24, 0x00       ; 0
  56:   90 40           sbci    r25, 0x00       ; 0
  58:   e1 f7           brne    .-8             ; 0x52 <main+0xc>
  5a:   00 c0           rjmp    .+0             ; 0x5c <main+0x16>
  5c:   00 00           nop
    _delay_ms(1000);
    asm("nop");
  5e:   00 00           nop
    asm("nop");
  60:   00 00           nop
    asm("nop");
  62:   00 00           nop

Das liegt mit dem 24bit-Zähler schon eher in der Nähe von 1Sek.

[Marc V. (Firma: Vescomp) (logarithmus)]

Marc Vesely schrieb:
> So sieht es bei mir aus:

 Ist zwar OT, aber trotzdem eine Frage an den Moderator:
 Du hast mein Beitrag moderiert, ich meine das mit Unterstrich und so,
 machst du das zu Fuss oder kann man autoedit irgendwie abstellen ?

[Karl H. (kbuchegg)]

Marc Vesely schrieb:
> Marc Vesely schrieb:
>> So sieht es bei mir aus:
>
>  Ist zwar OT, aber trotzdem eine Frage an den Moderator:
>  Du hast mein Beitrag moderiert, ich meine das mit Unterstrich und so,
>  machst du das zu Fuss oder kann man autoedit irgendwie abstellen ?

Wenn du dir angewöhnen würdest, bei Code gleich die Formatierzeichen 
einzufügen ....


Für C-Code am Beginn des Codes [ C ], am Ende des Codes [ /C ] (jeweils 
ohne die Leerzeichen.
Für Assembler Code am Beginn des Codes [ avrasm ], am Ende des Codes [ 
/avrasm ] (wieder ohne die Leerzeichen

... dann bräuchte ich deinen Post nicht editieren.
Mahr als diese Formatierzeichen ergänzen hab ich in deinem Posting nicht 
gemacht.

[Marc V. (Firma: Vescomp) (logarithmus)]

Marc Vesely schrieb:
> nicht as volatile deklariert, aber so schlau kann doch eigentlich kein
>  Compiler sein - oder doch ?
>  Versuchs mal mit irgendeiner Variable dahinter.

 Vor etwa 10 Jahren zeigte mir jemand ein Schnipsel aus den 60-er
 in FORTRAN. War fur IBMetwas geschrieben. Und zwar wollten die wissen
 wie schnell der IBM eigentlich rechnen kann.
 Also, Variable XYZ durch PI, in eine Schleife, 1000 Durchläufe, Zeit
 gemessen - nicht messbar.
 5000, 100000, 10000000, 1E12 - dasselbe.
 Na, so schnell kann der IBM doch gar nicht sein, dachten die
 Schlaumeier. Bis irgendeiner dahinter kam, dass die Variable ja
 nirgendwo ausgegeben oder benutzt wurde, also hat der compiler das
 Ganze einfach wegoptimiert...

[Marc V. (Firma: Vescomp) (logarithmus)]

Karl Heinz schrieb:
> ... dann bräuchte ich deinen Post nicht editieren.
> Mahr als diese Formatierzeichen ergänzen hab ich in deinem Posting nicht
> gemacht.

 Hab mich auch nicht beschwert, nur gefragt. Sorry.
 Wichtige Regeln - erst lesen, dann posten.
 Hurra, ich kann das !!!