13

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 !

Guillaume Petitjean
  • 2,408
  • 1
  • 21
  • 47
  • 3
    Quality of vendor supplied libraries? medium usually, just look at the code yourself (a simple glance should solidify your answer). Performance, poor, often written to cover several families, very bloated, some percentage of the code that executes is not for your chip and not completely if-then-elsed out. Speaking in general not specifically any one particular chip vendor... – old_timer Apr 03 '18 at 03:43
  • 1
    professionally you should be able to use the libraries or not use the libraries, you should periodically try each of the vendors solutions as well as just read the manual (when choosing the path for the next project). You own the code including the library you chose, your boss wont care that they have to eat 10,000 units because you wanted to save time by using someone elses code, your responsibility, you own it you look at the libraries and bless them/own them. – old_timer Apr 03 '18 at 03:45
  • 1
    I also find it easier to just read the manual and program the registers than try to get the libraries to work. Sometimes you have to dive into their code to find bugs in the manual, but while in there you find you are really glad you didnt use the library...speaking generically again...ST documentation is pretty good, not the best (pretty close), definitely not the worst. – old_timer Apr 03 '18 at 03:50

4 Answers4

16

I do not like HAL for many reasons:

  1. It gives pseudo developers false feeling that they do not have to know how their hardware works.
  2. Time spent learning HAL may be longer (and usually is) than needed to understand how the hardware works.
  3. Horrible overhead
  4. 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.

Bence Kaulics
  • 7,066
  • 7
  • 33
  • 63
0___________
  • 60,014
  • 4
  • 34
  • 74
  • Yes, you are right! Peripherals like USB and Ethernet are too complex to write drivers from scratch. But I really don't understand that someone control GPIOs, UART, SPI, and other simple peripherals with HAL. In case of own driver you have absolute control over peripheral. – vlk Apr 01 '18 at 18:48
  • Thank you for your answer. Could you elaborate on points 3 and 4 ? – Guillaume Petitjean Apr 01 '18 at 18:49
  • Also, what about the low level drivers provided by STMicro – Guillaume Petitjean Apr 01 '18 at 18:49
  • 1
    About point 1, isn't it exactly the purpose of an HAL in general ? :) – Guillaume Petitjean Apr 01 '18 at 18:52
  • 3. to make abstract layer almost always add some overhead, direct peripheral registers configuration need much less code and will also faster. – vlk Apr 01 '18 at 19:03
  • 1. very often to understand configuration of a peripheral with HAL you also need to study the datasheet how the peripheral works and not only HAL doc. My opinion is that this is useless and best is to access simple peripherals directly. – vlk Apr 01 '18 at 19:32
  • @GuillaumePetitjean you are making one horrible mistake. You think that abstraction level library frees you from knowing the hardware. But it does not!!. – 0___________ Apr 01 '18 at 21:05
11

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.

rel
  • 764
  • 5
  • 18
  • But an important note is that you compare Hal with stick and stones , of course Hal is better than nothing ,but still it is bad compered with a hypothetical normal working hardware abstraction layer (as the one Rust makes) – Spyros Mourelatos Mar 23 '20 at 11:58
6

I personally do not like HAL library for following reasons.

  1. 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).
  2. It internally uses interrupts ( i am pretty sure it does)
  3. It is not bug free , i once tried version 1.0 and failed horribly.
  4. 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.

Dheeraj Kumar
  • 377
  • 2
  • 13
  • #2 is not correct, HAL does not use interrupts unless you explicitly ask it to. – Richard at ImageCraft May 28 '19 at 07:42
  • #2 is incorrect. #3 is any software bug free? you are setting the bar a bit high there. #4 that is the case with anyone's code. – Tarick Welling Jul 04 '19 at 09:10
  • 1
    @TarickWelling You could afford to have bug in application. But getting bug in BSP will make you cringe while debugging. There is only one way you want to use your peripheral and that has to be right.. – Dheeraj Kumar Mar 23 '20 at 11:51
  • @Tarick Welling At least most softwares have the least decency that when a bug is issued they patch it before closing the issue. I was using an f1 with an old version of hal and the I2c protocol was working quite fine ,I updated to version 1.8 and Hal broke, I went on their github to see if someone issued this issue . I was worried that I did something wrong because there wasn't any related open issue .This idiots made a hotfix for a guy that had the same problem and then closed the issue without patching like nothing happend.[proof] (https://github.com/STMicroelectronics/STM32CubeF1/issues/6) – Spyros Mourelatos Mar 23 '20 at 11:51
  • @SpyrosMourelatos that doesn't get the beauty prize but it seems that they are internally patching it on the right repo and will publish it in future. So yes the public repo isn't patched but it seems that that will be fixed in future. The github also seems to be a release repository and *not* a development one (look at the commits/branches). As such I think it is quite valid of them to not fix on that repo but fix it internally and release a patched version with the new release. – Tarick Welling Mar 23 '20 at 12:31
  • 1
    @DheerajKumar I'm not saying that bugs in other people's code (even more so in core code like BSP) won't be bad and frustrating but it is a inevitable thing that there are bugs. Also I quite disagree with the conception that a peripheral can only be used in one way. Take the DMA for example, it is quite complex and can do a myriad of things and as such is quite difficult to program for. – Tarick Welling Mar 23 '20 at 12:36
  • @TarickWelling i agree Tarick, Just wanted to say the cost of bug in BSP is much higher than in application. Also yes peripherals have different configurations but one user want to use it in a single way, like DMA i might prefer to have 16 bits and you might prefer 8 bits depending on nature of program. we both are saying same thing but in different way :) – Dheeraj Kumar Mar 23 '20 at 12:44
0

I love the HAL and Cube, but you have to read the drivers and be prepared to suffer. I used to wiggle bits like the naysayers, you can pick your poison. In my situation, if I use the HAL, I can sucker a real programmer into maintaining my code. Say no more, I'm in on the HAL. Be forewarned, the Cube simply creates an approximation of something that works.

Guest
  • 21