STM32F2xx: Global Interrupt abfragen

Michael schrieb:
> Wenn mein Prozessor STM32F2xx gibt es die Befehle __get_CPSR und
> __set_CPSR nicht.

Interessant. Das sind direkte Umsetzungen von Prozessorbefehlen und es 
ist der gleiche Prozessor. Veraltete CMSIS oder falsche Funktion 
verwendet?

Michael schrieb:
> Das kommt aus einem Code-Beispiel von IAR direkt zu meinem
> STM32F2xx-Prozessor.

Nur ist die Version vom Core in beiden Fällen gleich. Der Kram für die 
Core-Version unterhalb von 7 bezieht sich auf ARM7/ARM9, kann also mit 
dem STM32F0xx eigentlich auch nicht funktioniert haben.

Such mal in der CMSIS, was dort der richtige oder auch nicht richtige 
aber von dir gesuchte Weg ist. Ein sinnvoller Weg geht beispielsweise 
über das BASEPRI/BASEPRI_MAX Register.

Michael schrieb:
> Hier würde ich gerne CriticalSection-Funktionen verwenden.

Und was stört dich an den dort enthaltenen Makros?
#define ENTR_CRT_SECTION() EntrCritSection()
#define EXT_CRT_SECTION()  ExtCritSection()

Michael schrieb:
> Also das Makro ist ja nicht das Problem, sondern "die Art" der
> umgesetzten CriticalSections....

Weshalb? Das Include setzt diese Makros für ARMv7 in CPSID/E Befehle um, 
genau wie es sein soll.

Michael schrieb:
> Guter Tipp, aber dazu muss ich mich bei ARM registrieren.

Normalerweise sollten wahlweise Hersteller des Compilers oder des 
Controllers da weiterhelfen. Die CMSIS findet sich beispielsweise 
zusammen mit dem STM32-Kram in der STM Library.

Michael schrieb:
> Ich will aber zusätzlich noch wissen, ob das Interrupt Flag beim
> Betreten der Critical Section -also vorher- schon gesetzt war, oder
> nicht.

Wozu? Wie sähe dein Code dann aus?

Such mal nach dem PRIMASK Register.

Wenn ausschliesslich der obige Code im Include für Critical Sections 
genutzt wird, dann dürfen die Critical Sections auch schachteln, da der 
Code einen Level-Counter mitführt.

EntrCritSection => CriticalSecCntr==1 / CPSID I
EntrCritSection => CriticalSecCntr==2 / nix
ExtCritSection  => CriticalSecCntr==1 / nix
ExtCritSection  => CriticalSecCntr==0 / CPSIE I

Michael schrieb:
> Für das Betreten und Verlassen einer Mutex ist ein Sicherer Bereich von
> Typ 1 = Critical Section von Nöten

Das ist ein Weg. Und zwar der bei den Cortex M schlechtere.

Der bessere trennt die Interrupt-Prioritäten in zwei Bereiche, 
unterschieden durch die RTOS-Priorität N. Interrupts, die RTOS nutzen, 
erhalten eine geringere Priorität als das RTOS in seinen kritischen 
Bereichen. Interrupts ohne RTOS Nutzung können einen höhere Priorität 
haben (funktionell betrachtet, nicht numerisch).

Eine kritische Sektion, die alle funktional geringeren Interrupts als K 
ausschliesst, kann man völlig ohne CPSID/E so definieren:
  enter: var old = BASEPRI
         BASEPRI_MAX = K
  ...
  exit:  BASEPRI = old
Eine Zuweisung an BASEPRI_MAX hat die Eigenheit, die Priorität nie zu 
verschlechtern, daher ist dieses Prinzip risikofrei anwendbar.

Für RTOS-Lockouts, wie beispielsweise für eine Mutex, lässt sich die 
kritische Sektion also mit ebendieser BASEPRI Aktion implementieren, mit 
K=N.

Vorteil: Zeitkritische Interrupts, die keine RTOS APIs verwenden, werden 
vom RTOS nicht blockiert, also auch nicht verzögert.

Michael schrieb:
> Eine ausführliche und interessante Antwort! - Verstehen tue ich dennoch
> nur Bahnhof!

Du bist dir ganz sicher, dass du mit Level=Bahnhof unbedingt einen 
RTOS-Kernel bauen willst (wg. Mutex)?

Michael schrieb:
> Mit RTOS, insbesondere OS, hat das alles recht wenig zu tun, aber mit
> Nested Interrupts.

In welcher Umgebung gibt es Mutexe? In Interrupts ist eine Mutex 
ziemlich sinnarm und eine kritische Sektion zum Schutz vor Interrupts 
ist keine Mutex. Und die Mutext hattest du eingeführt.

Also: Wo hast du ein Problem? Die Makros/Funktionen im Include 
jedenfalls führen - richtig eingesetzt - nicht zu einem Problem.