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
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.
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.
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.
Zusatz: Wenn ein Ereignis mehrmals auftritt,während Interrupts global gesperrt sind,wird bei den mir bekannten Controllerarchitekturen lediglich das zuletzt eingetretene Ereignis erkannt.
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.