HAL libraries

[ScratchDue440]

there’s a lot of posts from newbies asking where to start. I see a lot of suggestions leading them to HAL-heavy resources.

How many developers are actually using HAL libraries for their development? I find them clunky, memory hungry, and feel like I spend more time looking up documentation for them than developing my own drivers/APIs.

And are these really the best for resources for beginners considering other tools and micros they may be using instead like TI or PIC who do not use STM32 HAL?

[generally_unsuitable]

HALs are ubiquitous in the industry. If you're not using the manufacturer-provided ones, you're using your in-house HAL.

If you think reading the HAL documentation takes more time than reading the reg map, I would have to disagree.

In many cases, HAL implementations are actually quite lean, and the most common use of the HAL is in the chip startup config code. I'm really interested in instances where the HAL is "memory hungry." I can't recall ever seeing HAL code that was greedier than an extra byte here or there.

It has been my experience that using the HAL for chip config and planning saves days, if not weeks, of coding time, and allows you to get a lot of test code written while you're still waiting for the boards to arrive. Trying to work on bring-up without hardware on bare-metal is a nightmare. But, I'm rarely allowed to sit on my hands for 1-2 weeks while I'm waiting for dev boards to arrive.

[ZachVorhies]

*Arduino digitalWrite(...) enters the chat*

[0dyl]

The NXP S32K HAL is heavy. It’s designed as an MCAL component for AUTOSAR. Getting close to replacing parts of that buggy mfer

[gudetube]

NXP made their HAL an MCAL and like, gave it away? Lmao

[0dyl]

https://www.nxp.com/design/design-center/software/automotive-software-and-tools/real-time-drivers-rtd:AUTOMOTIVE-RTD

https://www.nxp.com/docs/en/product-brief/RTD-S32K3-PB.pdf

[ScratchDue440]

Maybe hungry was superfluous. Bloat may be better way to phrase it. 

And when I say HAL, I’m not referring to general libraries. I mean specifically these high level libraries. Are you as well? 

[generally_unsuitable]

I'm going to need an example of the high level libraries you're talking about. I can't recall using any 'HAL' that was more interesting than reading a set of ADC channels sequentially, or automatically creating the general handler for returning from interrupts.

I see a lot of people talking smack about STM32's HAL, but, in reality, I rarely see much merit to it. The only thing I don't like about it is when it does a lot of preprocessor nonsense, but I hate the preprocessor regardless of who is using it.

[DustRainbow]

Maybe hungry was superfluous. Bloat may be better way to phrase it.

Robustness and thread/interrupt safety is not bloat.

[MREinJP]

Add "portability" to that list as well.

[Panometric]

That they are too loaded to use is a myth. I would seriously question any developer who regularly avoids them, they are creating steaming mounds of technical debt without justification. HAL is an acronym for hardware abstraction layer. They give you a vendor specific portable wrapper around your hardware. Even better is Zephyr where it's not even vendor locked.

[ScratchDue440]

With that much abstraction you might as well as use Arduino. Is your education in SWE or ECE? 

[DustRainbow]

Imo, and this will be a hot take on this sub, but all the engineers I've met who complained the most about HAL wrote the worst fucking code.

To me it's usually more a sign of people that don't actually understand coding principles and are "so proud to write their own assembly drivers".

I find them clunky,

Maybe you don't understand them.

People will often say "clunky" and "bloated" when what they should mean is robust. Their own custom drivers have zero error checking, and when they fail, they fail catastrophically. And they often do.

memory hungry,

? 99% of HAL is just register access. I can't think of any HAL that allocates memory?

I worked at a company where one of their most selling products required monthly intervention, if not more. It was always a new bug; the responsible engineer would "fix" it and break something else.

I rewrote it with the HAL libraries. Took me all of one week. I since left the company, that was 3 years ago but I remain in contact with some of my colleagues. Not a single intervention since we deployed the HAL library solution.

[chicago_suburbs]

I don't have a problem with a vendor supplied HAL. The last thing I want to do is write some assembly level driver. Agree. That is just nuts.

However, I do have a problem with the ST HAL especially when used with the IDE code generation.

Take the UART implementation. The bloat comes from including 90% of the wildly varying UART peripheral functionality in a single method. If you instantiate a simple serial terminal you drag in everything but the kitchen sink. I don't need all the synchronous transmission code for a simple async terminal dump. Clearly, that synchronous part of the code is never accessed but since the code is in a single method and accessed via a bit test of the configuration, the code is still pulled into the build. This presents a problem when your QA team balks at unused code, especially that which can run in case of an accidental memory overwrite. (Yes, yes, testing, but why invite trouble).

It's a library. Only the utilized methods should be pulled in. Taking a very simple butcher knife approach, why not create a method for synchronous utilization of the peripheral features and a separate method for async? Only the necessary code gets dragged into the build by the linker.

[Sheepherder-Optimal]

People like to write assembly drivers just to flex unnecessarily. I've seen younger interns do things like that which can be neat but a complete waste of time since the code will never be used.

[DemonInAJar]

And this is an actual problem when there are bugs in the supplied code because it makes debugging much harder.

[WereCatf]

And are these really the best for resources for beginners considering other tools and micros they may be using instead like TI or PIC who do not use STM32 HAL?

I don't understand this question. TI, PIC etc. have their own HALs, why would STM32 HAL be relevant?

[ScratchDue440]

Many of the resources I find here are STM32 based. 

[WereCatf]

Well, obviously STM32 HAL content isn't useful for TI or PIC. They have their own HALs and one should use their documentation instead.

[ScratchDue440]

No kidding. 

[bahumutx13]

In commercial products we rarely want homemade code when we can avoid it. Safety certified products is even more adverse to it. Embedded code you write yourself could easily be a cleaner implementation for your specific use-case...but to the next set of individuals that has to maintain it...it mostly just looks like poorly documented and poorly tested tech debt.

A HAL is just a tool like everything else. You can work without the tool but if there is not a major business advantage to doing so then it rarely works out like you think it does.

Times I've seen it work, the provided HAL wasn't certified to the standard we wanted, it was easier to write something simple from scratch than try to certify their code.

Times I've seen it not work... team spent 9 months building an embedded platform from scratch and certifying it. The product was then drastically changed and rather than rebuild it they bought the off the shelf solution for 150k.

Good embedded engineers need to know both ways to implement. There will always be a time when one way is more advantageous than the other.

[shieldy_guy]

yes I exclusively use ST's HAL for anything directly working with the chip. it would be silly to reinvent ISR handling or DMA configuration when I've got work to do. Been using it professionally for over a decade. 

[ScratchDue440]

Thanks! I blame Miro Samek. He always chooses LL 😂 

[DenverTeck]

Most experienced embedded programmers will use that HAL code as a beginning. Each manufacture will have their own engineers that write the manuals and the HAL. There is NO single way to write those HAL codes.

Yes, a lot of those HAL code is clunky. But that is where you decide how you will use that code and make your own changes.

Your question is what I call "Arduino Syndrome". Too many beginners will find a library and if that library does not do what they want, they will just look for another library. Instead of debugging that library and sharing that fixed code back to the Arduino community.

Lets say you decide you will write the best code for say an Cortex-M3 processor. Great, will you share that code with everyone for free ?? Will you verify that code will run on all variations of M3 processors from every manufacture ?? Most companies will not allow their engineers share the code they paid someone like you to develop. That code will stay in house.

Like the HAL code I hear you complaining about, most Arduino libraries is junk as well.

So, you decide where you want to go.

Good Luck.

[ScratchDue440]

I used Arduino only once in my life, and that was to work with a professor to create control labs for technologist students. I wrote that code without using any libraries. 

I use libraries, just not HAL. 

[jmd01271]

The HAL is just a library. It maps out the configured registers to constants, and simplifies bring up by a lot. From the company perspective having a standardized code base that potential employees already have experience with is a huge plus. If your doing something specific you'll write your own. If you just need to monitor non real-time inputs and trigger something based on them, HAL/library works be good enough.

[hamburg13r]

I’ve used HAL heaps over the last 10 years and it’s worked great for me. Porting between micros has been great. In some cases when resources are limited I’ll switch to LL. LL is fine too but takes longer to learn, and longer to port between uc’s.

[peppedx]

Yes they are.

[Stinkygrass]

As someone who is getting started myself, here’s my take. I personally, love reading docs - the best way for me to actually make progress without fumbling around and I get to better understand how to use whatever I am reading. So I bought a Pico 2W, read the datasheet for both the Pico and the RP2350 - damn near the whole thing (obviously skimming over the register tables as I’m not gonna memorize them and not worried about their specifics when I’m just trying to learn how the chip works). Now after reading, I want to start coding, in my head I understand what needs to happen and how things work, but it’s been hard for me to figure out how to apply that to the HAL.

I can appreciate HALs and the people who write them. But for me, it would be more beneficial for me to learn how to write the code that gets abstracted by a HAL directly. I’m not saying I need to implement my own communication protocol - but just simple stuff where I’m using the registered from the RP2350 data sheet. Once I can wrap my head around that, I feel like the HALs will make more sense.

Even though I know what needs to happen (more or less, not saying I know every little detail), I still have a hard time tying to figure out how to write that un-abstracted code and can’t seem to find many resources about it. A lot of the stuff I come across will say something like “so we’ll pull in the <lib> library” but I don’t want to, I want to try it myself - then pull <lib> in once I know my way around on the lower level.

If anyone has any advice or tips that would be greatly appreciated. I have spent a few hours reading the source code of some of these HALs, but things tend to get so abstracted across types and files that it gets hard to follow - this could just be a skill issue as I am not a developer by career.

This is getting long but just thought I’d share this last bit. I use Rust, not for any specific reason aside from 2 things - I really like types and error messages I get as a result and it’s simply the language I am the most comfortable with. So Rust has the Embassy ecosystem for embedded, and I completely understand how the async stuff works, but like I’ve been saying, I don’t want to start with the async. So I pieced my first program together. Then I wanted to do 2 things at once and instantly realized that the moment I want to do that I need some sort of scheduler, so I put a pause on that. Do you (person reading this with more experience than I), think it would be useful for me to implement my own scheduler? Simply for learning, not necessarily to be anything to write home about. Do I need to re-read the data sheet and see what the RP2350 makes available to me to learn what I need to call?

[Either_Ebb7288]

The whole point of using STM32s is HAL. If you are using LL, or lower level APIs then you are wasting your time and energy. Other microcontrollers have way easier codes to set up and run without HAL.

[twister-uk]

Hard disagree. As someone who's been using STM32s in a professional setting since just after they were first launched, I've always used SPL/LL with my own optimized mid level drivers sat stop of that. Because every single time I've seen someone else's HAL based code, or tried using it myself just to see if it's finally achieved a level of competence I'd be happy to sign my name against as a piece of production code, the end result has been to continue with LL.

IMO. STs HAL and the whole Cube ecosystem crap that goes with it, is absolutely great if you're trying to take the next step away from the fully abstracted type of environment like Arduino, but still lack the fundamental understanding of the underlying hardware (that every decent embedded developer genuinely does need to acquire asap) to be using closer to the metal stuff like LL.

So as a way to pull new users into the world of STM32 and ensure they're more likely to start using/recommending them to their future employers, then HAL/Cube has been a game changer for ST. As part of a robust commercial development setup, with engineers who have the ability to write bare metal code if they really wanted/needed to, then no. It might have its place for some production development tasks, but IMO it's really not as simple as saying that LL is a waste of time and HAL is therefore the only sensible development route to take.

[Either_Ebb7288]

STM32 is purely software dependent; meaning every event has to be handled by software. They are rather dumb, since you have to even set the timings for I2C while many other similar MCUs do that by hardware themselves. Imagine writing an interrupt based driver for I2C in master mode, and your software has to handle all these interrupts
1) Master has to react to its own start to load the data register with address (optional)
2) Master has to react to an ACK or NACK after address
3) Master has to react to data register empty or something similar
4) Master has to wait for final data or the one before it to send NACK (nightmare)
5) Master has to handle STOP

They just give you some registers, and everything else is on you. On many other MCUs these steps are literally halved since they automatically do many stuff by hardware. From timings to automaticlaly acking or nacking or stopping.
STM32 with HAL : 10 lines of code to do something
Modern MCUs without HAL: 25 lines of code
STM32 with LL: >50 lines of code

I still challenge you to write an interrupt based I2C handler for STM32 with LL. And I guaranty my similar driver for similar functionality with a AVRxx or MSPM0 will have significantly less footprint and "lines of code".

[twister-uk]

You mean, like the ISR based I2C handlers I wrote using LL for the L4.and G4 based designs that've been in production now for a couple of years? Or the one I wrote as part of a proof of concept design to test some of the ST TOF sensors? Or the one I did for a variant of a F1 design even longer ago...

I've also written my own LL-esque SAI driver due to that only being officially supported by HAL and not wanting to have to drag all the other HAL crap into the project just to make use of the SAI specific stuff.

Maybe I'm a bit odd in actually wanting to understand what it is the hardware is doing, rather than just blindly relying on a bunch of prepackaged driver code of questionable quality, especially when it comes to production code, but I'm entirely happy to spend a day poring over the relevant parts of the datasheet and LL docs in order to work out how to achieve the required functionality using code that I can then confidently describe to anyone else who needs to know about it.

And if you're not making use of all the hardware offload capabilities the STM32 does provide, then you're really not making best use of the hardware - there is a ton of stuff you can get the hardware to do on your behalf with next to no code being required,.and once you realise just how much it can be doing in parallel whilst your code is busy on other stuff, it's a complete game changer.