TIM9_SR Interrupt-Flags beim STM32F4

[m.n. (Gast)]

Hier
Beitrag "ARM: kompliziert?"
wurde über die Vorzüge eines STM32F4 diskutiert, wobei das Problem der 
atomaren Befehle angesprochen wurde. Da diese im Gegensatz zu anderen 
µCs beim STM nicht vorhanden sind, können sich Probleme bei der 
Interruptverarbeitung ergeben.

Aktuell möchte ich beim Timer9 den Überlauf, sowie beide Capture-Flags 
per Interrupt auswerten. Die Bits CC2IF, CC1IF und UIF im 
TIM9_SR-Register werden durch das zugehörige Ereignis gesetzt und müssen 
per Software (in der Interruptroutine) auf '0' gesetzt werden.

UIF löscht man entsprechend mit TIM9->SR &= 0xfffe, was durch die 
Befehle Lesen, Maskieren, Zurückschreiben nicht atomar erledigt wird.
Wird nun währenddessen ein Capture-Flag gesetzt, wird es 
'großzügigerweise' gleich mit gelöscht: das ist schlecht!

Habe ich etwas übersehen oder wie kann eine zuverlässige Auswertung der 
Flags aussehen?

[(prx) A. K. (prx)]

m.n. schrieb:
> UIF löscht man entsprechend mit TIM9->SR &= 0xfffe

Nein. Genau hinsehen. Die Bits im SR vom Timer sind vom Typ rc_w0, d.h. 
1 schreiben ist neutral, 0 löscht. Die korrekte Aktion ist also
  TIM9->SR = 0xfffe;
Wobei man das besser durch die Konstante vom Includefile ausdrückt, also
  TIM9->SR = ~TIM_irgendwas_UIF;

[m.n. (Gast)]

Danke, es war ein langer Tag heute :-)

Ich bin wohl auch schon zu verwöhnt. Als Renesas RX-Fan hat mich 
'gewurmt', dass nicht zu jedem Bit ein separater Vektor existiert und 
das Int-Flag automatisch gelöscht wird.

[(prx) A. K. (prx)]

m.n. schrieb:
> Ich bin wohl auch schon zu verwöhnt. Als Renesas RX-Fan hat mich
> 'gewurmt', dass nicht zu jedem Bit ein separater Vektor existiert und
> das Int-Flag automatisch gelöscht wird.

Wieviel Vektoren hat denn so ein RX? Da kommen bei komplexeren Devices 
ja viele hunderte von Vektoren zusammen.

[m.n. (Gast)]

A. K. schrieb:
> Wieviel Vektoren hat denn so ein RX? Da kommen bei komplexeren Devices
> ja aberhunderte von Vektoren zusammen.

Die Tabelle hat 256 Einträge, wovon z. B. beim RX62 rund 200 genutzt 
werden.

A. K. schrieb:
> 1 schreiben ist neutral

Im TIMx_SR gibt es reservierte Bits, die '0' sind und nicht verändert 
werden sollen. Das hat mich wohl irritiert und zur Maske greifen lassen.

[m.n. (Gast)]

Pedanten, für die das Datenblatt ein heiliges Buch darstellt, müssen wie 
folgt formulieren:

TIM9->SR = TIM_SR_CC2OF | TIM_SR_CC1OF | TIM_SR_TIF | TIM_SR_CC2IF | 
TIM_SR_CC1IF;

UIF fehlt und wird gelöscht; alles sehr geschwätzig :-)

[(prx) A. K. (prx)]

Jo, da wär der Typ rc_w1 sinnvoller - muss man nur ein Bit angeben, und 
zwar das gewünschte. Nicht alle anderen.

[m.n. (Gast)]

A. K. schrieb:
> Jo, da wär der Typ rc_w1 sinnvoller

Ja, beim AVR und RX ist das so.
Andererseits scheint "TIM9->SR = ~TIM_SR_UIF;" nicht schädlich zu sein. 
Die oberen Bits werden vom Prozessor wohl ignoriert.

Bei der praktischen Arbeit fällt mir der einzige Interrupt-Vektor für T9 
negativ auf. Ich möchte hochfrequente Capture-Ereignisse sehr schnell 
und T9-Überläufe (ca. alle 0,4ms) gemächlich abarbeiten.
Beim RX hätte ich separate Vektoren, die zudem eine eigene Priorität 
bekommen können. Beim STM32 muß alles in einer einzigen Routine 
gehandhabt werden, was die Ausführung bremst. Mal sehen, wie schnell es 
am Ende laufen wird.

[m.n. (Gast)]

Jetzt habe ich den DMA-Controller angeworfen.
Bei DMA2->LIFCR muß man eine '1' schreiben, um das Int-Flag zu löschen.
Ruhe bewahren + Tee trinken :-)