Gast
#754206
hallo, wird diese delay so verarbeitet wie ich erwarte oder muss die gerundet werden (atmega32,8mhz) : _delay_us(4.5); mfg
Das geht so.
Gast
#754362
ich habe hier den code "main.lss" eingesehen und sehe, das die delay und portd zb nicht als asm-code erscheint, wie ich den asm-code von diesen einsehen? _asm_ volatile ( 9e: 89 e4 ldi r24, 0x49 ; 73 a0: 8a 95 dec r24 a2: f1 f7 brne .-4 ; 0xa0 <main+0xe> _delay_us(27.5); PORTD |= (1 << sync); ..... ...... wie genau ist die delay_us als float-zahl eigentlich? mfg
Mit WinAVR-20071222 sieht das anders aus. test.c - C-Quellcode
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
10 | |
Übersetzt wurde mit den Einstellungen MCU=Atmega128, -Os, F_CPU=8000000. test.lss - Ausschnitt Disassemblerlisting
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
Wegen eines Bugs in der neusten GCC-Toolchain sind die C-Quellcodezeilen nicht enthalten. In Adresse ce bis d2 ist die _delay_us Inline-Funktion. Aus 27.5 µs bei 8 MHz wurde der Schleifenzähler 0x49 berechnet. Die Genauigkeit könnte man überprüfen, indem man die Laufzeit dieses Abschnitts im AVR-Studio im Debugger mit dessen Stoppwatch misst. Man kann auch die Taktzyklen der einzelnen Befehle im AVR Instruction Set Manual nachschlagen und das mit Stift und Papier ausrechnen. Und bei Adresse d4 ist das Manipulieren des Ports.
Gast
#754541
...WinAVR-20071222.... wo hast du die version vom 22.12.07 her, ich habe nur die vom 21.12.07? habe festgestellt, das die genauigkeit mindestens immer aus einen durchlauf besteht "brne" ( ich glaube der keinste durchlauf hat 3 zyclen ): ldi r24, 0x01 dec r24 brne .-4 also bei 0,5µs (8mhz) hat er einen durchlauf, sind 3 zyclen, müsste aber 4 zyclen haben. der compiler baut selber keine nop rein. dieses machst sich noch nicht einmal bei meinem fbas-bildaufbau bemerkbar. also ich bin sehr zufrieden mit dieser zeitmessung.
WinAVR-20071221 habe ich auch. Ich hatte Tomaten auf den Augen.
@ bastle (Gast)
>wie genau ist die delay_us als float-zahl eigentlich?
Das landen des Schleifenzählers dauert 1 Takt. Ein Durchlauf dauert 3
takte, bis auf den letzten, der dauert nur zwei. Bei _delay_ms() dauert
das Laden des Schleifenzählers 2 Takte, ein Durchlauf vier, der letzte
3.
MFG
Falk
Gast
#755272
dieses habe ich aus einem warteschleifen-generator : 8mhz, und 0,5µs
; =============================
; Warteschleifen-Generator
; 4 Zyklen:
; -----------------------------
; warte 3 Zyklen:
ldi R17, $01
WGLOOP0: dec R17
brne WGLOOP0
; -----------------------------
; warte 1 Zyklus:
nop
; =============================
dann stimmt der ja nicht?oder?
bastle wrote: > dieses habe ich aus einem warteschleifen-generator : 8mhz, und 0,5µs > > ; ============================= > ; Warteschleifen-Generator > ; 4 Zyklen: > ; ----------------------------- > ; warte 3 Zyklen: > ldi R17, $01 > WGLOOP0: dec R17 > brne WGLOOP0 > ; ----------------------------- > ; warte 1 Zyklus: > nop > ; ============================= > > dann stimmt der ja nicht?oder? Warum soll das nicht stimmen? Hier werden 4 Taktzyklen verbraten. Bei 8 Mhz dauern diese 4 Zyklen 0.5µs. ldi 1 Takt dec 1 Takt -> das Ergebnis davon ist 0 brne 1 Takt weil der Branch nicht genommen wird nop 1 Takt -------- 4 Takte
Man hätte natürlich auch der Einfachheit gleich 4 NOPs nehmen können. ;-)
Gast
#755388
...Man hätte natürlich auch der Einfachheit gleich 4 NOPs nehmen können.... bei meiner einstellung -0s wird kein nop eingefügt sondern es wird mindestens immer eine schleife erstellt bei delay_µs( )........
Ja, _delay_us() und _delay_ms() machen wirklich nur einfache Schleifen. Es ging ja hier eher um deinen Warteschleifen- Generator (wo auch immer er her ist).
Gast
#755603
...Ja, _delay_us() und _delay_ms() machen wirklich nur einfache Schleifen..... reicht auch vollkommen aus, wenn ich auf 0,5µs runtergehen kann bei 8mhz. gute leistung für winvr-c.
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.