|
Anzeige
|
Kleinste Wartezeit mit Atmega32
Gast
#1799677
Hallo, wie niedrig ist die kleinste delay-zeit bei einem Atmega32 mit 16mhz mit : _delay_us bei Winavr-C ? Kann man auch feste Realzahlen übergeben? Gibt es einen Höchstwert, den man nicht übeschreiten darf bei der Übergabe? Gruss
Gast
#1799681
Etwas vergessen. Ich möchte die neueste Version von WinAvr benutzen.
Gast
#1799686
1/16MHz = 62.5ns
Gast
#1799696
Die 62.5ns gelten natürlich für einen NOP. Ansonsten siehe Dokumentation zur avrlibc oder probiere es im AVRStudio einfach mal aus.... (Dort kann man die Laufzeit in in CPU-Zyklen anschauen...)
Gast
#1799697
bastler schrieb: > Hallo, wie niedrig ist die kleinste delay-zeit bei einem Atmega32 mit > 16mhz mit : _delay_us bei Winavr-C ? > Kann man auch feste Realzahlen übergeben? > Gibt es einen Höchstwert, den man nicht übeschreiten darf bei der > Übergabe? Alle, wirklich alle, Antworten auf diese Fragen, und noch viel mehr, finden sich in der Dokumentation zur avrlibc. Eine deutsche Zusammenfassung dazu noch im avr-gcc-turorial, zu finden hier oben links im Menu. Oliver Peter schrieb: > Die 62.5ns gelten natürlich für einen NOP. ...den _delay_us() selbst nicht erzeugen kann, denn es ist eine fest vorgegebene Schleife. Die macht mindestens einen Durchlauf mit 2 Takten (der 3. entfällt, da der branch zurück ja nicht ausgeführt wird), braucht aber außerdem noch Zeit dafür, dass das Zählregister initialisiert wird. Je nachdem, ob ein entsprechender Initialisierungswert bereits in einem Register liegt oder nicht, braucht das also einen weiteren Takt (Register-Register-Kopie) oder zwei (zusätzlich noch ein LDI Rx, N). Der AVR-GCC im neuesten WinAVR enthält einen Patch, der die Funktion __builtin_avr_delay_cycles() bereitstellt; diese Funktion kann eine zyklengenaue Verzögerung implementieren, da der Compiler das nötige Wissen besitzt herauszufinden, ob er beispielsweise den Wert erst noch in ein Register laden muss oder nicht. Dafür kann diese Funktion natürlich nur ganzzahlige Werte übernehmen, die Umrechnung mittels F_CPU muss man hier also wieder selbst machen. In der aktuellen avr-libc (1.7.0) benutzen _delay_us() und _delay_ms() automatisch die Funktion __builtin_avr_delay_cycles(), allerdings runden sie derzeit meines Wissens immer nach unten bei der Berechnung des Arguments. Querverweis auf einen Bugfix der neuen delay-Funktionen in avr-libc 1.7.0 bis zum Erscheinen der Version 1.7.1: Beitrag "Re: _delay_ms() läuft 4 Mal schneller als erwartet" Antwort schreiben |
Anzeige
|
