Schwierigkeiten mit den externen Interrupts vom Atmega328p

[Laie Jonas (Gast)]

Ich versuche schon seit heute morgen mein Programm zum laufen zu bringen 
und mir sind mittlerweile die Möglichkeiten ausgegangen.
Ich möchte lediglich eine Led mit einem Taster ansteuern und dass über 
einen Interrupt (Ich weiß dass es eigentlich Sinnlos ist mit dem 
Interrupt).

Ich habe bereits viele Seiten abgeklettert, aber keins der Beiträge 
konnte mein Problem lösen.
Nicht einmal dieser hier: 
Beitrag "Externer Interrupt - ATmega328P - Assembler"
Dass es nicht funktioniert hat nichts mit meinem uC zu tun, denn ich 
teste die Programme immer zu erst mit dem AVR Simulator und auch da wird 
der INT0 nicht einmal angesprungen.

Vielleicht kann mir ja jemand helfen ^^

.equ XTAL = 16000000 ;16 mHz

.equ BTN  = 2 ;Pinnumber of PORT_D
.equ LED  = 3 ;Pinnumber of PORT_D

.def temp1 = r16
.def temp2 = r17

.MACRO store
  .if  @0>0x3F
    sts  @0, @1
  .else
    out  @0, @1
  .endif
.ENDMACRO


.org 0x000
  rjmp init
  rjmp int_0

.org 0x032
  reti
init:
  ;Init stackpointer
  ldi temp1, HIGH(RAMEND)
  out SPH,   temp1
  ldi temp1, LOW(RAMEND)
  out SPL,   temp1

  ;Set led pin to output
  ldi temp1, (1 << LED)
  out DDRD, temp1

  ldi   temp1, (1 << ISC01)|(1 << ISC01) ;INT0 bei steigender Flanke
  store EICRA, temp1
  ldi   temp1, (1 << INT0) ;Nur INT0 aktivieren
  store EIMSK, temp1
  ;ldi     temp1, 0b00000001 ;Keine Ahnung welchen Zweck die ext. int. Flag Register erfüllen
    ;store   EIFR, temp1
  sei ;Interrupts generell zulassen

main_loop:
  rjmp main_loop

int_0:
        ;save SREG
  push  temp1
  in    temp1, SREG
  push  temp1

  ldi   temp1, (1 << LED)
  out   PORTD, temp1

  ;restore SREG
  pop   temp1
  out   SREG, temp1
  pop   temp1
  reti

[Peter (Gast)]

Vielleicht versuchst du es erstmal in c und dann in Assembler

[Laie Jonas (Gast)]

Peter schrieb:
> Vielleicht versuchst du es erstmal in c und dann in Assembler

Wie oft muss ich das den noch gesagt bekommen.
C löst meine Probleme auch nicht!
Ich bringe mir bewusst Assembler bei, da ich die internen Abläufe einer 
MCU verstehen möchte.

[Peter D. (peda)]

Laie Jonas schrieb:
> C löst meine Probleme auch nicht!

C nimmt zumindest den richtigen Interruptvector.

[MerryXmas (Gast)]

>ldi   temp1, (1 << ISC01)|(1 << ISC01)

Wahrscheinlich meinst Du:

ldi   temp1, (1 << ISC01)|(1 << ISC00)

Solche Schludereien krass nix gut beim Proggen.

[Laie Jonas (Gast)]

MerryXmas schrieb:
>>ldi   temp1, (1 << ISC01)|(1 << ISC01)
>
> Wahrscheinlich meinst Du:
>
> ldi   temp1, (1 << ISC01)|(1 << ISC00)
>
> Solche Schludereien krass nix gut beim Proggen.

Das ist schon besser, genau.
Aber es klappt dennoch nicht :/

[MerryXmas (Gast)]

>  rjmp init
>  rjmp int_0

Da sind zwei "r" zuviel.

[Laie Jonas (Gast)]

MerryXmas schrieb:
>>  rjmp init
>>  rjmp int_0
>
> Da sind zwei "r" zuviel.

Ist in meinem Fall aber nicht Nötig

[Laie Jonas (Gast)]

Bzw. doch habe ich so eben herausgefunden.

[Laie Jonas (Gast)]

Hier noch mal ein Anhang.
Darauf ist zu erkennen, dass der PIN_2 von PORT_D (von mir) auf HIGH 
geschaltet wurde und dennoch wird kein Interrupt ausgelöst.

> MerryXmas schrieb:
>>>  rjmp init
>>>  rjmp int_0
>>
>> Da sind zwei "r" zuviel.
Das habe ich jetzt auch korrigiert.
Noch irgendeine Idee?

[Heiligenacht (Gast)]

MerryXmas schrieb:
> rjmp init
>  rjmp int_0
>
> Da sind zwei "r" zuviel.

Ich würde sagen ein nop zu wenig.

[MerryXmas (Gast)]

>Noch irgendeine Idee?

Nein. Habe es gerade im Simulator getestet. Bei mir funktioniert es.

[Peter (Gast)]

Laie Jonas schrieb:
> Peter schrieb:
> Vielleicht versuchst du es erstmal in c und dann in Assembler
>
> Wie oft muss ich das den noch gesagt bekommen.
> C löst meine Probleme auch nicht!
> Ich bringe mir bewusst Assembler bei, da ich die internen Abläufe einer
> MCU verstehen möchte.

Das ist lobenswert. Aber wie man sieht wohl einfach etwas viel für den 
Anfang. Außerdem kannst du dir wenn du es in c machst ja parallel den 
Assembler Code anschauen den der Compiler ausspuckt.

[Michael U. (amiga)]

Hallo,

Laie Jonas schrieb:
> ;ldi     temp1, 0b00000001 ;Keine Ahnung welchen Zweck die ext. int.
> Flag Register erfüllen
>     ;store   EIFR, temp1

nur wegen der Frage: damit wird das Interrupt-Flag zurückgesetzt.
Das wird gesetzt, wenn der Interruot ausgelöst wird und vom Aufruf der 
Interruptroutine autimatisch wieder gelöscht. Es gibt auch Interrupts, 
wo das nicht automatisch passiert, das Datenbaltt weiß, welche.

Hir wird es gelöscht, um einfach sicherzustellen, daß es am Anfang 
gelöscht ist. Es wird von der Hardwrae ja auch dann gesetzt, wenn die 
Interrupts global noch gesperrt sind. Das kann dann ja nach Programm 
durchuaus ungewollte Ergebinsse bringen.
Man kann ja auch den Interrupt global gesperrt haben und fragt z.B. das 
Flag selber ab, ob ein Interrupt erzeugt wird.
Kann durchaus in einigen Fällen auch Sinn machen.

Programmanfang sah bei mir immer so aus:

.include "m16def.inc"

.include "Definitionen.inc"

;****************************** Verktor-Liste ****************************
.CSEG
                rjmp    reset

.org INT1addr  ;External Interrupt1 Vector Address
                rjmp  irq_rds

.org OC1Aaddr  ;Output Compare1A Interrupt Vector Address
                rjmp  irq_timer


;****************************** Programm-Beginn **********************

;*********************************************************************
;  Initialisierungsroutine
;*********************************************************************
; Hardware initialisieren

.org  INT_VECTORS_SIZE

reset:  ldi     TEMP_A,low(RAMEND)     ; Stack an das interne Ram-Ende
        out     SPL,TEMP_A
        ldi     TEMP_A,high(RAMEND)
        out     SPH,TEMP_A

wenn man jetzt den Prozessor wechselt, muß man kaum was anpassen.
Die Reihenfolge, in der man die Vectoren einträgt, ist egal.
Man kann auch einfach RETI eintragen, um einen Aufruf abzufangen, der 
noch nicht fertig ist. Oder auch rjmp statt jmp...

Definitionen.inc enthält bei generell die Beschreibungen der benutzten 
Pins als Kommentar, dazu den ganzen .equ Kram meiner eigenen Pin-, 
Register, Ram-Adressennamen usw.

So kann man das gut "recyclen" und ich kann es auch nach 10 Jahren noch 
enträtseln, was uch da verzapft habe...

Gruß aus Berlin
Michael

[Thomas F. (igel)]

Laie Jonas schrieb:

> .org 0x032
>   reti
> init:


Besser ist:

.cseg
init:

[Marc V. (Firma: Vescomp) (logarithmus)]

Laie Jonas schrieb:
> Vielleicht kann mir ja jemand helfen ^^

 Und was genau soll deine INT-routine machen ?

  ldi   temp1, (1 << LED)
  out   PORTD, temp1

 Da wird, je nach Beschaltung, die LED ein einziges mal entweder
 ein- oder ausgeschaltet und das wars dann.

 Wenn die LED falschrum angeschlossen ist, wird sie nicht einmal
 aufleuchten.

[Dieter F. (Gast)]

Laie Jonas schrieb:
> ldi   temp1, (1 << ISC01)|(1 << ISC01) ;INT0 bei steigender Flanke

Mit 2 mal ISC01 ist das = "fallender Flanke" - da kannst Du den Pin 
setzten, bis es Ostern wird :-)

[Peter D. (peda)]

MerryXmas schrieb:
> Da sind zwei "r" zuviel.

Bzw. anders gesagt, das rjmp wird auf dem falschen Interruptvektor 
plaziert, da ein rjmp kürzer ist, als der Abstand der Vektoren.
Die saubere Lösung ist daher, mit der .org Anweisung immer die richtige 
Adresse zu erzwingen. Dann wäre es auf dem ATmega88 und auf dem 
ATmega328 lauffähig.
Mit Assembler muß man viel sorgfältiger und disziplinierter als mit C 
programmieren.

[Peter D. (peda)]

Laie Jonas schrieb:
> C löst meine Probleme auch nicht!

Das ist aber sehr weit aus dem Fenster gelehnt. Du hast ja keine C-Code 
gepostet, den man reviewen könnte.

Peter schrieb:
> Aber wie man sieht wohl einfach etwas viel für den
> Anfang.

Den Eindruck habe ich auch. Man baut damit nur noch weitere Fehler ein, 
anstatt sich besser auf das eigentliche Problem zu fokussieren.
Abgesehen davon, daß es hier mehr C-Experten gibt.

[Dieter F. (Gast)]

Ich bin jetzt kein Assembler-Freak - aber so sollte es funktionieren 
(zumindest im Simulator, da prellt nichts ...):

.equ XTAL = 16000000 ;16 mHz

.equ BTN  = 2 ;Pinnumber of PORT_D
.equ LED  = 3 ;Pinnumber of PORT_D

.def temp1 = r16
.def temp2 = r17

.MACRO store
  .if  @0>0x3F
    sts  @0, @1
  .else
    out  @0, @1
  .endif
.ENDMACRO

;Address Labels Code Comments
.org 0x0000 jmp RESET      ; Reset Handler
.org 0x0002 jmp EXT_INT0    ; IRQ0 Handler

RESET: 
  ldi r16, high(RAMEND)    ; Main program start
  out SPH,r16      ; Set Stack Pointer to top of RAM
  ldi r16, low(RAMEND)
  out SPL,r16


init:
  ;Set led pin to output
  ldi temp1, (1 << LED)
  out DDRD, temp1

  ldi   temp1, (1 << ISC00)|(1 << ISC01)  ;INT0 bei steigender Flanke
  store EICRA, temp1
  ldi   temp1, (1 << INT0)    ;Nur INT0 aktivieren
  store EIMSK, temp1

  sei          ;Interrupts generell zulassen


main_loop:
  rjmp main_loop





EXT_INT0:
  ;save SREG
  push  temp1
  in    temp1, SREG
  push  temp1

  sbi   PIND, LED            ; PIN 2 von Port D togglen

  ;restore SREG
  pop   temp1
  out   SREG, temp1
  pop   temp1
  reti

[Laie Jonas (Gast)]

Dieter F. schrieb:
> Ich bin jetzt kein Assembler-Freak - aber so sollte es funktionieren
> (zumindest im Simulator, da prellt nichts ...):

Das ist genau der gleiche Code den ich bei mir verwende (Nach der 
Korrektur natürlich).
Leider scheint auch das nicht bei mir zu funken.
Wenn es bei dir und @MerryXmas funktioniert, dann stimmt wohl etwa nicht 
mit meiner AVR-Studio Version (Erst kürzlich heruntergeladen).

[Dieter F. (Gast)]

Laie Jonas schrieb:
> Leider scheint auch das nicht bei mir zu funken.

Fällt mir schwer, das nachzuvollziehen.

Laie Jonas schrieb:
> Wenn es bei dir und @MerryXmas funktioniert, dann stimmt wohl etwa nicht
> mit meiner AVR-Studio Version (Erst kürzlich heruntergeladen).

Ich verwende die aktuelle Atmel Studio 7 Version (7.0.1931). Mit meiner 
Version funktioniert es prima (im Simulator).

[Oliver S. (oliverso)]

Mit deinem Studio wird schon alles stimmen. Das verhält sich 
grundsätzlich seltsam bei Interrupts.

Setz mal in die ISR einen Breakpoint, um setze den Eingang per 
Stimuli-File.

Oder probier es gleich auf der echten Hardware. Wenn die led leuchtet, 
hat es geklappt.

Oliver

[Laie Jonas (Gast)]

Ich habe es jetzt mal mit dem Beispielprogramm vom Tutorial getestet:
https://www.mikrocontroller.net/articles/AVR-Tutorial:_Interrupts#Beispiel

Wahnsinn, auch hier wird bei mir im AVR Simulator nicht in die Int. 
Vektor Tabelle gesprungen.
Die Endlosschleife läuft einfach weiter.
...

[Laie Jonas (Gast)]

Oliver S. schrieb:
> Oder probier es gleich auf der echten Hardware. Wenn die led leuchtet,
> hat es geklappt.

Es hat geklappt.
Nach mehrmaliger Fehlkorrektur hatte ich es einfach sein gelassen es auf 
echter Hardware zu testen und habe einfach den Simulator benutzt.

[Ben B. (Firma: Funkenflug Industries) (stromkraft)]

Also ich probiere es immer auf der echten Hardware. Den Simulator 
benutze ich nur, wenn ich wissen möchte, was intern mit den Registern 
passiert, bzw. wenn irgendwelche Stringfunktionen baue oder der berühmte 
Dauerbrenner Umwandlung von Zahlen oder "irgendwas von und nach ASCII".

Ich finde auch nicht, daß das zu schwer oder zuviel für den Anfang ist. 
Eine LED leuchten lassen ist irgendwann geschafft, ein "Hallo Welt!" auf 
einem Display ist irgendwann geschafft - und dann gibt es immer was 
neues, was sich auszuprobieren und zu lernen lohnt. Dabei gibts 
natürlich auch neue Fehler zu machen, neue Probleme und neue Fragen. 
Finde ich völlig normal so.

Muss aber dazu sagen, daß ich schon Erfahrung mit Assembler vom x86 
hatte. Und der hat die deutlich besseren Debugger, was die Bedienung 
angeht. Der muss aber keine extra Hardware beherrschen, vielleicht 
liegt's daran.

Lass Dich von den C-Fanboys hier nicht unterkriegen. Assembler auf dem 
AVR ist cool und macht Spaß. Beim PIC könnte ich verstehen wenn man sagt 
C ist besser. Der bietet nur sehr wenige Befehle und keinen großen 
Registersatz wie der AVR, das braucht man aber, um mit Assembler Spaß 
dran zu haben. Ich programmiere gerade meine AlarmSau in Assmbler, das 
sind derzeit etwa 120kb Quellcode, um die 4300 Befehle... da fängt's 
erst an, so richtig Spaß zu machen.

[Laie Jonas (Gast)]

Ben B. schrieb:
> Finde ich völlig normal so.

danke

Ben B. schrieb:
> Ich programmiere gerade meine AlarmSau in Assmbler, das
> sind derzeit etwa 120kb Quellcode, um die 4300 Befehle...

Mit welchen uC?

[MerryXmas (Gast)]

>Wahnsinn, auch hier wird bei mir im AVR Simulator nicht in die Int.
>Vektor Tabelle gesprungen.
>Die Endlosschleife läuft einfach weiter.

Hm... very komische Sache.

Stimmt die Controller-Einstellung im Simulator? Nicht, dass von Dir 
unbemerkt ein ATmega48 simuliert wird oder so (alles schon dagewesen...)
Menüpunkt Debug, Untermenü "Check platform and device"

Normalerweise müsste im Simulator sofort (einen Maschinentakt später) 
das Bit INTF0 im EIFR gesetzt werden, wenn Du PIND2 von 0 auf 1 änderst. 
Passiert das?

Und was ist, wenn Du PIND in Ruhe lässt, aber INTF0 von Hand setzt? Wird 
dann der Interruptvektor int_0 angesprungen?

Kannst Du beides noch testen, bitte?

[Ben B. (Firma: Funkenflug Industries) (stromkraft)]

>> Ich programmiere gerade meine AlarmSau in Assmbler
> Mit welchen uC?

ATMega1284P. (und ATMega88 für's Terminal).

[Laie Jonas (Gast)]

MerryXmas schrieb:
> Stimmt die Controller-Einstellung im Simulator? Nicht, dass von Dir
> unbemerkt ein ATmega48 simuliert wird oder so (alles schon dagewesen...)
> Menüpunkt Debug, Untermenü "Check platform and device"
>
> Normalerweise müsste im Simulator sofort (einen Maschinentakt später)
> das Bit INTF0 im EIFR gesetzt werden, wenn Du PIND2 von 0 auf 1 änderst.
> Passiert das?
>
> Und was ist, wenn Du PIND in Ruhe lässt, aber INTF0 von Hand setzt? Wird
> dann der Interruptvektor int_0 angesprungen?

Hatte ich bereits alles getestet und der das Bit INTF0 im EIFR wird auch 
richtig gesetzt, wenn es zum Interrupt kommt.
Aber angesprungen wird die Int. Tabelle dennoch nicht :/

Ben B. schrieb:
>>> Ich programmiere gerade meine AlarmSau in Assmbler
>> Mit welchen uC?
>
> ATMega1284P. (und ATMega88 für's Terminal).

Sieht sehr interessant aus.
Wusste gar nicht, dass es so große Elkos gibt :D
Hab auch deinen Beitrag dazu entdeckt: 
Beitrag "ambitioniertestes Lochraster-Projekt (und meine AlarmSau)"

[Ben B. (Firma: Funkenflug Industries) (stromkraft)]

Gibt noch viel größere Elkos... :) Der größte den ich hier habe, hat 
6800µF bei 400 oder 450V, der passt aber nicht so gut auf die Platine. 
Gibt auch welche im Stahlblechgehäuse für industrielle Anwendungen, da 
sind der Größe keine Grenzen gesetzt.