8051: Timer ISR sperren und nachholen lassen

[warp9 (Gast)]

Hallo,

eine Verständnisfrage zum 8051. Timer 0 ist im 16 Bit Timer Modus 
konfiguriert und läuft. Er soll normalerweise bei Overflow einen 
Interrupt auslösen. Tut er auch.

Nun möchte ich für einen kritischen Abschnitt temporär nur den Timer 
Interrupt sperren. Falls währenddessen ein Overflow auftritt, möchte ich 
die Serviceroutine nachholen.

Wenn ich also temporär IEN0.1 (ET0) lösche, aber IEN0.7 (EAL) gesetzt 
lasse, was passiert wenn ich IE0.1 wieder setze und zwischendurch der 
Überlauf passiert ist?

Nach meiner Beobachtung wird zwar das Überlaufflag TCON.5 (TF0) wie 
erwartet gesetzt, aber die Serviceroutine wird nicht nachgeholt. Mir 
bleibt also nichts anderes übrig als entweder EAL temporär zu löschen 
und damit auf alle Interrupts zu verzichten, oder TF0 am Ende meines 
kritischen Abschnitts manuell zu überprüfen. Korrekt?

Danke

[Michael F. (Firma: IAR Systems) (michael_iar)]

Moin,

was sagt denn das Reference Manual des konkreten 8051 Derivats dazu?

z.B. hier ein Auszug aus dem RM des Silicon Labs EFM8BB1:

If interrupts are not enabled, the interrupt-pending flag is ignored by the hardware and program execution continues as normal. The interrupt-pending flag is set to logic 1 regardless of whether the interrupt is enabled.

Seite 40 / Kapitel 6.1: 
https://www.silabs.com/documents/public/reference-manuals/efm8bb1-rm.pdf

Danach liest es sich so, dass der Interrupt "verloren" geht, wenn beim 
Überlauf des Timers die Flags nicht entsprechend gesetzt sind.

Wie lange dauert denn die Ausführung des kritischen Abschnitts und wäre 
der "Jitter" akzeptabel, wenn Du in der Zeit den Timer anhältst?

Gruß,
Michael

[Peter D. (peda)]

warp9 schrieb:
> Nach meiner Beobachtung wird zwar das Überlaufflag TCON.5 (TF0) wie
> erwartet gesetzt, aber die Serviceroutine wird nicht nachgeholt.

Dann machst Du irgendwas falsch. Es geht definitv.
Welcher 8051 ist das konkret?

[warp9 (Gast)]

Peter D. schrieb:
> Dann machst Du irgendwas falsch. Es geht definitv.
> Welcher 8051 ist das konkret?

Der hier: 
https://www.cast-inc.com/sites/default/files/pdfs/2020-08/cast_r8051xc2-xilinx.pdf

Heißt dass, wenn ich TCON.5 (TF0) setze während TCON.5 (TF0) bereits 
gesetzt ist, sollte er sofort die ISR anspringen?

[Thomas Z. (usbman)]

warp9 schrieb:
> Heißt dass, wenn ich TCON.5 (TF0) setze während TCON.5 (TF0) bereits
> gesetzt ist, sollte er sofort die ISR anspringen?

nein so funktioniert das nicht. Der Interrupt Vector wird angesprungen 
wenn TF0 gesetzt ist und du ET0 freigibst. Das TF0 Flag musst du ja in 
der Interrupt Funktion selbst löschen.

Bespiel:

   ....
   // critical section
   ET0=0;
   ....
   // critical ends
   ET0=1;
   ...

[Peter D. (peda)]

warp9 schrieb:
> Heißt dass, wenn ich TCON.5 (TF0) setze während TCON.5 (TF0) bereits
> gesetzt ist, sollte er sofort die ISR anspringen?

Nach allen Zugriffen auf die Interruptlogik erfolgt erst noch ein Befehl 
des aktuellen Tasklevels. Das kann das Main sein oder ein Interrupt 
niederer Priorität. Das ist notwendig, da die Polling-Sequenz verworfen 
und neu ausgeführt werden muß.

"How Interrupts Are Handled

The interrupt flags are sampled at S5P2 of every machine cycle. The 
samples are polled during the following machine cycle. If one of the 
flags was in a set condition at S5P2 of the preceding cycle, the polling 
cycle will find it and the interrupt system will generate an LCALL to 
the appropriate service routine, provided this hardware-generated LCALL 
is not blocked by any of the following conditions:
1. An interrupt of equal or higher priority level is already in
progress.
2. The current (polling) cycle is not the final cycle in the execution
of the instruction in progress.
3. The instruction in progress is RETI or any write to the IE or IP
registers.

Any of these three conditions will block the generation of the LCALL to 
the interrupt service routine. Condition 2 ensures that the instruction 
in progress will be completed before vectoring to any service routine. 
Condition 3 ensures that if the instruction in progress is RETI or any 
access to IE or IP, then at least one more instruction will be executed 
before any interrupt is vectored to. The polling cycle is repeated with 
each machine cycle, and the values polled are the values that were 
present at S5P2 of the previous machine cycle. Note that if an interrupt 
flag is active but not being responded to for one of the above 
conditions, if the flag is not still active when the blocking condition 
is removed, the denied interrupt will not be serviced. In other words, 
the fact that the interrupt flag was once active but not serviced is not 
remembered. Every polling cycle is new."

Ich habe bisher nur echte 8051 (Philips, Atmel, Siemens, Intel) 
verwendet. Der Soft-Core könnte fehlerhaft sein.

[warp9 (Gast)]

Thomas Z. schrieb:
> nein so funktioniert das nicht. Der Interrupt Vector wird angesprungen
> wenn TF0 gesetzt ist und du ET0 freigibst. Das TF0 Flag musst du ja in
> der Interrupt Funktion selbst löschen.

Oops, genau das meinte ich, habe aber (copy-paste) zweimal TF0 
geschrieben.

[Thomas Z. (usbman)]

>> nein so funktioniert das nicht. Der Interrupt Vector wird angesprungen
>> wenn TF0 gesetzt ist und du ET0 freigibst. Das TF0 Flag musst du ja in
>> der Interrupt Funktion selbst löschen.
>
> Oops, genau das meinte ich, habe aber (copy-paste) zweimal TF0
> geschrieben.

das muss dann aber funktionieren siehe Beispiel. Wenn nicht hat der Core 
einen Schuss.