edelay - exact delay

[s.o.]

Hallo,

aufgrund der managelnden Warteschleifen in C habe ich schon vor längerer Zeit ein in Inlineassemblergeschriebene Headerdatei entwickelt die ich jetzt hiermit veröffentlichen will.

Was kann das Tool?
Warteschleifen 100% genau, 1-760 Zyklen und superleichte implementierung. Achtung: Es werden nur Konstanten genommen!

Beispiel:
edelay(20);

Sprich der Avr wartet 20 Zyklen.

Genug der ganzen Worte!

Grüße

[s.o.]

Nun folgt ein Update, da sich noch einiges Verändert hat. So gibt es jetzt auch edelay4, um auch in 16bit zu warten.

[DerMaddin]

Hi :)

Mich würde interessieren, ob es in der Praxis relevant ist, 20 Zyklen zu warten. Ich denke, es ist eher interessant, 200ms exakt warten zu können, oder nicht? In den hier angegebenen Routinen werden mehrere Takte mit NOPs verbracht. Das dauert bei einem 1MHz Chip viel länger als bei einem 16MHz Chip. Was für einen Anwendungsfall hast du für diese Routinen hier?
Nochwas: Du hast alles als Präprozessormakros implementiert. Das heisst bei jeder Verwendung von delay(X) wird der gesamte Codeblock an die entsprechende Stelle kopiert. Steckt da ein tieferer Sinn dahinter? Warum baust du es nicht als Funktion, die nur einmal im Speicher liegt und einfach angesprungen wird?

[s.o.]

Hallo,

Es ist kein Problem 20µSec zu warten.Du weißt ja F_CPU, bzw. das ist in deinem Makefile Dann schreibst du edelay(F_CPU/1000000*20), wenn du willst kannst du dir das ja auch noch als Makro definieren. Bei ms multiplizierst Du einfach noch mit Faktor 1000.

Zur Codegröße: Im Best Case braucht eine Routine 2 Bytes (einfach NOP), im Normalfall 3-4 Bytes und im Worst case 12 Bytes (edelay4 mit 3 WarteNOPS=6 Bytes). Du siehst also selbst, es macht den Code nicht wirklich fett; vor allem wenn man bedenkt, dass ein Befehl 2 Byte ist.

Wieso das immer so hin kopiert wird: Ja, das ist tiefgründig. Die Funktion wird vom GCC schon "vorgerechnet", d.h. der GCC fügt eventuelle NOPs ein und berechnet die exakte Schleifendauer. (Desshalb auch exact delay.) Würde man den GCC das nicht vorrechnen lasssen, wäre das springen zwar kleiner, die eigentliche Funktion würde viel mehr Bytes einnehmen; und der Code wäre im Endeffekt größer. Abgesehen vom viel größeren Programmieraufwand.

[thewulf00]

Würde man den GCC das nicht vorrechnen lasssen, wäre das springen zwar kleiner, die eigentliche Funktion würde viel mehr Bytes einnehmen; und der Code wäre im Endeffekt größer. Abgesehen vom viel größeren Programmieraufwand.

... und abgesehen von der nicht mehr exakten Verarbeitungszeit! (Sprung = 2-3 Takte, return = 3-4 Takte)