_delay_us() sehr! ungenau?

[Arthur Dent (Gast)]

Hallo,

ich habe hier folgenden kurzen code-ausschnitt.

ich möchte damit einfach ein bussignal auswerten.
wenn ich mir den testpin (hier portd pd0) am oszi anschaue muss ich 
feststellen dass dessen frequenz zunimmt, ich habe testweise auch schon 
mal recvcount=20 initialisiert um das phänomen genauer zu untersuchen, 
auch hier scheint es so dass ich je öfter hintereinander ich _delay_us 
aufrufe, umso kürzer wartet es,.... kann doch nicht sein, oder?

wenn diese empfangsroutine dann nochmal von neuem aufgerufen wird ist 
beim ersten bit wieder alles in ordnung, aber um so mehr es gegen das 
achte bit geht um so kürzer wartet das delay,...

ich bin ratlos, aber vll kann mir jemand von euch weiterhelfen.

lg

RecvCount = 8;
loop_until_bit_is_clear(PIND, PD0);  //Auf Startbit warten
_delay_us(MyDelayValueAndAHalf);
do {
  RecvCount--;
  _delay_us(MyDelayValue);
  PORTD ^= (1<<PD1);       //***TEST
  if( !(PIND & (1<PD0)) ) Recv |= (1<<RecvCount);
  else Recv &= ~(1<<RecvCount);
} while (RecvCount != 0);

[Peter II (Gast)]

Arthur Dent schrieb:
> ich bin ratlos, aber vll kann mir jemand von euch weiterhelfen.

ja, doku lese hilft.

_delay_us();

darf nur mit konstanten und mit optimerung verwendet werden.

[Arthur Dent (Gast)]

Peter II schrieb:
> ja, doku lese hilft.
>
> _delay_us();
>
> darf nur mit konstanten und mit optimerung verwendet werden.

-os hab ich als optimierungsstufe gewählt,

und im code weiter oben (ziehmlich am anfang um genau zu sein ;)) steht 
folgendes:

#define MyDelayValue 8
#define MyDelayValueAndAHalf 14

jaja ich weis, 8*1,5 = nicht 14 ;)
aber diese werte hab ich experimentell ermittelt ;)

[Peter II (Gast)]

Arthur Dent schrieb:
> und im code weiter oben (ziehmlich am anfang um genau zu sein ;)) steht
> folgendes:
> #define MyDelayValue 8
> #define MyDelayValueAndAHalf 14

ok das hätte nich nicht erwartet, weil man define im üblichen GROSS 
schreibt. Dann ist das nicht das Problem.

(kommt aber auch nur weil man nicht alles wichtige sieht)

[Johann L. (gjlayde)]

Arthur Dent schrieb:

> -os hab ich als optimierungsstufe gewählt,

Das ist keine Optimierungsstufe, sondern es setzt die Ausgabedatei auf 
s. Siehe Dokumentation zu -o

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

Compilierfähiger Code wäre schon manchmal schön ...  Angabe des
genauen Controllers und der benutzten Taktfrequenz ebenfalls.

OK, ich habe deinen Code mal wie folgt ergänzt:

#include <avr/io.h>

#define F_CPU 8E6
#include <util/delay.h>

#define MyDelayValue 8
#define MyDelayValueAndAHalf 14

uint8_t Rx(void)
{
    uint8_t Recv, RecvCount;

    RecvCount = 8;
    loop_until_bit_is_clear(PIND, PD0);  //Auf Startbit warten
    _delay_us(MyDelayValueAndAHalf);
    do {
        RecvCount--;
        _delay_us(MyDelayValue);
        PORTD ^= (1<<PD1);       //***TEST
        if( !(PIND & (1<PD0)) ) Recv |= (1<<RecvCount);
        else Recv &= ~(1<<RecvCount);
    } while (RecvCount != 0);

    return Recv;
}

(Ja, ich weiß, hab' vergessen, Recv zu initialisieren.  Spielt aber
fürs Prinzip jetzt keine Geige.)

Wenn ich das jetzt für einen ATmega8 compiliere (GCC 4.5.1), bekomme
ich:

.global Rx
        .type   Rx, @function
Rx:
/* prologue: function */
/* frame size = 0 */
/* stack size = 0 */
.L__stack_usage = 0
.L2:
        sbic 48-32,0
        rjmp .L2
         ldi r20,lo8(37)
    1:dec r20
    brne 1b
        nop
        ldi r25,lo8(8)
        ldi r22,lo8(2)
        ldi r18,lo8(1)
        ldi r19,hi8(1)
.L3:
        subi r25,lo8(-(-1))
         ldi r20,lo8(21)
    1:dec r20
    brne 1b
        nop
        in r20,50-32
        eor r20,r22
        out 50-32,r20
        in r20,48-32
        movw r20,r18
        mov r0,r25
        rjmp 2f
1:      lsl r20
        rol r21
2:      dec r0
        brpl 1b
        or r24,r20
        tst r25
        brne .L3
/* epilogue start */
        ret

Wie du sehen kanst, sind deine Ausdrücke der Form (1 << RecvCount)
die Übeltäter.  Da der AVR keinen Schiebebefehl für mehrere Bits
hat, muss die variable Verschiebung durch eine Schleife von LSL/ROL
implementiert werden.  Je nachdem, wie groß dein RecvCount gerade
ist, nimmt diese Schleife eine unterschiedliche Zeit in Anspruch.

Das gesamte Timing des restlichen "Overheads" geht halt im Vergleich
zu deinen _delay_us() bereits heftig mit ein (mit 1 MHz CPU-Takt
könnte man die Sache bereits komplett in die Tonne drücken).

Wenn du mit -O3 compilieren lässt, entrollt der Compiler die
Schleife, und du bist die Abhängigkeit vom Durchlaufzähler los:

.global Rx
        .type   Rx, @function
Rx:
/* prologue: function */
/* frame size = 0 */
/* stack size = 0 */
.L__stack_usage = 0
.L2:
        sbic 48-32,0
        rjmp .L2
         ldi r24,lo8(37)
    1:dec r24
    brne 1b
        nop
         ldi r25,lo8(21)
    1:dec r25
    brne 1b
        nop
        in r25,50-32
        ldi r24,lo8(2)
        eor r25,r24
        out 50-32,r25
        in r25,48-32
         ldi r25,lo8(21)
    1:dec r25
    brne 1b
        nop
        in r25,50-32
        eor r25,r24
        out 50-32,r25
        in r25,48-32
         ldi r25,lo8(21)
    1:dec r25
    brne 1b
        nop
        in r25,50-32
        eor r25,r24
        out 50-32,r25
        in r25,48-32
         ldi r25,lo8(21)
    1:dec r25
    brne 1b
        nop
        in r25,50-32
        eor r25,r24
        out 50-32,r25
        in r25,48-32
         ldi r25,lo8(21)
    1:dec r25
    brne 1b
        nop
        in r25,50-32
        eor r25,r24
        out 50-32,r25
        in r25,48-32
         ldi r25,lo8(21)
    1:dec r25
    brne 1b
        nop
        in r25,50-32
        eor r25,r24
        out 50-32,r25
        in r25,48-32
         ldi r25,lo8(21)
    1:dec r25
    brne 1b
        nop
        in r25,50-32
        eor r25,r24
        out 50-32,r25
        in r25,48-32
         ldi r25,lo8(21)
    1:dec r25
    brne 1b
        nop
        in r25,50-32
        eor r25,r24
        out 50-32,r25
        in r24,48-32
        ldi r24,lo8(-1)
/* epilogue start */
        ret

Du kannst aber auch deinen Quellcode ein wenig umschreiben und
die Bitmaske als Variable mitführen, um dem Compiler zu helfen:

#include <avr/io.h>

#define F_CPU 8E6
#include <util/delay.h>

#define MyDelayValue 8
#define MyDelayValueAndAHalf 14

uint8_t Rx(void)
{
    uint8_t Recv, RecvCount, RecvMask;

    RecvCount = 8;
    loop_until_bit_is_clear(PIND, PD0);  //Auf Startbit warten
    _delay_us(MyDelayValueAndAHalf);
    for (Recv = 0, RecvCount = 0, RecvMask = 0x80;
         RecvCount < 8;
         RecvCount++, RecvMask >>= 1)
    {
        _delay_us(MyDelayValue);
        PORTD ^= (1<<PD1);       //***TEST
        if( !(PIND & (1<PD0)) ) Recv |= RecvMask;
        else Recv &= ~RecvMask;
    }

    return Recv;
}

Der sich ergebende Code (-Os) ist nicht nur invariabel von der Zahl
der Schleifendurchläufe, sondern auch noch kompakter:

.global Rx
        .type   Rx, @function
Rx:
/* prologue: function */
/* frame size = 0 */
/* stack size = 0 */
.L__stack_usage = 0
.L2:
        sbic 48-32,0
        rjmp .L2
         ldi r19,lo8(37)
    1:dec r19
    brne 1b
        nop
        ldi r18,lo8(8)
        ldi r25,lo8(-128)
        ldi r24,lo8(0)
        ldi r20,lo8(2)
.L3:
         ldi r19,lo8(21)
    1:dec r19
    brne 1b
        nop
        in r19,50-32
        eor r19,r20
        out 50-32,r19
        in r19,48-32
        or r24,r25
        lsr r25
        subi r18,lo8(-(-1))
        brne .L3
/* epilogue start */
        ret

Allerdings wird das Timing mit der nächsten Version des Compilers
trotzdem wahrscheinlich geringfügig anders sein.  Eigentlich sollte
man derartige Dinge wohl daher in Assembler schreiben (auch wenn
ich davon sonst nicht der große Protagonist bin ;) und dann die
Tatkzyklen gleich mit der Hand auszählen.

[Peter D. (peda)]

Delays können garnicht den Anspruch erheben, genau zu sein. Sie können 
ja nicht wissen, welche Zeit der Code davor und danach benötigt.

Z.B. braucht ein einzelner Befehl schon 1µs bei 1MHz und eine C-Zeile 
besteht fast nie aus nur einem Befehl, eher sinds 10 .. 20.

Und Interrupthandler addieren sich auch auf die Delayzeit auf.

Delays sollen nur nicht kürzer sein, als angegeben. Z.B. wenn man ein 
Byte an ein LCD schickt, muß man ~50µs warten. Wenns länger dauert, 
juckt das niemanden.

Je länger ein Delay, umso geringer wird natürlich der Einfluß der 
Codelaufzeit auf die Gesamtdauer.


Solls genau sein, muß man einen Timer nehmen.


Peter

[Johann L. (gjlayde)]

Jörg Wunsch schrieb:

> Eigentlich sollte man derartige Dinge wohl daher in Assembler
> schreiben (auch wenn ich davon sonst nicht der große Protagonist
> bin ;) und dann die Taktzyklen gleich mit der Hand auszählen.

Geht zB mit so einer Instruktionsfolge:

// Return   1 << (x & 7)
static inline __attribute__((always_inline))
unsigned char shift1 (unsigned char x)
{
    asm ("ldi  %0, 4"  "\n\t"
         "sbrc %1, 1"  "\n\t"
         "ldi  %0, 1"  "\n\t"
         "sbrc %1, 0"  "\n\t"
         "lsl  %0"     "\n\t"
         "sbrc %1, 2"  "\n\t"
         "swap %0"
         : "=&d" (x) : "r" (x));
         
    return x;
}

Dafür kann man dann 7-8 Ticks veranschlagen.

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

Johann L. schrieb:
> Jörg Wunsch schrieb:
>
>> Eigentlich sollte man derartige Dinge wohl daher in Assembler
>> schreiben (auch wenn ich davon sonst nicht der große Protagonist
>> bin ;) und dann die Taktzyklen gleich mit der Hand auszählen.
>
> Geht zB mit so einer Instruktionsfolge:

Nein, ich meinte nicht den Shift, sondern die gesamte Schleife,
die ja offenbar zeitkritisch ist.

[Arthur Dent (Gast)]

ok, vielen vielen dank,...

so was ähnliches hab ich in assembler schon rumliegen, das soll aber 
eben jetzt c werden (wenn möglich) warum?,... hmmm eigentlich nur weils 
halt noch mehr "state of the art" ist als asm ;) UND weil wir in letzter 
zeit immer öffter änbderungen oder spezielitäten hatten die sich in c 
dann besser anpassen/ändern lassen als in asm. momentan soll wieder eine 
änderung rein, und beim erneuten einlesen ins asm hab ich dann lieber 
angefangen das in c zu machen.

ich glaube mit den ansätzen kann ich heut gut arbeiten!!

vielen dank!

lg

[Frank (Gast)]

Verzögerungsschleifen programmier ich lieber selbst wenn Sie genau sein 
sollen.

Zum testen am besten auf einen OSI an einem pin ausgeben 
(Rechtecksignal) dann kann man das exakt messen.

Wenn es nicht Programmlastig werden soll die Delay Scheife über 
Timerinteruupt triggern.

[Klaus (Gast)]

Frank schrieb:
> Verzögerungsschleifen programmier ich lieber selbst wenn Sie genau sein
> sollen.
>
> Zum testen am besten auf einen OSI an einem pin ausgeben
> (Rechtecksignal) dann kann man das exakt messen.

Und das machst du wirklich nach jedem mal kompilieren erneut, und 
stellst die delays neu ein? Kann ich kaum glauben.

[Arthur Dent (Gast)]

Jörg Wunsch schrieb:
> Du kannst aber auch deinen Quellcode ein wenig umschreiben und
> die Bitmaske als Variable mitführen, um dem Compiler zu helfen:
> #include <avr/io.h>
>
> #define F_CPU 8E6
> #include <util/delay.h>
>
> #define MyDelayValue 8
> #define MyDelayValueAndAHalf 14
>
> uint8_t Rx(void)
> {
>     uint8_t Recv, RecvCount, RecvMask;
>
>     RecvCount = 8;
>     loop_until_bit_is_clear(PIND, PD0);  //Auf Startbit warten
>     _delay_us(MyDelayValueAndAHalf);
>     for (Recv = 0, RecvCount = 0, RecvMask = 0x80;
>          RecvCount < 8;
>          RecvCount++, RecvMask >>= 1)
>     {
>         _delay_us(MyDelayValue);
>         PORTD ^= (1<<PD1);       //***TEST
>         if( !(PIND & (1<PD0)) ) Recv |= RecvMask;
>         else Recv &= ~RecvMask;
>     }
>
>     return Recv;
> }

so scheints zu funktionieren!
vielen dank jörg!

jetzt kann ich mit dem ganzen drum herum loslegen....

schönen tag und lg

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

Arthur Dent schrieb:
> so was ähnliches hab ich in assembler schon rumliegen, das soll aber
> eben jetzt c werden (wenn möglich) warum?,... hmmm eigentlich nur weils
> halt noch mehr "state of the art" ist als asm ;) UND weil wir in letzter
> zeit immer öffter änbderungen oder spezielitäten hatten die sich in c
> dann besser anpassen/ändern lassen als in asm.

Du sollst ja deshalb auch nicht das ganze Projekt in Assembler
schreiben, sondern nur die eine, zeitkritische Funktion.  Diese
lässt sich ja dann als separates Objekt zu einem ansonsten in
C geschriebenen Projekt dazu linken.

Frank schrieb:
> Verzögerungsschleifen programmier ich lieber selbst wenn Sie genau sein
> sollen.

Wird nicht mehr und nicht minder genau als _delay_us().  Sieht mir
eher danach aus, als wüsstest du überhaupt nicht, wie diese
Verzögerungsschleifen tatsächlich implmentiert sind.

> Zum testen am besten auf einen OSI an einem pin ausgeben
> (Rechtecksignal) dann kann man das exakt messen.

Genau das hat Arthur ja versucht.  Hat nur nicht funktioniert.  Hast
du dir den Rest seines Problems denn überhaupt angesehen?