|
Anzeige
|
Delay: Exakt n Ticks erzeugen (avr-gcc)Hi, zum Erzeugen exakter Verzögerungen hier ein Makro, das exakt die vorgegebene Anzahl von Ticks zur Ausführung braucht. Dies beinhaltet natürlich nicht die Zeit evtl. ISRs. Erlaubt sind alle Konstanten <= 0x40000 (262144), wobei für Werte kleiner als 0 kein Code ausgegeben wird. Zeitmaschine gibt's erst nächstes Jahr :-) Verwendung zB:
verzögert genau 3 Ticks. Viel Spaß beim Testen
Gast
#1086207
>Dies beinhaltet natürlich nicht die Zeit evtl. ISRs.
Was verstehst Du denn unter exakt?
Gast wrote:
> Was verstehst Du denn unter exakt?
What you type is what you get :-)
Wenn du zB eine Verzögerung von 1000 Ticks haben willst, geht das evtl.
über eine Verzögerungsschleife.
Bei 1001 Ticks geht das dann nicht mehr, weil man keine Schleife
hinbekommt, deren Durchlaufzeit 1 Tick ist. Daher müssen nach der
Schleife ne bestimmte Anzahl NOPs eingefügt werden.
Diese lästige Arbeit wird von den Makros übernommen.
Ausserdem funktionieren sie auch für kleine Verzögerungen wie 0, 1, 2,
3, 4, ... ohne daß man sich den Kopf zerbrechen muss, wenn man den Delay
ändern/anpassen will. Bei 1000 Ticks will man ja auch nicht 1000 NOPs im
Code rumgammeln haben :-)
Gast
#1086505
Na ja, wenn ich 10 Takte Verzögerung haben möchte, und mir bei diesem "exakten" Verfahren ein Interrupt 1000 Takte daraus macht, ist mir nicht gedient. Ein Vorschlag meinerseits wäre, per CLI/SEI das Timing besser einzuhalten. Andernfalls kann man auch for-next Schleifen verwenden, die dann genauso "exakte" Zeiten liefern. Bei 1000 Takten und mehr sind Timer die bessere Wahl. Es ist das, was es ist: eine Warteschleife. Und kein Design-Guide oder Tipp-Sammlung, wann welche Strategie eingesetzt werden sollte ;-) Es ist einfach ein weiteres Teil in einem Werkzeugkasten. Nicht mehr, nicht weniger. Habs noch etwas verbessert: * Es geht jetzt auch für ältere Versionen der binutils * Der erzeugte Code ist kürzer geworden:
== EDIT == ARGL Hatte eben nen Tippteufel im Post... Könntest du das ganze noch auf längere Delays erweitern? Dann hättest du damit nämlich eine bessere delay Funktion geschaffen, als das was der gcc mitliefert. Benedikt K. wrote:
> Könntest du das ganze noch auf längere Delays erweitern?
hmmm... eigentlich wollte ich ja keine Monster-Makros schreiben...
Hab's erweitert auf ein Maximum von 0x5000007 = 83.886.087 Ticks.
Vielleich kann das auch mal jemand testen, der nen anderen Simulator als
Brain 0.9 hat?
Vielen Dank, ich werde es nachher mal an einem echten AVR nachmessen. 83.886.087 Ticks sind rund 4s (bei 20MHz), das sollte eigentlich für alle Fälle ausreichen. Klar, für Verzögerungen größer als ein paar ms ist ein Timer sinnvoll, aber z.B. für eine Wartezeit bei einer Init reicht solch ein einfaches Delay. Und es ist schön, wenn diese eine Delay Funktion eben alles kann, von 1 Tick bis >4s, dann kann man diese universell einsetzen. Ich habe es mal im AVR-Studio mit 0x5000007 durchlaufen lassen. Stimmt exakt. Danke für dieses nette Weihnachtsgeschenk. Hi, danke. Könntest du auch mal für ein paar kleinere Werte testen? Ist blöd, ich weiß, weil der Wert ja konstant sein muss. Könnte man das Testen irgendwie automatisieren? zB mal Durchtesten für alle Werte 0...1000? Dazu müsste man AVR-Studio skripten können bzw. batch-Jobs laufen lassen. Der Grund dafür ist, weil immer anderer Code generiert wird abhängig von der Verzögerung. Daß es also für eine Verzögerung stimmt, heisst nicht automatisch, daß es auch für einen anderen Delay korrekt ist. Auch dann nicht, wenn der Delay kleiner ist. Keine Ahnung wie man in AVR-Studio skriptet. Ich habe jetzt mal folgede Werte getestet und sie sind alle i.O. 1 5 10 bis und mit 50 100 500 1000 5000 10000 50000 Antwort schreiben |
Anzeige
|
