AVR Interrupt immer zu 0x000 (Assembler)

[Julian (Gast)]

Hallo Forum

(ATmega168)

Ich wollte mich eigentlich in das Thema Analogkomparator einarbeiten 
aber bin dann über ein eher unerwartetes Problem gestolpert:

Ich wollte via den Analogcomparator einen Interrupt auslösen und zwar 
wenn der Referenzwert über oder unterschritten (toggle) wird.
Nur ist jetzt das Problem, dass beim Simulieren im Atmelstudio der 
Interrupt immer auf die Adresse 0x000, also Reset oder Init ausgelöst 
wird. Das Programm kommt also gar nie in die ISR.

Hier der benutzte Code:

Das erste LED wird sofort gesetzt, das zweite soll dann wenn der 
Analogkomparator ausgelöst hat seinen Zustand ändern anschliessend gehts 
wieder in die Warteschlaufe.

.ORG 0x000 
rjmp RESET ; Reset Handler
;.ORG 0x001 rjmp EXT_INT0 ; IRQ0 Handler
;.ORG 0x002 rjmp EXT_INT1 ; IRQ1 Handler
;.ORG 0x003 rjmp PCINT0 ; PCINT0 Handler
;.ORG 0x004 rjmp PCINT1 ; PCINT1 Handler
;.ORG 0x005 rjmp PCINT2 ; PCINT2 Handler
;.ORG 0x006 rjmp WDT ; Watchdog Timer Handler
;.ORG 0x007 rjmp TIM2_COMPA ; Timer2 Compare A Handler
;.ORG 0x008 rjmp TIM2_COMPB ; Timer2 Compare B Handler
;.ORG 0x009 rjmp TIM2_OVF ; Timer2 Overflow Handler
;.ORG 0x00A rjmp TIM1_CAPT ; Timer1 Capture Handler
;.ORG 0x00B rjmp TIM1_COMPA ; Timer1 Compare A Handler
;.ORG 0x00C rjmp TIM1_COMPB ; Timer1 Compare B Handler
;.ORG 0x00D rjmp TIM1_OVF ; Timer1 Overflow Handler
;.ORG 0x00E rjmp TIM0_COMPA ; Timer0 Compare A Handler
;.ORG 0x00F rjmp TIM0_COMPB ; Timer0 Compare B Handler
;.ORG 0x010 rjmp TIM0_OVF ; Timer0 Overflow Handler
;.ORG 0x011 rjmp SPI_STC ; SPI Transfer Complete Handler
;.ORG 0x012 rjmp USART_RXC ; USART, RX Complete Handler
;.ORG 0x013 rjmp USART_UDRE ; USART, UDR Empty Handler
;.ORG 0x014 rjmp USART_TXC ; USART, TX Complete Handler
;.ORG 0x015 rjmp ADC ; ADC Conversion Complete Handler
;.ORG 0x016 rjmp EE_RDY ; EEPROM Ready Handler
rjmp ANA_COMP ; Analog Comparator Handler
;.ORG 0x018 rjmp TWI ; 2-wire Serial Interface Handler
;.ORG 0x019 rjmp SPM_RDY ; Store Program Memory Ready Handler

reset:
LDI    R16, LOW(RAMEND)
OUT    SPL, R16
LDI    R16, HIGH(RAMEND)
OUT    SPH, R16

SBI    DDRB,1      ;KONTROLL LED
sbi    ddrb,2      ;KONTROLL LED (TOGGLET BEI ANALOGINT)

;INIT ANALOG COMPERATOR
sbi    portb,2      ;KONTROLL LED

LDI    R16, 0B00001000
OUT    ACSR, R16
LDI    R16, 0B00000011
sts    DIDR1, R16

SEI
RJMP LOOP

ANA_COMP:
cbi    portb,2
SBIC  PORTB,1
rjmp LEDON
SBI    PORTB,1
RETI
LEDON:
CBI    PORTB,1
RETI

LOOP:
NOP
RJMP LOOP

Ich weiss, das Programm ist sehr simpel, aber trotzdem sehe ich den 
Fehler nicht.
Vielen Dank für eure Hilfe

[(prx) A. K. (prx)]

Mega168 und RJMP passt nicht, die Interrupt-Leiste ist also falsch und 
der Interrupt geht in den Wald.

[holger (Gast)]

>;.ORG 0x016 rjmp EE_RDY ; EEPROM Ready Handler
>rjmp ANA_COMP ; Analog Comparator Handler

Wo ist das org hin? Das steht nicht zum Spass da.

[(prx) A. K. (prx)]

holger schrieb:
> Wo ist das org hin? Das steht nicht zum Spass da.

Wär auch mit ORG falsch. Die Interrupt-Leiste ist vom falschen 
Controller abgeschrieben. Der Mega168 braucht 2 Worte pro Handler.

[LostInMusic (Gast)]

Im Datasheet zum ATmega48/88/168 findest Du im Kapitel "Interrupts" u. 
a. eine komplette Muster-Interrupttabelle. Dort ist auch erklärt, warum 
die so aussieht wie sie aussieht.

[Willi (Gast)]

Du hast ja fast alle Interruptvectoren auskommentiert.
Damit steht das rjmp ANA_COMP an der völlig falschen Stelle im Speicher.
der Sprung müsste bei 0x17 stehen.

Nimm alle ; vor den .ORGs raus und schreibe .ORG 0x17 vor rjmp ANA_COMP.

MfG Willi

[(prx) A. K. (prx)]

Willi schrieb:
> der Sprung müsste bei 0x17 stehen.

Nochmal: NEIN. Nicht beim Mega168. Nur beim Mega48/88.

[Willi (Gast)]

prx hat Recht:
Der Sprung gehört nach 0x2e.

LostInMusic hat auch Recht:
Besser Du guckst ins Datenblatt.

MfG Willi

[Amateur (Gast)]

Kopieren geht nicht immer über studieren!
In gewissen Grenzen sollte man wissen, was man(n) tut.

[Peter D. (peda)]

A. K. schrieb:
> Die Interrupt-Leiste ist vom falschen
> Controller abgeschrieben.

Deshalb schreibt man die ja auch nicht ab, sondern nimmt das zum Target 
passende Include:

Beitrag "Re: avr asm: interrupt int0 löst bei fallender flanke nicht aus"

[Julian (Gast)]

Vielen Dank an euch alle

Ich habe nochmals das Datenblatt zur Hand genommen und habe gesehen, was 
prx gemeint hat (auch mit den Unterschieden zu den mega48, mega88).

Ich werde das anpassen und nochmals versuchen.
(ja, ich gebe es zu, es ist das erste mal, dass ich mich über einen 
ATTiny2313 hinauswage)

Danke und Grüsse
Julian

[Thomas (kosmos)]

wenn du einzelne Interrupts nicht brauchst setzt du ein reti statt z.B. 
rjmp EXT_INT0

dann gibt es keine Fehlermeldung wenn du keine subroutine EXT_INT0 
erstellt hast und dein Programm macht einfach unbeeindruckt dort weiter 
wo es vor dem Interruptaufruf war und wenn du den Beginn mit .org 0x00 
setzt wird alles andere einfach nachfolgend geschrieben dann braucht man 
nicht jedesmal .org neu zu schreiben.

.ORG  0x00
rjmp RESET         ; Reset handler
reti               ; rjmp EXT_INT0      ; IRQ0 handler
rjmp PIN_CHANGE    ; Pin change handler
rjmp TIM1_CMP1A    ; Timer1 compare match 1A
rjmp TIM1_CMP1B    ; Timer1 compare match 1B
rjmp TIM1_OVF      ; Timer1 overflow handler
rjmp TIM0_OVF      ; Timer0 overflow handler
rjmp USI_STRT      ; USI Start handler
rjmp USI_OVF       ; USI Overflow handler
rjmp EE_RDY        ; EEPROM Ready handler
rjmp ANA_COMP      ; Analog Comparator handler
rjmp AD_C          ; ADC Conversion Handler

[Karl H. (kbuchegg)]

Thomas O. schrieb:

> setzt wird alles andere einfach nachfolgend geschrieben dann
> braucht man
> nicht jedesmal .org neu zu schreiben.

... und tappst wieder in die Falle, dass es unterschiedliche AVR gibt. 
Bei den einen reicht deine Lösung, bei den anderen reicht sie aber 
nicht, weil, banal gesagt, ein rjmp bzw. ein reti nicht genug Bytes 
verbraucht, um von einem Interrupt Einsprungspunkt zum nächsten zu 
gelangen.
Der vom TO verwendete ist genau so einer. Deine angedachte Lösung ist 
genau aus diesem Grund falsch.


Die .org Variante vermeidet dieses Problem. Es hat schon seinen Grund, 
warum sie empfohlen wird.

[Thomas (kosmos)]

es ist mir vollkommen klar das jeder AVR unterschieliche Interrupts hat 
und dadurch auch einen anderen Interruptvectortabelle erfordern, das war 
nur ein Beispiel eines ATTiny26 aber in jedem Datenblatt gibts auch die 
zugehörige Tabelle.

Die Tabelle des TO ist auch fortlaufend da bringen die ganzen ORG 
Anweisungen nicht.

Wenn man das Problem hat das man mit rjmp nur 2kbyte weit springen kann, 
dann sollte mal hat die Interrupt Unterprogramm halt in diesen 2kByte 
platzieren.

wenn man mit icall arbeiten will und 2 Befehle benötigt. Dann wird der 
Interruptvector bestimmt nicht fortlaufen sein sondern eher eine Stelle 
auslassen.

.ORG  0x00
mov     R30,R0
icall
.ORG    0x02
.....
icall

könnte auch so aussehen wenn man innerhalb der 2 kbytes bleibt
.ORG 0x00
nop
rjmp XYZ
nop
rjmp UVW
....
....

[c-hater (Gast)]

Thomas O. schrieb:

> Die Tabelle des TO ist auch fortlaufend da bringen die ganzen ORG
> Anweisungen nicht.

Doch, natürlich. Sie bringen genau dann etwas, wenn es 
auskommentierte/unbenutzte Vektoren gibt, dann sorgen sie nämlich dafür, 
daß die benutzten trotzdem an der richtigen Stelle im Flash liegen.

Das tun sie allerdings nur, wenn für das .org auch der richtige 
Parameter angegeben wird. Zahlenwerte zu verwenden ist hier 
kontraproduktiv. Dafür gibt es in den devicespezifischen Include-Dateien 
extra die passenden Symbole. Verwendet man die als .org-Parameter, 
stimmt schonmal die Adresse des Vectors ohne jede weitere Verrenkung, 
Rechnerei und Datenblatt-Recherche.

Das Programm des OP sollte also etwa so beginnen:

.include "m168def.inc"

.org 0        ;leider hat Atmel kein Symbol dafür vorgesehen
  rjmp reset
.org ACIaddr  ;die Definition steht in der includierten Datei
  rjmp acint

> Wenn man das Problem hat das man mit rjmp nur 2kbyte weit springen kann,

Das kann niemals passieren. Mit rjmp kann man +- 2k word weit 
springen, also insgesamt 8kByte Flash erreichen. Genau dieser 
Sachverhalt ist auch der Grund, warum die jmp-Instruktion nur bei den 
Devices nicht verfügbar ist, die 8k Flash oder weniger haben, hier 
reicht schlicht die rjmp-Instruktion aus, um den gesamten Speicher 
erreichen zu können.

[Karl H. (kbuchegg)]

Thomas O. schrieb:

> Wenn man das Problem hat das man mit rjmp nur 2kbyte weit springen kann,
> dann sollte mal hat die Interrupt Unterprogramm halt in diesen 2kByte
> platzieren.
>
davon war überhaupt nie die Rede und das ist ach gar nicht das Problem

> wenn man mit icall arbeiten will und 2 Befehle benötigt. Dann wird der
> Interruptvector bestimmt nicht fortlaufen sein sondern eher eine Stelle
> auslassen.

und auch davon war nie die Rede.

Die Rede ist davon, dass mit deiner Methode die Interrupt Tabelle mit 
rjmp und reti aufgebaut wird, bei einem Mega168 dieselbe Technik aber 
mit jmp und reti+nop aufgebaut werden muss (oder mit rjmp+nop und 
reti+nop)

was beim Mega48 so aussieht (am Beispiel vom INT1)

    rjmp RESET ; Reset Handler
    reti ; rjmp EXT_INT0 ; IRQ0 Handler
    rjmp EXT_INT1 ; IRQ1 Handler
    reti ; rjmp PCINT0 ; PCINT0 Handler
    reti ; rjmp PCINT1 ; PCINT1 Handler
    reti ; rjmp PCINT2 ; PCINT2 Handler
    reti ; rjmp WDT ; Watchdog Timer Handler
....

sieht beim Mega168 so aus

    jmp  RESET ; Reset Handler
    reti ; rjmp EXT_INT0 ; IRQ0 Handler
    nop
    jmp  EXT_INT1 ; IRQ1 Handler
    reti ; rjmp PCINT0 ; PCINT0 Handler
    nop
    reti ; rjmp PCINT1 ; PCINT1 Handler
    nop
    reti ; rjmp PCINT2 ; PCINT2 Handler
    nop
    reti ; rjmp WDT ; Watchdog Timer Handler
    nop
....

vielleicht bemerkst du den kleinen aber feinen Unterschied zwischen rjmp 
und jmp und warum bei der Version für den Mega168 nach einem reti 
jeweils ein nop stehen muss.

Damit, dass man auf einigen AVR mit einem rjmp nicht den kompletten 
Speicher erreichen kann, hat das ganze nur insofern zu tun, dass bei dem 
einen Controller (im Beispiel ein Mega48) der weiterführende rjmp an der 
Adresse 0x002 im Speicher steht, während er beim größeren Mega168 an der 
Adresse 0x004 im Speicher erwartet wird. Und das, obwohl beide 
Prozessoren ansonsten den gleichen Aufbau und die gleiche Reihenfolge 
der Interrupt Vektoren haben. Die beiden Mega-Typen teilen sich sogar 
das gleiche Datenblatt.

Da man in den wenigsten Fällen wohl die komplette Interrupt Vektor 
Tabelle braucht, so wie im Falle des TO, ist die Version mit dem 
wenigsten Tippaufwand wohl die hier

...
.org 0x0000
     rjmp   RESET

.org ACIaddr
     rjmp   ANA_COMP

.org INT_VECTORS_SIZE
RESET:
     ....

ANA_COMP:
     ....
     reti

sie hat auch gleichzeitig den Vorteil, dass man sich damit von dem 
Unterschied des Aufbaus der Vektortabelle beim Mega48 und Mega168 gelöst 
hat. Durch den ORG kümmert sich der Assembler darum. Die Lösung 
funktioniert auf Mega48 und Mega168 gleichermassen. Und wenn es bei 
einem Mega168 mal der Fall sein sollte, dass der RJMP nicht weit genug 
reicht, dann teilt einem das der Assembler mit und man ersetzt einfach 
den rjmp durch einen jmp, ohne sich um weiteres kümmern zu müssen.

Zudem ist man von der Reihenfolge der Interrupt Vektoren befreit. Selbst 
ein

...
.org 0x0000
     rjmp   RESET

.org ACIaddr
     rjmp   ANA_COMP

.org INT0addr
     rjmp   EXT_INT0

.org INT1addr
     rjmp   EXT_INT1

.org INT_VECTORS_SIZE
RESET:
     ....

mündet in einer korrekt aufgebauten Interrupt Vektor Tabelle, obwohl ich 
die einzelnen Vektoren in einer ganz anderen Reihenfolge im Code 
aufgeführt habe, als sie hinterher im Speicher stehen werden bzw. als 
sie im Datenblatt aufgeführt sind.