Gefahren bei schreiben ins Register TIMSK?

[fambi_mail]

Hallo,

Durch das Register TIMSK werden die Interrupts aller Timer gesteuert.

Nun habe ich z.B. meinen Timer so eingestellt, dass er alle 10 ms eine capture match interrupt aulöst und in die entsprechende ISR springt. Um die ISR kurz zu halten, setzte ich nur ein Flag welches ich dann in der main routine abrage um verschiedene Berechnungen auszuführen.

Nun kann es aber sein, dass diese Berechnungen nicht durchgeführt werden sollen. Aus diesem Grund lösche ich das entsprechen Bit im Register TIMSK, damit kein Interrupt generiert wird.

Meine Frage: darf TIMSK jederzeit verändert werden ohne vorher alle IRQs mit cli() zu deaktivieren?

[linux_80]

Hallo,
was heisst dürfen, es ist möglich und es scheint soweit keiner was dagegen zu haben ;-)

Es kann max. passieren, das während dem ändern des Bit eine IRQ auftritt.

[dennisstrehl]

Also das einzige was ich darüber finde ist folgender Satz im Datenblatt (Tiny15L):


When changing the COM1A1/COM1A0, bits, the Output Compare 1A Interrupt must be disabled by clearing its Interrupt Enable bit in the TIMSK register. Otherwise an Interrupt can occur when these bits are changed.

Abgesehen davon schiebt man, zumindest beim AtTiny15, die Interrupts durch deaktivieren, sei es durch cli oder durch löschen des entsprechenden IE-Bits, lediglich auf, wenn man dann mit sei oder durch aktivieren des entsprechenden IE-Bits den Interrupt wieder aktiviert, wird er dann sofort ausgeführt.

MfG

[linux_80]

Das deaktivieren des IRQ wird weniger das Problem sein, evtl. sollte man vor dem aktivieren zuerst das Interrupt-Flag löschen, damit kein ungeplanter IRQ auftritt.

[SprinterSB]

Meine Frage: darf TIMSK jederzeit verändert werden ohne vorher alle IRQs mit cli() zu deaktivieren?

Das kommt auf deine Applikation an. Die AVR-Hardware verändert TIMSK nicht. Das einzige, was TIMSK ändern kann, ist deine Applikation.
Wenn also von unterschiedlichen Interrupt-Ebenen aus auf TIMSK zugegriffen wird, muss der Zugriff auf den unteren Ebenen atomar sein.

Siehe auch:
https://www.roboternetz.de/wissen/index.php/Fallstricke_bei_der_C-Programmierung#Nicht-atomarer_Code