Forum: Compiler & IDEs Reset bei Int0 Interrupt (Interruptvektor falsch?)


von Wolfram Hildebrandt (Gast)


Angehängte Dateien:

Lesenswert?

Hallo

Ich möchte in C durch eine Flanke an INT0 eines Mega8 einen Interupt 
auslösen.
Die Hardware löst einen Interupt aus, jedoch wird dann sofort ein Reset 
ausgeführt.
Im Dissassembler steht bei Vector 1, dem INT0-Vektor keine konkrete 
Adresse, sondern eine auf den Programm Pointer bezogene eingetragen z.B. 
PC+0x002C.

Der Interupt INT0 lässt sich durch sein Enable Bit verhindern. Der Reset 
kommt dann nicht.
Ich denke, an Adresse 1 im Programmspeicher müsste die genaue Adresse 
der ISR stehen. Das tut sie aber wohl nicht.
In anderen Programmen habe ich auch die Anweisung PC+0x002C noch nicht 
in den  Interuptvektoren gesehen. Diese waren immer 0x000049 o.ä.

Ich habe das Interuptproblem in ein AVR Studio Projekt gepackt.
Kann das mal jemand compilieren?

Springt der AVR wieder zum Anfang, weil er keine konkrete ISR-Adresse 
bekommt?

von inoffizieller WM-Rahul (Gast)


Lesenswert?

>sondern eine auf den Programm Pointer bezogene eingetragen z.B.
>PC+0x002C

Das liegt ja auch daran, dass rjmp benutzt wird, was grundsätzlich nur 
Sprünge relativ zum Program Counter macht...
Jetzt wäre interessant, was denn an Adresse 0x2D (oder 0x2E?) 
passiert...
Laut deinem C-Quellcode sollte da irgendwas mit OUT oder so stehen (IN, 
OR, OUT...).

von Wolfram Hildebrandt (Gast)


Lesenswert?

Hallo

Er soll zu PC+0x002C springen.
Der PC hat aber immer einen anderen Wert. Die ISR-Adresse müsste doch 
darin stehen, oder?
Ich hatte gestern danach noch einaml die neueste Version von WINAVR 
installiert. Damit hing sich AVRStudio aber immer auf und jetzt ist 
wieder die Version 20050214 auf meinem System.
avr-gcc -v meldet Version 3.4.3

Muss ich da etwas mit Signal machen wegen alter Versionen?

Kann jemand vielleicht mal einen Int0 Testcode tippen, der in Vector1 
eine feste Adresse hieneinschreibt?
Oder ist der rjmp mit PC+X normal?

Im Anhang ist das Dissassembling der ISR.

von Wolfram Hildebrandt (Gast)


Angehängte Dateien:

Lesenswert?

Das Bild wurde nach der Vorschau nicht übertragen. Hier ist es.

von inoffizieller WM-Rahul (Gast)


Lesenswert?

Klar hat der PC immer einen anderen Wert.
Der wird jedes mal geändert, wenn ein Befehl abgearbeitet wurde.
Im Falle des ISR-Vectors befindet er sich beim nächsten "rjmp".
Von dort aus 0x2C Schritte weiter befindet sich ja auch die 
entsprechende ISR, wie man an deinem Bild wunderschön erkennen kann 
(hatte mich verrechnet...).
Dein Reset scheint (meiner Meinung nach) woanders her zu kommen.

von André K. (freakazoid)


Lesenswert?

Kann das sein, daß alle IRQ-Vektoren auf die gleiche Adresse zeigen?

0001: rjmp PC+002C -> 2d
0002: rjmp PC+002B -> 2d
...
002d: rjmp PC-002D -> 00 (Resetvektor)

Also wie ich das sehe, wird deine ISR überhaupt nicht angesprungen,
sondern direkt der Resetvektor  ...

Grüße, Freakazoid


von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

> Kann das sein, daß alle IRQ-Vektoren auf die gleiche Adresse zeigen?

Auf den Default-Vektor.  Dann ist wohl kein einziger Interruptvektor
installiert worden.  Der Default-Vektor springt zur Adresse 0, sieht
im Ergebnis also einem Reset sehr ähnlich.

Wenn ich das Ganze bei mir compiliere, wird der Interruptvektor für
den Externinterrupt 0 (der erste nach dem Reset) aber sehr wohl
ausgefüllt.  Allerdings habe ich 1. kein AVR Studio, compiliere das
also mit der Hand, und 2. ließ sich das Ganze so nicht compilieren,
da das #include "main.h" gefehlt hat.  Das legt also nahe, dass der
offierte Sourcecode irgendwie nicht zum Rest passt.

von André K. (freakazoid)


Lesenswert?

> Auf den Default-Vektor.  Dann ist wohl kein einziger Interruptvektor
> installiert worden.  Der Default-Vektor springt zur Adresse 0, sieht
> im Ergebnis also einem Reset sehr ähnlich. Das mein ich ja. Hab mich wohl 
schlecht ausgedrückt ;-)

Grüße, Freakazoid

von Wolfram Hildebrandt (Gast)


Lesenswert?

Das Problem war die ISR. Mit SIGNAL ging das Ganze.
Jetzt wird der Pin gesetzt, aber irgendwie bin ich damit noch nicht 
zufrieden.
Ich habe ein Handy-Display zusätzlich angeschlossen, die 
Displayschreibroutinen laufen jedoch nicht aus dem Interrupt heraus.
Ich habe alle Variablen als volatile deklariert.
Hin und wieder werdenneben dem Portsetzen, auch noch ein oder zwei Pixel 
gezeichnet.
Was muss ich beim Funktionsaufruf besonderes beachten?

@Freakazoid: bei mir ist die main included. Komisch.
AVR Studio zeigt auch bei der lauffähigen Interruptvaraiante immer noch 
diese relativen rjmp-Adressen an.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

> Das Problem war die ISR. Mit SIGNAL ging das Ganze.

Dann hast du 'ne zu alten Version der avr-libc (1.2.x, aktuell ist
1.4.5).

> die
> Displayschreibroutinen laufen jedoch nicht aus dem Interrupt heraus.

Sowas macht man nicht.  Interruptroutinen möglichst kurz halten.

> bei mir ist die main included.

Nicht in dem Zip-File, das du in deinem ersten Beitrag hast.  Dann
hast du da irgendwas zusammengewickelt, was nicht deinem Arbeitsstand
entspricht.

> AVR Studio zeigt auch bei der lauffähigen Interruptvaraiante immer noch
> diese relativen rjmp-Adressen an.


Dafür heißt es ja auch *r*jmp.

von peter (Gast)


Lesenswert?

Tip:

Bringe deine Software auf den neusten Stand: AvrStudio (SP4, Build-498) 
und WinAVR (WinAVR-20060421.) Sonst stolperst Du noch über alte 
Probleme, die schon längst gelösst sind! Dann funktioniert auch ISR() 
anstelle des längst nicht mehr aktuellen SIGNAL()

MfG  Peter

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
Noch kein Account? Hier anmelden.