PIC - kann sich die ISR selbst unterbrechen?

[A. S. (rava)]

guten abend,

heute habe ich eine ziemliche Grundlagenfrage dabei.

ich nutze eine einzige ISR in meinem PIC Programm. Wird diese 
aufgerufen, fragt sie alle möglichen Interrupt flags der Reihe nach ab

void interrupt high_priority ISR_highPriority()
{
    if(INTCONbits.INT0F == 1)
    {
        INTCONbits.INT0F = 0;
        Int0_Code();
    }


    if(PIR5bits.TMR5IF == 1)
    {
        PIR5bits.TMR5IF = 0;                    // clear interrupt flag
        Timer5_Code();
    }
...
}

nun liest man ja im Datenblatt allerhand über Prioritäten von 
Interrupts. Im Quelltext gibt es aber nur eine einzige Routine.

Nun meine Fragen:
- kann sich die Routine selbst unterbrechen? Also wenn z.B. timer 5 
zündet und er den entsprechenden quelltext abarbeitet und dann eine 
Flanke an INT0 auftaucht. Wird dann eine neue ISR gestartet? Oder wird 
die ISR erst dann gleich nochmal gestartet, wenn der alte Aufruf 
durchgelaufen ist?
- was wenn gerade der INT0-Bereich abgearbeitet wird und währenddessen 
der timer 5 alarm schlägt? Da ich kein return am Ende des 
INT0-Quelltexts habe, könnte derselbe ISR-Aufruf direkt in die 
timer5-routine laufen. Das wäre ja nicht weiter tragisch, aber gibt's 
dann danach noch einen zweiten ISR-Aufruf, in dem nichts mehr passiert?

dank euch...
lg

[Meister E. (edson)]

Nein. Beim Eintritt in die ISR wird GIE von der CPU zurückgesetzt und 
erst wieder gesetzt wenn ein retfie ausgeführt wurde.

Ein High-Priority-Interrupt kann aber die Low-Priority ISR unterbrechen.

[Meister E. (edson)]

A. S. schrieb:
> Nun meine Fragen:
> - kann sich die Routine selbst unterbrechen? Also wenn z.B. timer 5
> zündet und er den entsprechenden quelltext abarbeitet und dann eine
> Flanke an INT0 auftaucht. Wird dann eine neue ISR gestartet? Oder wird
> die ISR erst dann gleich nochmal gestartet, wenn der alte Aufruf
> durchgelaufen ist?

Letzteres.

> - was wenn gerade der INT0-Bereich abgearbeitet wird und währenddessen
> der timer 5 alarm schlägt? Da ich kein return am Ende des
> INT0-Quelltexts habe, könnte derselbe ISR-Aufruf direkt in die
> timer5-routine laufen. Das wäre ja nicht weiter tragisch, aber gibt's
> dann danach noch einen zweiten ISR-Aufruf, in dem nichts mehr passiert?

Es wird so laufen, wie du schon selber geschrieben hast. Am Ende der ISR 
sind beide Flags gelöscht und es gibt keine erneute Unterbrechung wenn 
das GIE wieder freigegeben ist.

> dank euch...
> lg

Edit: Im vorigen Post habe ich die Assembler-Instruktion retfie 
angesprochen, die du möglicherweise gar nicht kennst weil das der 
C-Compiler für dich erledigt. Dieser Befehl kennzeichnet das Ende einer 
ISR und bringt die CPU wieder in den "normalen Modus" zurück.

[Carsten M. (ccp1con)]

Das alles hängt natürlich auch davon ab, von welchem PIC hier die Rede 
ist!?
Manche haben nur eine ISR andere zwei (high and low priority) und manche 
haben für jede int source eine eigene mit eigenen Prioritäten.

[A. S. (rava)]

Carsten M. schrieb:
> Das alles hängt natürlich auch davon ab, von welchem PIC hier die Rede
> ist!?

sorry, vergessen
PIC18F46K22

wenn ich versuche, eine low_priority und eine high_priority ISR zu 
schreiben, nörgelt der Compiler

[Carsten M. (ccp1con)]

Hängt auch wieder vom Compiler ab. :-)
Aber mit XC8 sollte das gehen

void interrupt high_priority your_ISR(void)
{
}

void interrupt low_priority your_low_ISR(void)
{
}

[Max H. (hartl192)]

Vergiss nicht die Prioritäten auch zu aktivieren (RCON.IPEN)

[Carsten M. (ccp1con)]

und
INTCONbits.GIEH = 1;
INTCONbits.GIEL = 1;

[Meister E. (edson)]

Carsten M. schrieb:
> Das alles hängt natürlich auch davon ab, von welchem PIC hier die Rede
> ist!?

Tut es nicht. Ein einziger Blick auf den vom TE geposteten Code reicht 
übrigens aus um zu sehen, dass es sich um PIC18 handelt.

> Manche haben nur eine ISR andere zwei (high and low priority) und manche
> haben für jede int source eine eigene mit eigenen Prioritäten.

Meine Antworten stimmen sowohl für PIC mit nur einem Interrupt als auch 
für PIC18 mit seinen zwei Interrupt-Vektoren.

[Carsten M. (ccp1con)]

Hat jemand gesagt, dass deine Antworten nicht stimmen?
Chill mal ..

[Meister E. (edson)]

Carsten M. schrieb:
> Hat jemand gesagt, dass deine Antworten nicht stimmen?
> Chill mal ..

Hallo? Ich habe nicht gepostet um mich zu rechtfertigen sondern um hier 
ein paar eindeutige und richtige Angaben zu ergänzen. Für den TE, der 
die Frage gestellt hat. Du wurdest zitiert weil deine Aussage nicht 
stimmt, das muss man in einem Fachforum schon aushalten können, Carsten.

[Carsten M. (ccp1con)]

Ja gut ... halte ich aus.