delay us: Wie reparieren?

[Joachim .. (joachim_01)]

Hab hier nen SAM3X8E mit f_cpu = 84MHz. Bei 1000us messe ich auf dem 
Oszi aber um die 1920us (nicht Faktor 2) am Port.

das hier steht in cycle_counter.h (ich benutze gcc):

void portable_delay_cycles(unsigned long n);

#if (defined __GNUC__)
#  define cpu_ms_2_cy(ms, f_cpu)  \
  (((uint64_t)(ms) * (f_cpu) + (uint64_t)(57e2-1ul)) / (uint64_t)57e2)
#  define cpu_us_2_cy(us, f_cpu)  \
  (((uint64_t)(us) * (f_cpu) + (uint64_t)(57e5-1ul)) / (uint64_t)57e5)


#elif (defined __ICCARM__)
#  define cpu_ms_2_cy(ms, f_cpu)  \
  (((uint64_t)(ms) * (f_cpu) + (uint64_t)(14e3-1ul)) / (uint64_t)14e3)
#  define cpu_us_2_cy(us, f_cpu)  \
  (((uint64_t)(us) * (f_cpu) + (uint64_t)(14e6-1ul)) / (uint64_t)14e6)
#endif

#define delay_cycles               portable_delay_cycles

#define cpu_delay_ms(delay, f_cpu) delay_cycles(cpu_ms_2_cy(delay, f_cpu))
#define cpu_delay_us(delay, f_cpu) delay_cycles(cpu_us_2_cy(delay, f_cpu))

Die Datei ist aus dem Atmel Framework. Scheinbar gehört der Code aber zu 
einem anderen uC. Wie kann ich die Berechnungen korrigieren damit ich
cpu_delay_us(delay, f_cpu)
vernünftig benutzen kann?
Und was hat's mit den unterschiedlichen Anhängseln für gcc und IAR auf 
sich?

[Uwe Bonnes (Gast)]

Laeuft der Systick Timer? Dann haengt Dich an den ran. Etwa wie in 
Nut/Os

void NutMicroDelay(uint32_t us)
{
    int32_t start_ticks;
    int32_t current_ticks, summed_ticks=0;
    int32_t end_ticks;

    start_ticks = SysTick->VAL;
    end_ticks = (us * (SysTick->LOAD +1))/SYS_TICK_FREQ;
/* Systick counts backwards! */
    while (summed_ticks < end_ticks)
    {
        current_ticks = SysTick->VAL;
        summed_ticks += start_ticks - current_ticks ;
        if (current_ticks > start_ticks)
            summed_ticks += (SysTick->LOAD +1);
        start_ticks = current_ticks;
    }

[Joachim .. (joachim_01)]

>Laeuft der Systick Timer? Dann haengt Dich an den ran.

Ja, das hab ich auch schon überlegt.
Das freundlicherweise mitgelieferte mdelay() liefert Mllisekunden, ich 
hab die Timer samt ISR aber bis jetzt immer zu umgehen versucht ;-) 
Wobei der System-Timer wohl einfacher ist. Ich werd's in den nächsten 
Tagen angehen.

Danke.

[Peter D. (peda)]

Uwe Bonnes schrieb:
> void NutMicroDelay(uint32_t us)
> ...

Das ist ja ganz schön viel Holz.
Es geht auch deutlich einfacher.

Hier ein Delay mit Timer auf dem AVR:

void delay( int16_t d )          // d = 0 ... 32000 ticks
{
  d += TCNT1;
  while( (TCNT1 - d) & 0x8000 ); // until positive
}

Der Trick dabei ist, daß es überlauffest ist (Differenzen stimmen 
immer).

Bei 32Bit wird der Überlauf zwar seltener sein, muß aber trotzdem 
berücksichtigt werden.

Uwe Bonnes schrieb:
> end_ticks = (us * (SysTick->LOAD +1))/SYS_TICK_FREQ;

Erfordert aber zwingend einen MC mit Divisionsbefehl, sonst kommt da 
noch massig Delay hinzu.

[Uwe Bonnes (Gast)]

Peter Dannegger schrieb:
> Das ist ja ganz schön viel Holz.
> Es geht auch deutlich einfacher.
>
> Hier ein Delay mit Timer auf dem AVR:void delay( int16_t d )          //
> d = 0 ... 32000 ticks
> {
>   d += TCNT1;
>   while( (TCNT1 - d) & 0x8000 ); // until positive
> }
>
> Der Trick dabei ist, daß es überlauffest ist (Differenzen stimmen
> immer).
>

Peter, der SysTick Timer beim Cortex dient meist Zeitbasis und laeuft 
daher sowieso. Ausserdem ist er bei allen Cortex Type vorhanden, 
waehrend die anderen Timer herstellerspezifisch sind. Allerdings zaehlt 
der Systick im Betrieb als Zeitbasis halt nur von 0 bis x und nicht bis 
zum Ueberlauf, daher die komplexere Arithmetik.

> Bei 32Bit wird der Überlauf zwar seltener sein, muß aber trotzdem
> berücksichtigt werden.
>
> Uwe Bonnes schrieb:
>> end_ticks = (us * (SysTick->LOAD +1))/SYS_TICK_FREQ;
>
> Erfordert aber zwingend einen MC mit Divisionsbefehl, sonst kommt da
> noch massig Delay hinzu.

Irgendwo hatte ich (SysTick->LOAD +1))/SYS_TICK_FREQ auch schon mal 
waehrend des Startups berechnet und dann in NutMicroDelay nur noch 
multipliziert. Der Code ist aber irgendwie nicht im Repsoitory 
angekommen. Danke fuer die Codereview!