F: Interrupt-Logik bei Mikrocontroller/PC-CPU?

Liebe Gruppe ;-)

Was genau passiert eigentlich, wenn bei einem Mikroprozessor ein Interrupt angelegt wird?

Mich würde interessieren, was vom Anliegen des Signals bis zum Eintritt in die Interrupt-Service-Routine passiert.

Ein Verweis auf eine Herstellerdokumentation oder ähnlich belastbares Material wäre angenehm.

Falk P.S.: Hintergrund ist der, daß ich "nebenan" die Meinung vertrete, daß die IRQ-Leitung _nicht_ zyklisch abgefragt wird, sondern "in Hardware" das Verhalten des Prozessors beeinflusst.

"Falk Willberg" schrieb im Newsbeitrag news: snipped-for-privacy@mid.individual.net...

Es gibt keinen Hersteller eines Mikroprozessors. Mikroprozessor ist ein generischer Name. Du muesstest schon einen bestimmten Typ nennen. Normalerweise wird aber zu Beginn eines Befehlszyklus nachgeschaut, ob der Interrupt-Pin aktiv ist, und dann nicht der naechste Befehl abgearbeitet, sondern eine Sequenz in der der Programmzaehler auf den Stack geschoben wird, meist noch einige Register wie das Statusregister, und dann an der Adresse weitergemacht wird, die zum Interrupt passt.

Der Pin wird also schon zyklisch abgefragt, maximal ist eine Logik drin, die den Pin bis zum naechsten Befehl aktiv haelt, wenn er mal kurz aktiv, Interrupt ist dann also eine Art Set-Leitung fuer ein FlipFlip.

--
Manfred Winterhoff, reply-to invalid, use mawin at gmx dot net
homepage: http://www.geocities.com/mwinterhoff/
de.sci.electronics FAQ: http://dse-faq.elektronik-kompendium.de/
Read 'Art of Electronics' Horowitz/Hill before you ask.
Lese 'Hohe Schule der Elektronik 1+2' bevor du fragst.

Falk Willberg schrieb:

Alle üblichen Prozessoren haben einen Takt, arbeiten also zyklisch. Die Interruptleitung macht da keine Ausnahme.

Es wäre ja fatal, wenn mitten während eines Taktes, wo sich durch Stromfluss gerade ein neuer stabiler Zustand der Flipflops des Prozessors ausbildet, irgendwas an diesen Stromflüssen geändert würde. Dann könnte man die ganze Digitaltechnik vergessen, weil es nun auf Zeitpunkt und genaue Parameter der Leitungen und Ladungsspeicher ankäme, wenn man den Folgezustand vorausbestimmen will.

Mit freundlichem Gruß

Jan

Falk Willberg schrieb:

Dafür solltest du erstmal klären was ihr überhaupt unter zyklisch abgefragt versteht. Die Hardware wird in aller Regel die IRQ-Leitung nur auf den Flanken irgendeines Taktes abfragen. Falls das Signal also nur ganz kurz zwischen zwei Flanken gesetzt wird dann wird kein Interrupt ausgelöst. Insofern wird sie natürlich zyklisch abgefragt. Die zyklische Abfrage geschieht aber durch die Hardware, du musst in deine Software keine regelmässig auszuführende Routine einbauen, die falls nötig einen Interrupt auslöst.

Jan

Bis aus Gatter-Ebene kannst du das bei den CPUs von opencores.org nachvollziehen, z.B. bei diesem 6502 Klon:

Der Interrupt-Pin ist IRQ_n, der mit jeder steigenden Taktflanke abgefragt wird und in IRQ_n_o übernommen wird (Zeile 357), um das von Jan Kandziora beschriebene Problem zu vermeiden. Zu Beginn eines Befehlszyklus wird dann geprüft, ob dieses Bit gesetzt ist (Zeile 490) und dann entsprechend andere Aktionen ausgeführt, wie aktuellen Programmcounter auf den Stack legen usw., statt den nächsten Befehl auszuführen.

Das funktioniert so ähnlich auch bei vielen anderen Microcontrollern, nicht nur bei der CPU vom C64.

--
Frank Buss, fb@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de

Ja, das führt zu interessanten Problemen. Ich habe mal eine RS232 Schnittstelle in VHDL programmiert und das Eingangssignal direkt verwendet, um es intern in einer Statemachine auszuwerten. Lief im VHDL-Simulator gut, nur wenn man in der Praxis reale Signale anlegte, dann blieb die Statemachine nach ein paar Sekunden Daten empfangen einfach stehen, obwohl das von der Ablauflogik her nicht möglich gewesen sein sollte. Der Grund war, daß die Statemachine intern per one-hot-encoding vom Synthesetool im FPGA implementiert wurde und die scheinbar in einen Zustand kam, wo mehrere Ausgänge aktiv waren. Seitdem ich das Eingangssignal mit steigender Flanke erstmal zwischenspeichere und erst im nächsten Takt die Zwischenspeicherung auswerte, sodaß es immer für einen Takt stabil anliegt, läuft die Schnittstelle problemlos.

--
Frank Buss, fb@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de

Pick dir einen beliebigen Prozessor und schau in die Docs. Bisher hatte noch jeder ein entsprechendes Kapitel.

Man muß hier unterscheiden zwischen "abgefragt" und "drauf reagiert". Natürlich kann jeder Prozessor nur zu bestimmten Zeitpunken auf einen Interrupt reagieren - immer dann wenn er den gerade laufenden Befehl fertig hat (Spezialitäten wie Sleep-Modi mal außen vor). Zu diesen Zeitpunkten wird der *Status* des Interrupts abgefragt. Das ist i.d.R.

*nicht* der Pegel am Interrupt-Pin.

Anhand welcher Bedingung auf der Leitung der Interrupt-Status geändert wird, steht auch im Datenblatt. Flankengetriggerte haben in jedem Fall ein Flipflop hinter dem Interrupt-Pin hängen. Pegelgetriggerte verlangen i.d.R. eine Mindestimpulsbreite oder gar daß der Pin aktiv bleibt, bis der Prozessor den Interrupt quittiert. Anhand der Mindest- impulsbreite kann man schon ableiten, ob der Pin synchron abgefragt wird oder ob das nur die Set-Zeit eines Flipflops ist.

IMNSHO ist synchrone Abfrage nur sinnvoll, um Noise-Pickup zu vermeiden. Interrupts sind ja per Definition asynchron zum normalen Programmfluß. Eine (langsame) Synchronisierung wäre kontraproduktiv.

XL

Übliche Designs sind taktsynchron, d.h. der Status der Leitung wird mit der Flanke des hierfür verwendeten Takts übernommen und dann z.B. bei flankengesteuerten Interrupts intern per Hardware-Vergleich geprüft, ob es eine Änderung gab. Danach läuft das Signal gewöhnlich durch eine Interrupt- Controller-Logik, die feststellt, ob es jetzt gerade überhaupt pässlich (enabled) ist, ob nicht andere höher priorisierte Interrupts anstehen oder in Bearbeitung sind usw.

Kommt alles hin, dann wirkt das Signal im Bereich der Instruktionsholung und Auswertung, wo genau, ist typabhängig, bei einfachen Controllern z.B. durch Wegschalten des Program Counter und Anlegen einer definierten (Tabellen-) Adresse am Bus, bei komplexen Designs mit Pipeline kann das wesentlich komplizierter sein, z.B. Pipeline Stall und dann Wiederauffüllen mit den Instruktionen der Interrupt- Routine.

Die IRQ-Leitung wird gewöhnlich nicht per Programm oder Mikrocode abgefragt, schlechte Ausnahmen bestätigen die Regel, sondern beeinflußt in der Tat direkt die CPU-Hardware.

Genau deshalb hat man sie ja, sonst ist sie witzlos, "Interrupt" heißt Interrupt, weil es wie Interrupt geschrieben und gesprochen wird, was wiederum heißt, dass es nicht wie "Polling" geschrieben und gesprochen wird ;-)

Sie wird aber so wie praktisch alles in derartigen Designs _synchron_ mit dem Takt verarbeitet, d.h. die Statusänderung wird mit dem (internen) CPU Takt per dedizierter Hardware abgefragt.

Gruß Oliver

--
Oliver Bartels + Erding, Germany + obartels@bartels.de
http://www.bartels.de + Phone: +49-8122-9729-0 Fax: -10

Prinzipiell sollte man hier vielleicht noch erwaehnen, dass es verschiedene Arten der Interruptauswertung gibt. Nehmen wir als Beispiel einen Atmel AVR, da kann man die externen Interrupts uebelicherweise flanken- (rise/fall) oder zustandsgetriggert (low level) konfigurieren.

Im ersten Fall setzt die passende Flanke am Pin ein Interruptflag. Ist der betreffende Interrupt eingeschaltet wird beim naechsten Befehl (oder irgendwann spaeter wenn das globale I-Flag der CPU gerade nicht gesetzt ist) die ISR angesprungen. Die Flanke wird hier also wirklich (oder zumindest quasi) asynchron zum CPU Takt erkannt und so lange gespeichert bis die CPU die ISR ausfuehrt.

Im letzteren Fall wird der Pin nur dann abgefragt wenn die CPU die Entscheidung treffen muss die ISR auszufuehren. Er wird daher nicht in konstanten Intervallen abgefragt, laeuft z.B. gerade eine andere ISR und das I-Flag der CPU ist deswegen zurueckgesetzt, loest auch ein beliebig lang anliegendes Signal keinen Interrupt aus solange die CPU noch nicht wieder aus der anderen ISR zurueckgekehrt ist. Der Interrupt wird in diesem Fall ignoriert wenn er nach der Rueckkehr aus der anderen ISR nicht mehr aktiv ist.

Fuer Interrupt sharing ist z.B. das zweite Schema besonders geeignet (wired OR).

Micha

--
> > Ich mag es immer noch nicht glauben.
> Glaube gehoert in die Kirche!
Stimmt und wir sind hier nicht in der Kirche.
                           Gesehen in defa

Dürfte in ziemlich jedem Datenblatt zu finden sein, z.B.

S. 104 des PDF-Dokuments, bzw. Page 102 des Datenblatts

...

Die Begriffe "nachschauen" und "abfragen" will der OP hier vermutlich nicht sehen :-)

Man könnte auch sagen, der Interrupt wird mit dem Prozessortakt synchronisiert und zu einem definierten Zeitpunkt, d.h. wenn der aktuell laufende Befehlt abgearbeitet ist ausgeführt. Die dazugehörige Logik ist üblicherweise in Hardware und nicht in Software ausgeführt. Alles andere würde den Prozessor ausbremsen.

Die Begriffe "abfragen" und "nachschauen" sind natürlich nicht falsch sondern beschreiben sogar recht anschaulich, was genau passiert.

Gruß

Stefan DF9BI

Das hängt vom konkreten Design ab. So wie "Auto" nicht gleich "Auto" ist, ist µC nicht gleich µC.

In jeder Hardwarereferenz eines µC findet sich auch ein Kapitel über das Interruptsystem. Naja, außer bei denen, die garkeine Interrupts kennen. Auch sowas gibt's nämlich.

Wie gesagt, das kommt drauf an. In aller Regel wird aber tatsächlich zyklisch (nämlich mit der Taktfrequenz oder einem ganzzahligen Bruchteil davon) "abgefragt". Allerdings muß das nicht notwendigerweise heißen, daß das Interuptereignis auch unbedingt in genau diesem Moment auftreten muß. Im Gegenteil, der Normalfall ist, daß das Ereignis zuerst mal nur einen Flipflop setzt. "Abgefragt" wird nicht das Ereignis selber, sondern der Zustand dieses Flipflops.

Im übrigen geschieht diese zyklische "Abfrage" aber meist wiederum "in Hardware". Das beides schließt sich nicht gegenseitig aus, wie du wohl zu glauben scheinst.

AMD hatte mal eine AM2900-Serie. Das waren Bausteine wie Rechenwerke, Mikroprogrammspeicher, Registerblöcke, Mikroprogramm-Sequencer etc. Dich interessiert hier hauptsächlich der Sequencer.

Es gab zu diesen Bausteinen eine Reihe von Büchlein, die die Funktionsweise ganz wunderbar beschrieb. Der Titel war "Build Your Own Microprocessor Today" oder so ähnlich, Band 1 bis +-6.

Bei AMD bekommt man die wohl nicht mehr, es sei denn, dass die einen Museumsserver unterhalten. Auf sollt man aber noch was finden können.

Ansonsten: Andrew Tannenbaum: "Structured Computer Organization"

Transputer sind da eher ein Gegenbeispiel. Alles von einem event bis zum Starten des zugehörigen Prozesses in Hardware und Mikroprogramm. Sonst hätte man sich die vier 5/10/20 MBaud-Links gleich schenken können.

Wow.

Gruß, Gerhard

Nuja, mein Argument "nebenan" war, dass der Interrupt-Pin eben gerade nicht (meinetwegen noch verknüpft mit dem Taktsignal und dem Interrupt- Flag) direkt in die Reset-Eingänge der anderen Prozessor-Verarbeitungs- einheiten geht, um die Ausführung ganz interrupt-like auf die ISR umzubiegen, sondern doch irgendwie vom Mikrocode an definierten Stellen gepollt wird.

Für diese These spricht zum einen die Tatsache, dass der laufende Befehl noch zuende ausgeführt wird (dieses Verhalten fand ich im Manual zum

80C186), zum anderen die schiere Komplexität dessen, was bei einem Interrupt passiert (8 Seiten Pseudo-Pascal-Code bei IA32), die eine Verarbeitung des Interrupts in Mikrocode erzwingt.

Stefan

Nack, wird er gewöhnlich nicht. Deine Sicht der Dinge ist bzgl. moderner CPU's und Controller recht naiv.

Das würde den Controller deutlich langsamer machen (und unnötig langsame CPU's haben keinen Markt ;-)

Dass bei der _Verarbeitung_ des Interrupts bei gewissen Architekturen, die so sind, wie sie sind, weil letztlich quasi- Kompatibilität zum Intel 8008 gefordert wurde und deshalb extremer Overhead mitgeschleppt wird, _nach_ dem Stall der Pipeline spezieller Mikrocode angestoßen wird, ist ein ganz anderes Ding.

Aber _gepollt_ wird da garnix im Microcode, denn der Poll wäre ein zusätzlicher unnötiger Zyklus bei jeder Instruktion. Bei Mikrocode-Architekturen wirkt der Interrupt dann halt direkt auf den Sqeuenzer (bzw. auf die Pipeline-Stufen vor der Zerlegung in uOps, bei den großen CPU's, die das meiste eh' wieder rein in Hardware machen und nur selten auf uC zurückgreifen).

Gruß Oliver

--
Oliver Bartels + Erding, Germany + obartels@bartels.de
http://www.bartels.de + Phone: +49-8122-9729-0 Fax: -10

In article , Frank Buss writes: |> Ja, das führt zu interessanten Problemen. Ich habe mal eine RS232 |> Schnittstelle in VHDL programmiert und das Eingangssignal direkt verwendet, |> um es intern in einer Statemachine auszuwerten. Lief im VHDL-Simulator gut, |> nur wenn man in der Praxis reale Signale anlegte, dann blieb die |> Statemachine nach ein paar Sekunden Daten empfangen einfach stehen, obwohl |> das von der Ablauflogik her nicht möglich gewesen sein sollte. Der Grund |> war, daß die Statemachine intern per one-hot-encoding vom Synthesetool im |> FPGA implementiert wurde und die scheinbar in einen Zustand kam, wo mehrere |> Ausgänge aktiv waren. Seitdem ich das Eingangssignal mit steigender Flanke |> erstmal zwischenspeichere und erst im nächsten Takt die Zwischenspeicherung |> auswerte, sodaß es immer für einen Takt stabil anliegt, läuft die |> Schnittstelle problemlos.

Du beschreibst Metastabilität und die Abhilfe dagegen ;-) Bei one-hot-Codierung fällt das immer am schnellsten auf, weil die nicht zeitgleiche Übernahme der Eingangsdaten dann dazu führt, dass entweder gar kein Zustandsbit mehr heiss ist (Zustandskoma) oder mehrere an sind.

--
         Georg Acher, acher@in.tum.de
         http://www.lrr.in.tum.de/~acher
         "Oh no, not again !" The bowl of petunias

Bin halt Softwerker :-)

[...]

Aber, zumindest bei dem zitierten 80C186, wirkt er nicht direkt auf das ablaufende Mikroprogramm, sondern nur zu den Zeitpunkten, wo das Mikroprogramm gerade mal Lust hat (=Anfang einer neuen Instruktion). Dass man dann in das Mikroprogramm nicht das Äquivalent von bt [status], INT // prüfe interruptbit jc do_interrupt // wenn ja, mache Interrupt mov R, [cs:ip++] // sonst lade neuen Befehl hat, sondern das irgendwie in eine dicke 'fetch_next_insn'-Mikro- operation packt, ist wohl naheliegend.

Andererseits wirkt der Interrupt natürlich auch auf das x86-Programm nur, wenn selbiges Lust dazu hat und das Interrupt-Flag anknipst.

Stefan

Warum sollte man das tun? Auch das kostet 2 Takte im Mikroprogramm. Wenn man das (maskierte) Interruptsignal direkt in die Statemachine für die Ablaufsteuerung führt, kostet das im Normalbetrieb nichts, und bei Anliegen eines Interrupts findet bei nächster Gelegenheit ein passender Statewechsel statt - der *dann* dazu führen kann, daß passende Mikroprogrammteile ausgeführt werden. Ich gehe mal davon aus, daß auch der 80C186 einfache Operationen direkt ausführt und nicht per Microcode.

Das ist ja nichts weiter als ein AND-Gatter und für die Behandlung des Interrupts erstmal egal.

cu Michael

--
Some people have no respect of age unless it is bottled.

Stefan Reuther schrieb:

Merkt man.

In der Mitte einer Instruktion zu unterbrechen wäre einfach viel schwieriger machbar, schliesslich muß der Programmstrom später wieder fortgesetzt werden. Wenn man Interrupts nur zwischen den Instruktionen zulässt dann muß viel weniger an Zustandsinformation gespeichert werden damit später transparent fortgesetzt werden kann. Wirkliche Vorteile würden daraus auch nicht entstehen, denn die zusätzliche Verzögerung kann man im Vergleich zur Ausführungendauer der Interruptroutine vernachlässigen. Eine Aufgabe die Reaktionszeiten braucht, die in der Größenordnung der Ausführung einer einzigen Instruktion sind, muß eh per Hardware gelöst werden.

Es gibt auch einen Haufen CPUs ganz ohne uCode. Auch die können Interrupts. Die Diskussion um uCode bringt dich auch nicht weiter. Code alleine wird nicht ausgeführt, da nützt es dir auch nichts den Code in uOPs zu verlegen, von alleine führen die sich auch nicht aus.

Jan