I'm about to start a new project on a classical STM32L4 based product. I have a good experience in ARM developpement but not in STM32 specifically. I am wondering what is the quality and performance of the STM32 HAL and low level drivers provided by STmicro (in the package STM32Cube). I'd like to gather developpers experience and feedback on the topic. Basically I'd like to know if you are happy with this code or on the contrary if you encounter some issues, if some of you developped their own drivers for some reasons, etc... Thank you !
The STM32 Hardware Abstraction Layer (HAL) provides a simple, generic multi-instance set of APIs (application programming interfaces) to interact with the upper layers like the user application, libraries and stacks.
HAL will make development faster because it's easy to use. This is especially true for first prototypes or examples where you do not need extensive tests but you need something to show quickly. HAL usually makes code easily portable within same brand/manufacturer. HAL is safer than accessing registers directly.
The STM32 HAL-LL drivers, an abstraction layer offering a set of APIs ensuring maximized portability across the STM32 portfolio. The BSP drivers of each evaluation, demonstration or nucleo board provided for this STM32 series.
A hardware abstraction layer (HAL) is a logical division of code that serves as an abstraction layer between a computer's physical hardware and its software. It provides a device driver interface allowing a program to communicate with the hardware.
After the transition from smaller 8-bit microcontrollers to ARM, I've started to use the HAL library on STM32 right away and had a more or less satisfying experience. But it comes with an overhead like already stated and a quite large set of poorly documented functionality. That can lead to some confusion.
However, the big advantage of using the HAL over hand-written-code-from-scratch was the level of abstraction it provides. That came in handy when I needed switch from one type of STM32 to another; and also when I needed to get things up and running quickly. - I've used quite similar code on a couple of very different types / families of STM32 micros (L0, L1, F1, F4, F7); it actually worked most of the time. Using the HAL library made the transition much less painful, than when you need to know the exact memory map and register layout of the specific micro...
With that said, I need to admit that I'm still a newbie when it comes to modern embedded software and I'm still learning, after about 2 years of prototyping work on different STM32 based projects (hobby and professional). I still need to learn more about the provided LL code, for example.
Entering the embedded field with a different software background, using HAL level code instead of twiddeling single bits of different registers in the right sequence, and taking all the different restrictions into account to get for example basic UART / SPI / I2C communication working, eased things up quite a bit for me. IMHO, the STM32 HAL lies in a middleground between pure hand written code and what mbed does for example (C++ / vender-agnostic abstraction (as far as I know)). - It tames the complex beast to an acceptable level, so that an average software developer like me can handle it. That comes with some trade-offs, like already mentioned by others...
After all, the STM32 HAL also kind of serves as a boiler plate code repository, that can sometimes be easier to read/understand than the cryptic reference manual in some cases. - Using HAL code generated by STM32CubeMX always gave me a much smoother start at bring-up time, when I needed quickly test a new board. It can also help to experiment and test things out. And when a performance critical part needs to be hand-optimized later on, then that will still be possible after setting up a project, or even incrementally adjusting it with STM32CubeMX. You can mix handwritten code with HAL code.
Some problems recognized since 2016:
Some constants, structs and function signatures changed when new code updates were released by ST. Things seem to be in constant development.
Lack of good documentation (comments in code files) and clean example code (too specific, also not well documented).
Convoluted, sometimes inefficient code.
Spelling errors.
I personally do not like HAL library for following reasons.
What I liked by ST was Standard Peripheral Library, it was just assembly to C converter and very easy to use.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With