Frage zu Interrupts

Nehmen wir an, mit einem Schalter wird ein Interrupt ausgelöst, der Beispielsweise eine Displayausgabe macht, die etwas länger dauert. Was passiert, wenn die Interruptroutine bzw. die Funktion die damit ausgeführt wird, noch aktiv ist und der selbe Interrupt ein zweites Mal ausgelöst wird. Wird der von der CPU verarbeitet? Falls ja, wann?

Wird der Interrupt eigentlich nur dann ausgelöst, wenn ein Bit von 0 auf 1 kippt oder auch bei der anderen Richtung?

BTW: Es geht um ein 8051-Derivat

MfG,

Markus

Reply to
Markus
Loading thread data ...

Markus schrieb:

Man kann zwischen pegel- und flankengetriggerten Ints unterscheiden, deren Polarität meistens programmierbar ist. Nach Auslösen eines Interrupts ist dieser zunächst gesperrt, bis die Interruptroutine (idealerweise ist sie es) explizit den Interrupt wieder freigibt. Dieser Mechanismus des Freigebens hängt vom jeweiligen Prozessor und dessen Interruptcontroller- und struktur ab, da hilft nur die HW-Beschreibung des Herstellers, steht üblicherweise alles drin. Stichwort "interrupt nesting", "nested interrupts" etc.

Welches.

- Udo

Reply to
Udo Piechottka

"Udo Piechottka"

Polarität meistens programmierbar ist.

Ach klar. Ich bin blind. Danke dir!

Interruptroutine (idealerweise ist sie es) explizit den

jeweiligen Prozessor und dessen Interruptcontroller- und

üblicherweise alles drin. Stichwort "interrupt nesting",

Man lernt nie aus..

80C552. Aber das ist auch nicht so wichtig. Das war mehr eine Grundsatzfrage die mich mal interessiert hat.

MfG,

Markus

Reply to
Markus

Deine Frage ist als Grundsatzfrage ungeeignet. Deshalb gibts für jeden Controller Handbücher, da sollt drin stehen wie Interrupts behandelt werden..

timo.

Reply to
Timo Schlick

Sicher. Aber man sollte vorher prinzipiell verstanden haben, wie Interrupts funktionieren. Der Rest ist nur die Umsetzung mit jeweiligen Eigenarten.

Mfg Falk

Reply to
Falk Brunner

Fehler: mechanische Schalter prellen. Daher lässt man sie (normalerweise) nicht selbst interrupten, sondern pollt sie im Timer-Interrupt und signalisiert erst dann "Taste gedrückt" nach oben, wenn sie einen stabilen Wert haben. Da kein Benutzer auf 20 ms genau eine Taste drücken kann, ist die Zeitverzögerung nicht störend.

Guter Stil ist es, in Interruptroutinen nur den zeitkritischen Teil der Verarbeitung zu machen, die länger dauernden Operationen erledigt dann die Hauptschleife. Die Kommunikation (welche Taste wurde gerade gedrückt => welche Aktion muss ausgelöst werden) übernehmen dann globale Variablen.

--
cheers, J"org               .-.-.   --... ...--   -.. .  DL8DTL

http://www.sax.de/~joerg/                        NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)
Reply to
Joerg Wunsch

Und da sind alle Interrupts gleich? Hardwaremäßig? Softwaremäßig?

Bernd

Reply to
Bernd Laengerich

Hallo Joerg,

Man kann schon. Nur muss man dann weitere Interrupts von der gleichen Quelle ueber x msec ignorieren.

--
Gruesse, Joerg

http://www.analogconsultants.com
Reply to
Joerg

Bernd Laengerich schrieb:

Na ja, manche und je nach Hardware k=F6nnen mit h=F6here Priorit=E4t niedriger Prior angelegte ISP unterbrechen, manche lassen sich unterdr=FCcken, andere wieder nicht (NMI) usw. Ich glaube das Gemeinsame besch=F6pft sich oft darin, dass Interrupt mehr oder weniger asynchron, die ,,normale" Abarbeitungss=E4quent unterbrechende Ereignisse sind, welche ein wie auch immer ausgepr=E4gtes ,,Unterprogramm" einzuschieben um dann die Unterbrochene Sequenz fortzusetzen, als sei nichts gewesen=20 tt.

Reply to
Juergen

Joerg schrieb:

Ist nur nicht sehr sinnvoll. In aller Regel braucht man für viele andere Sachen sowieso eine Zeitbasis, da kann man dort auch gleich die Schalter mit abfragen.

Aber ich schrieb auch ,normalerweise': um einen Controller per Tastendruck aus dem Tiefschlaf zu befördern, ist natürlich ein Interrupt, der von der Taste ausgelöst wird, sinnvoll. Danach kann man in den Poll-Modus verfallen, bis der Prozessor wieder schlafen gelegt wird.

--
cheers, J"org               .-.-.   --... ...--   -.. .  DL8DTL

http://www.sax.de/~joerg/                        NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)
Reply to
Joerg Wunsch

Juergen schrieb:

Ja, aber das beantwortet keineswegs die Fragen, wie sie hier gestellt wurden. Und danach hilft nur ein Datenbuch weiter, es gibt da wirklich krumme Konzepte.

Bernd

Reply to
Bernd Laengerich

Bernd Laengerich schrieb:

Ich wollte die Frage ja auch nicht vorrangig beantworten, das war bereits ausreichend geschehen. Ich wollte verhindern das der Eindruck entstehen k=F6nnte Interrupt sei gleich Interrupt. Bis auf die Tatsache, dass sie in der Regel etwas Unterbrechen, sind sie sehr verschieden Implementiert und man muss von Fall zu Fall das Beste draus machen.

Gerade bei den in diesem Thread noch angesprochenen Powersavemode bzw. das daraus wieder Erwachens, sind fast immer interruptartige Implementierungen vorzuziehen, wenn nicht sogar die einzig m=F6glichen.

tt.

Reply to
Juergen

Juergen schrieb:

Genau darum ging es, deshalb meine provokante Frage an Falk, ob er bei seiner Aussage, man solle erstmal Interrupts generell verstanden haben, meine, daß der Satz "Kennste einen, kennste alle" gelte.

Bernd

Reply to
Bernd Laengerich

Im Prinzip Ja.

Wesentliche unterscheidung ist eben flanken/levelgetriggert sowie Verschachtelte oder nichtverschachtelte Interrupts (Prioritäten)

MfG Falk

Reply to
Falk Brunner

Bernd Laengerich schrieb:

Würde ich im wesentlichen schon so gelten lassen. Klar, kleine Gemeinheiten und Stolperfallen gibts immer. So what.

MfG Falk

Reply to
Falk Brunner

Hallo Falk,

Dann sollte man noch aufpassen, dass sich die Interrupts nicht gegenseitig das Leben schwer machen und einer kommt, waehrend ein anderer mit hoher Prioritaet noch nicht abgearbeitet war. Das ist mir gerade beim MSP430F2013 im Eifer des Gefechts passiert. Aber dafuer gibt es ja Hardware-Tests und ich hatte natuerlich noch nichts drangehaengt, wo es einen Knall haette geben koennen.

--
Gruesse, Joerg

http://www.analogconsultants.com
Reply to
Joerg

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.