Is ST Cube IDE a piece of buggy crap?

[Siwastaja]

And is ST's HAL really that bad? I looked at it a couple of years ago and the code looks reasonable...

It's not that bad per se (at least compared to the horrible former ST style copy-paste struct initialization pattern offering no abstraction at all). HAL just offers poor abstractions and forces patterns that are suitable for general purpose desktop computing over an operating system but on a microcontroller, just reduce flexibility, add another layer of extra work (because normally you need to go into the low level code inside the HAL anyway), without offering any significant upsides.

It's enough to have properly documented peripherals with working examples for the most common use cases, instead of poorly documented peripherals with one typical use case hidden inside the HAL implementation. This is exactly what AVR, PIC and similar did for decades, no problem even for a beginner. And usage of most peripherals on STM32 is same complexity as on AVR or PIC, really - typically 5 lines of code.

And this is the opposite of being elitist.

[nctnico]

And is ST's HAL really that bad? I looked at it a couple of years ago and the code looks reasonable...

It's not that bad per se (at least compared to the horrible former ST style copy-paste struct initialization pattern offering no abstraction at all). HAL just offers poor abstractions and forces patterns that are suitable for general purpose desktop computing over an operating system but on a microcontroller, just reduce flexibility, add another layer of extra work (because normally you need to go into the low level code inside the HAL anyway), without offering any significant upsides.

Not everybody sees it that way. Over the years I've come across enough embedded software engineers who strongly prefer a library like ST's HAL over programming bare metal. And they do come up with software that meets the design goals.

[Kjelt]

CMIIW but AFAIK the Cubes implementation is so relatively more "bloated" because it has to support ALL STM32 microcontrollers, which mean M3,M4, etc. And even the peripherals from the STMF1xx are not the same as on the newer STMF4xx which also has a newer Arm core etc. Etc. Than it also supports the HW prototype nucleo boards.

If you as many hobbieists or small companies only use one specific family of the STM32 uCs you can optimize the bloated generated code varily easy, adapt it to your wishes and so make your own libraries.

But even experienced Emb SW eng. from scratch program the HAL for themselves for all peripherals even for a single uC? Probably a few months incl. debug and get it operating to satisfaction.
Most hobbieist with their own stack only support 40% of what the peripherals can do and probaly satisfies everything they want to do with it.

ST does not have that luxury, they need something for all possible usages of the peripherals in combination with all their devices.
This means abstraction layer on abstraction layer which makes it bloated.
That in it self is already a miracle they have something and it also most of the time works   

[NorthGuy]

You hit the nail on the head. There isn't anything that can compare to having good examples that work. It is so simple to take a working example, figure out the details of it, and modify it to your own needs. If a manufacturer spent the time to give us those kinds of examples, rather than on making flawed auto configurators, etc., many of us would be much better off.

As you program more and more, you have more and more code. If you face something you've done before, you can just copy your old code and modify it as needed. That's the same as missing examples.

I found that copying your earlier code and modifying it for the task often works better than libraries which try to be a master-of-all-trades.

[NorthGuy]

Why would you write a UART driver if you have a piece of code which already does that for you in a way which is suitable for the project?

Because it's just few lines of code. It's easier to write than to figure out whether the code written by someone else is suitable for your project. Besides, hardware modules typically have much better documentation than libraries. So, you'll save some time too.

[nctnico]

Why would you write a UART driver if you have a piece of code which already does that for you in a way which is suitable for the project?

Because it's just few lines of code. It's easier to write than to figure out whether the code written by someone else is suitable for your project. Besides, hardware modules typically have much better documentation than libraries. So, you'll save some time too.

You say it is a few lines of code but that isn't the case when you throw in DMA, software FIFO buffers and interrupts (the latter basically means it has to be thread safe). It can get hairy pretty quick especially if the UART supports an internal FIFO as well. Not every programmer has code like this lying around.

[SiliconWizard]

And is ST's HAL really that bad? I looked at it a couple of years ago and the code looks reasonable...

It's not that bad per se (at least compared to the horrible former ST style copy-paste struct initialization pattern offering no abstraction at all). HAL just offers poor abstractions and forces patterns that are suitable for general purpose desktop computing over an operating system but on a microcontroller, just reduce flexibility, add another layer of extra work (because normally you need to go into the low level code inside the HAL anyway), without offering any significant upsides.

Not everybody sees it that way. Over the years I've come across enough embedded software engineers who strongly prefer a library like ST's HAL over programming bare metal. And they do come up with software that meets the design goals.

To be honest, I have done baremetal on a lot of MCUs, but I've always used the HAL on STM32 ones. Of course, sometimes I'll write additional functions tailored to my needs when the HAL ones are not efficient enough - but I admit that's just a few in a given project. On example would be using DMA: most peripheral drivers come with a DMA version for transfering data, and it works, but is pretty inefficient if execution time is critical, as they usually reconfigure the DMA channel every time you call them, whereas configuring it separately would be much more efficient. That's one example for which I sometimes write my own functions.

Using vendors' libraries has pros and cons of course.
Pros are not just saving time; it usually allows porting to a different MCU from the same vendor a breeze with rare exceptions.

As I mentioned in another thread, the STM32 HAL may look bloated, but obviously functions must cover as many cases as possible. That's the obvious price to pay. They also use a style that one may not like, but that mainly comes from the fact it's MISRA-C compliant.

Now I'm not advocating one way or another. It all depends on your goals, available time, coding rules you may have to comply with, and so on...

[dietert1]

This discussion contains very strange statements. The capability to understand and make use of the work other engineers have done before should never be called incompetence. It is something valuable that needs training and experience, too. You cannot always work alone and start from scratch.

Regards, Dieter

[NorthGuy]

You say it is a few lines of code but that isn't the case when you throw in DMA, software FIFO buffers and interrupts (the latter basically means it has to be thread safe). It can get hairy pretty quick especially if the UART supports an internal FIFO as well. Not every programmer has code like this lying around.

You may use DMA, or you may not use DMA. You may use interrupts or you may not use interrupts. You can use different kinds of buffering or none at all. You may split your processing between interrupts and "main" code in different ways. You may use RTOS or you may not. Now, try to write code which covers all the cases. This will be very complex code which is very hard to deal with. Or you can omit most of the cases and provide something very limited. Take your pick. That's the situation library writers are in - they don't know how their code will be used, so they unavoidably make it either too complex or too restrictive. They're not magicians and cannot write good code without knowing the task.

I like to write specific code, tailored to the task. It makes things much easier and straightforward. Just so happened that yesterday I needed a circular buffer which was, sort of, unusual - one writer but two independent readers. Not related to UART, but a FIFO anyway. Took me 20 minutes, 45 lines (including some data processing). Worked from the second run. Is it really worth digging into libraries for the code that small?

[NorthGuy]

This discussion contains very strange statements. The capability to understand and make use of the work other engineers have done before should never be called incompetence. It is something valuable that needs training and experience, too. You cannot always work alone and start from scratch.

That's the other way around. Incompetence is not an ability. Incompetence is inability. Like inability to understand forces people to guess. Or inability to write code forces someone to use code written by others.

[bson]

Start using git.  "git diff" will tell you right away what has changed.  And, yes, IDE editors are pretty poor - the only reason to use IDEs in the first place is indexing and debugger integration.  If emacs had a better indexing system than etags I'd probably never touch IDEs at all; personally find it much easier to work with Makefiles than 100s of settings pages to find where, for example, you set a linker option or linker command file.

[AaronLee]

To be honest, I have done baremetal on a lot of MCUs, but I've always used the HAL on STM32 ones. Of course, sometimes I'll write additional functions tailored to my needs when the HAL ones are not efficient enough - but I admit that's just a few in a given project. On example would be using DMA: most peripheral drivers come with a DMA version for transfering data, and it works, but is pretty inefficient if execution time is critical, as they usually reconfigure the DMA channel every time you call them, whereas configuring it separately would be much more efficient. That's one example for which I sometimes write my own functions.

Using vendors' libraries has pros and cons of course.
Pros are not just saving time; it usually allows porting to a different MCU from the same vendor a breeze with rare exceptions.

As I mentioned in another thread, the STM32 HAL may look bloated, but obviously functions must cover as many cases as possible. That's the obvious price to pay. They also use a style that one may not like, but that mainly comes from the fact it's MISRA-C compliant.

Now I'm not advocating one way or another. It all depends on your goals, available time, coding rules you may have to comply with, and so on...

For me, I have a fairly limited number of customers, and the projects they need are generally the same general types over and over again. Meaning there's lots and lots of functions that I use over and over again. So things like UART interfaces, with similar usage, ADC and DAC used in similar ways, etc. Also, there's a variety of different MCUs I use, but it's not huge. Once in a while I need to design for a new MCU because I inherit an existing project for which just minor changes are needed, but if there's a major overhaul, I'll specify that the MCU be changed to one in my normal repertoire. Given this sort of usage, it ends up being very worthwhile for me to completely skip the vendor's libraries as much as possible/practical.

If my projects were all over the map, and using all sorts of different MCUs, there's more chances that using the vendor's libraries could save time and be of an advantage in more cases. But given my usage, it makes much more sense to me to develop my own "libraries", which are just a common way of designing/calling these functions I use again and again. At the core is code which contains no bloat, because I've tailored it to my specific usage.

So I think it really depends on the skill and experience level of each firmware engineer plus their usage as to how much/little they use the vendor's libraries. As time goes by and I gain more experience, I see less and less of an advantage for using vendor's libraries. Even if it takes a bit more time initially, I learn that again and again I save a lot of time and headaches in the long run by having as much as possible of the code being my own.

[peter-h]

A lot of truth written above, but there is a spectrum and different people are in different places.

For example I am a businessman first (it is my business) and my #1 job is to look after the business. So in product development I have to "pick my battles" and do stuff which will work and crucially which can be done in a futureproof way so I can revisit a job in 10 years' time. Even if I have help now, I can be sure I will be working on it alone by then.

But if I was working for somebody else's company, I don't need to care much. I can spend a week learning some new tool. It will cost my employer 1000 quid while I am playing with that, but I don't need to care. I don't need to document anything, and actually that improves my job security (in the short term, anyway). One sees this in web (server side software) development where a new tool, worthy of a 1000 page manual, comes out every week. No doubt produced by a bright young lad who doesn't have a girlfriend so he can be incredibly productive. That tool will be forgotten in 10 years' time. Try to get somebody to work on Ruby on Rails; it may as well be Cobol/66.

"It's enough to have properly documented peripherals with working examples for the most common use cases, instead of poorly documented peripherals with one typical use case hidden inside the HAL implementation. This is exactly what AVR, PIC and similar did for decades, no problem even for a beginner. And usage of most peripherals on STM32 is same complexity as on AVR or PIC, really - typically 5 lines of code."

I agree 100%. I have just spent a few hours trying to work out, from the RM, how to set up UART1 for 9600,8,n,1, polled. This is just for debugs very early on after startup when there are no interrupts and I can't call the ST libs because this is a boot loader. I reckon it could be done in 10 lines, but setting up the pins (the various alternate function options) so the UART TX and RX actually come out is a lot more complicated; I reckon at least a day's reading and trial and error. I gave up and found another way. Rather than a bloated code generator, ST should have offered code examples, for each peripheral.

Well, it is more complicated because of inter-dependencies like clock configs, alternate functions, half the UARTs/SPIs/whatever are not usable because the pins are used for other stuff. Setting up that sort of stuff is a great use for a GUI.

[dietert1]

A procedure that i remember was generating my own code examples using the CUBE framework just to extract some essential components i wanted. This may help with the "cannot use ST library for boot loader" part.
With the durability part i agree you have to write some kind of work log since GIT will not tell you the reasoning of changes. Even with notes it can be surprisingly difficult to understand the work oneself has done before (e.g. two years ago).

Regards, Dieter

[Kjelt]

For example I am a businessman first (it is my business) and my #1 job is to look after the business. So in product development I have to "pick my battles" and do stuff which will work and crucially which can be done in a futureproof way so I can revisit a job in 10 years' time. Even if I have help now, I can be sure I will be working on it alone by then.

If you're serious about this then there is only one way: Linux and Arm compiler and only license free software packages.
Windows, IDEs, VMs, cloud based solution, software that needs a license, they are all not 10 year proof and I have experienced that in my previous company multiple times.

In that case forget about Cube unless you create your product with it and then store the bare C code, but do not think in ten years you can start it up, change some I/O pins through the IDE and recompile, that is not going to work, probably not even in three years.

[peter-h]

Windows is not that bad, and I am still running some 1990s software in a winXP VM without any problems.

Indeed; I would never use any software which uses online license checking. That is a disaster looking for a time to happen.

[nctnico]

Windows is not that bad, and I am still running some 1990s software in a winXP VM without any problems.

Indeed; I would never use any software which uses online license checking. That is a disaster looking for a time to happen.

The problem is not that a license expires but that you can't move a license to a new PC. This is the reason that I only use software which is either 'free' or for which a hack is available so I don't have to depend on the supplier to continue using software that I have paid for.

[abyrvalg]

A short example of Cube's code "quality" that hit my eye right at the start, a piece of startup.s (comments under // are mine):

Code: [Select]

  * @author    MCD Application Team
 ...
/* Copy the data segment initializers from flash to SRAM */ 
  movs  r1, #0
  b  LoopCopyDataInit

CopyDataInit:
  ldr  r3, =_sidata   //mem read
  ldr  r3, [r3, r1]     //mem read
  str  r3, [r0, r1]     //mem write
  adds  r1, r1, #4
   
LoopCopyDataInit:
  ldr  r0, =_sdata   //mem read
  ldr  r3, =_edata   //mem read
  adds  r2, r0, r1
  cmp  r2, r3
  bcc  CopyDataInit
- each loop iteration does 3 useless mem accesses for each 2 useful (+both additions could be replaced by post-indexing)
There is no universal purpose in this, it just was written by an ARM beginner, "For gamers by gamers" (Interplay's old times motto).
(keeping the asm startup tradition on Cortex-M designed to start right to C code is another question)

[peter-h]

Well, almost nobody knows assembler these days, and much promotion is based on "you can do this all in C" so no wonder the startup .s code is not optimal.

You could never do this with say a Z80, but a 32F417 running at 168MHz does most things "instantly". It's the old story about 95% of the time spent in 5% of the code, and it certainly isn't spent in startup.

[dietert1]

You get those libraries for free including source. If you think you can do better and it matters for your application, edit the source, no problem. Or try other optimization settings of your compiler. I know that IAR optimizes to a degree that you can no longer debug in a meaningful way - i mean if you want that.

Regards, Dieter

[abyrvalg]

That code is from startup_stm32f407xx.s, optimization settings wouldn't affect it. And the question is not "should we say thanks to ST or tar&feather them", just saying that code looks like written by a beginner.

[dietert1]

If it's an assembly file, edit the source. If it's a C file, you can try the optimization settings first. If that doesn't help, edit the source.
Your conclusion about beginner work requires benchmarking alternative solutions. Those MCUs are complex enough to falsify simple assumptions which code will run faster.
I remember very well my first encounters with Kinetis MCUs about ten years ago and software experiments to check instruction cache size, flash memory clock, peripheral clock etc. Of course for serious work you can't use that cheap/free stuff as a black box. You need to look at some details. The vendor provided examples and frameworks are meant to get you started.

Regards, Dieter

[Siwastaja]

This discussion contains very strange statements. The capability to understand and make use of the work other engineers have done before should never be called incompetence. It is something valuable that needs training and experience, too. You cannot always work alone and start from scratch.

... a complete strawman argument which shows nothing else that you did not read or understand anything you seemingly commented about.

It's completely unfruitful reiterating it again and again because all the points have been made and if you can't understand it, then I don't know what to do. I'm just happy I don't need to work with you in my teams.

Enjoy your echo chamber, you'll have no lack of members.

(nctnico at least gets the idea that different viewpoints can exist, and coexist, and different people have different ways of working, which I'm thankful.)

[Sal Ammoniac]

You could spend half your day with the data sheep and alternate pin function mappings just picking pin mux settings.

You could spend the other half of your day looking at the AC specifications / PLL reference manual / clock generator documentation just figuring out the PLL / clock division settings for the more important peripherals.

Once the GUI tool helps you visualize the pinmux / pinout and clocking and pick settings yeah the API calls aren't that hard but do you really want to read the DS + architecture manual + reference manuals / user guides + application notes cross referencing 200 different scattered pages to know what a given $7 MCU variant is capable of?

Oh and what is the magic sequence needed to program / sequence various internal voltage / power domain / clock settings registers to switch from internal RC oscillator at 1 MHz to external crystal + PLL depending on the MHz you want to run at?

For a timer capture how / where do you control the edge polarity, what interrupt channel is that again?

There are too many details even for a single modern MCU part to manually deal with that all 2000 different relevant register settings / capabilities / sequencing / alternative assignments by manual documentation process.

What you're describing is lazy engineer syndrome. Why bother understanding the capabilities and settings for a particular MCU when you can let some automated tool take a stab at it? IMO, any embedded engineer doing commercial work should understand the intricacies of the components he's using in his designs and not rely on automated tools to do his thinking for him.

Relying on automated tools leads to less understanding of how things work and how they interrelate. What are you going to do, for example, if you're at a customer site one day trying to debug an issue in the autogenerated clock configuration code with an irate customer breathing down your neck? I've actually been in exactly this situation and was able to resolve the issue quickly and defuse the irate customer because I thoroughly understood the clock configuration code I wrote myself.

[dietert1]

So you had an issue in the clock configuration you wrote yourself. This is a strange example. For a beginner it is much safer to rely on vendor provided framework. The STM32 libraries are pretty mature.

Regards, Dieter