Important changes to forums and questions
All forums and questions are now archived. To start a new conversation or read the latest updates go to forums.mbed.com.
8 years, 10 months ago.
CMSIS vs STM32CUBE(HAL) vs MBED
I'm bit confused about this APIs
As far as I understand, CMSIS try to unify Cortex programming, by simplifying it.
It is different from STM32CUBE (Hal libraries) or the MBED libraries?
With all of them you can program more "human" like language.
I`ve heard than Mbed is made over Hal libraries, so, Hal libraries are included when programming in Mbed.
What about CMSIS?
Thanks
4 Answers
8 years, 10 months ago.
CMSIS are low level vendor independent methods to access the hardware of ARM Cortex devices. Some vendors, for example STM, provide libs on top of or next to CMSIS such as the STM32CUBE libs. The mbed libs provide a higher level vendor independent interface (C++ API) to the hardware from different vendors. The mbed lib may be using CMSIS conventions, calls to CMSIS functions or maybe STM32CUBE functions. The details of the implementation depend on the choices made by whoever provided the mbed lib for that platform.
8 years, 10 months ago.
The various layers in an mbed program are as follows (top to bottom):
6. Your C++ program
5. mbed C++ library
4. Target-specific mbed HAL layer
3. Target-specific vendor-supplied HAL layer (optional)
2. Target-specific CMSIS layer
1. The microcontroller
The CMSIS layer acts like a small abstraction layer between the rest of the code, and the microcontroller. Basically, it ensures that access to CPU registers, interrupts, etc, are consistent between microcontrollers. Then, a vendor-supplied HAL layer (e.g. STM32Cube) may be supplied to make accessing the rest of the microcontroller's peripherals easier. The mbed HAL layer provides a generic C API for controlling the microcontroller's peripherals, and may or may not use the optional vendor-supplied HAL layer to do it. The mbed C++ library contains generic C++ objects for the various peripherals (e.g. DigitalOut, SPI, Serial) that use the generic C API provided by the HAL layer. Your program sits at the top, and uses these generic C++ objects to control the microcontroller at the bottom through the various abstraction layers.
Essentially, all these layers allow your program to be microcontroller-independent. Which is to say, you shouldn't be dealing with STM32Cube, or the HAL APIs, you should only be dealing with the mbed C++ library. There are rare cases in which you might use some of the CMSIS functions, such as __disable_irq() and NVIC_SystemReset(), but these are few and far between.
This is a interesting discussion and touches on the very issue that has confused me.
There may be times where you might want to write an additional driver and this might require diving down closer to the hardware. An example might be the flexible memory interface (not supported in mbed), or an unprotected driver for using I2C in an ISR (mbed-os puts locks around it's I2C client APIs, so they can't be used in an ISR).
Do I understand it correctly that each manufacturer writes their own drivers for the peripheral set in mbed (I2C, SPI, DigitalOut etc...)?
Therefore, for an individual, the most realistic option is to write a target specific driver for their particular board using any of the abstraction layers below mbed?
posted by 25 Jul 2017
6 years, 3 months ago.
I m a little confused on this. For example developing mbed can bus application for STM32-DISCO is just CAN can1(PD_0, PD_1); How mbed configures these pins for can bus alternate function. Do we need to add HAL_GPIO_Init into main to chose alternate function or is it enough alone to create can1 object?
6 years, 3 months ago.
No need to call HAL_GPIO_Init or any ST HAL functions to configure GPIOs, Alternate-Functions, clocks.... This has already been configured by the low-level layers.
Hi, can you speak more on this or, preferably, point to some literature that explains the interaction between mbed and the application code calling the HAL? I'm using an STM32L4 part with the latest mbedOS5, but need to use a comparator+DMA+GPIO setup, which is not supported by mbed. I've gone through the well documented instructions on the HAL source files for the drivers I would like to use, but it seems that when I enable a timer (TIM2) it is not actually enabled (I believe this to be the case because TIM2 supporting code is not enabled during debug and I've seen that these are protected behind a #define during compilation). I'm wondering if there is a conflict in mbed's config and my modifying the HAL in my application. I have a fairly good grasp of mbed's high level system architecture, but little understanding of how it utilizes CMSIS and the target's HAL. Is a potential conflict possible? Is there documentation explaining this? Thanks.
posted by 12 Oct 2018