[Stm32] Am I the only one not using HAL?

[Siwastaja]

Not to dive into a religious discussion, but all I can say is what has worked for me.

Probably many here like me have been concerned about the ongoing chip shortage, and certainly abstractions like HAL and CubeMX can mitigate migration of code to newer available chips as intended.

Call factual posters religious. State that you are not going to dive in. Then dive in 100% and post totally religious claim 

It's exactly the opposite, as westfw says. Chip shortage has been a breeze for people like myself, no problem whatsoever. We can use any microcontroller!

Yet, people who only can work with STM32HAL and CubeMX are in constant agonizing pain, obviously because it has been really tricky to get almost any STM32 part.

Sorry, could not resist - this was just so hilarious. I would have assumed everybody understood what "vendor lock-in" means and why it is a bad thing (unless it can't be avoided), but clearly this isn't the case.

Really, if you want an actual protip instead of bullshit, the answer is simple: write your own minimal and simple hardware abstraction (don't spend too much time on it, it doesn't need to be fancy), which can be ported quickly as needs arise.

[westfw]

I think a key thing is that YOU need to have an “abstraction” of the things you want your microcontrollers to do.  Whether you implement those abstractions by using vendor tools or bare metal, they make it MUCH easier to drill down through the tool or chip documentation.  “Here is what I think I want - how does this particular chip (or library) DO that” leaves you in a better position than just facing 1000 pages of documentation and trying to figure out how to get to a high level application.


Hopefully, this “personal abstraction” is somewhere between Arduino’s triviality and the vendors’s horribly complete library.  But perhaps it doesn’t need to be.


And your opinions can quickly eliminate some choices.  “I want a stream-oriented UART” can rule out all sorts of more “file oriented” abstractions, and “I want a zero-copy USB driver” eliminates lots of the choices (so maybe it’s not a great “want”?)

[Kleinstein]

The hardware abstraction libraries are supposed to make things easier. However the documaentaion for HAL is about as long that documentation for the direct hardware. If in doubt you still need to look at the HW documentation if the HAL docs are missing details or just refers to the hardware documentation.

As long one is using the µC in the HAL is meant to use it, it is OK. This includes many simpler programs.  However with more special functions and unusual use (e.g. use the UART to send a bit pattern instead of normal serial data) not directly supported by HAL things get nasty and one has to resort to direct register porgramming / maybe LL. So even more to read and learn and extra traps when the same HW is used both directly and via HAL. One of the more frustrating parts is when you hit a limitiation of HAL that is not well documented and after reading the chapter from HAL over an over again still have to resort to doing it by hand.
HAL also adds quite some code length, which can become a problem with a smaller (e.g. <= 32 kB Flash) µC.

[peter-h]

Looking at the project I've been coding for the last 1-2 years, about the only HAL functions still there are the ones which set up the pin alternate function mapping. New stuff I always write directly by reference to the RM.

The HAL functions are useful to see how something was done, and I often use them after stripping out ~90% of the code - because the writer tests loads of config register bits for optional features, which is stupid because you would never bloat your code with e.g. checking the SPI config for whether CRC is enabled when 20 lines further back you disabled the CRC feature

Enjoy this
https://www.eevblog.com/forum/microcontrollers/32f417-spi-running-at-one-third-the-speed-it-should/

[Siwastaja]

Looking at the project I've been coding for the last 1-2 years, about the only HAL functions still there are the ones which set up the pin alternate function mapping.

Even this is very simple, I came up with this in a few minutes and most of that work is silencing an old GCC version from giving unnecessary warning:

Code: [Select]

#define IO_TO_ALTFUNC(port, idx) do{ uint32_t _tmp_ = (port)->MODER; _tmp_ &= ~(1UL<<((idx)*2)); _tmp_ |= 1UL<<((idx)*2+1); (port)->MODER = _tmp_; }while(0)

#define IO_SET_ALTFUNC(port, pin, af) do{ _Pragma("GCC diagnostic push") _Pragma("GCC diagnostic ignored \"-Wshift-count-negative\"")  _Pragma("GCC diagnostic ignored \"-Wshift-count-overflow\"") \
if((pin)<8) {uint32_t _tmp_ = (port)->AFR[0]; _tmp_ &= ~(0b1111UL<<((pin)*4));     _tmp_ |= af<<((pin)*4);     (port)->AFR[0] = _tmp_;} \
        else {uint32_t _tmp_ = (port)->AFR[1]; _tmp_ &= ~(0b1111UL<<(((pin)-8)*4)); _tmp_ |= af<<(((pin)-8)*4); (port)->AFR[1] = _tmp_;} _Pragma("GCC diagnostic pop") }while(0)

#define IO_ALTFUNC(port, pin, af) do{ IO_TO_ALTFUNC((port),(pin)); IO_SET_ALTFUNC((port),(pin),(af));}while(0)

Usage:

Code: [Select]

IO_ALTFUNC(GPIOB, 5, 1); // sets GPIOB.5 to AF1.

That macro looks ugly but you only need to do it once.

[nctnico]

Such a macro is way better off living live as a function. Additional bonus is that the code is there only once instead of being replicated over and over.

[peter-h]

What CPU does the above work on?

[Siwastaja]

Such a macro is way better off living live as a function. Additional bonus is that the code is there only once instead of being replicated over and over.

I'd agree, nowadays I recommend using functions. It was written as a macro to get it inlined, and I haven't bothered to change something that works.

End result is the same. Even if it looks messy, the if-else will be compile-time constant and it reduces to a few simple register writes with literals. By making it static inline __attribute__((always_inline)), nothing changes really, but code will be more readable than a macro because we can get rid of (argument_parentheses) and weird do-while(0) wrapper.

In any case, this is something to be inlined. If the compiler truly implements it as a function with external linkage, code size will grow and execution speed gets slower because now it suddenly becomes run-time calculation.

By saying "code is replicated over and over", maybe you did not realize that this macro does nothing more than write a few literals from ROM (code) to registers. You can't make it significantly smaller; it's extremely small even if "replicated". If it is a true function, then it will be significantly larger, and at the call site, you still have to store the argument literals - and they will take roughly the same amount of code ROM from the literal pool.

All this code does is make the compiler calculate what bits to clear and set, from compile-time constants. This will be ANDing and ORing with literals, and those literals are what the compiler actually calculates, instead of doing it by hand, or by CPU run-time.

What CPU does the above work on?

All STM32's AFAIK. At least all I have used have the same MODER and AFR register naming and bit slicing conventions. But geez, this is all very simple stuff.

[cv007]

nowadays I recommend using functions

Or move over to C++, which has some nice advantages.

Just trying to compare the macro posted to what a gpio c++ class does-
https://godbolt.org/z/6s4n3vTxs

They end up producing the same code (the mode setting is done different, but same result). That will change if the gpio class takes on storage, which it doesn't in this simple example as was done in a way only to compare the macro. One difference in this particular case is by default the class constructor is going to enable the gpio clock in rcc, so no real need to think about whether the gpio clock is already enabled, although the macro could be changed to do that also. Not very efficient to keep enabling the same bit in rcc, but harmless and keeps one away from problems if this is otherwise required to be done separately.

Change the class to a template version where no storage is needed because all the needed info about a pin will be contained in the template parameters, then you are truly going to always do just as well as any macro or static C code. The downside to that is templates are infectious and it gets difficult to pass around pins as each is a unique type (requiring more templates).

You can use the normal/non-template version to always get to the macro equivalent (via optimization) if you do not let a gpio class instance (if even created) take on storage by letting it live beyond the current scope (which was done in the example). Much simpler to let your handful of pins use some bytes for each instance as it is an insignificant amount. Ease of use beats saving some bytes.

Another example for initializing a group of pins, such as ethernet pins (I think I saw something earlier in the thread using macros/enums/code to do this)-
https://godbolt.org/z/c1zjGc1M1

C++ is just a better, more powerful macro system.

[Siwastaja]

nowadays I recommend using functions

Or move over to C++, which has some nice advantages.

Just trying to compare the macro posted to what a gpio c++ class does-
https://godbolt.org/z/6s4n3vTxs


They end up producing the same code

... but also demonstrates how much boilerplate (which is not very readable, IMHO, either) one needs to write for the "nice C++ style". Of course, your C++ class does a lot more than just this, so it's hard to compare.

C++ is just a better, more powerful macro system.

Better I don't know, more powerful for sure.

For readability and maintainability, best would be a simple C function:

Code: [Select]

static inline __attribute__((always_inline)) io_altfunc(GPIO_Typedef_whatever_it_was * port, int pin, uint32_t af)
{
    if(pin<8)
    {
            uint32_t tmp = port->AFR[0];
            tmp &= ~(0b1111UL<<(pin*4));
            tmp |= af<<(pin*4);
            port->AFR[0] = tmp;
    }
    else
    {
            uint32_t tmp = port->AFR[1];
            tmp &= ~(0b1111UL<<((pin-8)*4));
            tmp |= af<<((pin-8)*4);
            port->AFR[1] = tmp;
    }

        uint32_t _tmp_ = port->MODER;
        tmp &= ~(1UL<<(idx*2));
        tmp |= 1UL<<(idx*2+1);
        port->MODER = tmp;
}


The same as the macro but without (), \ and do-while(0) stupidity, and with typing of the arguments.

Compare this to the C++ class used to achieve the same and many would agree it is more obvious what happens here.

C++ template system shines when you need type genericity, same code working for any arbitrary data type. In C, there is no other ways to macros to achieve that (see libraries like uthash, for example) - it works but is pretty crude. Here this is of course irrelevant.

[voltsandjolts]

Finding and hiring embedded programmers is troublesome, certainly in my locality.
I see a mix of embedded skills, such as picbasic, mikropascal and C (preferred of course).
During hiring processes I haven't seen anyone with embedded C++ skills, and that is what steers me away from it.
Hiring a C++ programmer (and allowing C++ to be used) is a risk because replacing them would be difficult and leave some projects in limbo.

[peter-h]

A guy in a local company employing ~50 coders said C++ was the only way to have say 20 working on the same product and have any chance of it working eventually.

There was no pretence of high productivity, however, apparently because few people are really good at it.

The above was applied even with 8/16 bit micros like the H8. The result was really slow e.g. a Modbus data request for some floating point values would see a gap of 1-2 seconds before anything started coming back, but that was because a) floats were used without hardware fp b) double floats were used pointlessly but were the default type c) nobody was bothered so long as it worked. Today, say arm32, it would all be a lot faster, but they still use C++ now for the above reason.

I've never written C++ and don't intend to I get the impression it is used for embedded in large companies only. But if that was true, wouldn't ST produce C++ versions of all their Cube libs? Big companies are by far the biggest chip users.

[pcprogrammer]

And why would you use C++ in embedded. 

You are working with limited program memory and limited data memory, why waste it on al the overhead it might bring.

The same goes for using malloc for that matter. For most of the embedded code it is known how much memory is needed and it is carefully planned what goes where.

For me plain C is much easier to read. No hidden functionality you have to dig for. But Java I find even worse. Whats up with the "class.sub_class.yet_another_class.function()" crap

[wilhe_jo]

And why would you use C++ in embedded. 

Because embedded includes >1MB flash, and you would get way faster, small, easier to read and better code with C++.

This horrific piece of bloatware ST calls a HAL is truely written by someone without experience.
I mean, you have numerous structs that pollute your stack just to do some case-switching inside some crazy-bastard-#if-orgy-spagetti-code....

All these "embedded-HAL" things are not really a HAL. They - at best - are just another layer of confusion.
Even those Arduino Guys have understood that C++ makes for better looking code!

But well, that's my view and you're welcome to use plain C (as I do as well).

For me, the best combination is to have a very,very,very thin layer of C under a functional HAL made in C++.
If done right, you get absolutely clean code without any overhead (in my experience you get faster and smaller binaries with c++ because of better high-level-optimization) that is a dream to port to other platforms.

But I think at this point, it's important to quote  Bjarne Stroustrup: "C makes it easy to shoot yourself in the foot; C++ makes it harder, but when you do it blows your whole leg off"

73

[Siwastaja]

Finding and hiring embedded programmers is troublesome, certainly in my locality.
I see a mix of embedded skills, such as picbasic, mikropascal and C (preferred of course).
During hiring processes I haven't seen anyone with embedded C++ skills, and that is what steers me away from it.
Hiring a C++ programmer (and allowing C++ to be used) is a risk because replacing them would be difficult and leave some projects in limbo.

Yes - a simple procedural C function is easy, because it is understandable and translatable to any other language. (Of course, with all the weird C quirks like integer promotions and whatnot, but most of these apply to C++ as well.) Such function is also compatible with both C and C++ (though not compatible with some C++ programmers).

C++ in embedded sadly screams the "rockstar" mentality. If used really really well, then others can of course accept to use and adapt to the project and even learn in process. But it's a risk.

Reason why C++ usually isn't worth it in basic IO and peripheral things is because in C, the solution is nearly minimal already. If your interface to turn GPIOA pin 5 high is, for example, set_pin(GPIOA, 5, PIN_HIGH) or similar, and the implementation is 1 or 2 lines of code, there is not much you can do to make it any smaller or more readable, or any easier to use.

Arduino uses almost zero C++ features and their subset and coding style is very C-like. They make code look nicer by eliminating some boilerplate common in both C and C++ by a code preprocessing step.

[emece67]

.

[peter-h]

like the ST HAL that, seems to me, does no provide any practical benefit.

ST HAL code does provide a practical benefit, even if you don't use it as-is: it gives you a starting point.

For example I am trying to put together an AES256 encrypt/decrypt function which uses the 32F417 AES hardware, preferably with DMA. There is some code online but it is all very old (~10 years) and one can't be sure whether more recent code (from ST) has silently fixed some issues. So I found stm32f4xx_hal_cryp.c from 2021. I now need to spend a day or two wading through that huge mess and pull out just the stuff I need but it is a lot less work than just reading the RM and spend a few days fixing problems.

[cv007]

If your interface to turn GPIOA pin 5 high is, for example, set_pin(GPIOA, 5, PIN_HIGH) or similar, and the implementation is 1 or 2 lines of code, there is not much you can do to make it any smaller or more readable, or any easier to use.

The problem with macros or static functions, is you first have to come up with names that do not collide with anything else. The next problem if using macros is your collection of macros grows and grows, and it ends up being another language you have to take care of and document, and can be hard to see what is actually happening. Static functions in a header are better, but still left with the naming problem and there is little or no validation that your arguments make any sense (some arguments will be be validated by the way they are used in the function/macro, such as a struct/register pointer, but other normal values will not).

I do think you end up with more readable code, easier to use, and same code generated with C++.

C++

Code: [Select]

Gpio led{ A5, LOWISON }; //we now have a name we can use- led, do not need a define for the pin or manually specify port/pin each time we use the led
led.off().mode( OUTPUT );
led.on(); //no need to know whether we need hi/low for on, we already decided when led was created

//can also init at instance creation
auto led = Gpio(A5,LOWISON).off().mode( OUTPUT ); //off will set pin high, so led will be off when output mode selected
auto sw = Gpio(C1, LOWISON).mode( INPUT ).pull( PULLUP );

while(1){ led.on( sw.isOn() ); } //led state matches switch (on() is overloaded, can also take true/false argument)

macros-

Code: [Select]

#define LED GPIOA,5 //will want something like this as we do not want to change all code if our led moves to another pin

set_pin(LED, PIN_HIGH); //off before output
set_pin_mode(LED, OUTPUT);
set_pin(LED, PIN_LOW); //we have to know whether low or high is on, or create more macros

#define SW GPIOC,1
set_pin_mode( SW, INPUT );
set_pin_pull( SW, PULLUP );

while(1){ set_pin( LED, get_pin(SW) ? PIN_HIGH : PIN_LOW ); } //need to figure out get_pin returns 0 when sw pressed, and led is low when on
With C++, I think the usage of the class functions 'attached' to the instance makes for nicer use since the first item is the instance (led) and what follows is an available function for the instance (ide's will help here).

[pcprogrammer]

Because embedded includes >1MB flash, and you would get way faster, small, easier to read and better code with C++.

Sure some devices have big or external FLASH, but not all. And smaller, easier to read and better code with C++, well that is your opinion.
For me certainly not true for Arduino. Sure it is nice for easy testing and if you are a noob, but for real serious stuff come on In case of a bug in the Arduino backware you are f....d. Good luck finding it.

This horrific piece of bloatware ST calls a HAL is truely written by someone without experience.
I mean, you have numerous structs that pollute your stack just to do some case-switching inside some crazy-bastard-#if-orgy-spagetti-code....

No argument there. That's what this thread is about. Not using that crap.

But well, that's my view and you're welcome to use plain C (as I do as well).

For me, the best combination is to have a very,very,very thin layer of C under a functional HAL made in C++.
If done right, you get absolutely clean code without any overhead (in my experience you get faster and smaller binaries with c++ because of better high-level-optimization) that is a dream to port to other platforms.

Everybody should use what they like best. For me it is plain C on the bare bones of the target. No standard library, no nothing. Put in plenty of comments and you get the easiest to read code.

But I think at this point, it's important to quote  Bjarne Stroustrup: "C makes it easy to shoot yourself in the foot; C++ makes it harder, but when you do it blows your whole leg off"

Well there you go, If you know what you are doing, I rather shoot myself in the foot then blow my whole leg off

[DavidAlfa]

HAL is dangerous!

[SiliconWizard]

What is "dangerous" is to use something without understanding it.

[langwadt]

And why would you use C++ in embedded. 

You are working with limited program memory and limited data memory, why waste it on al the overhead it might bring.

The same goes for using malloc for that matter. For most of the embedded code it is known how much memory is needed and it is carefully planned what goes where.

For me plain C is much easier to read. No hidden functionality you have to dig for. But Java I find even worse. Whats up with the "class.sub_class.yet_another_class.function()" crap

that you don't understand something and think it is too complicated doesn't necessarily mean that it is bad/bloated/wasteful, it just means you don't understand it...

[pcprogrammer]

And why would you use C++ in embedded. 

You are working with limited program memory and limited data memory, why waste it on al the overhead it might bring.

The same goes for using malloc for that matter. For most of the embedded code it is known how much memory is needed and it is carefully planned what goes where.

For me plain C is much easier to read. No hidden functionality you have to dig for. But Java I find even worse. Whats up with the "class.sub_class.yet_another_class.function()" crap

that you don't understand something and think it is too complicated doesn't necessarily mean that it is bad/bloated/wasteful, it just means you don't understand it...

What makes you think I don't understand C++. (Or Java for that matter)

I have used it enough to know how it works and that I don't like using it on embedded systems.

[Siwastaja]

And why would you use C++ in embedded. 

You are working with limited program memory and limited data memory, why waste it on al the overhead it might bring.

The same goes for using malloc for that matter. For most of the embedded code it is known how much memory is needed and it is carefully planned what goes where.

For me plain C is much easier to read. No hidden functionality you have to dig for. But Java I find even worse. Whats up with the "class.sub_class.yet_another_class.function()" crap

that you don't understand something and think it is too complicated doesn't necessarily mean that it is bad/bloated/wasteful, it just means you don't understand it...

What makes you think I don't understand C++. (Or Java for that matter)

I have used it enough to know how it works and that I don't like using it on embedded systems.

The confusion is here: people disagree about what C++ means.

Those who use it in embedded use a minimalistic subset, removing all features that do not work well on embedded; for example, C++ exceptions.

If you are familiar with C++ application development and have seen "full" C++ being used, it is no wonder using it in embedded seems crazy.

In embedded, basically they use just the class system with constructors, not even destructors because usually you use C++ in embedded to just init with a tad less writing, but never want to deinit, so objects are either global, or in main() so that they never go out of scope because of the infinite loop.

Once you want full control where you init and deinit things dynamically, as in many of my projects, you do it in C because you want to control exactly what deinits() and WHERE, and in which order, because of shared resources, nasty cross-dependencies, and timing constraints. For similar reason, linux kernel is in C, not C++. C++ allows some nice abstractions, but it's exactly those nice abstractions which also fall apart when the use case becomes slightly unexpected. A true C++ pro is always able to somehow manage everything in C++, but us mere mortals then become unable to read their code and participate, because the class interactions can become very complex.

The purpose to use C++ is to change the simple and readable 8 LoC C code into 15% simpler and 20% more readable 6 LoC C++ code, as demonstrated above by cv007. For this to look convincing, you have to ignore the work that went into writing the class implementation, which is much longer than the C equivalent, and also has quite some boilerplate in it. But sure enough, you "only need to do it once", and sure enough, for simple static cases, it sure does optimize to the same machine code.

Some embedded C++ examples indeed look very good, there clearly is potential. But I still think an embedded C++ developer as a risk factor. Best case, C++ is "only in the name", or opposite kind of best case, the nice C++ abstractions happen to work with the project very well. Worst case - you have expanding unmaintainable mess with one rockstar C++ developer who is driven over by a bus.

I think Linus Torvalds' description of C++ applies to embedded as well:

inefficient abstracted programming models where two years down the road
you notice that some abstraction wasn't very efficient, but now all
your code depends on all the nice object models around it, and you
cannot fix it without rewriting your app.

This is the general problem with object-oriented languages used to their "fullest", with cathedral-like class hierarchy design, often designed with tools like UML.

Set of simple procedural functions with less built-in interdependency, spread over a few modules, does not look nearly as fancy, but also carries less risk and offers more opportunities for modification and reuse, even if the project scope isn't exactly as planned.

[pcprogrammer]

But sure enough, you "only need to do it once"

Which also applies to the plain C case. I only figured out once how to initialize the STM32F103 clock system and reuse it for every project I do with a STM32F103.

And you are right, my C++ experience comes from graphical application development.