[ARM / Cortex-M0(+)] delay-Funktionen "avr-libc style"

Ich möchte Dein Thread nicht mit langen Diskussionen über RTOS ja/nein, 
Sinn von längeren Spin-Loops etc. zumüllen. Nur wer über die Suche 
Deinen Code hier findet, sollte sich überlegen, ob er wirklich einen 
solchen "AVR-Style" Spin-Delay möchte.

Eine Alternative wäre ein kleines RTOS mit wunderschön bequemen 
Sleep-Funktionen und noch ein paar hübschen Sachen mehr. Eben 
"CortexM-Style".

Auch für die kleinsten Cortex M0 (STM32F030) verwende ich mittlerweile 
eigentlich immer ChibiOS, hier dann in der reduzierten NIL-Variante:
http://chibios.org

Sleep sieht dann so aus:

1

    chThdSleepMicroseconds(100);

Und ein Sleep, der gleichzeitig noch auf Events (z.B. aus anderen 
Threads oder IRQs) wartet:

1

eventmask_t evmask=0;

2

3

// US2ST: microseconds to system ticks

4

evmask = chEvtWaitAnyTimeout(ALL_EVENTS, US2ST(100));

5

6

if (evmask != 0)

7

{

8

    // event

9

}

10

else

11

{

12

    // timeout

13

}

Gerd E. schrieb:
> Eine Alternative wäre ein kleines RTOS

Nee, du hast den Sinn von sowas nicht verstanden.

Um einen 500-ns-E-Impuls auf einem HD44780 zu generieren, hilft
mir ein RTOS rein gar nichts.  Solange braucht das schon für den
Taskwechsel.

Dass Spinloop-Delays keine richtigen Timer ersetzen können, ist
(völlig unabhängig vom Prozessor) sonnenklar.  Aber sie ergänzen
sich – je nach Situation.

Ingo Less schrieb:
> Nette Sache, aber wer auf nem Coretex den Systick-Timer nicht
> standardmäßig mitlaufen lässt

Der läuft, was genau hülfe der mir hier?

Solange ich während des Delays sowieso nichts anderes tun kann,
ist es auch so ziemlich egal, ob ich nun via SysTick eine Millisekunde
warte oder via Delay.  (Nur so: ich hatte das vorher auf einem Timer
aufgesetzt, aber der ist mir zu schade für dieses bisschen Gepopel,
der soll mal bessere Dinge zu tun bekommen können.)

Jörg W. schrieb:
> Um einen 500-ns-E-Impuls auf einem HD44780 zu generieren, hilft
> mir ein RTOS rein gar nichts.  Solange braucht das schon für den
> Taskwechsel.

Das stimmt, der Taskwechsel liegt irgendwo so zwischen 1 und 2 µs 
(@48MHz). Wenn es aber mehr als vielleicht 10µs werden, dann sieht die 
ganze Sache anders aus, dann kannst Du die Zeit sinnvoll für was anderes 
nutzen.

Auch musst Du in vielen Fällen damit rechnen, daß Dein Wartecode von was 
anderem, viel wichtigerem (IRQ, High-Prio-Thread,...) unterbrochen 
wurde. Deine hart gecodete Warteschleife wartet jetzt einfach noch 
länger.

Da finde ich Ingos Vorschlag, den normal sowieso mitlaufenden 
Systick-Timer abzufragen, gar keine so dumme Idee.

> (Nur so: ich hatte das vorher auf einem Timer
> aufgesetzt, aber der ist mir zu schade für dieses bisschen Gepopel,
> der soll mal bessere Dinge zu tun bekommen können.)

Ingo meint keinen der wertvollen Timer aus der Peripherie mit PWM etc., 
sondern den speziellen Systick-Timer des Cortex-M-Kerns. Der ist 
eigentlich genau für solche Aufgaben gedacht.

Gerd E. schrieb:
> Ingo meint keinen der wertvollen Timer aus der Peripherie mit PWM etc.,
> sondern den speziellen Systick-Timer des Cortex-M-Kerns.

Ja, ist mir schon klar.  Ich schrieb ja auch, dass der
selbstverstänlich auch bei mir läuft (war das erste, was ich in
Betrieb genommen habe auf meinem kleinen Experimentierboard).

> zwischen 1 und 2 µs (@48MHz)

Klar, aber danach hast du noch kein Stück nützlichen Code in der
neuen Task abgearbeitet – dann müsstest du schon wieder zurückschalten.

Dass Delays nicht das Allseligmachende sind, ist auch auf dem AVR
nicht anders.  Es gibt aber Situationen, in denen man in der
Zwischenzeit ohnehin nichts anderes tun kann, genau dafür sind sie
gut.  Der einzige Sinn und Zweck des geposteten Codes ist es, dass
der Compiler sich die Anzahl der zu verplempernden Taktzyklen selbst
ausrechen kann, sodass man als Programmierer eben für den E-Impuls
einfach schreiben kann "delay_us(0.5);".

(Es sollte übrigens "avr-libc style" heißen, ich korrigiere das mal.
Es geht dabei nur um die API-Kompatibilität, nicht um grundlegende
Konzepte, wo man besser einen Timer benutzen würde.)

temp schrieb:
> Das Register SystemCoreClock wird eigentlich immer vom CMSIS gesetzt.
> Wenn nicht, dann muss da der Systemtakt rein.

Davon abgesehen, dass Atmel es leider nicht für nötig hält, das zu
implementieren, was mich daran stört ist, dass man dann die
Berechnung der Zyklenzahl zur Laufzeit macht.  Gerade für sehr kurze
Delays entsteht daraus wieder zusätzlicher Overhead.

Obige Version erledigt (mit aktivierter Optimierung) alles zur
Compilezeit.

Dass so ein paar simple Delays ihre Grenzen haben (vor allem bei CPUs
mit Cache), ist logisch.

temp schrieb:
> Allerdings hat deine
> Variante den zusätzlichen Nachteil im Debugmodus die Berechnungen auch
> noch in double auszuführen.

Ja.

-O0 kommt für mich einfach nicht in Frage, weil man dann sowieso
was komplett anderes debuggt als das, um was es eigentlich geht. ;-)

> Da bei sowas die Zeiten immer direkt im Code stehen, kann das der
> Präprozessor rechnen.

Der Präprozessor rechnet nicht, das macht immer der Compiler.  Der
Präprozessor ersetzt nur stur Texte.  Der wesentliche Unterschied
mit den Makros dürfte es sein, dass ein -O0 das Inlining obiger
Funktionen verhindert.  Wenn es auch -O0-fähig sein soll, müsste man
wohl auch delay_us und delay_ms als attribute "always_inline"
festzurren, das wird m. E. auch bei -O0 honoriert.  Da die Ersetzung
der konstanten double-Ausdrücke ja offenbar mit deinen Makros klappt,
müsste sie dann auch funktionieren.

Ich habe das oben mal entsprechend modifiziert.

temp schrieb:
> das ist jedenfalls das Ergebnis mit "inline":

Danke fürs Testen!

Ein bisschen mysteriös ist es schon, dass der GCC den
Gleitkommaausdruck (wie er aus dem Präprozessor dann rausfällt) ohne
Optimierung trotzdem zur Compilezeit ausrechnet, die inline-Funktion
jedoch nicht.  Naja, lässt sich dann wohl nicht ändern.

> Noch dazu wenn der Leidensdruck das nicht erfordert.

Inline-Funktionen sind ein wenig netter anzusehen, man hat lokale
Variablen und nicht diese grässliche Backslashitis.  Aber es ist
natürlich richtig, wenn man damit Funktionalität einbüßt, die man
mit den Makros bekommen kann, dann sind sie die zweite Wahl.  Ich
schau's mir heute abend nochmal an, und werde dann die
Makro-Implementierung nehmen.

Ich hatte übrigens gar nicht damit gerechnet, dass der Compiler
diese Ausdrücke ohne Optimierung jemals zur Compilezeit umsetzt,
daher hatte ich den Fall „Optimierung ist aus“ gedanklich für so
ein Vorhaben ausgeklammert.  (Wer nicht optimiert, dem ist die
Ausführungszeit ja sowieso egal. ;-)

Was mich übrigens noch stutzig macht: warum musst du das eigentlich
durch 6 teilen?  Ach, hmm, hast du wait states für den Zugriff auf
den Flash?  Wäre noch die Frage, wie man diese in die Formel Einzug
halten lässt.

temp schrieb:
> Man könnte jetzt noch untersuchen ob die selbe Routine im RAM ausgeführt
> anders läuft

Vermutlich schon.

Die Ausführungszeiten der Befehle des Cortex-M0+ sind ja durch ARM
so vorgegeben, da können die einzelnen Siliziumhersteller nichts
ändern.  Damit kann es aber nur an Flash-Waitstates liegen.  Der
SAMD20, den ich hier gerade in den Fingern habe, kann bis 24 MHz
ohne Waitstates arbeiten (dann passt das auch mit dem Teilen durch
4), darüber müsste man da auch einen Waitstate einschieben.

Allerdings müssten es mit einem Waitstate eigentlich 7 CPU-Zyklen
pro Iteration werden (vier für die Befehlsausführung, drei
Waitstates für drei Befehle).

Bei Ausführung aus dem RAM geht's natürlich bis zu maximalem Takt
ohne Waitstates.

Ja, klar, der Flash ist natürlich 32-bittig organisiert bei einem
ARM.  Das erklärt dann auch den Teilerfaktor 6: du holst die ersten
beiden Befehle mit einem zusätzlichen Waitstate (+ 2 Takte für die
Ausführung), danach wird der Sprungbefehl ebenfalls mit einem Waitstate
geholt plus weitere zwei Takte für die Ausführung.

Hmm, ok, danke für den Tipp!  Ich werde das Alignment da ebenfalls
noch reinsetzen.

Jörg W. schrieb:
> Allerdings müssten es mit einem Waitstate eigentlich 7 CPU-Zyklen
> pro Iteration werden (vier für die Befehlsausführung, drei
> Waitstates für drei Befehle).

so einfach ist es glaube ich nicht: die meisten Cortexe haben ja noch 
einen Cache, der den Effekt der Waitstates mindern soll. Ob und wie 
effektiv der Cache ist, hängt dann aber vom Alignment und von Sprüngen 
ab. Sieht man ja an den Ergebnissen von temp oben.

Und es hängt natürlich von der genauen Implementation des Caches ab. Und 
soweit ich weiß, implementiert jeder Hersteller hier seinen eigenen 
Cache, der ist nicht von ARM vorgegeben. Auch unterscheiden sich die 
Caches zwischen den unterschiedlichen Linien eines Herstellers.

Ich hatte anno LPC2000 eine ähnliche Variante selbstkalibierend 
implementiert. Bei Start des Systems wird über einen bekannten Timer, 
Systick oder RTC, das Zeitverhalten der Delay-Routine gemessen und ein 
Faktor abgeleitet. Der zur Kalibrierung verwendete Timer ist danach frei 
für anderweitige Verwendung.

Damit sind dann auch dynamische Zeiten möglich, solange der Core einen 
Multiplier hat und nicht zu langsam getaktet wird. Und der Code 
funktioniert unabhängig von Waitstates, Caches und dergleichen. Dafür 
handelt man sich durch den Referenz-Timer eine Abhängigkeit von der 
Controller-Familie ein.

A. K. schrieb:
> Ich hatte anno LPC2000 eine ähnliche Variante selbstkalibierend
> implementiert.

Magst du die hier vorstellen?  Klingt auch interessant.

Jörg W. schrieb:
> Magst du die hier vorstellen?  Klingt auch interessant.

Da der LPC2129 sicherlich nicht mehr viele Freunde hat und der Code 
ausserdem schlecht aus meiner Devicelib rausgezupft werden kann hier mal 
die STM32 Variante. Viel verwendet worden ist die allerdings nicht, also 
Vorsicht damit. Nicht adaptiv ist bisher die Angabe des Overheads, da 
könnte man noch dran feilen.

Sind auch Definitionen drin, die ich mir zu den CMSIS Includes 
hinzugefügt habe. Sowas wie SysTick_LOAD_RELOAD_Msk findet sich dort 
nicht. Also direkt übersetzen lässt sich das für euch nicht. Müsst ihr 
schon selbst was draus machen.

Bisschen Erklärung: Der Trick liegt darin, in der Schleife nicht 
Durchläufe zu zählen, sondern Nanosekunden zu addieren bis die Zeit 
erreicht ist. Wär mit 16 Bits etwas eng, aber der ARM hat genug davon.

Die Kalibrierung bestimmt, wieviele Nanosekunden ein Durchlauf benötigt. 
Ein Faktor ist in dieser Variante nicht erforderlich und der Multiplier 
wird nur für dynamische µs/ms gebraucht, oder beim unoptimierten 
Debugging.

Es kann natürlich sein, dass der Durchlauf nicht genau in ns 
spezifizierbar ist. Gibt dann eine systematische Abweichung. Aber bei 
ohnehin ungenauen Spinloops sollte man damit leben können, solange die 
verwendeten ARMe weit genug von den GHz weg sind.

Die Schleife ist mit Absicht nicht inlined, um in jedem Fall immer 
denselben Code an derselben Stelle zu haben.

Danke, klingt gut!

Ja, dass die 32 Bits da manche Dinge einfacher machen, ist 
offensichtlich.