Hallo da,
ich versuche mich gerade am Interrupt mittels Comparematch im CTC Mode.
Das läuft aber nicht so ganz. Ich weiß vorallem nicht, was mir diese Fehlermeldung sagen will.
Vielleicht kann mir jemand sagen, was ich falsch mache.
Danke
Ich seh da auf Anhieb keine Fehlerquelle.
Hast Du das Programm schon mal im Simulator getestet ?
Was passiert wenn der Counter 2 den Zählerstand 255 erreicht ?
Was passiert wenn du das Comparematch Interrupt Flag des Timers 2 manuell im Simulator auf 1 setzt ?
Hallo nochmal,
hab noch etwas rumexperimentiert und die fehlermeldungen sind weg.
Vorallem die meldung mit dem "odd" ist weg.
Nur tun, tut sich nix.
Kann da jemand helfen?
Code:.include "AVR.H" ;------------------------------------------------------------------------ ;Reset and Interrupt vector ;VNr. Beschreibung ;Start, Power ON, Reset ;----------------------------------------------------------------------- .org 3 rjmp interrupt rjmp reset reset: ldi r16,hi8(RAMEND) out SPL,r16 ldi r16,lo8(RAMEND) out SPH,r16 ldi r16,0b11111111 out DDRB,r16 ldi r16,255 ;compare value out OCR2,r16 ldi r16,0b00100010 ;CTC - PRS 8 out TCCR2,r16 ldi r16,0b10000000 ;Interrupt enable out TIMSK,r16 sei ;global int. enable ldi r17,0b00000000 ldi r18,0b11111111 ;Hier Init-Code eintragen. ;------------------------------------------------------------------------ mainloop: wdr rjmp mainloop interrupt: ;toggle Port B in r16,PINC ori r16,255 breq interrupt1 out PORTB,r18 interrupt1: out PORTB,r17 interrupt2: reti
Hi,
zwei Sachen fallen mir da auf:
1. Du springst mit Deinem ersten Befehl sofort in die Interruptroutine, und beim Reti weiß der Prozessor nicht, wohin er zurückspringen soll. Die Reihenfolge wie im ersten Post ist da schon richtig.
2. bei der Definition des Stackpointers hast Du SPL und SPH vertauscht. Das war auch schon mal richtiger im ersten Beispiel
Ergo, ich weiß auch nicht, warum Dein erstes Beispiel nicht geht ^^
greetz Rajko
Probier mal den CODE für AVR Studio 4.
Dein Code schaltet zwar Portb kurz ein aber dann sofort wieder aus!
Der Interrupt wird also durchlaufen, nur Du merkst ausser einem sehr kurzen Impuls an PORTB nichts davon. Dein Interrupt wird bei einer Quarzfrequenz von 4MHz alle 512 µsec aufgerufen, was einer Frequenz von ca. 1000 Hz entspricht.
Ich hab auch noch die verwendeten Register auf dem Stack gesichert.
PORTB,3 has Du anscheinend mit einer Sonderfunktion belegt, der ist bei mir dauerhaft 0 im simulator!
Code:.include "m8def.inc" ;------------------------------------------------------------------------ ;Reset and Interrupt vector ;VNr. Beschreibung ;Start, Power ON, Reset ;----------------------------------------------------------------------- .cseg .org 0 rjmp reset .cseg .org 3 rjmp interrupt reset: ldi r16,low(RAMEND) out SPL,r16 ldi r16,high(RAMEND) out SPH,r16 ldi r16,0b11111111 out DDRB,r16 ldi r16,255 ;compare value out OCR2,r16 ldi r16,0b00100010 ;CTC - PRS 8 out TCCR2,r16 ldi r16,0b10000000 ;Interrupt enable out TIMSK,r16 sei ;global int. enable ldi r17,0b00000000 ldi r18,0b11111111 ;Hier Init-Code eintragen. ;------------------------------------------------------------------------ mainloop: wdr rjmp mainloop interrupt: ;toggle Port B PUSH r16 IN R16,SREG PUSH r16 PUSH r18 LDI r18,0xFF In r16,PORTB EOR r16,r18 out PORTB,r16 POP r18 POP r16 OUT SREG,r16 POP r16 reti
NICHT SCHON WIEDER EIN USERPROBLEM!!!!!!!!!!!
Also ich hab´s jetzt und der Fehler lag in meiner Bedienung vom AVR Studio.
Man muss den Code eben erst "build"-en bevor man ihn brennt
Und danke, an alle, die was geschriben haben.
The Man
Manchmal kann ich es wirklich nicht verstehn -
Da arbeitet man mit AVR Studio und nutzt den Simulator nicht, lieber ärgert man sich tagelang mit irgendwelchen lapidar Problemen rum, anstatt das fehlerhafte Stück Code mal im Simulator zu testen.
Hättest Du auf meinen 1sten Post hin deinen Code getestet, hättest Du ihn auf jeden Fall "builden" müssen und das Problem wäre gegessen.
Aber manche brauchen halt "Die harte Tour"
Sicher - der Simulator ist nicht perfekt.
Falsch eingestellte Fuse Bits können nicht erkannt werden.
Die Simulation von Datenaustausch über Peripherieschnittstellen (SPI, seriell, TWI) ist schwierig bis unmöglich.
Nichts destotrotz ist der Simulator ein mächtiges Werkzeug um einen Quellcode zu debuggen, aber sehr viele Leute nutzen das einfach nicht, wie hier einige Posts beweisen !
Ich progge jetzt seit ein paar Monaten in C (Codevision AVR) und nutze auch hier den Simulator vom Studio zum debuggen der Software.
Das klappt vorzüglich und ich krieg sehr oft eine sofort laufende Software in den Controller.
Sicher ist ein JTAG Hardware Debugger noch besser, aber mein schmales Hobby Budget gestattet so eine Anschaffung halt nicht.
Ausserdem ist die Anzahl der ATMEL- Controller mit JTAG Interface sehr Übersichtlich.
Ist ja nicht so, dass ich den Simulator nicht genutzt hätte.
Ich hab mich nur eben gewundert, dass es da lief und auf dem AVR nicht.
Das wundert mich aber.
Wenn man "built" macht wird doch das .hex File neu generiert.
Oder hast Du dann immer wieder eine alte umbenannte Variante in den Chip eingespielt?
Das läuft dann unter der Rubrik "blöd gelaufen" und ich entschuldige mich hiermit für meine Äußerungen.
Berechtigungen
Zitieren
Lesezeichen