Timer enable/disable innerhalb Timerfunktion

Gast #715785
Lesenswert?
• ▲
▼
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.:
1
main()
2
{
3
init();
4

5
timer_enable;
6

7
for(){};
8

9
}
10

11

12
void timer(void)
13
{
14
timer_disable;
15

16
//tu_was...//
17

18
timer_enable; // <- kritische STELLE?????
19
}
#715813
Lesenswert?
• ▲
▼
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
#715827
Lesenswert?
• ▲
▼
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?
#715841
Lesenswert?
• ▲
▼
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
#715862
Lesenswert?
• ▲
▼
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
Gast #715869
Lesenswert?
• ▲
▼
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?
Gast #715874
Lesenswert?
• ▲
▼
@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
#715881
Lesenswert?
• ▲
▼
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.

...
Gast #715885
Lesenswert?
• ▲
▼
>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).

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

oder

Mit Google-Account einloggen

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren