CMSIS compliant drivers STM32

[vijith]

Posted on May 14, 2014 at 13:44

Hi,

Currently i am working on a code refactoring project, my first requirement is to use CMSIS driver library for replacing existing driver library(developed by us) so that incase of a microcontroller change in the future, there wont be much work required. I looked at the CMSIS documents and downloaded CMSIS version 4 libraries from ARM and CMSIS complaint device drivers (STM32f105) from ST. The CMSIS folder has core peripheral access files, DSP files, RTOS files and so on. It has a driver API but which is not talking to the CMSIS compliant drivers(ST). (but as mentioned in the CMSIS ver4 architechture http://www.keil.com/pack/doc/cmsis4/General/html/index.html, the CMSIS driver API should call the low level CMSIS compliant ST drivers)Can anyone please clarify1.   CMSIS is only meant for standardization of core peripheral access functions and peripheral register name definitions only? (then there is no point in mentioning CMSIS as a interface standard for porting with different microcontrollers )2.  Or is there a way to use those CMSIS driver API's(CMSIS ver 4) to call this CMSIS compliant ST drivers?RegardsVijith #arm-cmsis-driver-pack #stm32f10x #cmsis

[chen]

Posted on May 14, 2014 at 13:59

Hi

This is MY understanding (and it may be flawed so do not take my word as absolute). The CMSIS standard is divided up into 'sections' There is a CMSYS for the ARM core (processor) - which (nearly) all silicone vendors abide by and provide Library routines for. There is a CMSIS standard for peripherals. ST have provided one library for 1 processor (which I can never find on their web site!). Very few silicone vendors provide any CMSIS compliant libraries for the peripherals in their parts. (if they did, it means that you can easily switch between any vendors parts with very little work but they do not want that! ). There is a CMSIS standard for OS This is an abstraction layer for OS. OS vendors should provide their OS compliant to the wrapper layer. This would allow you to switch between different OS with little work. However, like the silicone vendors, none of the OS vendors have a CMSIS wrapper for their OS as far as I know ''1.   CMSIS is only meant for standardization of core peripheral access functions and peripheral register name definitions only? (then there is no point in mentioning CMSIS as a interface standard for porting with different microcontrollers )'' 'core peripheral' - means the peripherals provided by ARM - NVIC, SystemCtrlBlock and SysTick 'peripheral register name definitions only' - if you mean the other peripherals provide by the silicone vendor - not that I understand. ''2.  Or is there a way to use those CMSIS driver API's(CMSIS ver 4) to call this CMSIS compliant ST drivers?'' Only if ST have provided the peripheral library in CMSIS compliant format - but generally NO for the ST peripherals.

[Tesla DeLorean]

Posted on May 14, 2014 at 15:49

The V3.x.x firmware library for the STM32F1xx parts is ''CMSIS Compliant'', the most current version is V3.5.0 and uses CMSIS V1.30

[vijith]

Posted on May 15, 2014 at 06:38

Hi clive,

We say CMSIS compliant drivers because it uses the core_cm3.h files and stm32f10x.h files which are provided in CMSIS pack. Is it so? So in case i am changing my microcontroller i have to replace drivers by making modifications in my application code?. then how is it easily portable across different platforms(as mentioned in CMSIS documentation).?

[chen]

Posted on May 15, 2014 at 17:30 ''stm32f10x.h'' this file will change for each ST processor. ''So in case i am changing my microcontroller i have to replace drivers by making modifications in my application code?.'' Yes. Depending on how much spare binary space you have - invent a Hardware Abstraction Layer. Define a HAL API for each peripheral device. Have the application use the HAL API. The HAL API can just wrap the device driver. If you change the processor - you can change the device driver and re-write the HAL wrapper layer. The application layer is none the wiser that the driver has changed. '' then how is it easily portable across different platforms(as mentioned in CMSIS documentation).?'' Yeah, this is just marketing. It sort of works for the ARM core but then that stays pretty much the same (unless you change cores eg CortexM3 to Cortex M0)

[Tesla DeLorean]

Posted on May 15, 2014 at 17:49

So in case i am changing my microcontroller i have to replace drivers by making modifications in my application code?. then how is it easily portable across different platforms(as mentioned in CMSIS documentation).?

I don't think that FW V3.5.0 based on CMSIS V1.30 is going to fulfill any of the extended specifications of CMSIS V4.x with respect to peripheral drivers. At the current level it provides some degree of transparency in the Cortex-M3/M4 core you chose, but the ST FW V3.5.0 is unique to ST and their peripheral set and implementation. My observation is that you aren't going to be able to port easily unless you have an incredibly bloated abstraction layer to provide uniformity where none really exists between parts and/or vendors. I'm able to port things I write relatively easily because I already understand where the HW/SW abstraction should be, and that GPIO/LED/USART stuff is simple, and the TIM stuff is very hard and device specific. I'd suggest you pick an architecture you understand, and are comfortable with, and that provides you with some flexibility using the same (or materially the same) foot print for a wide selection of parts, and extended families.

[dieter 123]

Posted on October 25, 2017 at 05:39

Hi,

so 3 years later what is the current status of CMSIS drivers for Peripherals like SPI and UART at ST? Are they supported?

THx

[AVI-crak]

Posted on October 25, 2017 at 08:40

For this it is enough to separate the program and the iron level.

The driver can not be compatible by definition - it is always unique for the selected microprocessor.The wrapper of the software layer can be compatible - the number and type of arguments for such functions must be fixed.