Problem mit Interrupt

[The Man]

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

[wkrug]

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 ?

[The Man]

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?


.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

[bax]

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 O:)

Ergo, ich weiß auch nicht, warum Dein erstes Beispiel nicht geht ^^

greetz Rajko

[wkrug]

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!

.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

[The Man]

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 :Haue

Und danke, an alle, die was geschriben haben.

The Man

[wkrug]

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" O:)

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.

[The Man]

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.

[wkrug]

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.