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?
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_tSysTick_Config(uint32_tticks)
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:
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)
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.
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^^
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.
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.
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.
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.
