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
Moin, was sagt denn das Reference Manual des konkreten 8051 Derivats dazu? z.B. hier ein Auszug aus dem RM des Silicon Labs EFM8BB1:
1 | 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
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?
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?
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:
1 | ....
|
2 | // critical section
|
3 | ET0=0; |
4 | ....
|
5 | // critical ends
|
6 | ET0=1; |
7 | ...
|
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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.
>> 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.
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.