TIM9_SR Interrupt-Flags beim STM32F4

m.n. Gast #2883190
Lesenswert?
• ▲
▼ 
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?
Antwort Zitieren Bearbeiten Thread verschieben Thread sperren Anmeldepflicht aktivieren Anpinnen Thread löschen Thread mit anderem zusammenführen Beitrag melden
m.n. Gast #2883208
Lesenswert?
• ▲
▼ 
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.
Antwort Zitieren Bearbeiten Löschen Beitrag melden
m.n. Gast #2883234
Lesenswert?
• ▲
▼ 
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.
Antwort Zitieren Bearbeiten Löschen Beitrag melden
m.n. Gast #2883255
Lesenswert?
• ▲
▼ 
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 :-)
Antwort Zitieren Bearbeiten Löschen Beitrag melden
m.n. Gast #2884065
Lesenswert?
• ▲
▼ 
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.
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Thread beobachten

Antwort schreiben

Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt. Bitte hier nur auf die ursprüngliche Frage antworten, für neue Fragen einen neuen Beitrag erstellen.

Formatierung
  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] – Link zu einem Artikel
  • Verweis auf einen anderen Beitrag: Rechtsklick auf dessen Beitrags-ID (#8078628), „Adresse kopieren“, in den Text einfügen

Mehr zur Formatierung

Längeren Sourcecode als Anhang, nicht in den Text. JPG nur für Fotos und Scans; Zeichnungen und Screenshots als PNG oder GIF. Siehe Bildformate.

Dein Name und deine E-Mail-Adresse

Schon registriert? Anmelden

Wird nicht angezeigt. Wir schicken dir einen Link; sobald du damit bestätigst, erscheint dein Beitrag.

Mit dem Abschicken legst du einen kostenlosen Account an und erkennst die Nutzungsbedingungen und die Datenschutzerklärung an.