|
Anzeige
|
TIMER1 COMPA Interrupt löst nicht aus ATmega328PHallo an alle, ich versuche mich nun seit einigen Stunden daran einen TIMER1 COMPA Interrupt auslösen zu lassen. Beim Debuggen kann ich sehen, dass das TCNT1 bis 10 zählt und dann wieder auf Null gesetzt wird. Allerdings springt er nicht in die ISR. Komme nicht auf den Fehler. Könnt ihr mir bitte weiter helfen? Vielen Dank im Voraus :) Hier der ganze Code:
Addi J. schrieb: > PORTD ^= (1<<PD2); > } Hast du die Interrupst enabled? Kurt Danke für die schnelle Antwort. Mit TIMSK und sei() sind doch die benötigten gesetzt, oder? Das was ich gepostet habe, ist der komplette Code. Gruß Addi
Gast
#4384103
Zwei Sachen fallen mir ein: 1) schreibe mal nur "PORTD ^= (1<<PD2);" in die ISR. Geht es dann? Deine Init ist ansich richtig, würde ich auch so machen. 2) verschiebe den Zugriff auf das OCR1A hinter TIMSK1. Das war mal bei einem anderen Atmel bei mir von durchschlagender Wirkung. Keine Ahnung warum. Addi J. schrieb: > Allerdings springt er nicht in die ISR. Doch, tut er. Wie kommst du darauf, dass er das nicht tut? und gewöhn dir diesen Scheiss ab: > TCCR1B =0x0A; Hier geht es doch auch: > PORTD ^= (1<<PD2); mfg. @Felix Adam: welcher Code in der ISR steht ist erstmal irrelevant, da er beim debuggen gar nicht erst in die ISR springt. Und dein Vorschlag hat leider auch keine Änderung bewirkt. @Thomas Eckmann: Ok, das Flag wird tatsächlich gesetzt. Aber er springt wie gesagt nicht in die ISR. Grüße Addi Addi J. schrieb: > Aber er springt > wie gesagt nicht in die ISR. Aber sicher tut er das. Warum soll er das auch nicht tun? Der hat doch gar keine andere Wahl. mfg.
Angehängte Dateien:
Könnte es sein, dass da unterschiedliche IDE benutzt werden (im Bild von Thomas scheint es das AVR Studio 4.xx zu sein) und da etwas anders ist? @Addi J. könntest du das .lss-File mal posten, falls es immer ncoh nicht geht? Felix A. schrieb: > Könnte es sein, dass da unterschiedliche IDE benutzt werden (im Bild von > Thomas scheint es das AVR Studio 4.xx zu sein) und da etwas anders ist? Höchst wahrscheinlich wird das so sein. Aber an dem Progrämmchen ist klar ersichtlich, nachdem man die Hexwerte bei der Initialisierung aufgedröselt hat, dass es in die ISR springen muss. Das habe ich ja auch gezeigt. Der Unterschied, dass es das bei ihm angeblich nicht tut, ist aber eher der verwendete Debugger. Das wird bei ihm der Simulator sein, während es bei mir ein richtiger Debugger ist und alles auf einem richtigen Controller läuft. mfg. Simulator und Debugger hätte ich jetzt als unterschiedlich betrachtet. Es klang so, als hättest du den Simulator sowie Debugger und Addi J. den Debugger (wie geschrieben) genutzt ... Wobei Debugging natürlich auch im Simulator erfolgen kann. Kann es sein, daß Addi für den falschen ATmega übersetzt und eine andere Interrupt-Vektor-Tabelle benutzt? Gruß, Stefan Ach. Im AVR.Studio gibt es eine Einstellung, mit dem dem Debugger gesagt wird, dass er ISR ignorieren soll. Die Simulation führt die Befehle richtig aus, aber im Debugger wird das nicht angezeigt. ZU finden im Menü unter Tools / Options Dann "Tools" "Tool settings" und dort dann der Punkt "Mask Interrupts while stepping" Wer immer sich das ausgedacht hat, dass hier eine Einstellung von true als Default eine gute Idee wäre, sollte noch einmal darüber nachdenken. Um die restlichen Fragen zu beantworten: Richtig, bei mir war es nur der Simulator von AtmelStudio 7 und es war tatsächlich so, wie Karl Heinz sagte, der Punkt "Mask Interrupts while stepping" war tatsächlich enable :o Aber jetzt geht es :D Vielen Dank für eure Bemühungen :) Antwort schreiben |
Anzeige
|
