Timer enable/disable innerhalb Timerfunktion

[Timi (Gast)]

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.:

main()
{
init();

timer_enable;

for(){};

}


void timer(void)
{
timer_disable;

//tu_was...//

timer_enable; // <- kritische STELLE?????
}

[Peter D. (peda)]

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

[Timi (Gast)]

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.

[Andreas K. (a-k)]

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 (Gast)]

ATMega32

[Andreas K. (a-k)]

Da sind in einer Interrupt-Routine alle Interrupts abgeschaltet. Ist 
also überflüssig.

[Timi (Gast)]

gut zu wissen :-)..

Vielen Dank

[Peter D. (peda)]

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

[Timi (Gast)]

@Peter

jetzt bin ich aber verwirrt :-$%§&

[Hagen R. (hagen)]

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

[Timi (Gast)]

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?

[Timi (Gast)]

@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

[Peter D. (peda)]

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

[Hannes L. (hannes)]

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.

...

[AVRFan (Gast)]

>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).