Anfängerfrage - Kollision mehrer Interrupts

Wenn man einen wirklich schnellen jitterarmen Interrupt braucht, wirds 
auf den AVRs haarig.

Es gibt im Prinzip 3 Möglichkeiten:


1.
Man verzichtet auf sämtliche anderen Interrupts und pollt diese im Main


2.
Man enabled einen 2. Timerinterrupt, der sich selber stoppt und dann die 
Interrupts global freigibt.
Dieser pollt dann alle anderen Interruptquellen und ruft deren Handler 
auf.
D.h. diese Interrupts werden quasi virtuelle Interrupts, dürfen also 
nicht wirklich freigegeben werden.

Dadurch erreicht man folgendes:

Der gestoppte Timer kann sich nicht selber unterbrechen
Nur der schnelle Interrupt kann ihn unterbrechen.

Allerdings werden sämtliche anderen Interruptquellen maximal durch das 
gewählte Timerintervall verzögert.


3.
Du nimmst ne andere MC-Familie mit Prioritäten, z.B. AT89LP4051


Peter

@ snoopy

>a) schneller Interrupt durch Timer 0 -> Refresh etc
>b) langsamer Interrupt PCINT0

>Da a) höher priorisiert ist als b) wird a) ohne Unterbrechung
>ausgeführt.

Die Interruptroutinen werden auf dem AVR im allgemeinen immer ohne 
Unterbrechung ausgeführt, d.h eine Interruptroutine wird nicht von einem 
anderen Interrupt unterbrochen. Andere Prozessoren haben Prioritäten, da 
kann ein höherpriorisierter Interrupt einen nierderpriorisierten 
Iterrupt unterbrechen.
>Ist während der Ausführung von a) ein Interruptereignis b) aufgetreten,
>wird nach Abarbeitung von a) 1 Befehl des Hauptprogramms abgearbeitet
>und dann b) nachgeholt.

Ja.

>b) wird von a) beliebig unterbrochen.

Nein, nicht auf dem AVR. Man kann mit einigen Tricks das so hinbiegen, 
ist aber bisweilen schwierig.
MFG
Falk

Du musst wahrscheinlich einfach gar nichts weiter tun.  Lass dich von
den vielen ,,man kann das auch so und so machen''-Antworten mal nicht
zu sehr verwirren.  Beim AVR sind die Interrupts während der ISR
einfach gesperrt, damit läuft deine wichtige Routine immer bis zu
Ende durch.  Alle anderen Interrupts, die in dieser Zeit auftreten,
bleiben anhängig und werden nach deren Ende abgearbeitet.

Natürlich sollte dein wichtiger Interrupt nicht gerade so lange in
seiner Bearbeitung brauchen, dass zwei der anderen Interrupts in
dieser Zeit auftauchen können: dann würdest du natürlich nur noch
von einem ausgehen.  Zwei verschiedene andere Interrupts jedoch
werden (an Hand ihrer Interruptflags) unterschieden.

Jörg Wunsch wrote:

> Natürlich sollte dein wichtiger Interrupt nicht gerade so lange in
> seiner Bearbeitung brauchen, dass zwei der anderen Interrupts in
> dieser Zeit auftauchen können:

Ich vermute, er wills genau umgekehrt:

Die unwichtigen Interrupts sollen nicht den wichtigen Interrupt 
verzögern.


Peter

snoopy wrote:
> andere Interruptroutine läuft, wird diese nach Beendigung der laufenden
> Routine (zwischendurch 1 Befehl Hauptprogramm) ausgeführt (steht
> sozusagen in einer Art Warteschlange).

Die existiert aber nur auf einer logischen Ebene.

>
> Frage: wie viel darf sich denn in der Warteschlange so anstauen ? Liegt
> die auf dem Stack?

Nein.
Es existiert keine Warteschlange.
Für jeden Interrupt gibt es ein Flag in einem Register.
Ist das Flag gesetzt ist eine entsprechende Interrupt-
anforderung eingegangen.
Die CPU schaut einfach die Flags nach einem bestimmten
Schema (daher auch die Reihenfolge) durch: Ist das entsprechende
Flag gesetzt, wird der Interrupt ausgeführt. Kommt während
einer Interruptbearbeitung ein neuer Interrupt herein, wird
das entsprechende Flag gesetzt. Hat die CPU den bisherigen
Interrupt fertig, beginnt sie auch wieder sich um diese Flags
zu kümmern und findet dann das inzwishcen gesetzte Flag.

> 1. Interrupts gehen nicht verloren

Das kann man so nicht sagen.
Wenn man sich nur genug anstrengt, kann man sehr wohl
Interrupts verlieren.

> 2. wirklich exaktes Timing kann bei mehreren Interrupts nie garantiert
> werden

Yep.

>
> Ich sollte als besser in der schnellen, wichtigen Interruptroutine oder
> im Hauptprogramm das langsamere Ereignis pollen, also nur einen
> Interrupt verwenden.

Das kommt drauf an welche Timingvorstellungen du hast.
EIn µC ist ja kein Beamter, bei dem das Blumengiessen von
9:30 bis 10:15 Uhr dauert. Der ist schon ein bischen schneller.

@ snoopy

1.-3. Alles Korrekt.

>Frage: wie viel darf sich denn in der Warteschlange so anstauen ? Liegt
>die auf dem Stack?

Nö, das sind die Interrupt-Flags in den Registern. Also theoretisch und 
praktisch können alle gleichzeitig gesetzt sein, das sollte die Hardware 
nciht aus dem Tritt bringen. Ob es die Software verkraftet ist eine 
andere Frage. ;-)

>1. Interrupts gehen nicht verloren

Interrupts gehen nur verloren, wenn während eines laufenden Interrupts 
zwei andere Interrupts vom gleichen Typ auftreten. Wenn beispielsweise 
deine 10ms Timerroutine zu lang ist und währenddessen 2 Interrupts vom 
Empfänger des UARTs kommen, weil der mit 115k2 Baud Daten empfängt.

>2. wirklich exaktes Timing kann bei mehreren Interrupts nie garantiert
>werden

Definiere "wirklich exakt".

Im worst case kann die Interruptausführung verzögert werden, mämlich um 
die maximale Laufzeit des Iterrupts der kurz vorher (ein Takt reicht) 
sich angemeldet hat. Da der Zeitpunkt der Interrupts zufällig ist, ist 
auch die Verzögerung im Bereich 0..maximale Laufzeit des anderen 
Interrupts zufällig (Jitter).

>Ich sollte als besser in der schnellen, wichtigen Interruptroutine oder
>im Hauptprogramm das langsamere Ereignis pollen, also nur einen
>Interrupt verwenden.

JAIN. Ist von der Anwendung abhängig.

>Hab ichs jetzt ??

Ich denke schon.

MfG
Falk

Mist, wieder zu langsam. ;-)

MFG
Falk

snoopy wrote:

> 2. Treten 2 Interruptereignisse gleichzeitig auf, wird der
> ausgeführt, dessen Vector in der Liste vorn steht (der andere steht
> in der Warteschlange)

Wobei dieser Fall in aller Regel nur eintritt, wenn mehrere Interrupts
während einer Interruptsperre eintrafen (egal ob während einer ISR
oder während einer sonstigen CLI-Periode) und die Sperre aufgehoben
wird.

> Frage: wie viel darf sich denn in der Warteschlange so anstauen?
> Liegt die auf dem Stack?

Du hast einfach eine falsche Vorstellung davon.  Das ist keine
Schlange oder sowas.  Jede Interruptquelle hat ihr Interruptflag (in
einem IO-Register).  Zusammen mit den Freigabebits der einzelnen
Interruptquellen werden diese Flags über eine große ODER-Logik
vernknüpft.  Das bildet dann das Signal der globalen
Interruptanforderung.  Dieses wird nochmals mit dem I-Bit aus SREG
UND-verknüpft und entscheidet dann, ob der laufende Code unterbrochen
wird.

Sobald also eine freigegebene Interruptquelle einen Interrupt anmelden
würde, hängt es nur noch vom I-Bit ab, ob es zu einer Unterbrechung
kommt.  Wenn du gerade in einer ISR bist, ist das I-Bit normalerweise
gelöscht.  Das RETI setzt es dann wieder, und damit können alle noch
anhängigen Interrupts sich erneut um die CPU streiten.

Pro freigegebenen Interrupt kannst du also in einer beliebigen
Sperrzeit maximal ein Ereignis puffern.  Sind es mehrere, wird dir nur
ein Ereignis via Interrupt signalisiert.

> 2. wirklich exaktes Timing kann bei mehreren Interrupts nie
> garantiert werden

Wirklich exaktes Timing kann bei Interrupts nie garantiert werden. ;-)
Wirklich exaktes Timing macht man mit Hardware.

Einzige Ausnahme: du hast keinerlei Interruptsperrzeiten.  Aber das
ist unrealistisch.  Der Compiler selbst baut ja schon Code ein, um die
Interrupts mal kurz zu sperren, wenn er den Stackpointer (für den
Stackframe) manipuliert.  Du wirst sicher selbst auch noch weitere
Sperren brauchen.

> Ich sollte als besser in der schnellen, wichtigen Interruptroutine
> oder im Hauptprogramm das langsamere Ereignis pollen, also nur einen
> Interrupt verwenden.

Muss nicht sein.  Wenn du nur zwei Interruptquellen hast, kannst du
auch die unwichtige problemlos unterbrechbar machen.  Wenn es dir
tatsächlich auf die letzte Nanosekunde ankommt, dann geht das mit
einer Deklaration wie

1

void INT0_vect(void) __attribute__((interrupt));

2

void INT0_vect(void)

3

{

4

  /* hier die unterbrechbare ISR */

5

}

Das __attribute__((interrupt)) veranlasst den Compiler, ganz vorn in
der ISR bereits ein SEI einzubauen.  Damit ist die Interruptsperre auf
das absolute Minimum reduziert.

Wenn du andererseits in der unwichtigen ISR wirklich nur ein Flag
setzt, dann kannst du auf sowas wohl auch verzichten.  Das Flag pollst
du dann in main() ("volatile" nicht vergessen!).

Hmm, war ich ja viel zu langsam. ;-)