externer Interrupt an PIC18

[Unterbrecher (Gast)]

hallo,

ich arbeite mit einem PIC18LF25K50 MPLABX v2.25 und C18 Compiler 
(v.3.47).
Ich lese von einem externen Device den Status an RB2 aus. Hierfür möchte 
ich gerne den externen Interrupt 2 an RB2 nutzen. Der Interrupt soll bei 
ansteigender Flanke Triggern, d.h. wenn ich der Pin von LOW auf HIGH 
wechselt. RB2 habe ich als Input deklariert. Das ganze sieht in etwa wie 
folgt aus:

#pragma interrupt extern_interrupt
void extern_interrupt(void) {

    if(INTCON3bits.INT2IF)
    {
        // tue irgendetwas
        INTCON3bits.INT2IF = 0;     // cleare Interrupt Flag wieder, damit dieser wieder ausgelöst werden kann
    }
    
}
#pragma code

void main(void) {
...

 // interrupts / USART interrupts configuration
    RCONbits.IPEN   = 0;    // disable interrupt priority
    INTCONbits.GIE  = 1;    // enable interrupts
    INTCONbits.PEIE = 1;    // enable peripheral interrupts.
    PIE1bits.RCIE   = 1;    // enable USART receive interrupt
    PIE1bits.TXIE   = 0;    // disable USART TX interrupt
//    PIR1bits.RCIF = 0;    // make sure the RX flag is clear

    TRISBbits.TRISB2 = 1;       // Input
    INTCON3bits.INT2IE = 1;     // Enables the INT2 external interrupt
    INTCON3bits.INT2IF = 0;     // Internal 2 external interrupt Flag bit zurücksetzen
    INTCON2bits.INTEDG2 = 1;    // INT2 bei ansteigender Flanke, d.h. er triggert wenn er von LOW auf HIGH
}

Ich nutze also noch gleichzeitig den UART Interrupt, dieser funktioniert 
tadellos.

Wenn ich jetzt debugge und sehe dass sich  der Status an RB2 ändert wird 
jedoch Nie die Interruptroutine ausgelöst. Woran kann dies liegen?
Was fällt auf?

Danke

[Stampede (Gast)]

Sind die Analogfuntkionen am RB2 deaktiviert? ANSELB Regstier sollte das 
sein.

[Unterbrecher (Gast)]

Stampede schrieb:
> Sind die Analogfuntkionen am RB2 deaktiviert? ANSELB Regstier
> sollte das
> sein.

Jop, habe ich vergessen dazuzuschreiben:

 ANSELB = 0x00;

Daran kann es also nicht liegen, aber guter Hinweis!

[Witkatz :. (wit)]

Für IOC wird der Inhalt des PORTB mit dem gelatchten Wert der letzten 
Leseroutine verglichen. Vor dem Löschen des INT2IF sollte PORTB immer 
gelesen (oder geschrieben) werden.

Gruß
witkatz

[Unterbrecher (Gast)]

Witkatz :. schrieb:
> Für IOC wird der Inhalt des PORTB mit dem gelatchten Wert der
> letzten
> Leseroutine verglichen. Vor dem Löschen des INT2IF sollte PORTB immer
> gelesen (oder geschrieben) werden.
>
> Gruß
> witkatz

HMM ok,
habe es editiert:

void extern_interrupt(void) {

    if(INTCON3bits.INT2IF)
    {
        PORTBbits.RB2;    // Lese den Wert immer bevor Flag Bit gelöscht
        INTCON3bits.INT2IF = 0;
    }
    
}

Dies dürfte aber nicht der Grund dafür sein, dass die Interruptroutine 
gar nicht erst auslöst. Habe RB2 einmal als Output gesetzt und dann über 
Latch Register den Eingang manuell von LOW auf HIGH gezogen um zu testen 
ob der Interrupt dann auslöst. Ebenfalls ohne Erfolg!

[Volker S. (vloki)]

INT2 ist doch gar kein IOC.

Wie sehen denn die Pegel für high und low genau aus? (und was für VDD)

Der Code für RX und INT2 ist natürlich in der gleichen Routine, oder?

[Unterbrecher (Gast)]

Volker S. schrieb:
> INT2 ist doch gar kein IOC.
>
> Wie sehen denn die Pegel für high und low genau aus? (und was für VDD)
>
> Der Code für RX und INT2 ist natürlich in der gleichen Routine, oder?

VDD ist 3,3V
Ich habe den UART Interrupt jetzt erst einmal komplett auskommentiert, 
um wirklich nur den externen Interrupt zu testen. RB2 ist in der Tat ein 
EXT Interrupt (INT 2) Pin, d.h. KEIN Interruput on Change Pin -> IOC 
Register müßte demzufolge wegfallen.

Mich interessiert gerade nur warum der Interrupt nicht triggert, obwohl 
der Pin nachweislich von Low auf High gezogen wird!

[Witkatz :. (wit)]

Volker S. schrieb:
> INT2 ist doch gar kein IOC.

Sorry, mein Fehler.

Du könntest in main das INT2IF auf einem Testausgang ausgeben, um zu 
schauen ob das Flag gesetzt wird.

Ich bin mit C18 nicht so vetrtraut, aber sollte nicht vor dem #pragma 
interrupt der Funktionsprototyp void extern_interrupt(void); deklariert 
werden?

[Hagi (Gast)]

Stimmt auch das "Interrupt Priority" INTCON3bits.INT2IP ?

[Volker S. (vloki)]

Unterbrecher schrieb:
> VDD ist 3,3V

low = ?
high = ?

Hagi schrieb:
> Stimmt auch das "Interrupt Priority" INTCON3bits.INT2IP ?
Ist völlig egal, da IPEN = 0...

[Volker S. (vloki)]

Witkatz :. schrieb:
> Ich bin mit C18 nicht so vetrtraut, aber sollte nicht vor dem #pragma
> interrupt der Funktionsprototyp void extern_interrupt(void); deklariert
> werden?

Nein, nicht unbedingt. Leider fehlt der Teil im Post :-(
Im "compatibility mode" (nur eine Ebene/Vektor) muss man nur dafür 
sorgen, dass die Funkion an der richtigen Stelle steht.

#pragma interrupt extern_interrupt


#pragma code high_vector=0x0008
void extern_interrupt(void) {
...

Im "priority mode" kann ja am high-priority Vektor nur ein Sprung zur 
Funktion stehen. Dann braucht man den Prototyp. (wenn der Vektor nicht 
nach der Routine seht)

[Unterbrecher (Gast)]

Volker S. schrieb:

> #pragma code high_vector=0x0008


Daran scheint es gelegen zu haben. Wird hier die Prirität des Interrupts 
angegeben, obwohl ich diese enablet habe? Warum ist diese Zeile für die 
Funktion so wichtig?

Nutze ich für den UART und externen Interrupt jetzt am besten dieselbe 
ISR oder zwei verschiedene Interrupt Routinen schreiben?

[Witkatz :. (wit)]

Unterbrecher schrieb:
> Warum ist diese Zeile für die
> Funktion so wichtig?

C18 User's Guide Kap. 2.9.2.3 INTERRUPT VECTORS:
"MPLAB C18 does not automatically place an ISR at the interrupt vector."

[Volker S. (vloki)]

Puuuhhhh, ganz schön viele Fragen auf einmal;-)

Also die 0x0008 ist eine der beiden Adressen im Programmspeicher auf die 
gesprungen wird, wenn ein Interrupt ausgelöst wird. Da du den Priority 
Mode nicht aktiviert hast, ist es sogar die einzige Adresse.

An dieser Adresse muss jetzt ein Sprung zu deiner IR-Service Routine 
oder eben die Routine selbst stehen.
Somit kann es auch nur eine Funktion geben in der alle deine IRs 
abgearbeitet werden...

Etwas ausführlicher ist das Thema im Kapitel 5 von uC_Quick-X.pdf 
dargestellt. (google...)

Mit was programmierst du deinen PIC? PICKITx?

[Unterbrecher (Gast)]

Volker S. schrieb:
> Puuuhhhh, ganz schön viele Fragen auf einmal;-)
>
> Also die 0x0008 ist eine der beiden Adressen im Programmspeicher auf die
> gesprungen wird, wenn ein Interrupt ausgelöst wird. Da du den Priority
> Mode nicht aktiviert hast, ist es sogar die einzige Adresse.
>
> An dieser Adresse muss jetzt ein Sprung zu deiner IR-Service Routine
> oder eben die Routine selbst stehen.
> Somit kann es auch nur eine Funktion geben in der alle deine IRs
> abgearbeitet werden...

Super vielen Dank. Ich beschäftige mich erst seit kurzen mit Interrupts, 
deswegen ist jeder Input willkommen :)

Vielleicht noch eine Frage:
Wenn ich den PIC vorher in den Sleep Modus versetzt habe, wird der Pic 
wenn der externe Interrupt über RB2 ausgelöst wird dann automatisch aus 
dem Sleep Modus herausgeholt? Dies ist nämlich genau das, was ich 
realisieren möchte. Was anderes soll der externe Interrupt eigentlich 
nicht tun. Getestet habe ich dies nun wie folgt:

// start ISR code
#pragma interrupt isr   // let the compiler know that the function isr() is an interrupt handler
#pragma code isr = 0x08 // store the below code at address 0x08
void isr(void)
{

    Nop();
    Nop();

    if(INTCON3bits.INT2IF)
    {
        // bei Triggerung des externen Interrupts erwacht der Controller automatisch aus dem Sleep Modus
        INTCON3bits.INT2IF = 0;
    }

    if(PIR1bits.RCIF == 1)  // if the USART receive interrupt flag has been set
    {
        
            rx_char = getcUSART1();                             
        
    }
}


void main(void) {
...
#pragma code // return to the default code section
     // interrupts / USART interrupts configuration
    RCONbits.IPEN   = 0;    // disable interrupt priority
    INTCONbits.GIE  = 1;    // enable interrupts
    INTCONbits.PEIE = 1;    // enable peripheral interrupts.
    PIE1bits.RCIE   = 1;    // enable USART receive interrupt
    PIE1bits.TXIE   = 0;    // disable USART TX interrupt
//    PIR1bits.RCIF = 0;    // make sure the RX flag is clear

    TRISBbits.TRISB2 = 1;       // Input an RB2
    ANSELBbits.ANSB2 = 0;       // digitaler pin

    INTCON2bits.INTEDG2 = 1;    // INT2 bei ansteigender Flanke, d.h. er triggert wenn er von LOW auf HIGH
//    INTCON3bits.INT2IP = 1;     //High Priority
    INTCON3bits.INT2IE = 1;     // Enables the INT2 external interrupt
    INTCON3bits.INT2IF = 0;     // Internal 2 external interrupt Flag bit zurücksetzen
    INTCON2bits.INTEDG2 = 0;


...
while(1)
{
Sleep();    // Sleep Modus
}
}

[Volker S. (vloki)]

Unterbrecher schrieb:
> Vielleicht noch eine Frage:
> Wenn ich den PIC vorher in den Sleep Modus versetzt habe, wird der Pic
> wenn der externe Interrupt über RB2 ausgelöst wird dann automatisch aus
> dem Sleep Modus herausgeholt? Dies ist nämlich genau das, was ich
> realisieren möchte. Was anderes soll der externe Interrupt eigentlich
> nicht tun. Getestet habe ich dies nun wie folgt:

Ja, das sollte so sein ;-) Was ist bei deinem Test heraus gekommen?

[Unterbrecher (Gast)]

Der externe Interrupt löst wie gewünscht an RB2 aus. Leider funktioniert 
dann der UART Interrupt nicht mehr wie gewünscht :(
Ohne Sleep() Funktion läuft es einwandfrei.

Wie implementiert: Wird der PIC bei externen Interrupt immer aus dem 
Sleep Modus geholt? Ist dies richtig so? Gewollt ist:

1. Setze PIC in Sleep
2. Durch externen Interrupt PIC "awaken"
3. Wach bleiben und über UART Interrupt Daten einlesen
4. Wenn fertig PIC wieder in Sleep Modus setzen und auf externen 
Interrupt warten!

[Volker S. (vloki)]

In dem Test-Programm, das du gepostet hast, geht der PIC doch sofort 
wieder in den Sleep (wenn er aus dem Pin-IR zurück in main kommt)

[Unterbrecher (Gast)]

Is natürlich quatsch :)

Habe es jetzt wie folgt:

// start ISR code
#pragma interrupt isr   // let the compiler know that the function isr() is an interrupt handler
#pragma code isr = 0x08 // store the below code at address 0x08
void isr(void)
{

    if(INTCON3bits.INT2IF)
    {

        // bei Triggerung des externen Interrupts erwacht der Controller automatisch aus dem Sleep Modus
        INTCON3bits.INT2IF = 0;
    }

    if(PIR1bits.RCIF == 1) // if the USART receive interrupt flag has been set
    {
         Nop();
         Nop();
        
         rx_char = getcUSART1();  

        
    }
}
#pragma code // return to the default code section


void main(void) {
    
    ...

     // interrupts / USART interrupts configuration
    RCONbits.IPEN   = 0;    // disable interrupt priority
    INTCONbits.GIE  = 1;    // enable interrupts
    INTCONbits.PEIE = 1;    // enable peripheral interrupts.
    PIE1bits.RCIE   = 1;    // enable USART receive interrupt
    PIE1bits.TXIE   = 0;    // disable USART TX interrupt

    INTCON2bits.INTEDG2 = 1;    // INT2 bei ansteigender Flanke, d.h. er triggert wenn er von LOW auf HIGH
//    INTCON3bits.INT2IP = 1;     //High Priority
    INTCON3bits.INT2IE = 1;     // Enables the INT2 external interrupt
    INTCON3bits.INT2IF = 0;     // Internal 2 external interrupt Flag bit zurücksetzen
    INTCON2bits.INTEDG2 = 0;

    Sleep();   // gehe per default in Sleep Modus
    while(1)
    {
     // wenn Uart Verbindung beendet gehe wieder in Sleep Mode
     if(UART_END)
            Sleep();

}

Das scheint per Software schon einmal so zu funktionieren. Dumme Frage 
zum Schluß: Kann ich per Software kontrollieren, ob der PIC sich 
wirklich im Sleep Modus befindet oder ist dies nur meßtechnisch zu 
ermitteln? Habe leider nur nen Voltmeter und kein Oszi oder ähnliches 
hier.

[Noch einer (Gast)]

> ob der PIC sich wirklich im Sleep Modus befindet

Einfach schauen, wie schnell die Spannung sinkt, nachdem du das 
Netzgerät ausschaltest. Größenordnung - Ohne sleep() nicht mal eine 
Sekunde, mit sleep() 20 Sekunden.

[Unterbrecher (Gast)]

Hmm in dem Zeitintervall kann ich leider keinen großen Unterschiede im 
Sleep oder ohne Sleep entdecken. Die Spannung fällt innerhalb einer 
Sekunde auf 0,5V rapide ab und dann in etwa 10 Sec gegen 0V (sowohl im 
Sleep Mod als auch im "normalen" Modus).

Das ist natürlich sehr unprofessionell ohne Oszi aufgenommen.

[vloki (Gast)]

Warim sollte der pic nicht in den sleep gehen? Setz einfach einen 
Ausgang auf high nach dem Sleep und vor dem while.
Ob man das auch mit dem Debugger testen kann, weiss ich jetzt nicht...

[Noch einer (Gast)]

> keinen großen Unterschiede

Hmm... wer weiß, was das Netzgerät macht. Besser nur einen Elko 
entladen. Elko an die Pic-Platine und einen Schalter in die Zuleitung.

> Warim sollte der pic nicht in den sleep gehen?

Die Frage ist eher, bring es was? Wieso mit sleep() und Interrupts 
rumärgern, wenn da ein Spannungsteiler mehr Strom verbraucht, als der 
Controller.