Forum: Mikrocontroller und Digitale Elektronik CMSIS und das Cortex-M"x" Gewusel


von Maude (Gast)


Lesenswert?

Hallo zusammen,

ich bin noch unorientiert, was den Geltungsbereich von CMSIS angeht. Ich 
habe bis jetzt das smt32F3Discovery zusammen mit den standard peripheral 
Treibern von ST unter µVision Keil benutzt.

Ich habe einige Fragen, wo ich es nicht wirklich schaffe, AN´s o.ä. zu 
finden, um mir einige Fragen so zu beantworten, dass ich nicht das 
Gefühl habe im Bereich der Interpretation zu sein. Mir geht es also 
weniger darum konkrete Antworten auf eine spezifische Frage zu bekommen 
als eher Hinweise wo ich aufklärende AN´s finde und welche konkret das 
sind. Ich war natürlich schon bei arm.com und habe etwas 
Schwierigkeiten, mich zurecht zu finden.

Der Sinn von CMSIS ist ja eine einheitliche API für die CortexM 
Prozessoren zu haben, die über Lizensierung in Derivaten verschiedener 
Hersteller verbaut werden und erst dort vom Prozessor zum Controller 
werden. Anbei ein paar Fragen, die meine Gedanken zusammenfassen.

viele Grüße!

1.)
Mir ist nicht ganz klar, was CMSIS tatsächlich ist. Da es sich (so wie 
ich es verstanden habe) um eine API zum PROZESSOR handelt, müsste es 
sich bei jeder "M-Nummer" (M0, M0+ etc.) jeweils um eine andere Variante 
des CMSIS handeln? Grundsätzlich aufwärtskompatibel?

2.)
Wenn es nur um den Prozessor geht, hört CMSIS doch schon auf, sobald ein 
Vendor anfängt irgendetwas an den Kern dranzu bauen (RAM, UART etc). Wie 
viel bringt mir ein standardisiertes CMSIS dann, wenn geschätzte 95% 
eines Datenblattes/UserManuals eines konkreten Controllers eines 
Herstellers aus eben selbst drangebauten Peripherien besteht?

3.) Was beinhaltet der Kern an "Funktionen"? Klar, den Befehlssatz, eine 
Busarchitektur, um überhaupt Periperien anhängen zu können. Auch das 
Clock Managment,MPU, DMA, usw.? Gibt es eventuell Timer z.B. für SysTick 
die schon im lizensierten Kern dabei sind?

4.)
Im konkrten Fall der stm32: Die laufen ja auch mit Postfixen als 
Bezeichnung unter M0, M0+ M3 etc. Da nehme ich stark an, dass es sich um 
die Bezeichnungen der ARM "Nummerierung" handelt jedoch auf keinen Fall 
mit den "ST-internen" F1, F2, Nummern zu verwechseln sind?

von Andi K. (fry12)


Lesenswert?

Maude schrieb:
> 3.) Was beinhaltet der Kern an "Funktionen"? Klar, den Befehlssatz, eine
> Busarchitektur, um überhaupt Periperien anhängen zu können. Auch das
> Clock Managment,MPU, DMA, usw.? Gibt es eventuell Timer z.B. für SysTick
> die schon im lizensierten Kern dabei sind?

Unter 
http://www.arm.com/products/processors/cortex-m/cortex-microcontroller-software-interface-standard.php 
auf "Download Specifications" bekommst du unter Anderem eine Doku, die 
einige deiner Fragen beantwortet.

Um beim Beispiel SysTick Timer zu bleiben: CMSIS liefert eine Funktion 
zur Konfiguration des SysTick Timers:
1
uint32_t SysTick_Config (uint32_t ticks)
Da der SysTick Timer im eigentlichen ARM Kern enthalten ist, kann die 
Funktion auch von jedem beliebigen ARM Cortex-Mx (ob die M0 SysTick auch 
haben, weiß ich gerade nicht) verwendet werden.

Anderes Beispiel, das häufig verwendet wird: Interrupt Konfiguration 
mittels CMSIS Funktionen, wie:
1
void NVIC_EnableIRQ (IRQn_Type IRQn);
2
void NVIC_DisableIRQ (IRQn_Type IRQn);
3
void NVIC_SetPriority (IRQn_Type IRQn, uint32_t priority);
4
// etc. etc.

Dann gibt es noch viele DSP-Funktionen, die über CMSIS C-Funktionen 
einfach aufzurufen sind, Funktionen zum Lesen der Core Register, wie 
bspw. Lesen des Main Stack Pointer (MSP) etc.

Außerdem legt CMSIS fest, wie die Schnittstelle zur 
herstellerspezifischen Peripherie auszusehen hat (in der Dokumentation 
unter CMSIS-CORE->Reference->Peripheral Access zu finden)

: Bearbeitet durch User
von W.S. (Gast)


Lesenswert?

Maude schrieb:
> Der Sinn von CMSIS ist..

Naja.. eigentlich war es ein Versuch, herstellerübergreifend die 
Hardware per Software-Zwischenschicht zu vereinheitlichen. Das ist 
gründlich mißlungen, denn durch CMSIS und Konsorten ist anstelle 
richtiger gut optimierter Treiber lediglich eine Schicht von vielen 
zusätzlichen Definitionen und simplen Funktionen eingeführt worden. Die 
eigentliche Arbeit bleibt dem jeweiligen Anwender nach wie vor am Hacken 
kleben und durch CMSIS wird es nicht einfacher, sondern nur anders. 
Anstelle das HW-Manual lesen zu müssen muß man jetzt das Manual zu dem 
Zeug lesen, was in CMSIS drinsteckt.

W.S.

von Maude (Gast)


Lesenswert?

Ehrlicherweise zweifle ich wie mein direkter Vorposter im Moment an dem 
Sinn des Ganzen. In dem was ich mir über "Download Specifications" 
runtergeladen habe sind in Documentation letztendlich immer html Files, 
die mich zu arm.com verlinken (was nicht der Grund für meine Zweifel 
ist).

Ich bin erstmal über "index" gegangen und hier gelandet
file:///C:/Users/Justus/Downloads/CMSIS-SP-00300-r4p2-00rel0/CMSIS/Docum 
entation/Core/html/_using_pg.html

Wenn ich dort den LinkButton "Peripheral Acces" nehme, lande ich hier
file:///C:/Users/Justus/Downloads/CMSIS-SP-00300-r4p2-00rel0/CMSIS/Docum 
entation/Core/html/group__peripheral__gr.html

Das erste was mich stört ist
"Describes naming conventions, requirements, AND OPTIONAL FEATURES for 
accessing peripherals"
In dem Moment wo etwas optional ist, habe ich doch schon nen Fallstrick 
eingebaut, wenn ich auf Derivat A etwas nutze, was im Derivat B von 
einem anderen Hersteller nicht existiert.

Die Schreibweise
> LPC_UART1->DR
unter dem UART Beispiel habe ich schon mal gesehen, nur eben für stm32. 
Durch die vom ersten Antwortpost genannte Namensconvention von CMSIS 
erreicht man damit doch letztlich nur eine Einheitliche Lesbarkeit, aber 
das hat mit Austausch- bzw. mit Portierbarkeit ín meinen Augen nichts zu 
tun.

Ich habe mir noch den Cortex-M3 Devices User Guide
http://infocenter.arm.com/help/topic/com.arm.doc.dui0552a/DUI0552A_cortex_m3_dgug.pdf
runtergeladen. In Kapitel 4.2.1 finden sich Funktionen zum NVIC 
Management. Aber damit hat es sich soweit ich das sehe.

Bitte um gerechte und strenge Bestrafung, wenn ich falsch liege^^

von (prx) A. K. (prx)


Lesenswert?

W.S. schrieb:
> Anstelle das HW-Manual lesen zu müssen muß man jetzt das Manual zu dem
> Zeug lesen, was in CMSIS drinsteckt.

Nicht "anstelle", sondern zusätzlich. Die Hardware muss man trotzdem 
verstehen, und beim Debuggen auch die Bits kennen.

von (prx) A. K. (prx)


Lesenswert?

Maude schrieb:
> In dem Moment wo etwas optional ist, habe ich doch schon nen Fallstrick
> eingebaut, wenn ich auf Derivat A etwas nutze, was im Derivat B von
> einem anderen Hersteller nicht existiert.

Eine universelle und immer noch effiziente Abstraktion von 
beispielsweise Timern kann es nicht geben. Dafür sind die zu 
unterschiedlich.

Es kann nun einen einheitlichen Layer für die Cortex M Prozessoren geben 
- und den gibt es - und eine auf formale Aspekte begrenzte Spezifikation 
für herstellerabhängigen Kram.

: Bearbeitet durch User
von Andi K. (fry12)


Lesenswert?

Maude schrieb:
> Durch die vom ersten Antwortpost genannte Namensconvention von CMSIS
> erreicht man damit doch letztlich nur eine Einheitliche Lesbarkeit, aber
> das hat mit Austausch- bzw. mit Portierbarkeit ín meinen Augen nichts zu
> tun.
Stimmt, damit erreicht man keine Portierbarkeit. Für die lesbarkeit ist 
es aber immerhin besser als wenn jeder Hersteller sein eigenes Süppchen 
kocht.

Das Problem ist doch:

Wie will man bei Mikrocontrollern ohne großen Aufwand Portierbarkeit 
erreichen? Denn selbst wenn der eigentliche CPU Kern identisch ist 
(meinetwegen Cortexs-M4), so sind die Unterschiede in der Peripherie der 
einzelnen Mikrocontroller hinsichtlich Art, Anzahl, Funktionalität etc. 
doch gewaltig.

: Bearbeitet durch User
von Random .. (thorstendb) Benutzerseite


Lesenswert?

Ho,

CMSIS ist eig. "nur" die Vereinheitlichung der Device Headerfiles und 
einiger standardisierter Core Funktionen (PLL setup, NVIC, SysTick, 
WFE/WFI etc.).
Dazu kommen noch die SVD Files, aus welchen mittels SVDConv.exe CMSIS 
Headerfiles und MDK-ARM SystemViewer (Registerinhalte in Textform beim 
debuggen) Files erzeugt werden können.
Seit neuestem reiht sich hier das CMSIS-Pack ein, welches den Device 
Support IDE unabhängig bündelt, sowie das CMSIS RTOS, wo es gelungen 
ist, Hersteller von RTOSen unter eine API zu bringen.

Damit wurde insbesondere in den Device Headerfiles der Wildwuchs aus 
verschiedenen Herangehensweisen (structs, #defines, ...) vereinheitlicht 
und vor allem übersichtlicher gestaltet.

Dadurch, dass beim Cortex-M der Interrupt Controller jetzt Bestandteil 
des Cores ist, konnte hier ein einheitlicher Layer für das anfangs 
komplex anmutende Core-Peripheral erstellt werden.

Dazu kommt, dass vor dem Einsprung in main() (vgl. startup.s) die 
SystemInit() Funktion aufgerufen wird, welche sich um das grundlegende 
MCU setup (PLL etc) kümmert.

Der User wählt also im Optimalfall seine MCU aus, und kann direkt bei 
main() loslegen. So funktioniert es aktuell im MDK-ARM/µVision 5 mit dem 
RTE (RunTimeEnviroment).

An einer einheitlichen API wird im Rahmen der Middleware gearbeitet. 
Dort geht es aber um Middleware-Funktionalitäten (z.B. USB, Eth, 
SD-Card) und nicht um die Vereinheitlichung der Peripheral APIs. Das ist 
nicht möglich, weil sich die Peripherals der Hersteller zu stark 
unterscheiden, und diese - denke ich - auch kein Interesse an einer 
generellen Austauschbarkeit haben.

Die Hersteller-Driverlibs sind also ggf. CMSIS-kompatibel (nutzen also 
im Kern diese Strukturen), sind aber selbst kein Teil der CMSIS.


VG,
/th.

von Maude (Gast)


Lesenswert?

Das hier enthält auch Erklärungen, was sich mittels "Cortex" definiert 
wird
http://www.hitex.com/fileadmin/pdf/insiders-guides/stm32/isg-stm32-v18d-scr.pdf

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
Noch kein Account? Hier anmelden.