"Clear Interrupt" Anweisung bei µCs = Schwachsinn??

[Denker (Gast)]

Hallo!

Ich bin gerade am Programmierien eines µC und versuche mich dabei 
unteranderem am RTI. Was ich überhaupt nicht verstehe - wieso muss in 
der ISR der Interrupt "gecleared" oder auch "bestätigt" werden. Ich 
mein, wie kann dieser (oder egal welcher) Interrupt überhaupt verpasst 
werden. Der Name sagt doch schon "Interrupt" = "Alles andere 
Unterbrechen und mich ausführen". Ich hoffe doch mal der µC hat intern 
eine kleine Queue für Interrupts, damit falls ein IRQ während dem 
Ausführen einer anderen ISR, einfach gepuffet wird.

Wie auch immer, da ich sie wohl benötigte, da ansonsten der RTI 
andauernd und nicht nur im angegebenen Intervall aufgerufen wird - 
schreibe ich diese "Clear" Anweisung dann am besten am Anfang der ISR, 
ganz am Ende oder einfach in der Mitte. Was passiert wenn ich den 
Interrupt mehrmals bestätige?

Kurz gesagt, mir ist der Sinn + die Logik dahinter total 
unbegreiflich...

Beste Grüße

[Christian U. (Gast)]

Nein der Controller hat keine Que für Inerrupts wär ja auch schwachsinn 
Inerrups sind dafür da das sie ausgeführt werden wenn etwas passiert und 
nicht irgendwann später mal. Es wird lediglich das Flag gesetzt.

[Dirk H. (arm-dran)]

Mit welchem µC arbeitest Du denn.

Es gibt da einen großen Unterschied.

Ein normaler CLI Befehl sperrt schlichtweg alle Interrupts, bis auf den
NMI (non maskable interrupt) falls vorhanden.

Das was Du innerhalb der ISR meinst, ist wohl das Rücksetzen des 
jeweiligen
InterruptFLags)
Dies soll bedeuten, ich habe den Interrupt erkannt und bearbeitet.
Außerdem schützt er vor dem nächsten gleichen Interrupt.

In manchen ISR wie zum Beispiel bei der seriellen Schnittstelle erzeugen
mitunter versch. Ereignisse einen Interrupt auf dem gleichen I-Vector.
Durch auslesen und rücksetzen dieser Flags kannst Du dann die einzelnen
Ereignisse in der ISR abarbeiten.

[Ronny (Gast)]

Grundsätzlich wird erstmal irgendwo ein Flag gesetzt,sobald die 
Interruptbedingung eintritt.Dann wird,sofern Interrupts nicht global 
gesperrt sind,nach der aktuell gerade in Arbeit befindlichen Instruktion 
in den Interrupt verzweigt.

Wie man nun die Interrupt-Kondition wieder los wird ist von Controller 
zu Controller unterschiedlich.Bei einigen muss man ein bestimmtes 
Statusregister lesen,bei anderen auf irgend ein Datenregister 
lesend/schreibend zugreifen und bei wieder anderen genügt wenn die 
Interruptroutine angesprungen wird.

Nun gibt es allerdings auch Controller,wo sich mehrere Module (z.B. 
UART-Empfänger und UART-Transmitter) den selben Interruptvektor 
teilen.In diesem Fall bestünde die Gefahr,das ein Interrupt nicht 
behandelt wird,wenn 2 Interruptbedingungen gleichzeitig eintreten.Von 
daher macht es schon Sinn,wenn man explizit die Bedingung löschen 
muss,da man gezwungen ist zumindest den Fall einzuplanen,das der 
Interrupt auftritt.

[Ronny (Gast)]

Zusatz:

Wenn ein Ereignis mehrmals auftritt,während Interrupts global gesperrt 
sind,wird bei den mir bekannten Controllerarchitekturen lediglich das 
zuletzt eingetretene Ereignis erkannt.