Diskussion:Interrupt

message: Diesen Hinweis bitte nicht entfernen oder archivieren und immer an erster Stelle auf dieser Diskussionsseite belassen.
Die Artikel Interrupt und Unterbrechungsanforderung haben sich thematisch überschnitten. Daher wurden aus dem Artikel Unterbrechungsanforderung einige Textpassagen übernommen und in Interrupt eingefügt.
* hier findet sich der Artikel Unterbrechungsanforderung zum Zeitpunkt der Übernahme
* hier findet sich die zusammengefasste Versionsgeschichte des Artikels Unterbrechungsanforderung.
Damit werden die Lizenzbestimmungen der GNU-Lizenz für freie Dokumentation (GNU FDL) und der CC-BY-SA 3.0 gewahrt.Darian (Diskussion) 01:05, 30. Aug. 2016 (CEST)
thread_title:  Lizenzhinweis 

message: Ohne auf den Inhalt einzugehen mus ich sagen, dass die Struktur sehr unübersichtlich ist. Als ich die Seite gesehen habe hatte ich gleich keine Lust mehr weiterzulesen, weil mir nur ein riesen Text entgegengeworfen wurde. Vielleicht wäre eine sinnvollere Einteilung des Inhalts machbar. --77.2.209.57 13:18, 11. Jan. 2008 (CET)
replies: text: Umm, neue Punkte bitte immer unten anhängen und nicht oben reinklemmen. - Das Problem hat auch damit zu tun, dass es einen Parallelartikel gibt (siehe Box am Anfang), der zwar übersichtlicher gegliedert ist, aber weniger ausführlich ist. D. h. irgendjemand wird sich irgendwann mal aufraffen, aus diesen beiden Artikeln einen schönen, runden zu machen und dabei alle diese Probleme mit abzuarbeiten. Aber das ist so viel Aufwand, da sind alle wohl bisher davor zurückgeschreckt und haben erstmal gar nichts gemacht. Seufz, ich ja auch nicht. --PeterFrankfurt 22:31, 11. Jan. 2008 (CET)
replies: text: Sollte nach der Zusammenführung jetzt besser sein - Feedback ist erwünscht :-)  Gruß, Darian (Diskussion) 01:06, 30. Aug. 2016 (CEST)
thread_title:  Struktur des Artikels 

message: Kommentar zum Textteil
'Insbesondere bei hardwarenahen ereignisgesteuerten Anwendungen, wie sie z. B. in eingebetteten Systemen üblich sind, wird u. U. praktisch die gesamte Programmausführung des Systems in die Interrupt-Routinen (bzw. in von diesen angestoßene Tasks) verlegt.'
Von der Softwarearchitektur ist es auf jeden Fall nicht sinnvoll gesammte Programmausführungen in die ISR zu legen. Das blockiert das System unnötig. Wenn man im ISR Kontext abarbeiten muss, verwendet man einen FORK Mechanismus, der z.B. über Queuing nach der Erstbearbeitung der Datenregister die Bearbeitung des Restes vor dem letzten 'Return from Tnterrupt' unter 'enable IRQ' wieder aufnimmt. Dann sind alle IRQs bearbeitet, aber noch nicht in den Mainstream zurückgekehrt. Selbstvertändlich muss das Queueing auch das Reentern dieses Teils der Abarbeitung verhindern, was relativ einfach möglich ist. Der theoretische Unterbau dazu ist etwas schwierig, die Realisierung jedoch aus eigener Erfahrung letztendlich mit wenigen instruktionen zu erledigen. Große Betriebssysteme haben ähnliche Mechanismen integriert. 15.Okt 2007 (RDIE)
:All dies ist natürlich extrem vom jeweiligen Prozessor und dem (falls überhaupt vorhandenen) Betriebssystem abhängig. Die Bandbreite gerade bei Mikrocontrollern (4 bis 64 Bit breit, 256 Byte bis 16 MB RAM oder noch mehr) ist halt immens. Hat der Prozessor selbst überhaupt mehr als einen Interrupt? Zusätzlich kann man auch noch HW- und SW-Interrupts (Traps) unterscheiden. Ich kann mir nach meiner Erfahrung mit Mikrocontrollern durchaus Fälle vorstellen, in denen das OS aus einer winzigen Hauptschleife besteht, in der vielleicht irgendein Timer (Watchdog) gepflegt wird, und die eigentliche Arbeit erfolgt dann ausschließlich eventgesteuert nach Interrupt(s). Das ist bestimmt nicht die Regel, aber ich würde es nicht für ungewöhnlich halten. --PeterFrankfurt 01:10, 16. Okt. 2007 (CEST)
replies: text: Da denkst Du zu allgemein/kompliziert. Gerade im Mikrocontrollerbereich hat man es manchmal mit allereinfachsten Aufgabenstellungen zu tun. Heutzutage steckt in manchen Autos doch fast schon hinter jeder LED ein eigener Mikrocontroller. Die haben dann nur einen einzigen Interrupt und scheren sich nicht um hohe Theorie, bei der einfachen Struktur ist einfacher dann auch sicherer, da lässt man sogar aus Sicherheitsgründen jeden Overhead an OS weg. Da läuft die pure Anwendung und sonst fast nichts. --PeterFrankfurt 00:56, 17. Okt. 2007 (CEST)

text: Natürlich Rücksprung, aber oft in eine weitgehend leere Idle-Schleife. Und zum allgemeinen Artikel: Gerade darum darf man doch nicht alles auf ein einzelnes Konstruktionsprinzip einengen. Und wenn ich mir die Stückzahlen ansehe, die bei solchen Mikrocontrollern in Autos oder noch einfacheren Haushaltsgeräten anfallen, dann sind das womöglich keineswegs Sonderfälle, sondern die große Mehrheit... Wie gesagt, es gibt beides, man darf nur nichts davon als "unsinnig" unberechtigterweise ausschließen. --PeterFrankfurt 02:03, 18. Okt. 2007 (CEST)

text: Der "Mainstreamcode" besteht nicht lediglich bloß aus einer Schleife, sondern idealerweise auch aus einer Schlaffunktion, die den Mikrocontroller schlafen legt, bis ein Interrupt ihn wieder aus dem Schlaf holt. Denn das spart Energie und ist besser als nur eine Schleife. --84.158.122.178 23:27, 6. Jan. 2022 (CET)
thread_title:  Programmausführung im Interrupt ? 

message: Hier steht, es gibt insgesamt 256 Interrupts... Sind diese Interrupts 256 fest vorgeschriebene, "eingebrannte" Routinen, oder kann man seine eigenen Interrupts schreiben? Danke, --Abdull 22:25, 19. Apr 2005 (CEST)
replies: text: Man kann seine eigenen Interrupts schreiben! Aber das Betriebssystem legt eine Schale drumrum (Stichwort protected mode). --HartmutS 00:57, 12. Feb 2006 (CET)
replies: text: Nicht, wenn man in DOS Arbeitet (stichwort Real Mode). Allerdings gibt es sehr wohl interrupts, die für bestimmte Aufgaben reserviert sind, z.B. die Interrupts, welche den IRQs entsprechen oder Int 19h. Btw, Interrupts sind nicht das selbe wie IRQs, es gibt 256 Interrupts (00h-FFh), aber nur 16 IRQs (0-15, man könnte aber auch statt dessen 0h-Fh schreiben. Diese IRQs entsprechen den Interrupts 69h-77h). --MrBurns 23:23, 16. Okt. 2007 (CEST)

text: Dass die ersten 31 Interrupts alle reserved (das bedeutet im Prinzip unbenutzt) sind halte ich für ein Gerücht. Z.B. erfüllen die Interrupts 19h (=25) und 13h (=19) wichtige Funktionen. Für letzeren gibst sogar einen Artikel bei der englischen Wikipedia. Es gibt irgendwo eine Seite, wo alle mlöglichen interrupt-Aufrufe aufgelistet sind (also nicht nur die Vektoren), aber ich hab die URL vergessen. --MrBurns 02:52, 22. Jan. 2010 (CET)
replies: text: PS: Ich hab die Seite gefunden: . Es handelt sich um Ralf Brown's Interrupt List. --MrBurns 03:43, 22. Jan. 2010 (CET)
thread_title:  256 IRQs 

message: Warum wird hier, daß das Wort aus dem Lateinischen kommt. Das deutsche Fachwort Interrupt kommt doch aus dem Englischen. 
: Aber es ist richtig und informativ, dass auch im Latein von Interrupt geredet wird! --HartmutS 00:57, 12. Feb 2006 (CET)
replies: text: Interrupt kommt aber sicher vom englischen, weil to interrupt heißt auf englsich unterbrechen und wie wohl jedem bekannt ist kommt die x86-Architektur genauso wie so ziemlich jede andere Computerarchitektur aus Amerika. --MrBurns 23:26, 16. Okt. 2007 (CEST)
thread_title:  latein ? 

message: Der Interrupt Controller löst die Interrupts nicht aus. Er kümmert sich lediglich darum, dass Interrupts mit verschiedenen Prioritäten korrekt (d.h. in der richtigen Reihenfolge) abgearbeitet werden.
Das tut er, indem er im Interruptzyklus die entsprechenden Vektoren auf den Datenbus legt. Damit der Interruptzyklus ausgelöst wird, muss der Controller (INTEL Systeme) selbstverständlich das Interruptsignal am CPU Eingang setzen, den Interrupt also auslösen. Allerdings hat er natürlich seinerseits vorher entsprechende Fertigsignale von den angeschlossenen Geräten bekommen, die ihn dazu veranlassen. (24.10.2007 RDIE)
Diesem Einwand kann ich nur zustimmen. Im Artikel entsteht der Eindruck, dass jedes interruptfähige Gerät über einen Interruptcontroller verfügen muss. Dieser existiert jedoch i.d.R. nur einmal im System und arbeitet Interrupts ab. -- Johann Uhrmann 11:58, 6. Jan. 2009 (CET)
thread_title:  Interrupt Controller 

message: Was bedeutet es, wenn ein Interrupt "maskiert" ist? -- 84.141.243.127 23:23, 2. Okt 2006 (CEST)
replies: text: Ach, hab's gerade selber herausgefunden. Wenn man nur bestimmte Interrupts zulassen will, muss man eine Maske aus einzelnen Bits erstellen, die angeben, ob die verschiedenen Interrupts gesperrt sind, oder nicht. Nicht maskierbare Interrupts lassen sich nicht softwareseitig sperren. Das könnte dem Artikel eventuell noch hinzugefügt werden. -- 84.141.243.127 02:36, 3. Okt 2006 (CEST)
thread_title:  Maskierte Interrupts? 

message: Insbesondere früher, als USB und so noch nicht so verbreitet war, hörte man den Begriff „Interrupt“ im Zusammenhang mit dem Einbau von ISA- oder PCI-Erweiterungen in Rechner. Dabei hieß es oft (so oder so ähnlich), dass eine Hardware-Karte soundsoviel Interrupts belegt bzw. das durch Umjumpern ein Interrupt freigegeben werden kann. Diese Interrupt haben verschiedene Nummern.
Ich habe nie verstanden, was es mit diesen Interrupts auf sich hat. Gibt es ein System zwischen Prozessor und den Slots, das eventuelle IRQs der Kartenhardware an den Prozessor weiterreicht? Wie ist dieses System standardisiert? Warum kann eine Hardware auch benutzt werden, wenn auf den Interrupt verzichtet wird? Was bedeutet der in diesem Zusammenhang auftretende Begriff vom Teilen der Interrupts?
Werden die IRQs direkt an den Prozessor weitergereicht?
Oder ist das ganze ein System von Softwareinterrupts (im Sinne von Systemaufrufen über einen IRQ-Mechanismus bzw. SW-Traps), über die die Treibersoftware mit der Hardware zusammenarbeitet?
(Was) hat es mit Interruptnummern zu tun, die man manchmal in BIOS-Einstellungen sieht („Festplatte schreiben über Interrupt 0xXY“, oder so ähnlich).
Insgesamt habe ich den Eindruck, dass im Bereich der BIOS-Terminologie das Wort „Interrupt“ bzw. „Interrupt Request“ (IRQ) in einem leicht anderen, wenn auch nicht komplett anderen, Zusammenhang als dem hier im Artikel genannten (der mir durchaus geläufig ist) gebraucht wird.
-- Pemu 18:04, 31. Jan. 2007 (CET)
replies: text: Gibt es ein System zwischen Prozessor und den Slots, das eventuelle IRQs der Kartenhardware an den Prozessor weiterreicht? Dieses System heißt PC-Interruptcontroller.  Warum kann eine Hardware auch benutzt werden, wenn auf den Interrupt verzichtet wird? Dies ist in den meisten Fällen nicht sinnvoll möglich. Manche Geräte können auch per Polling betrieben werden, z.B. der Druckerport. Manche Geräte benutzen Interrupts nur für Spezialzwecke, wie z.B. manche Grafikkarten. Was bedeutet der in diesem Zusammenhang auftretende Begriff vom Teilen der Interrupts? Dies bedeutet, daß verschiedene Geräte ihre Interrupts über dieselbe Signalleitung anmelden. Da die ISA-Schrotti-Technik dafür elektrisch nicht ausgelegt war, funktionierte die Angelegenheit nicht. Daher gab es mehrere Leitungen, von denen jede Karte genau eine erhalten mußte,  und ein lustiges Konfigurationspuzzle. Oder die IRQ-Leitung wurde trotzdem gesharet, dann war aber gleichzeitiger Betrieb unmöglich (waren nicht COM1 und COM3 standardmäßig auf demselben Interrupt? Urgh). Die Nummern (IRQ0 bis IRQ7, bei ISA-16 bis IRQ15) sind die Signalnummern am PIC/an den PICs (Programmable Interrupt Controller). Sollte das nicht alles unter ISA und PIC stehen? (Was) hat es mit Interruptnummern zu tun, die man manchmal in BIOS-Einstellungen sieht („Festplatte schreiben über Interrupt 0xXY“, oder so ähnlich). 0x13? 0x13 ist der BIOS-Software-Interrupt zum Lesen und Schreiben von Sektoren. IDE-Controller haben natürlich auch einen Interrupt im obigen Sinne, normalerweise IRQ14 und IRQ15. --88.74.189.122 21:29, 28. Dez. 2009 (CET)
thread_title:  Interrupt und BIOS 

message: Die Ausführlichkeit der Beschreibung ist doch etwas mager. 
Bitte bei der weiteren Ergänzung an der Englischen Version 
orientieren, die ist wirlich super:     http://en.wikipedia.org/wiki/Interrupt
Z.B. habe ich vermisst dass nichts über level triggered oder edge triggered drinsteht.
Edge- und leveltriggered sind Spezialitäten des (UR-) Interruptcontrollers, die wohl aus Kompatibiltätsgründen geblieben sind. Edge detektiert die Änderungen am Eingang. Das sieht zwar einfach aus, hat aber Probleme, weil der Interrupt auch gelöscht werden muss. Wenn in die kleine Zeitlücke zwischen Erkennung und Löschung ein neuer Interrupt fällt, wird dieser mit gelöscht. Bei 'level' kann das nicht passieren, weil er danach immer noch ansteht. Bei Level ist das Problem, wenn die Quelle des Interrupt nicht bekannt ist und nicht abgeschaltet werden kann... Besonders schwierig wird es, wenn - wie heute üblich - mehrere Devices auf einem Interrupteingang arbeiten. Spezielle Softwarekonzepte sind möglich, um diese Probleme abzufangen. Deshalb haben Betriebssystemhersteller diesen Mechanismus im System integriert und erlauben Treibern teilweise nur noch über Schnittstellen zuzugreifen. 20:40 16.Okt 2007 (RDIE)
:Fuer x86-PCs kann ich nur diese einzigartige Quelle empfehlen : http://www.cs.cmu.edu/~ralf/files.html - das Ding ist fuer hardware- und/oder systemnahes Programmieren Gold wert, was fuer CP/M und z80-Asm der Rodnay Zaks ist, ist Ralf Braun fuer IMB-PCs in allen Varianten. Sollte man das hier vielleicht verlinken, auch wenn die Begriffserklaerung Interrupt ja eigentlich systemunabhaengig ist? -- 194.126.228.2 17:34, 22. Mär. 2013 (CET)
thread_title:  Ausführlichkeit der beschreibung 

message: Der Abschnitt Maskierbarer Interrupt sollte nochmal durchgegangen werden.
1. Sollte erkärt werden, sofern es kein Fehler ist, warum der Pin "meistens mit NMI bezeichnet" ist.
2. ist diese Beschreibung IMHO viel zu x86-spezifisch. 
-- Pemu (Diskussion) 00:11, 1. Jul. 2020 (CEST)
replies: text: Der ganze Abschnitt ist Müll, da falsch bzw. völlig am Thema vorbei. Eigentlich sollte da erst einmal stehen, was ein maskierbarer Interrupt ist. Ich kenne übrigens die Antwort, aber ich werde den Artikel nicht verbessern. Stattdessen setze ich meinen Counter weiter hoch. --84.158.117.10 19:28, 28. Apr. 2023 (CEST)
thread_title:  Überarbeiten 

message: Im Artikel heißt es: 
"Erscheint an diesem meistens mit NMI bezeichnete Pin ein Signal ([Vcc]) während Interrupts aktuell nicht maskiert sind (bei x86 ist dann das Interrupt-Flag (IF) gesetzt), so maskiert die CPU alle maskierbaren Interrupts und liest die Nummer des angeforderten Interrupts vom Systembus (Intel64-Hardware unterscheidet 256 Interrupt-Nummern). Dort muss der Anforderer die Nummer vor der Anforderung anlegen."
Falls ich mich nicht irre, sollte man vielleicht im Artikel erwähnen, dass es nicht möglich ist, dass zwei Geräte zur gleichen Zeit ihre gewünschte Interrruptnummer im Systembus ablegen können, denn sonst könnte Gerät B die angelegte Interruptnummer von Gerät B überschreiben, bevor Gerät B der CPU Bescheid sagt.
Wenn ich mich nicht irre, dann darf nur ein Gerät den Systembus zu selben Zeit nutzen, womit eine Synchronisierung und atomare Operation sichergestellt wäre und das Problem somit nicht auftreten kann. Falls das nicht der Fall sein sollte, dann sollte man im Artikel erklären, wie dieses Problem behandelt wird. --84.158.122.178 21:39, 6. Jan. 2022 (CET)
replies: text: Erfolgt an einem x86 am NMI (Non-maskable interrupt) ein Signal so wird der INT 2 ausgelöst. Für die nicht maskierbaren Interrupts gibt es die Leitung INTR (Interrupt Request). An diesem hängt beim IBM PC ein Intel 8259. später hat man eine Kaskade an eine Leitung gebaut. Theoretisch kann man mit 9 8259 Chips 64 Hardwareinterrupts sich selbst verdrahten. --79.206.196.40 13:56, 20. Aug. 2023 (CEST)
thread_title:  Gleichzeitiges Anlegen einer Interruptnummer durch zwei verschiedene Geräte