zu viele Interrupts?

[flyingwolf (Gast)]

Hallo Leute
Wenn ich mehrere Interrupts z.B. externe verwende, macht es dann Sinn
während der Interruptroutine die Interrupts zu sperren um ein
merhfaches auftreten zu verhindern?
Wie wirkt sich das z.B. af den Timer aus, der den Takt für die Interne
Uhr birgt?
Wie handhabt ihr das?

[A.K. (Gast)]

Plattform?

[johnny.m (Gast)]

Was fürn µC??? Bei den AVRs werden die Interrupts automatisch
(hardwaremäßig) während einer ISR gesperrt...

[flyingwolf (Gast)]

Die Frage war allgemein gemeint, aber bei den Prozessoren geht es so um
die AVR-Megas und die Plattform wird in der Regel GCC sein.

[johnny.m (Gast)]

...Und ob es im Einzelfall Sinn macht, hängt von der Anwendung ab.
Verschachtelte Interrupts sind gefährlich (möglicher Stacküberlauf ->
Systemabsturz) und sollten nur dann eingesetzt werden, wenns gar nicht
anders geht und der Programmierer genau weiß, was er tut. Grundsätzlich
sollte in einer ISR nur absolut notwendiger Code stehen und der Rest im
Hauptprogramm abgearbeitet werden, damit zeitkritische Interrupts auch
korrekt abgearbeitet werden können. Wenn man einige Grundregeln
beachtet (keine Warteschleifen und Funktionsaufrufe in ISRs), kann man
die Verwendung von verschachtelten Interrupts fast immer vermeiden.

P.S.: Da es sich tatsächlich um AVRs handelt, siehe oben...

[A.K. (Gast)]

Sperren geht automatisch. Entsperren geht in vielen Fällen, nämlich dort
wo mit der Routine automatisch der Interrupt zurückgesetzt wird.

Theoretisch kann man also vorne in manchen Interrupt-Routinen die
Interrupts wieder einschalten. Praktisch muss man dann aufpassen, dass
man genug Stack hat, um bei alle potentiell gleichzeitig auftretenden
Interrupts nicht abzusaufen.

Sollte man also nur machen, wenn's wirklich nicht anders geht.

[Sebastian Heyn (Gast)]

habe das schon gemacht mit nem avr einfach als ersten aufruf im
interrupt SEI aufrufen. Das problem ist (ich hatte infrarotsignale
ausgewertet, und benötigte timer+interrupt) wenn mal kurze unerwartete
flanken auftauchen kann das den programmablauf ungewollt beeinflussen,
besonders wenn zu oft interrupts etc auftreten..  habe dann für die
kritischen sachen einfach nen tinyAVR dazugenommen. dann ging es

[flyingwolf (Gast)]

Verstehe ic das recht?
Beim AVR macht es keinen Sinn die Int in der ISR zu blockieren, weil
keine Int abgearbeitet werden, wenn sich das Programm in einer ISR
befindet?

[A.K. (Gast)]

Ja.

[johnny.m (Gast)]

Es macht keinen Sinn, sie zu blockieren, weil sie automatisch blockiert
werden. Beim Einsprung in die ISR löscht die Hardware automatisch das
I-Bit im SREG (was man sonst mit cli machen müsste) und setzt es erst
dann wieder, wenn die ISR abgeschlossen ist (in Assembler mit reti, in
C mit der abschließenden '}').

Wie oben gesagt, man kann nested Interrupts in bestimmten Fällen
zulassen, muss sich aber über sein tun im klaren sein (Beispiel: Ein
Timer-Interrupt, der sich selbst unterbrechen kann und der sich
schneller wiederholt, als die zugehörige ISR abgearbeitet ist,
unterbricht ständig die eigene ISR [Das auslösende Flag wird ja
ebenfalls bereits beim Einsprung in die ISR automatisch gelöscht und
kann durch ein erneutes Ereignis prinzipiell sofort wieder gesetzt
werden], was bereits nach kurzer Zeit zu einem Stacküberlauf führt).
Deshalb die Grundregeln für die Interrupt-Bearbeitung beachten (ISR
kurz halten, keine Funktionsaufrufe und Schleifen, irgendeine Variable
in der ISR als Job-Flag setzen und im Hauptprogramm abfragen), dann
kann eigentlich nicht viel schief gehen...