delay: nop() als Schleife ausführen?

Du meinst z.B. ?

1

_delay_loop_1(uint8_t __count)

2

 {

3

         __asm__ volatile (

4

                 "1: dec %0" "\n\t"

5

                 "brne 1b"

6

                 : "=r" (__count)

7

                 : "0" (__count)

8

         );

9

 }

Werde ich mir mal genauer anschauen.

Falk Brunner schrieb:
> Was spricht dagegen, die _delay_us() Funktion bzw. _delay_ms() funktion
> nachzubauen?
Dass die Laufzeit stark variieren wird, wegen eben der Pipeline und 
Out-of-Order-Execution. Deswegen macht man soetwas mit Timern; die kann 
man problemlos zyklengenau programmieren, und in einer "busy-loop" fragt 
man ab ob der Timer schon abgelaufen ist. Alternativ mit Interrupt&WFI. 
Besser ist natürlich, das ganze komplett in Hardware zu machen - 
mithilfe von UART/SPI -Modulen, Timer-PWM-Input oder Timer+DMA lassen 
sich schon so einige serielle Protokolle verwerten.

Peter Dannegger schrieb:
> Den Timer initialisierst Du einmalig, dann läuft er durch.
> Zum Start des Delays lädst Du in ein Compareregister Timer + Delay,
> löscht das Pending-Flag und loopst, bis es wieder gesetzt ist.

Dr. Sommer schrieb:
> Deswegen macht man soetwas mit Timern; die kann
> man problemlos zyklengenau programmieren, und in einer "busy-loop" fragt
> man ab ob der Timer schon abgelaufen ist.

So habe ich es eigentlich auch schon probiert: Einen 32 bit-Timer mit 
maximaler Geschwindigkeit (coreclock) frei laufen lassen. Zu Beginn der 
Funktion den aktuellen Wert lesen, delay hinzuaddieren und dann den 
Timer auf kleiner Zielwert pollen. So kommen sich z.B. verschachtelte 
delays (z.B. Interrupt) nicht in die Quere, auch wenn das Timing des 
ersten delays wohl dahin wäre. Leider hat das enormen Overhead (z.B. 206 
statt 72 clocks bei 12 MHz; entspricht gut 17 statt 5 µs). Überlauf auch 
berücksichtigt, wobei das kaum etwas ausmacht und bei 72 zu über 4 
Milliarden auch nicht sehr wahrscheinlich ist.
Ich werde mal schauen, ob das in Assembler etwas bringt.

Pete K. schrieb:
> Ich hab mir mal das hier zusammengesammelt für einen STM32. Damit
> funktioniert auch OneWire.

Ohne es jetzt getestet zu haben: 25 MHz / 8 ist gut 3,5 mal langsamer 
als 12 MHz. Ein clock wäre etwa 0,32 µs.
Den Timer auf Null setzen, starten und am Ende wieder stoppen kostet 
auch zusätzlich Zeit.

Hartmut schrieb:
> Leider hat das enormen Overhead
Ein paar Zyklen muss man beim Timer-Abfragen halt abziehen um den 
Overhead auszugleichen...

Nun gebe ich ja ehrlich zu, kein sonderlicher Profi zu sein. Mit 
assembler schon gar nicht. Wie weit man dem Disassembler trauen kann 
(compiliert mit -S), weiß ich nicht. gcc und ohne Optimierung. Ich nutze 
die aktuelle LPCXpresso-Umgebung auf einem Cortex M0, 12 MHz.

Mein bisher bester Versuch

1

inline void delay_us(uint32_t us)

2

  {

3

    LPC_TMR32B1 ->TC = 0;    //debug

4

    LPC_TMR32B1 ->TCR = 1;    //debug

5

    uint32_t tc = DELAY_TIMER ->TC;    // get current timer value

6

    uint32_t delayclocks = (us * 1000000) / delay_clktime_us;    // convert us in (nanoseconds * 1000) as "clockbase"

7

    uint32_t loopclocks;

8

    if ((tc + delayclocks) < 0xFFFFFFFF)

9

      {

10

        loopclocks = tc + delayclocks;    // minus a few clocks to compensate calculation time for value of delay_clocks doesn't work

11

      }

12

    else

13

      {

14

        loopclocks = delayclocks - (0xFFFFFFFF - tc);

15

      }

16

    while (DELAY_TIMER ->TC < loopclocks)

17

      {

18

        asm volatile ("nop");  //;

19

      }

20

    LPC_TMR32B1 ->TCR = 0;    //debug

21

  }

Den Timer LPC_TMR32B1 nutze ich nur zum Messen, da der M0 leider nichts 
anderes zu bieten hat. Er verursacht sicher auch einen Overhead, aber 
der ist zum Vergleichen konstant.
delay_clktime_us hat in einer init-Funktion nur den aktuellen coreclock 
in Nanosekunden * 1000 umgerechnet.
Beide Timer laufen mit coreclock.
Im Disassembler kommt da schon ordentlich lang was raus; hätte ich nicht 
gedacht. Interessanter Weise bringt in der letzten while das nop 15 
clocks weniger als ein leeres statement; wieder was gelernt.

Vielen Dank, an 32 bit angepaßt klappt das mit einem kleinen konstanten 
Offset schon sehr gut. Im Disassembler ist es auch demensprechend 
deutlich kürzer. Habe da wieder gleich mehrere Dinge gelernt:
- Wenn der Compiler es rechnen soll, müssen schon alle Zahlen zur 
Compilezeit bekannt sein.
- Und man muß es dann auch tatsächlich so schreiben, daß der Compiler es 
auch erkennt. Nicht "nehme dir zur Laufzeit eine Variable und lese dort 
...". Ich hatte ein wenig spekuliert, daß der Compiler das auch so 
erkennt und entsprechend optimiert. Aber natürlich Quatsch und ohne 
eingeschaltete Optimierung ja sowieso unmöglich.
- Zuerst dachte ich, daß der mögliche Überlauf des frei laufenden Timers 
nicht berücksichtigt wäre. Ist aber ganz schön clever gemacht!

Einziger Nachteil durch die Konstanten ist, daß ein Wechsel des 
coreclocks so nicht geht. Beim Cortex M0 in rechenintensiven Abschnitten 
schon eher eine Option, aber wann kommt es mal vor und dann weiß man 
auch, wo man aufpassen muß