About STM32 HAL quality and performance
I personally do not like HAL library for following reasons.
- It takes up much memory in my controller, I really do not have space where i would fit in Bootloader and Application and here i need to add 2 HAL overheads as well ( one in Bootloader and another in Application).
- It internally uses interrupts ( i am pretty sure it does)
- It is not bug free , i once tried version 1.0 and failed horribly.
- Debugging is pain , You never know where the bug is, in your application or in HAL.
What I liked by ST was Standard Peripheral Library, it was just assembly to C converter and very easy to use.
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 do not like HAL for many reasons:
- It gives pseudo developers false feeling that they do not have to know how their hardware works.
- Time spent learning HAL may be longer (and usually is) than needed to understand how the hardware works.
- Horrible overhead
- Many errors.
But on the other hand I use HAL (actually deeply modified by me) to control two peripherals USB & Ethernet as writing could take too much time. But as I wrote before I know how does it work on the hardware/low level and modified it for my liking.