Die Version mit der Schleife hat viel mehr zu tun: Zaehler erhoehen,
Schleifenbedingung ueberpruefen, zurueckspringen zumm Anfang der
Schleife. alles das 50 mal. Ass das braucht extra Zeit.
afaik wird der Compiler bei der zweiten Variante die benötigte Zeit für
den Funktionsaufruf etc mitberücksichigen, so dass wirklich nur 50 ms
pausiert wird. Bei der ersten Variante hast du aber 50x 1 ms Delay und
dazu den Overhead...
Weshalb nimmst du ein Größerzeichen und nicht das Kleinerzeichen, also
for (j=0;j<50;j++) ...
statt
for (j=0;j>50;j++) ...
> Wobei man ja eigentlich den ersten Fall benutzen soll.
Wie kommst Du darauf?
> ich habe grade etwas zeitkritsches programmiert> ...> _delay_ms(50);
das widerspricht sich sowieso.
zeitkritisch und Warteschleifen in dieser Dimension passen nicht
zusammen
Wo hast du bitte her, dass man für delays Schleifen verwenden soll?
Hinter der Definition von delay_ms() steht in der Regel ein Makro das
dir entprechend der Taktfrequenz die richtige Anzahl NOPs einfügt.
Die Eigenbauschleife würde auch gehn. Dann musst du aber nachrechnen
wieviele Takte die Schleife braucht. Damit du das nicht tun musst gibt
es die vordefinierten delay-Funktionen.
Da es in der Regel unsinnig ist den µC tausende Take lang nichts tun zu
lassen, verwendet man in der Regel einen Timer mit entsprechendem
Interrupt.
Dass die erstere Version für Wartezeiten verwendet werden soll ist
definitiv falsch. Wenn du es aus einem Lehrbuch hast, wirf es weg. Wenn
dir das jemand sa erklärt hat, hat er keine Ahnung.
hsh schrieb:
> Wo hast du bitte her, dass man für delays Schleifen verwenden soll?
Ganz Unrecht hat er damit nicht, solange er sich auf die
delay-Funktionen der avr-libc bezieht: die koennen naemlich, abhaengig
von der eingestellten Taktfrequenz, nur Werte kleiner als 255 korrekt
verarbeiten, d.h. _delay_ms(50) geht eventuell schief.
Rik Langobar schrieb:
> Ganz Unrecht hat er damit nicht, solange er sich auf die> delay-Funktionen der avr-libc bezieht: die koennen naemlich, abhaengig> von der eingestellten Taktfrequenz, nur Werte kleiner als 255 korrekt> verarbeiten, d.h. _delay_ms(50) geht eventuell schief.
Besorg dir bitte ein WinAvr Update.
Diese Einschränkung gibt es schon lange nicht mehr.
Rik Langobar schrieb:
> Zitat aus> http://www.nongnu.org/avr-libc/user-manual/group__util__delay.html :>> The maximal possible delay is 262.14 ms / F_CPU in MHz.>> (Im Uebrigen laueft WinAVR nicht unter Linux ;-) )
Der nächste Absatz:
> When the user request delay which exceed the maximum possible one,> _delay_ms() provides a decreased resolution functionality. In this mode> _delay_ms() will work with a resolution of 1/10 ms, providing delays up> to 6.5535 seconds (independent from CPU frequency). The user will not> be informed about decreased resolution.
Im Übrigen hat das nichts mit WinAVR zu tun, sondern mit der avr-libc,
und die gibt es natürlich auch für linux.
Uwe ... schrieb:
> Rik Langobar schrieb:>> Zitat aus>> http://www.nongnu.org/avr-libc/user-manual/group__util__delay.html :>>> The maximal possible delay is 262.14 ms / F_CPU in MHz.>>>> (Im Uebrigen laueft WinAVR nicht unter Linux ;-) )>> Der nächste Absatz:>>When the user request delay which exceed the maximum possible one, >_delay_ms()> provides a decreased resolution functionality. In this mode >_delay_ms() will
work
> with a resolution of 1/10 ms, providing delays up to >6.5535 seconds
(independent
> from CPU frequency). The user will not be >informed about decreased resolution.>> Im Übrigen hat das nichts mit WinAVR zu tun, sondern mit der avr-libc,> und die gibt es natürlich auch für linux.
Das dass nichts mit Linux zu tun ist mir klar, die Aussage bezog sich
auf den Hinweis ich solle mein WinAVR updaten. Meine Angabe "255" war
ein Schnellschuss, aendert aber nichts daran, dass die Korrekte
Verarbeitung von der Taktfrequenz abhaengig ist.
@ hsh (Gast)
>Wo hast du bitte her, dass man für delays Schleifen verwenden soll?
Aus dem Forum?
>Hinter der Definition von delay_ms() steht in der Regel ein Makro das>dir entprechend der Taktfrequenz die richtige Anzahl NOPs einfügt.
Das Makro verwendet keinerlei NOP. Es ist nixhts weiter als eine 16 Bit
Zählschleife in ASM ;-)
>Die Eigenbauschleife würde auch gehn. Dann musst du aber nachrechnen>wieviele Takte die Schleife braucht. Damit du das nicht tun musst gibt>es die vordefinierten delay-Funktionen.
Nöö. Denn die kann nur mit konstanten Werten aufgerufen werden. Die
Schleifenfunktion mit variablen. Und genau DAs ist der Sinn der Sache.
Der Overhead der Schleife fällt praktisch nicht ins Gewicht, da man
sowieso nie EXAKT 50ms mit so einem Anstatz erwartet und auch nicht
braucht.
>Da es in der Regel unsinnig ist den µC tausende Take lang nichts tun zu>lassen, verwendet man in der Regel einen Timer mit entsprechendem>Interrupt.
Jain. Für Anfänger und einfache Sachen ist _delay_ms() absolut OK.
MfG
Falk
Eine eigene Frage?
Dieser Thread ist über 17 Jahre alt.
Stell sie in einem eigenen Thread – dort lesen mehr Leute mit, und sie wird öfter und schneller beantwortet.