_delay_ms Faktor 13 zu langsam

[mc (Gast)]

Hallo,

bin gerade auf einen seltsamen Effekt mit _delay_ms aus der avr/delay.h 
gestossen.

Folgendes Setup:

Atmega8 mit externem 16MHz Crystal. lfuse:w:0x9f:m hfuse:w:0xd9:m.
F_CPU per Makefile auf 16000000 gesetzt.
Es laufen mehrere ISRs und auch usart wird per

#define BAUD 38400
#define UBRR F_CPU/16/BAUD-1

gesetzt und funktioniert.
Daher wuerde ich davon ausgehen, dass die Settings alle korrekt sind.
Wenn ich testweise auf den langsameren internen Oszillator wechsle, geht 
z.B. usart erwartungsgemaess nicht mehr.

So, nun die _delay_ms()-Funktion: laeuft relativ genau Faktor 13 
langsamer als sie soll, also ein Testsignal mit _delay_ms(38) 
ontime+offtime laeuft ca. mit 1Hz.
Finden konnte ich nichts dazu, hat jemand sowas schonmal gesehen?

[Frank M. (ukw) (Moderator)]

_delay_ms funktioniert nur korrekt mit eingeschaltetem Optimizer. Stell 
Dein Projekt auf Release um oder schalte die Optmierung ein, also zum 
Beispiel -Os.

[c-hater (Gast)]

mc schrieb:

> Finden konnte ich nichts dazu, hat jemand sowas schonmal gesehen?

Optimierung ist aus.

[mc (Gast)]

Ah richtig, das hatte ich vergessen zu erwähnen: -Os wird verwendet.

[c-hater (Gast)]

mc schrieb:

> Ah richtig, das hatte ich vergessen zu erwähnen: -Os wird verwendet.

Das ist die falsche Optimierung.

[mc (Gast)]

Und was wäre dann korrekt? -O1 ist identisch.

Hat sich da was mit einem avr-gcc update geändert?
avr-gcc ist bei mir 5.4.0 aus debian testing.
Wenn ich mich recht erinnere, ist das Verhalten recht neu, fast 
identische init code templates + gleiches Makefile habe ich schon Jahre 
verwendet, das hat bisher immer wie gewollt funktioniert.

[Ferger (Gast)]

c-hater schrieb:
> mc schrieb:
>
>> Ah richtig, das hatte ich vergessen zu erwähnen: -Os wird verwendet.
>
> Das ist die falsche Optimierung.

Das ist Quatsch, wie üblich bei dir.

[Kalter Rechner (Gast)]

mc schrieb:
> _delay_ms(38)
> ontime+offtime laeuft ca. mit 1Hz.

Um 1 Hz mit ontime+offtime zu erzeugen müsste man _delay_ms(500)
benutzen .....

[mc (Gast)]

Kalter Rechner schrieb:
> mc schrieb:
>> _delay_ms(38)
>> ontime+offtime laeuft ca. mit 1Hz.
>
> Um 1 Hz mit ontime+offtime zu erzeugen müsste man _delay_ms(500)
> benutzen .....
Ja, stimmt doch? 38x die erwähnte Abweichung um den Faktor 13 ergibt 
knapp 500.

[Oliver S. (oliverso)]

Mach ein Minimalprogram daraus, und zeig das hier.

Oliver

[Kalter Rechner (Gast)]

mc schrieb:
> Es laufen mehrere ISRs

... die evtl. eine Menge Arbeit inline erledigen?

Z.B. Zeichenketten in der ISR über UART ausgeben ist tötlich,
aber wir kennen ja dein Programm nicht ....

[Matthias L. (Gast)]

Die richtige Optimierung ist, kein delay zu verwenden.

[Kalter Rechner (Gast)]

Matthias L. schrieb:
> Die richtige Optimierung ist, kein delay zu verwenden.

Das hilft auch nichts (mehr) wenn eine ISR die andere jagt.

[mc (Gast)]

Oliver S. schrieb:
> Mach ein Minimalprogram daraus, und zeig das hier.
>
> Oliver

Gerne, hab das mal minimalisiert. USART-Kram ist noch drinnen weil auch 
ISR.
Ich habe übrigens definitiv eine Abhängigkeit von compiler+lib bei dem 
Effekt. Bin gerade am schauen, wo das genau herkommt, vielleicht 
irgendwelche falsch gezogenen Artefakte.

#include <stdlib.h>
#include <avr/io.h>
#include <inttypes.h>
#include <avr/interrupt.h>
#include <util/delay.h>
#include <stdio.h>
#include <util/atomic.h>
#include <stdbool.h>

#define BAUD 38400
#define MYUBRR F_CPU/16/BAUD-1

int usart_putchar_printf(char var, FILE *stream);
static FILE mystdout = FDEV_SETUP_STREAM(usart_putchar_printf, NULL, _FDEV_SETUP_WRITE);

void usart_init( uint16_t ubrr)
{
    UBRRH = (uint8_t)(ubrr>>8);
    UBRRL = (uint8_t)ubrr;
    UCSRB = (1<<TXEN);
}
void usart_putchar(char data)
{
    while ( !(UCSRA & (_BV(UDRE))) );
    UDR = data;^M
}

unsigned char usart_kbhit(void)
{
    unsigned char b;
    b=0;^M
    if(UCSRA & (1<<RXC)) b=1;
    return b;
}
void usart_pstr(char *s)
{
    while (*s) {
        usart_putchar(*s);
        s++;
    }
}

int usart_putchar_printf(char var, FILE *stream)
{
    if (var == '\n') usart_putchar('\r');
    usart_putchar(var);
    return 0;
}
void init( void )
{
    DDRB |= (1 << PB0) | (1 << PB1) | (1 << PB2) | (1 << PB3) | (1 << PB4) | (1 << PB5);
    DDRD |= (1 << PD2) | (1 << PD5);
    PORTC |= (1 << PC0) | (1 << PC1) | (1 << PC2) | (1 << PC3) | (1 << PC4) | (1 << PC5);
    PORTD |= (1 << PD6) | (1 << PD7);

    TCCR1A |= (1<<WGM10);
    TCCR1A |= (1<<COM1A1) | (1<<COM1B1);
    TCCR1B |= (1 << CS10);
    TCCR2 |= (0 << CS22) | (0 << CS21) | (1 << CS20);
    TIMSK |= (1 << TOIE2);
    TCCR0 |=  (1 << CS00);
    TIMSK |= 1<<TOIE0;

    sei();
}

ISR( TIMER2_OVF_vect )
{
    TCNT2 = 0; // temp avoid opt
}

ISR( TIMER0_OVF_vect )
{
    TCNT0 = 145;
}

int main(void)
{
    init();

    stdout = &mystdout;
    usart_init( MYUBRR );

    _delay_ms(100);
    printf("\nfoo\n");
    do {
        _delay_ms(50);
        PORTD &= ~(1 << PD2);
        _delay_ms(50);
        PORTD |= (1 << PD2);
    } while (1);
}

Compiled mit:

avr-gcc -c -mmcu=atmega8 -I. -DF_CPU=16000000UL -Os -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -Wall -Wstrict-prototypes -Wundef -Wa,-adhlns=obj/main_test.lst  -std=gnu99 -Wundef -MD -MP -MF .dep/main_test.o.d main_test.c -o obj/main_test.o

[Oliver S. (oliverso)]

Das muß ein Problem in deiner toolchain sein. Bei mir tut es das 
prinzipiell (avr-gcc 10.1, Windows). Es sind zwar keine 50ms, sondern 
ca. 61ms, weil da die ISRs noch dazwischenfunken, aber ansonsten 
fuktioniert das.

Oliver

[mc (Gast)]

Oliver S. schrieb:
> Das muß ein Problem in deiner toolchain sein. Bei mir tut es das
> prinzipiell (avr-gcc 10.1, Windows). Es sind zwar keine 50ms, sondern
> ca. 61ms, weil da die ISRs noch dazwischenfunken, aber ansonsten
> fuktioniert das.
>
> Oliver

Vielen Dank für den Test! Sieht wirklich ganz nach build-umgebung aus, 
auf einer neuen VM bekomme ich es (auch debian) nicht reproduziert. In 
diesem Sinne Verzeihung fuer die eigentlich überflüssige Frage, aber da 
denkt man erstmal nicht dran...

[Einer K. (Gast)]

Oliver S. schrieb:
> Das muß ein Problem in deiner toolchain sein.
Es gibt da noch ein Problem mit der Toolchain.

Wollte das Programm testen und mein 10.2.0 Gcc hats mir um die Ohren 
gehauen.

mc schrieb:

static FILE mystdout = FDEV_SETUP_STREAM(usart_putchar_printf, NULL, _FDEV_SETUP_WRITE);

In stdio.h wird die Struktur im C Stil initialisiert.
Das klappt unter C++ nicht.

Abhilfe:

  #undef FDEV_SETUP_STREAM
  #define FDEV_SETUP_STREAM(p, g, f) { 0, 0, f, 0, 0, p, g, 0 }