Is ST Cube IDE a piece of buggy crap?

[esepecesito]

My experience was I had to make a lawnmower robot in 1 month. I came back to programming microcontrollers after 5 years of no touching anything...
I had many IIC sensors, UART, USB, had to support low power modes, I had to make signal processing (some FIR and IIR filters) and 2 PID controllers; so I had to use DMA for the communications if I did not want to loose time.
Also had to control 3 BLDCs, including overcurrent protection.
Requirement was to have an operating system running, so it was modular with tasks (customer requirement).
In the middle of the project I had to make me an "Oscilloscope" -- long history. I did it with the USB and ADC of the controller. Took like 1/2 hour to make.
Now should I have started bare metal, MAYBE I could have made it in 6 months?. Alone reading the manual for the low power modes and clock generation would take me couple of days.
I got it running in 2 weeks (first prototype), and working correctly after another couple of weeks. For me it would have been impossible to do all without the help of CUBE.
Yes for a blinker, maybe not good. Maybe for a professional product, also no good. But for some small projects like mine, it was a big accelerator! Just my experience.
As I said, it depends on experience, ability, and project needs. I understand it may not be good for you.

[SiliconWizard]

As I repeatedly say, even if you want to use the HAL with STM32 (especially if you're beginning with them), just browse the example projects provided with the SDK instead of using Cube. It'll get you there in a short time without having to deal with code generators further "hiding" what you need to know.

Now of course if you directly want to go "bare" without the HAL, read the manuals. But still, example code with be handy, because there's quite a number of things to know when you start (configuring clocks, understanding the clock tree, and so on...)

[Sal Ammoniac]

Another good option for hobby projects is Segger Embedded Studio. It runs on Windows/MacOS/Linux and is free for non-commercial use. It's much faster than any Eclipse-based IDE.

The only caveat is that it only supports J-link. That's not a problem for most Nucleo and Discovery boards as you can reflash the ST-LINK firmware on the board with J-Link firmware.

https://www.segger.com/products/debug-probes/j-link/models/other-j-links/st-link-on-board/

[profanum429]

Another good option for hobby projects is Segger Embedded Studio. It runs on Windows/MacOS/Linux and is free for non-commercial use. It's much faster than any Eclipse-based IDE.

The only caveat is that it only supports J-link. That's not a problem for most Nucleo and Discovery boards as you can reflash the ST-LINK firmware on the board with J-Link firmware.

https://www.segger.com/products/debug-probes/j-link/models/other-j-links/st-link-on-board/

I'm a big fan of the Segger ecosystem. A J-Link EDU + SES is a good combination for hobbyist work and I find SES works for me way better than any Eclipse based solution. Another option is CMake+some editor/IDE like VS Code or CLion but I find this is a bit harder to jumpstart the first time around.

[dkonigs]

Whatever tool you use, there is absolutely no excuse to not use source control.  Thanks to modern systems like Git, its even easy to do source control local to your own working directory.  Heck, I'll even use it for scratch projects that don't get checked in anywhere.  Its an invaluable tool for tracking what changed from one moment to the next, whether the change was done by you or by some tool.  Think of it like an "undo history" that lives beyond your current IDE/editor session.

The only acceptable excuse for not using source control, IMHO, is because you don't understand how. But that really just means you need to learn.

(Anyways, I've been using STM32CubeIDE and haven't really had any showstopper problems with it. I have noticed that oddity with the debugger opening a random file, but that's the only one I regularly run into.)

[peter-h]

I last used source control many years ago. My main issue is having a futureproof development environment, which I can understand and is self-documenting, because I often have to revisit a project after many years. And running everything in a VM (and archiving the VM) is a tacky option, which I reserve for old software and such.

Yesterday I managed to trash my project, seconds after I backed it up. It was done by copying the project directory to a network drive, as I do now at least daily. Except instead of Copy I did Cut

And I saw all the open files, and everything else in Cube, disappear, over a few seconds

Getting it back wasn't easy, because Cube stores some config under the project and some under c:\st (or whatever, under Configuration). And as Cube sees files disappear (due to external action) it reconfigures itself accordingly. I had to retrieve the \st directory from a machine at the office, which had an older copy of the sources I am working on. The reason was that the \st directory got trashed as the files disappeared from Cube, even though I never touched anything in \st.

Then I got it all back but the project file hierarchy (on the left) was all one level. I eventually found that doing a reindex / clean / build restored things. But I lost the debugger configs.... That took a bit longer.

A stupid mistake... Took an hour to get it all back. I'd like to know how this can be prevented, with an app which stores its config all over the machine.

I have a 3am auto backup of the project anyway, but that currently gets overwritten each time.

Obviously backup up a project while Cube is running is a less than great idea, but it does normally work. Except that you aren't backing up the "whole project".

Coming back to the randomly appearing open files, this clearly exists and has done for ages, which shows the arrogance of the people who developed this thing. If this was my business. I would fix such obvious stuff right away.

[JOEBOBSICLE]

It'd drive me up the wall not having version control, I use it to find where I've gone wrong all the time.

[Silenos]

@peter-h To me it seems you are inventing issues not known by others, and then waste time bravely battling them.
I advice investing a week into fixing the toolchain and workplace into something stable, even sth like vsc+c|make-whatever+integrating it with code generation from Cube, if you insist on that. I bet the investment will return in less than half a year.
And apart from that do git (or something) course. Put a repository on your network drive and forget the ctrlc/v crap.
Few years ago I sat with 61 years old coworker; he was doing "version control" by manually copying project trees into catalogues with timestamp, manually, all his life. I gave him some git gui client and managed to teach him that in half a day, he was gasping in awe when he saw diff tool. So really, no excuses here.

[newbrain]

Yesterday I managed to trash my project

I'd be tempted to do some victim blaming, but I'll abstain and instead reiterate what was said above:
Use a version control system. (Ctr-C Ctrl-V ain't one)

You can learn git (others VCSes exist, but git is the most commonly used and has great support in all decent IDEs) from the book or in more gamified way if you are so inclined.

I'm sure tons of other tutorials exists, for any taste - these are a bit the two extremes (but the game makes you use real commands, if you want to, being based on an actual git installation!).

Git is in a nutshell an application to manage (directed acyclic) graphs where each node is a commit (a picture of the repository at a specific moment in time) - once that is understood the "advanced" concepts like branching, merging and rebasing are easier to grasp.

Even in an extremely basic usage pattern (just periodically committing on a single history line) it helps immensely.
It's easy to revert a bad change or an experiment, globally or at the single file level.

The integration in VS C (plus Gitgraph or Gitlens extensions) is simple to use even for a git novice.

Using a remote repo of some sort will make you safe from the kind of disaster you've just experienced, but even without it, it's very difficult to hose a local repo, unless one starts poking where they shouldn't.

There are many service that offer free, private repository (Github, Gitlab etc.), or you can set up your own server (Gitlab CE, Gitea etc.) or just use another local directory in a pinch.

[dkonigs]

Using a remote repo of some sort will make you safe from the kind of disaster you've just experienced, but even without it, it's very difficult to hose a local repo, unless one starts poking where they shouldn't.

There are many service that offer free, private repository (Github, Gitlab etc.), or you can set up your own server (Gitlab CE, Gitea etc.) or just use another local directory in a pinch.

The best part about systems like Git, as opposed to the older version control systems (SVN, CVS, etc) is that you don't even need to setup a server to use it. You can get many of the advantages entirely within the confines of your local working directory. It makes it easy to use even in cases where you'd normally never even bother setting up a hosting solution.

(Heck, I even use it on the local output of CubeMX-generated code dumps just as an easy way of tracking the relationship between project settings and generated code.)

[DavidAlfa]

Git is like these stupid TV ads, "Git has saved my live", "I'm a new person after meeting Git", "There's never enough git"", with a difference: it's not BS!

I remember those moments when I had changed something, somewhere, and it no longer compiled, throwing a strange error that didn't identify the offending line of code.
*Deep breathing*... What the *** did I *** up? I had to read every damn line of code with a magnifying glass.
Usually something hard to catch, like a dot, space, dash, bracket... And lost 2 hours of my life with a such dump thing.

STM32 IDE has some bugs, but once you get used to it, it's pretty nice.
I don't know what skills are you having, by but no way you can code by hand all the initialization code faster than cubeMX.
After learning how to use it, the configuration takes minutes. Set up all the gpios, pullups, input, outputs, dma channels, spi peripheral, enable interrupts, change priorities...
And you're ready to start you app. Of course, it takes a lot of time to know everything because the documentation is inexistent.
I hated it so much at the beginning! Now, knowing the typical issues and how to fight them, it works really well.

[Siwastaja]

cp * ./backup2021_08_01

works almost acceptably for a single-developer project as long as you remember to do that every day or so. You can always diff.

... But why do it that way since git does not require any more work, and basic usage (init, add, commit, checkout, diff, log, push, pull) is learnt in a few hours.

So just use git for anything fancier than a quick led blinker test.

[Siwastaja]

After learning how to use it, the configuration takes minutes. Set up all the gpios, pullups, input, outputs, dma channels, spi peripheral, enable interrupts, change priorities...

I don't really understand this. None of this takes more than a few minutes, completely irrelevant in the large scale of things. The only exception is when dealing with some non-trivial configuration - requiring extensive and careful reference manual reading, reverse-engineering and testing - which has high chances of Cube and/or HAL being totally unable to deliver such code at all.


You need code generator to change interrupt priority because it's otherwise so time consuming?

How about writing:

Code: [Select]

NVIC_SetPriority(TIM2_IRQn, 5);
Really, if you struggle to do that to the point of requiring a point&click interface, how can you program at all? Sorry, I just don't understand, can you elaborate? Or is the Cube generating 420 lines of code to do that, as well, so you think it must be hard?

Enabling interrupts? So each time you need to enable/disable interrupt you click through the GUI, get some chunk of code, and then copy-paste it (or let the GUI insert it where you need it) in the suitable place in your program code, instead of just writing

Code: [Select]

NVIC_EnableIRQ(TIM2_IRQn);
Sorry but I just see this as a horrible waste of time.

[Siwastaja]

That's a valid point, and you need to do that before committing to PCB design. I have been hit once by an STM32 where I simply was unable to use DMA where that would have been very beneficial and my original plan, because the stupid DMA channel mapping limitations (can't use DMA for two specific peripherals at the same time). Looking at the DMA mapping list of the manual would have solved it in 1 minute, but I wasn't that experienced with STM32 back them, I assumed you can arbitrarily map DMAs (like you now can in H7 devices) without looking it up. Cube would have revealed this, as well; Cube did not exist, I was fighting against different piece of crap tools back then. Now people who said they can't live without them don't remember those ever existed. Remember CooCox?

I would be very satisfied with just a very simple UI where I click which peripheral combinations I need, when I need to use DMA and so, and it would just print out "possible" or "impossible"; maybe list me the AltFunc numbers and DMA Channel numbers to save me the (IMHO, relatively small) task of looking them up from the manuals.

Doing that manually for a more complex project takes a few hours after all, still insignificant for projects than run for months to years.

Oh, that should be Javascript on the vendor's website.

Basically, a product selector that does not lie; one that takes into account the combinations I need. You don't need a code generator, you need a product selector which would have the advantage of being able to suggest different devices instead of you iteratively starting a project for some chip you think might be able to do the job.

But you need to understand, this has absolutely nothing to do with software, it's purely a problem of hardware design; design software can help solve it, but you don't need the generated code for that pattern to be useful. But having code generated kind of locks you in because these tools are notorious for bloating the code so it makes you feel like it did save you a lot of job; a typical 5-LoC operation becoming 50 or 100 LoC.

I always hand-calculate the PLL settings, it's elementary school math involving 1-3 multiplications and maybe 4-5 divisions, does not take "half a day", but maybe you can save 15 minutes by installing and "learning to use" a tool, working around bugs thereof? Does it ever pay back the invested time?

Complex C APIs where you cant remember which argument is which and then solve it with an IDE, and curse about the IDE being unable to help after all, that's a completely made-up problem. Microcontroller peripherals are simple, write simple abstractions, refuse to use crappy ones!

[dietert1]

Another observation is about the wrong and unrealistic expectations people develop from marketing and ads. You know that in ads children are clean and friendly, the dog stays in its corner etc. If you never worked with STM32, you cannot expect a nucleo board arrive from Digikey in the morning and your project finished in the evening of the same day. Although some youtube videos may give you that impression, that is complete nonsense. You will have to register on web sites, find downloads, install them, try different tools, read some example code, read some forum threads.
Like olympic competitions: Besides lot's of exercise you may also need some coffee as doping. Take your time and learn! I think STM32 is fairly mainstream and the effort won't be wasted. In the end the Arm infrastructure is common to other brands.

Regards, Dieter

[Kjelt]

Another observation is about the wrong and unrealistic expectations people develop from marketing and ads. You know that in ads children are clean and friendly, the dog stays in its corner etc. If you never worked with STM32, you cannot expect a nucleo board arrive from Digikey in the morning and your project finished in the evening of the same day.

Exactly this. I stop with reacting in topics who have such a negative statement in them.
My personal experience with people who have big trouble with embedded systems categorie:

-HW engineers without much programming experience
-SW engineers without much embedded experience, (the malloc 1GB people)
- princes and princesses of the 2000+ Born generations that have been pampered by their parents, whose school assignments even if they sucked where "fantastic !" and have a perserverance to solve a problem on their own of almost zero.

If you can't get a led to blink on a Nucleo board with ST Cube within one or max two days even with the st forum help Embedded SW is probably not for you.

That said if you are a (small) business only use Cube as fast start up, rewrite critical HAL parts for yourself and create your own infrastructure. Don't expect a project that compiled, build an finished two years ago to do the same today   

[peter-h]

"-HW engineers without much programming experience"

That's why I am here asking questions

[Kjelt]

Then I would recommend to pose open questions and prepare to put in some serious effort. As said many times before on this forum since 2010 at least, 8 bit micros are relatively easy to understand and comprehend for HW engineers, datasheets are few hundred pages and registers for peripherals are easily programmed.

32 bit Arm based uCs different breed and datasheets are scattered over the core manufacturer (Arm) and the integrator, who all use their own peripherals with their own quirks, ST for the STM32. Multiple hundreds and hundreds of pages of datasheet (AND errata!) and it just takes time to investigate step by step how to use such a device.

[JOEBOBSICLE]

"-HW engineers without much programming experience"

That's why I am here asking questions

I recommend you go through one of the full cortex m courses or books. I recommend you understand the build system and linker before you start shipping anything to customers.

Do you understand how the stack works? Do you know how to avoid Malloc. How do you setup freertos? What's the difference between the PSP and the MSP. What happens when you pass note than four arguments to a function on cortex m?

All of these questions you should know the answer to before anything goes out the door. You will get weird/intermittent bugs especially if you don't have -Wall on and having the confidence to debug any problem is key.

[peter-h]

" prepare to put in some serious effort."

Been doing a number of hours a day.

Today was spent on reading files (FatFS), CRC checking, and writing them into a serial FLASH (Adesto 45DBxx). Got that running nicely now. Even got flashing lights when doing it

"Do you understand how the stack works? "

Done megabytes of assembler since c. 1980 (see list in sig) so I think I do

"Do you know how to avoid Malloc. "

Wouldn't touch malloc() with a 20ft bargepole, in an embedded system.

"How do you setup freertos? "

Have had the system running with FreeRTOS for about 6 months. Rock solid.

"What's the difference between the PSP and the MSP. "

No idea.

"What happens when you pass note than four arguments to a function on cortex m?"

Hmmm, it loads the first ones in registers and the rest go on the stack? It would be obvious when watching the asm listing during single stepping, as I often do.

The questions I am posting here are on quite specific areas. One cannot learn about how good some IDE is by reading the website, because they all say theirs is a fantastic tool for modern software artisans

Based on what I hear and see I think I will stay with Cube IDE

As regards version control, the last one I used was Polymake (PVCS), in the 1980s. I am sure they have moved on.

[NorthGuy]

I'm sure that an experienced professional, such as Siwastaja, can do the job much faster and much better without Cube. Of course, he wasn't born that way. He spent some time at school. The, I guess he did many projects with various CPUs, made many mistakes, learned from them, and gradually became competent. And even now he continues to learn, and isgetting better and better. But this takes time.

Things like Cube are designed to "help" inexperience people to do the job without becoming competent. The result may be somewhat ugly, but there's no way for the incompetent people to judge. The Cube generated code may be 10x or 20x times bigger than the code written without Cube, and consequently would have more bugs and would be much more difficult to work with. It's also likely to be less efficient and not targeted to the specific situation. But they don't care. Funny, but at the same time they want their CPU to be faster and more efficient and they want super-optimizing C compilers.

"But I was thinking of a plan
To dye one’s whiskers green,
And always use so large a fan
That they could not be seen."

But here's the rub. IMHO, for incompetent people the best solution is to learn and become competent. This is common sense. Why in the world would you use a tool which is designed to prevent you from becoming competent?

[nctnico]

As regards version control, the last one I used was Polymake (PVCS), in the 1980s. I am sure they have moved on.

Please do yourself a big favour and start using Git. I know it is another piece of complexity and learning curve but being able to go back to a working version or just check what you have changed between versions is great. Cube IDE should have integration with Git (or it should be possible to install it from the Eclipse repository). And Git also supports binary files (AFAIK Git treats any file as a binary file anyway) so you can add external libraries / binaries to your project and have them under version control as well. This makes using externally compiled binaries (think FPGA image or bootloader for example) much easier; you are always sure you have the right version together with your project.

I'm also using Git to keep track of software packages I send to customers in binary form.

[Siwastaja]

I'm sure that an experienced professional, such as Siwastaja, can do the job much faster and much better without Cube. Of course, he wasn't born that way. He spent some time at school. The, I guess he did many projects with various CPUs, made many mistakes, learned from them, and gradually became competent. And even now he continues to learn, and isgetting better and better. But this takes time.

Thanks but I'm younger and less experienced than you might think. I still clearly remember the time I was beginner with microcontrollers so I can relate. Yes, jumping to ARM took time due to one silly bug in the stupid tutorial I was following, but if I had a non-broken linker script as an example, the time consumption would have been totally manageable, not too many hours actually.

And of course, microcontroller-based product design / firmware design&implementation is not taught (properly) at school anyway. My major was "computer engineering" so around FPGAs and some ASIC design etc. MCUs are from hobby basis originally.

The point is,
* Crappy tools like Cube waste your time and limit your abilities long term - this is quite agreeable I think, no?
* But I would go further and say - they don't save enough time short term either, to be worth the long-term cost, no matter what coeffs you put for importance of short term vs. long term as long as it's something more sane than 100%-0%.

My statement is, the sole reason beginners have to resort to such tedious, crappy and time-consuming broken workflows like Cube and ST HAL, is the utter lack of proper examples and tutorials guiding beginners, or if they exist, they are damn hard to find.

I often play with the idea of writing such tutorials but it requires a lot of time to do properly - I don't want to be part of the problem -, and I have enough to do already.

Classic principles of abstraction work really well on this problem. For example, I have a simple one-liner I can use to configure an IO pin as an alternative function, and set the AF number, instead of having to remember the register names and correct bit shift distances for the two registers involved. Coming up with such simple solutions does not take a lot of time, but saves it a lot long-term.

[nctnico]

But here's the rub. IMHO, for incompetent people the best solution is to learn and become competent. This is common sense. Why in the world would you use a tool which is designed to prevent you from becoming competent?

But what if people can't reach the competence level required to do without code generation tools and hardware abstraction libraries? And what if people are not willing to learn not to use such tools? The answer to 'what it the simplest solution?' will depend entirely on the person you are asking the question to and many different answers will be right. There is no black or white / right or wrong here.

And is ST's HAL really that bad? I looked at it a couple of years ago and the code looks reasonable and seems to be MISRA compliant indeed. For sure there will be bugs and it is more bloated due to needing more flexibility but IMHO that doesn't make it a complete non-starter. 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? Not wanting to use the HAL out of elitist thinking / not-invented-here syndrome doesn't seem sensible to me in terms of spending time efficiently. Especially given the wide variety of peripherals ST is using in their microcontrollers at least the HAL gives you some portability.

[AaronLee]

My statement is, the sole reason beginners have to resort to such tedious, crappy and time-consuming broken workflows like Cube and ST HAL, is the utter lack of proper examples and tutorials guiding beginners, or if they exist, they are damn hard to find.

I often play with the idea of writing such tutorials but it requires a lot of time to do properly - I don't want to be part of the problem -, and I have enough to do already.

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.