Hi, warum funktioniert das nicht: #include <avr/io.h> void delay(unsigned int p) { unsigned int i; for(i=0; i<p; i++) { asm volatile ("nop"); } } void main(void) { DDRB = 0xFF; while(1) { PORTB = 0x00; delay(0xFFFF); PORTB = 0x01; delay(0xFFFF); } } wenn ich allerdings die zwei aufrufe der delay funktion in der main() durch zwei for-schleifen ersetze dann funzts das ganze... also es scheint irgendwie an der funktion zu liegen... könnte auch sein das mein makefile schrott ist -> könnte mir jemand ein gescheites "standart-makefile" schicken? MFG Marcel
Nun, vielleicht hättest Du ja statt des ,,Hää'' ja lieber mal beschreiben sollen, was denn bei Dir nicht funktioniert. Ich bekomme jedenfalls in der Simulation einwandfrei einen Rechteck mit einer Periodendauer von ca. 115 ms (@ 8 MHz CPU) an PB0.
hmm nunja wenn ich das ganze kompiliere und auf nen AT90S4433 schreibe dann tut sich garnix wenn ich es allerdings so mache: #include <avr/io.h> void main(void) { unsigned int i; DDRB = 0xFF; while(1) { PORTB = 0; for(i=0; i<0xFFFF; i++) { asm volatile ("nop"); } PORTB = 1; for(i=0; i<0xFFFF; i++) { asm volatile ("nop"); } } } und dies dann kompiliere und auf meinen AT90S4433 schreibe funktioniert es also wieso funktioniert das oben nicht aber das hier funzt? MFG Marcel
Wie geschrieben: bei mir funktioniert die Version, die bei Dir nicht tut, sehr wohl. (OK, in der Simulation, einen Chip zum Testen habe ich jetzt hier nicht zur Hand.) Aber ich habe da so einen Verdacht... Du hast -mmcu=$(MCU) in Deiner Linker-Kommandozeile vergessen (also in dem Aufruf von avr-gcc, der das Linken vornimmt). Dadurch wird für den falschen AVR gelinkt, was zur Folge hat, daß der Stack im Nirvana landet. Stört keinen bis zu dem Moment, da Du die erste Funktion aufrufen willst... Ein Standard-Makefile-Template ist bei WinAVR wohl dabei. Das solltest Du als Basis für Dein eigenes Makefile benutzen.
ok danke ich werds mal versuchen... wie genau und womit simulierst du denn deine programme? MFG Marcel
Mit VMLAB, siehe http://www.amctools.com/ -- man verzeihe mir die Schleichwerbung. Ist Payware, hat aber eine deutlich bessere Peripherie-Simulation als AVR Studio und für mich vor allem den Vorteil, daß es auf meinem FreeBSD mit dem Wine Windows-Emulator läuft. Alternativ habe ich avr-gdb + simulavr zum Simulieren. Vorteil ist, daß es Freeware ist und der GDB als Debugger an Features von keinem noch so ausgefeilten GUI wirklich zu schlagen ist, außerdem kann man auf die vollen Debug-Informationen der ELF-Datei zurückgreifen. Nachteil ist, daß simulavr praktisch nur zum Simulieren reiner Algorithmen geeignet ist und nur rudimentäre IO-Fähigkeiten besitzt. Ohne avr-gdb und simulavr hätte aber das avr-libc Projekt weder ein malloc() noch eine komplette printf() und scanf() Familie, zumindest nicht aus meiner Feder (bei printf() nur teilweise, die Basis unseres printf() ist von Alexander Popov geschrieben worden, von dem ich leider seither nichts mehr gehört habe).
Nein, warum sollte sie denn? Erstens gäbe es keinen Grund, warum der Compiler sie innerhalb einer Funktion wegoptimieren sollte und innerhalb von main() nicht (Marcel schrob ja, daß es beim direkten Einfügen in main() tut), zweitens hat Marcel im Body der Schleife ordentlich ein »asm volatile("nop")« stehen, der Compiler darf das also gar nicht wegoptimieren, drittens kann man sich den generierten Assemblercode ja ruhig ansehen, und schließlich habe ich nicht umsonst die sich ergebende Ausgangsfrequenz meiner Simulation mit gepostet, der man ebenfalls entnehmen kann, daß es sich um ein deutliches Delay handelt.
hi ich bins nochmal, also joerg hatte recht, ich hatte als mmcu einen falschen AVR gesezt -> autsch :D danke für eure hilfe... MFG Marcel
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.