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_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
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.
:
Bearbeitet durch User
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
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.
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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.