Forum: Mikrocontroller und Digitale Elektronik Interrupt-Handler - Keine Parameter?


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von ARMAnfänger (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich habe da mal eine kleine Frage bezüglich Interrupt-Handler.

Warum können einem Interrupt grundsätzlich keine Parameter übergeben 
werden, bzw. warum hat er keine Rückgabewerte?


Also es handelt sich hierbei um eine Frage aus einer Klausur.


Ich hätte jetzt einfach gedacht, dass das Problem ist, dass der 
Interrupt irgendwann auslöst und mein main-Programm dadurch unterbrochen 
wird.
Da er an einer X-beliebigen Stelle unterbrochen wird und ich ihn nicht 
gezielt also z.B. genau in der Codezeile 77 im Programmcode aufrufen 
kann, also nicht irgendwelchen Variablen angeben kann, die dessen 
Rückgabewerte speichern sollen, hat es auch keinen Sinn 
Rückgabeparameter zu verwenden.

Außerdem habe ich oft etwas von einem Stack und Variablen sollten 
volatile sein gelesen und deshalb kann man keine Parameter angeben.


Über Hilfe in einfachen und verständlichen Worten wäre ich sehr erfreut! 
;)
Schonmal Danke an die Leute die sich dafür die Zeit nehmen!

von Noch nicht Rentner (Gast)


Bewertung
-2 lesenswert
nicht lesenswert
Funktionsparameter werden auf dem Stack uebergeben. Da der Interrupt 
irgendwann kommt, wie sollten da Parameter auf dem Stack uebergeben 
werden koennen ? Wenn ein Interrupt vorbei ist, ist alles wie vorher, 
daher kann auch kein Interrupt resultat auf dem Stack sein.
Variablen, die ein Interrupt benoetigt, muessen daher global sein.

von Peter II (Gast)


Bewertung
1 lesenswert
nicht lesenswert
Noch nicht Rentner schrieb:
> Funktionsparameter werden auf dem Stack uebergeben. Da der Interrupt
> irgendwann kommt, wie sollten da Parameter auf dem Stack uebergeben
> werden koennen ?

die Begründung ist falsch. Das Parameter auf dem Stack übergeben werden 
ist nirgends festgelegt und je nach Plattform auch nicht (immer) der 
Fall.

von Ruediger A. (Firma: keine) (rac)


Bewertung
-1 lesenswert
nicht lesenswert
Also erstmal würde nichts dagegen sprechen, daß Parameter an ISRs 
übergeben würden. Voraussetzung dafür ist allerdings, daß

- die Hardware das könnte (da der ISR nicht unter Entwicklerkontrolle 
aufgerufen wird, muß es der Controller machen) und
- die Vorgaben des ABI eingehalten würden (also der/die Paramter an den 
lt. ABI erwarteten Stellen werden, richtiger Punkt von Peter II).

Wie "NochNichtRentner" richtig schreibt, ist das Problem hier des 
Kontextes; da der ISR nicht kontrolliert aufgerufen wird, muß der 
Prozessorzustand nach Beendigung des ISRs exakt dem vor Eintritt des 
ISRs entsprechen. Für Parameter wäre das sogar denkbar (der 
Prozessorkern müßte je nach ABI nur vor dem Setzen der Parameter die 
entsprechenden Register pushen und danach wieder poppen oder einen 
größeren Exception stack frame nutzen), aber der Rückgabewert wäre ein 
echtes Problem, da der einen Anderen Prozessorzustand impliziert.

Parametrierte ISRs würden in gewissen Szenarien sogar Sinn machen, z.B. 
könnte ein Prozessorkern verschiedene Instanzen von ISRs gleichartiger 
Funktionalität (z.B. USARTs) über einen gemeinsamen ISR abbilden und 
Instanzinformationen an den gemeinsamen ISR übergeben (das wird 
normalerweise über Software gemacht, d.h. jeder ISR hat einen eigenen 
Eintrag in der IVT, aber jeder Eintrag pusht seine 
Identifikationsparameter und ruft gemeinsamen Code auf). Allerdings 
überwiegen m.M. nach die Nachteile so einer möglichen Architektur 
(größerer Stackbedarf oder ISR Umlaufzeiten, erzwungene ABI Konformität, 
Fallunterscheidungen je nach benötigter Parameteranzahl etc) die 
Vorteile (kleinere IVTs, Softwareunterstützung in HW).

Mußt Du die Klausur vor oder nach diesem thread schreiben? ;-)

von Noch nicht Rentner (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Ok. Anderer Ansatz.
Woher sollen die Parameter an die Interrupt Procedur denn ueberhaupt 
kommen ? Funktionsparameter kommen aus einem Kontext heraus. Welchen 
Kontext hat eine Interrupt Prozedur ?

Genau. Der Kontext ist global. Daher sind auch Interrupt Variablen dort.

von Ruediger A. (Firma: keine) (rac)


Bewertung
0 lesenswert
nicht lesenswert
Noch ein kleines Detail zum OP: Ein ISR unterbricht nicht 
notwendigerweise die main() Funktion, sondern irgendwas im Thread Mode, 
d.h. main() nur wo kein RTOS im Betrieb ist, sonst in der Regel eine vom 
OS gemanagte task - oder einen anderen, bereits laufenden ISR. Mag wie 
Haarspalterei klingen, aber in der Praxis werden diese Unterschiede sehr 
schnell sehr wichtig... ;-)

von Rufus Τ. F. (rufus) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Es gibt sogar Interrupts mit Parametern -- aber das sind dann sogenannte 
"Softwareinterrupts", die werden zum Aufrufen von 
Betriebssystemfunktionen o.ä. verwendet.

Der "gute alte" IBM-PC nutzt dieses Konzept zur Kommunikation mit dem 
BIOS und zum Aufruf von Funktionen von DOS. Die Parameter werden vor 
Aufruf des Interrupthandlers in Prozessorregistern untergebracht und 
etwaige Resultate nach Ende des Interrupthandlers wiederum in 
Prozessorregistern zurückgegeben.

Das setzt naturgemäß einen Prozessor voraus, der Softwareinterrupts 
kennt; die 8-Bit-AVRs kennen so etwas nicht.

Hardwareinterrupts hingegen, die völlig asynchron zum Programmablauf 
auftreten, können keine vom Programm vorgegebenen Parameter übergeben 
bekommen. Warum das nicht geht, wurde ja schon ausführlich beschrieben.

von Uwe B. (Firma: TU Darmstadt) (uwebonnes)


Bewertung
0 lesenswert
nicht lesenswert
Ethernut registiert Interrupts mit
extern int NutRegisterIrqHandler(IRQ_HANDLER * irh, void (*handler) 
(void *), void *arg);
Die Parameter werden also vorher gespeichert und wenn der Interrupt dann 
erfolgt, wird der Interruptnutzcode mit Parametern angesprungen.

von Rufus Τ. F. (rufus) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Das sind dann aber keine Interrupthandler im eigentlichen Sinn mehr, 
sondern Callback-Funktionen.

von Marc V. (Firma: Vescomp) (logarithmus)


Bewertung
0 lesenswert
nicht lesenswert
Rufus Τ. F. schrieb:
> Der "gute alte" IBM-PC nutzt dieses Konzept zur Kommunikation mit dem
> BIOS und zum Aufruf von Funktionen von DOS.

 Ja, INT 0x13.
 Aber abgesehen davon, dass es ein Software-Interrupt ist, funktioniert
 das nur mit DOS, in WINDOWS wird der abgefangen und umgeroutet.

ARMAnfänger schrieb:
> Warum können einem Interrupt grundsätzlich keine Parameter übergeben
> werden, bzw. warum hat er keine Rückgabewerte?

 Also, das stimmt schon mal nicht.
 Rückgabewerte sind kein Problem, nur - wie sollen diese ausgewertet
 werden ?
 Und Parameter könnte nur die CPU übergeben, nur - wie soll die CPU
 wissen, welche Parameter für Zeile 77 und welche Parameter für Zeile
 1234 übergeben werden sollen ?

von c-hater (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Rufus Τ. F. schrieb:

> Hardwareinterrupts hingegen, die völlig asynchron zum Programmablauf
> auftreten, können keine vom Programm vorgegebenen Parameter übergeben
> bekommen.

Naja, ganz so ist es nicht. Erstens gibt es Hardwareinterrupts, die 
durchaus synchron zum Programmablauf sind (oder zumindest sein können, 
wenn man das so will, siehe z.B. Timerinterrupts beim AVR) und zweitens 
gibt es bei praktisch jeder Architektur die Möglichkeit, die 
Interruptausführung mittels Interruptsperren zu synchronisieren. In 
beiden Szenarios sind die Interrupts aus Sicht des zu unterbrechenden 
Codes nicht mehr unvorhersehbar, sondern deterministisch. 
Dementsprechend wäre auch in beiden Szenarien eine Parameterübergabe 
realisierbar.

Nur einen Sinn ergibt so ein Konstrukt wohl selten bis garnicht. Da 
hätte man ja mit mehr oder weniger viel zusätzlichem Aufwand letztlich 
nur die Funktionalität einer normalen Funktion erreicht und das ganze 
Konzept von Interrupts ad absurdum geführt. Ich kann mir keinen 
Anwendungsfall vorstellen, wo das nützlich sein könnte...

von Ruediger A. (Firma: keine) (rac)


Bewertung
0 lesenswert
nicht lesenswert
c-hater schrieb:

>
> Naja, ganz so ist es nicht. Erstens gibt es Hardwareinterrupts, die
> durchaus synchron zum Programmablauf sind (oder zumindest sein können,
> wenn man das so will, siehe z.B. Timerinterrupts beim AVR) und zweitens
> gibt es bei praktisch jeder Architektur die Möglichkeit, die
> Interruptausführung mittels Interruptsperren zu synchronisieren. In
> beiden Szenarios sind die Interrupts aus Sicht des zu unterbrechenden
> Codes nicht mehr unvorhersehbar, sondern deterministisch.
> Dementsprechend wäre auch in beiden Szenarien eine Parameterübergabe
> realisierbar.
>

? Stimmt so nicht, wenn ich die obige Aussage richtig interpretiere - es 
ist im zweiteren Fall deterministisch, wann die Interrupts nicht 
auftreten können, aber solange die interrupts nicht gesperrt sind, 
können sie indeterministisch auftreten. Außer man würde sich die Mühe 
machen, Interrupts so zu sperren, daß sie nur an genau einer Stelle 
offen sind, aber das würde nun überhaupt keinen Sinn machen...

von ARMAnfänger (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Okay vielen Dank für die ausführlichen Antworten!

Also ich muss die Klausur noch schreiben und die Frage ist mal in einer 
Klausur gefallen, wurde aber nicht richtig beantwortet.

Ich hätte vielleicht präziser sein sollen:
Warum kann ein Interrupthandler, der in C wie eine Funktion geschrieben 
wird - keine Parameter haben oder Rückgabewerte zurückgeben?


Also ich nehme jetzt kurz und knapp mit, dass:
- es mit "speziellen" Softwareinterrupts durchaus möglich wäre
- bei den "normalen/einfachen" ISR jedoch nicht, da der Kontext eine
  wichtige Rolle spielt.

Die CPU kann nicht zuordnen, was mitübergeben werden soll und wer was 
mit dem Ergebnis anfangen kann.

Vielen Dank für die Antworten, ich bewundere es immer wieder, dass es 
Leute wie euch gibt, die sich die Zeit nehmen um anderen bei solchen 
Dingen zu helfen! Respekt und Danke! ;)

von Georg (Gast)


Bewertung
0 lesenswert
nicht lesenswert
ARMAnfänger schrieb:
> es mit "speziellen" Softwareinterrupts durchaus möglich wäre

Softwareinterrupts sind definitiv keine Interrupts, sondern normale 
Prozeduraufrufe mit einer festen Aufrufaddresse. Sie unterbrechen den 
Programmablauf auch nicht, sondern werden genau da ausgeführt wo der 
Programmierer sie aufruft. Wer immer sich die Bezeichnung ausgedacht hat 
(Intel? Microsoft?) hatte mehr Verschleierung im Sinn als logische 
Klarheit.

Georg

von Rufus Τ. F. (rufus) (Moderator) Benutzerseite


Bewertung
1 lesenswert
nicht lesenswert
Georg schrieb:
> Wer immer sich die Bezeichnung ausgedacht hat

Spätestens Intel, mit Einführung des INT-Befehls im Befehlssatz des 
8086. Eine Vorform davon war der RST-Befehl des 8080.

von W.S. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
ARMAnfänger schrieb:
> Warum kann ein Interrupthandler, der in C wie eine Funktion geschrieben
> wird - keine Parameter haben oder Rückgabewerte zurückgeben?

Es hängt ganz grundsätzlich NICHT von irgend einer Programmiersprache 
ab.

In einem µC oder auf dem PC oder eben sonstwo, wo ein Prozessor werkelt, 
hat man Maschinencode und der wird abgearbeitet und irgendwann zumeist 
eben nicht präzise vorhersagbar durch einen Interrupt unterbrochen. 
Deswegen heißt der auch so: Interrupt.

Dabei ist es sonnenklar, daß der Zustand des Systems (Register, Flags 
und so weiter) bei einem Interrupt, der von der Hardware ausgelöst wird, 
ebenfalls nicht präzise vorhersagbar ist und deshalb alles, was im 
Interrupt-Handler benutzt wird, eben zuvor in irgend einer Weise 
gerettet und hinterher restauriert werden muß. Da gibt es ganz 
grundsätzlich KEINEN Platz für irgendwelche Datenübergaben. Wenn man mit 
einem Interrupt-Handler kommunizieren will, dann eben NUR per globalen 
Variablen und auch nur in einer Art, daß beide Seiten nach irgend einem 
Schema ihre Kommunikation miteinander synchronisieren. Sonst geht das 
schief und produziert zufällige Fehler.

Eine Ausnahme machen eben die erwähnten Soft-Interrupts, bei ARM werden 
die SVC's genannt (Supervisor Calls). Das sind aber spezielle 
Maschinenbefehle (die der GCC nicht kann). Sowas ist gut für das 
Aufrufen von Funktionalitäten aus Betriebssystemen und so, also immer 
dann, wenn man eine geordnete Schnittstelle zwischen mehreren separat 
übersetzten Programmteilen benötigt, denn die tatsächliche Adresse des 
SVC-Handlers und seiner nachgeordneten Funktionen braucht der 
aufrufenden Anwendung garnicht bekannt zu sein. Hatte ich vor Jahren bei 
der Lernbetty schon mal vorgeturnt.

W.S.

von Rolf M. (rmagnus)


Bewertung
1 lesenswert
nicht lesenswert
Marc V. schrieb:
> ARMAnfänger schrieb:
>> Warum können einem Interrupt grundsätzlich keine Parameter übergeben
>> werden, bzw. warum hat er keine Rückgabewerte?
>
>  Also, das stimmt schon mal nicht.
>  Rückgabewerte sind kein Problem, nur - wie sollen diese ausgewertet
>  werden ?
>  Und Parameter könnte nur die CPU übergeben, nur - wie soll die CPU
>  wissen, welche Parameter für Zeile 77 und welche Parameter für Zeile
>  1234 übergeben werden sollen ?

Streng genommen haben Interrupts teilweise schon gewisse "Parameter", 
nur nicht in Form von C-Funktionsparametern, sondern zumeist in 
irgendwelchen I/O-Registern - beispielsweise bei einer UART-Receive-ISR 
das empfangene Byte.

von Arduino Fanboy D. (ufuf)


Bewertung
0 lesenswert
nicht lesenswert
ARMAnfänger schrieb:
> Warum können einem Interrupt grundsätzlich keine Parameter übergeben
> werden, bzw. warum hat er keine Rückgabewerte?

Leider ist es etwas aus der Mode gekommen (Programm)Flussdiagramme zu 
zeichnen.
Leider...

Denn, wenn man das mal tun würde, dann würde sich fix zeigen, dass für 
die Anwendung und für die (Hardware)ISR, 2 völlig  unabhängige Abläufe 
gezeichnet werden wollen. Da diese keinen Kontakt haben, ist eine 
direkte Parameterübergabe unmöglich.

Zum Glück, durfte ich mich Damals (TM) noch mit Datenflussdiagrammen 
rumschlagen. Ein solches würde zeigen, dass sich durch einfügen 
irgendeiner "shared Memory" Variante, sehr wohl ein Datenfluss 
realisieren lässt.
z.B. der Ringbuffer der Seriellen ist ein typisches Beispiel dafür.

von Marc V. (Firma: Vescomp) (logarithmus)


Bewertung
-1 lesenswert
nicht lesenswert
Rolf M. schrieb:
> Streng genommen haben Interrupts teilweise schon gewisse "Parameter",
> nur nicht in Form von C-Funktionsparametern, sondern zumeist in
> irgendwelchen I/O-Registern - beispielsweise bei einer UART-Receive-ISR
> das empfangene Byte.

 Streng genommen sind das keine Parameter, sondern der Zustand der
 CPU und deren Register. Eine UART-ISR benutzt normalerweise nicht die
 Timer-Register und eine Timer-ISR interessiert UDR nicht, obwohl sich
 bei beiden der Zustand wahrscheinlich geändert hat.

: Bearbeitet durch User

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.