Hallo, ich habe Probleme mit dem Compare Mode des 16bit Timers. Mein Programm soll den Ausgang OC1A mit einer langsam schneller werdenden Frequenz ansteuern. Dazu will ich kontinuierlich den Vergleichswert OCR1A Wert in einer Schleife ändern. f=(fquarz/(2*OCR1A) Um dies zeitlich zu koordinieren, warte ich bis der Controller das match bit im TIFR setzt(das er nach Interrupt wieder löscht). Leider springt der Controller nicht in meine for schleife und ändert somit den Wert nicht. In einer Simulation mit Win AVR hängt er in dem Interrupt ähnlich einer Schleife fest und verläßt diese nicht mehr. Frage ist warum. Wenn ich weiter das Programm verändere und z.B noch z.B ein Portb|(1<<1); in der while schleife setze überspringt er auch die for schleife, geht einmal in den compare interrupt und dann verharrt er in der while... Ich verstehe nicht was ich falsch mache. Bedanke mich im voraus für jede Hilfe. Zum Kompilieren verwende ich Programmers Notepad.
>for(i=65535;i==10000;i--){
Mach mal aus i==10000 ein i>=10000 .
jetzt hängt er im loop_until_bit... da das bit bei einen compare nicht mehr ausgelöst wird. Vieleicht hast du noch eine Idee woran das liegt. Wenn ich das loop_until_bit_is_set Wegnehme verharrt er auch wieder in der compare interupt Schleife. Aber das Vergleichregister verändert sich dann. Dass heißt, das die for schleife jetzt arbeitet(auch wenn er da nciht hinspringt).
Du kannst nicht ein Interrupt Flag gleichzeitig pollen und es einen Interrupt auslösen lassen! Wenn der Interrupt auslöst, wird das Flag automatisch gelöscht, und die Polling-Schleife bekommt dann gar nichts mit. Was soll das überhaupt werden?
Johannes hat recht. OCF1A is automatically cleared when the Output Compare Match A Interrupt Vector is executed. Wirst wohl eine zweite Variable brauchen die im Int z.B. auf 1 gesetzt wird.
Habe noch eine Variable eingefügt die den kontinuierliches Laden bis zu einer gewissen Frequenz, ohne sprünge. Leider springt das Programm trotzdem nur einmal in Compare Interrupt danach wird anscheinend nicht nochmal ein match ausgelöst. Woran kann das noch liegen? (was heißt pollen?) Zur Funktion: Es ist wichtig das OCR1A langsam von 65000 bis 10000 läuft volatile unsigned short i=65535,k=0; ISR(TIMER1_COMPA_vect){ k=1; OCR1A=i; //aktualisierung des Vergleichregisters } int main(){ TCCR1A |= (1<<COM1A0); //Umschalten des Ausgangs OC1A TCCR1B |= (1<<CS10)|(1<<WGM12); //interne Frequenz 1.1 und löschen des Timers nach match (CTC Mode) TIMSK |= (1<<OCIE1A); //enable timer1 compare interrupt DDRD |= (1<<5); //Ausgang für digitalen Ausgang OCR1A=65535; //laden des Vergleichregisters sei(); for(i=65535;i>=10000;i--){ while(k==0){} //damit jeder i Wert runtergezählt wird und keine Sprünge auftreten k=0; } while(1){} return 0; }
Was hat dein Problem mit der main.c im Anhang zu tun ? Gar nichts !
Hab dein Programm jetzt mal in einen ATMega32 gebrutzelt und das Osci an OC1A gehängt. Funktioniert wunderbar. Die Impulse werden immer kürzer und bleiben irgendwann stehen.
Nachtrag:
>Die Impulse werden immer kürzer und bleiben irgendwann stehen.
Sie bleiben natürlich nicht stehen sondern die Pulsbreite
wird nicht mehr kleiner weil die Schleife abbricht.
*Scheiß auf den Simulator !* Der taugt nicht die Bohne.
Programme simuliert man nicht, man probiert sie aus. Zwischen
Simulation und Realität gibt es erhebliche Unterschiede.
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.