why is CMSIS DRIVER not providing all the important drivers used in embedded world

173 Views Asked by At

I wanted to use CMSIS driver APIs instead of HAL provided by stm. when I visited the link CMSIS DRIVER APIs No where I found, the most commonly used drivers like pwm, adc, gpio etc., why is that so, do we have to depend on both CMSIS and HAL for Microcontroller programming?

I've tried to find the answer in the arm community also, there is one question asking the same, surprisingly, none given the answer for that.

3

There are 3 best solutions below

1
kkrambo On BEST ANSWER

A microcontroller contains a hardware core along with hardware peripherals such as GPIO and ADC. Arm Cortex-M is a core commonly used by microcontroller vendors such as STMicroelectronics, Espressif, NXP and others. But the hardware peripherals vary from vendor to vendor. (For example STMicroelectronic's ADC is different from Espressif's ADC.) Arm provides the CMSIS to interface with the hardware core defined by Arm. Microcontroller vendors provide a HAL to interface with their custom hardware peripherals. CMSIS does not include the vendor-specific peripherals because Arm does not define those peripherals. Think of the CMSIS as a layer above the common hardware core while the HAL is a layer above the CMSIS and the vendor-specific hardware peripherals.

0
0___________ On

why is that so, do we have to depend on both CMSIS and HAL for Microcontroller programming?

No, you can write it yourself and not rely on HAL bloatware.

0
Clifford On

The CMSIS-Driver specification is concerned with communications interfaces rather than low-level I/O.

CMSIS is a specification not an implementation. It is defined by ARM and generic across ARM Cortex-M devices. It is up to either you or the MCU vendor or a third party whether you implement a driver to that specification.

The purpose of CMSIS is to support portability across ARM Cortex-M based MCUs from multiple vendors.

The STM32 HAL on the other hand is STM32 specific, and designed to support portability only across the extensive and long-lived series of STM32 devices with hundreds of subtle differences that make low level (direct peripheral register access) code non-portable.

It is perhaps not in ST's interest to support portability away from their devices, but certainly in thier interests to abstract away the differences between their own parts. Hence the HAL, CubeMX, CubeIDE etc. ecosystem. While at the same time, it is in ARM's interest to abstract away the differences between ARM licencees - Hence CMSIS, and at a higher level, Mbed.

So it is marketing, business, and licence issues. I imagine that as ARM licencees, ST are obliged to implement a minimal subset of the CMSIS API, and they will do that and no more, and do everything can to get design "lock-in" and make it very difficult to migrate a design to a competitor.

To that end you might consider Mbed as a higher level platform over STM32Cube for example.

If you had been using STM32 for a while, you will remember the "Standard Peripheral Library" (SPL), it pre-dates STM32Cube and was lower level and less portable than HAL (and needlessly different than LL). Don't get me started on STs effective abandonment of long term STM32 users when they dropped that. Either way when you choose your platform, realise that if it comes from the vendor, they are doing it to sell their chips, no one else's. Also realise that chip vendors are not necessarily the best software designers, much less software developers.