Servus,
in der Suche bin nicht fündig geworden.
Ein Timer liefert alle 100ys Interrupt und springt in die
Timer-Funktion.
Innerhalb dieser Funktion wird am Anfang der Timer deaktiviere und am
Ende wieder aktiviert.
Kann es passieren, dass bevor ich aus der Funktion raus bin noch mal
Interrupt kommt und in der Funktion eine "Unterfunkiton" entsteht (so
eine Art unendliche Versachtelung, wo man nicht mehr rauskommt)..
---------------
Bsp.:
Timi wrote:
> Kann es passieren, dass bevor ich aus der Funktion raus bin noch mal> Interrupt kommt und in der Funktion eine "Unterfunkiton" entsteht (so> eine Art unendliche Versachtelung, wo man nicht mehr rauskommt)..
Ich kenne keine Architektur, die ohne Tricks Interrupts sich selbst
unterbrechen läßt.
Irgendwelche Sperren sind also völlig überflüssig.
Will man das doch, braucht man z.B. beim 8051 ein extra RETI im
Interrupthandler.
Bei den ARMs kann es so scheinen, als das Interrupts sich blockieren.
Dort werden pending Interrupts hintereinander ausgeführt, ohne noch eine
Instruktion des Main dazwischen auszuführen.
Die ARM Cortex M3 sparen sich dabei sogar das Popen/Pushen der Register.
Peter
ja aber wenn ich in der Funktion bin, bleibt der Timer doch gar nicht
stehen (oder etwa doch ?!?!).. Und wenn der Timer bei 0 landet wird
Interrupt erzeugt und springt in die ISR.
Timi wrote:
> ja aber wenn ich in der Funktion bin, bleibt der Timer doch gar nicht> stehen (oder etwa doch ?!?!).. Und wenn der Timer bei 0 landet wird> Interrupt erzeugt und springt in die ISR.
Üblicherweise sind in einer Interrupt-Routine entweder alle Interrupts
automatisch abgeschaltet, oder zumindest der betreffende Interrupt und
niedriger priorisierte.
Welche Architektur?
Timi wrote:
> ja aber wenn ich in der Funktion bin, bleibt der Timer doch gar nicht> stehen (oder etwa doch ?!?!)..
Natürlich nicht!
Viele Programmaufgaben erfordern exakte Zeiteinhaltung und da wäre es
äußerst blöd, wenn der Timer für eine zufällige von der
Programmausführung abhängige Zeit stehen bleiben würde.
Der Timer muß weiterlaufen, das ist der Sinn eines Hardware-Timers!
Peter
Timer ist was anderes als Timer-Interrupt. Der Timer läuft natürlich
weiter auch wenn du gerade in der Timer-Interrupr-Service-Routine
drinnen bist. Sollte der Timer in diesem Moment erneut eine
Interrupt-Anforderung auslösen so wird erstmal in einem Register nur ein
Bit gesetzt. Erst wenn die aktuelle ISR mit RETI beendet wird werden
diese IRQ-Anfoderungsbits durch die CPU ausgewertet und falls eines
gesetzt ist in die installierte ISR gesprungen.
Gruß Hagen
dann ist es richtig, dass innerhal der Funktion der Timer-Interrupt
ausgelöst wird und bevor die Funtion fertig wird eine Versachtelung
stattfindet..
Dann zu meiner ursprüngliche Frage:
Erst am Ende der Funktion wird der Timer aktiviert. Kann es trotzdem
vorkommen, dass bevor man aus der Funktion rausgeht ein Timer-Interrupt
ausgelöst wird?
@Hagen
das finde ich gut erklärt :-)
dh. auch wenn Timer-Interrupt ausgelöst wird, wird es in einer "Queue"
gespeichert und später ausgeführt.
Dann ist mir auch klar, dass Interrupt mit hoher Prio durchkommen weil
NICHT ALLE Interrupt deaktiviert sind :-D
Ein Timerinterrupt macht nur dann Sinn, wenn man das Timerintervall so
groß wählt, daß der Interrupthandler darin garantiert (worst case)
abgearbeitet wird.
Ansonsten hat man keinen Timer, sondern einen Zufallsgenerator.
Peter
Timi wrote:
> dh. auch wenn Timer-Interrupt ausgelöst wird, wird es in einer "Queue"> gespeichert und später ausgeführt.
Nein, keine Warteschlange, nur ein Bit. Schau doch einfach mal ins
Datenblatt, da wird alles sehr genau erklärt.
>> Dann ist mir auch klar, dass Interrupt mit hoher Prio durchkommen weil> NICHT ALLE Interrupt deaktiviert sind :-D
Der AVR hat keine Interrupt-Prioritäten, siehe Datenblatt.
...
>dann ist es richtig, dass innerhal der Funktion der Timer-Interrupt>ausgelöst wird und bevor die Funtion fertig wird eine Versachtelung>stattfindet..
Dafür muss der Timer aber erstmal soweit zählen, dass die "nächste"
Timer-Interruptbedingung auch eintritt. Weil er dafür üblicherweise
recht "lange" braucht, ist das Programm längst wieder aus dem Interrupt
draußen, bevor das passiert (Interrupts sind ja grundsätzlich kurz zu
halten).
Eine eigene Frage?
Dieser Thread ist über 18 Jahre alt.
Stell sie in einem eigenen Thread – dort lesen mehr Leute mit, und sie wird öfter und schneller beantwortet.
