Is ST Cube IDE a piece of buggy crap?

[LM2023]

In many years I've tried a lot of different ones all either not configurable enough, or looking like a Win 3 program, or not multi platform, or slow or buggy or all of it at the same time (◐).
 
VS Code is the only editor/light IDE that managed to make me abandon Emacs, I started at version 0.13 IIRC and never looked back - the only thing I miss are keyboard macros, but multiple cursors cover 90% of my needs.

I like VS (not Code) a lot too, but that's Windows only - not using it much since Code came around.

Have you tried Qt Creator ? It is optimized for Qt development but it is multiplatform and supports C/C++ development and debugging with any GCC or CLang toolchain for Windows, Linux and Mac OS/X.
The latest version also has a "Bare Metal" plugin that directly supports ST-Link, J-Link, OpenOCD etc. (it is disabled by default, but you can enable it).
To use Qt Creator you don't have to download the full Qt SDK, just the application and point it to where your toolchain, debugger (and eventually CMake) are.

[DavidAlfa]

Could anyone suggest why I am getting this all the time I restart the target

Because... CubeIde 1.13? 

[peter-h]

I am just amazed this is even possible... the code you wrote bombing the debugger.

[eutectique]

I am just amazed this is even possible... the code you wrote bombing the debugger.

Could you step it in assembly? You can pinpoint the exact location where it happens and what is going wrong.

[peter-h]

I will do that next time it happens. Now I have moved on...

One possibility is that the source code doesn't exist. This is often the case with arm32 and conditional instructions - as in the case above. The debugger needs to deal with this and it is not going to be trivial. When stepping, you see it happening when a piece of sourcecode is just skipped, as it discovers that there is no machine code present. The debugger may not be handling all the possible cases.

[paulca]

C / C++ folks have always been hard to please.  Traditionally you basically had a text editor (maybe a fancy one or a fully configured Vim) and a terminal for Unix development.  For Windows development you had Visual Studio or a selection of other payware options from the likes of Borland.

My 3 years in C/C++ dev in stock exchanges was 90% Vim + Shell + Sconscript.  Later Eclipse CDT was "played with".  As it couldn't integrate the SConscript or the PerForce source control (with had it's own GUI) so the only bonus it provided was code indexing and CTRL+Click to follow references... which it didn't do all that well either and "Grep" was far more reliable.

Eclipse was born and bred in IBM as an IDE for IBM WebSphere Java application platform.  IBM have a long history of "Trading" with OSS and so they created the Eclipse Foundation and open sourced the main IDE, keeping only the IBM WebSphere integrations prop.  You can immediately see where the model eclipse uses comes from, core functionality shared and enabled with more specific integrations.

Eclipse therefore was and still is primarily a Java IDE.  Yes efforts have been made to keep the core functionality agnostic, but the truth is the user base is orders of magnitude more likely to be Java developers.  It has far more functionality and far more stability and is far more "prolific" in use for Java.

Eclipse CDT is fairly mature, however the C/C++ build and deploy environments aren't.  The best you get is the GNU stack, the rest is bespoke, custom or proprietary, so a small and uncompetitive market with no "consensus" like exists in Java where there are only 2 dependency and build management systems and only a few deployment management systems.  So almost all of those have direct integration in Eclipse (and other IDEs).  In C/C++ they would need to implement dozens and dozens of combinations.  Even when only targetting a single platform (STM32) it's complicated by different versions of the dependencies and the targets themselves.   C/C++ is not cross platform.  So using a cross platform IDE is a little puzzling... however , STM have basically choosen it as the base of their proprietary IDE.  They could have tried Inteli/CLion or any other, but they choose Eclipse CDT.  The rest is up to STM.

Out of interest (found on my travels).  Python is just about overtaking Java as the main Enterprise language.  The reason behind that is, Java costs too much, Python is easy to learn, you can hire anyone and give them a crack at python.  It's quick to write and dog slow to run, which works for many organisations.... until it doesn't.  The other issue with Python, and why myself and others defend core infra from it, is "latent syntax errors".  Almost always in untested error handling code, compounding the issue.

C/C++..  it depends on where you read and if they just harvested CVs and think that HTML/CSS is the most common language, it's sub 15% of the market.

In fairness that should elevate salaries... however I suspect micro-controller platform companies may still be far-shoring development.

[dietert1]

People use STM32 Cube because it is free, so maybe it should compete with other free stuff. Anybody who can spend a little money will get IAR or the like and just use CubeMX and the HAL libraries to get things started. Or go bare metal if the sponsor can pay.

Debugging problems often stem from optimization. Compilers come with defaults and you have to turn it all off in order to be able and debug along a source file. In IAR we have "Release" and "Debug" at project level and they provide library sources just like STM. I remember a project with severe problems only in the "Release", so we had to setup a third stage in between to debug those problems.

Regards, Dieter

[peter-h]

All possible but it still should not crash like that, because the whole program has to be restarted.

The whole Debug v. Release paradigm is that you can define different build options and then just build one or the other by ticking the box. I don't use it because it is a massive hostage to fortune to build a working product in Debug and then rebuild in Release and send out 100 or 1000 of them to customers! Regression testing is simply impossible on anything which does more than toggle an LED (you get my drift). So much is timing sensitive; I have just spent all day chasing one such issue with ADC timing... I build with -Og all the time and will ship with -Og. There are a few times in Cube when you can't see variables properly (unless you build with -O0) but it is easily fixed for the few minutes by putting "volatile" before the variable But even then, conditional instructions can mean there ain't no code there!

Sure corporates will pay because it makes them happy but IME pricey tools are not necessarily good. I have used £10k ICE boxes, £1k+ IAR tools (1980s pricing) which were horrible, etc. Licensed tools tend to bite you in the bum because the floating license server has broken, a remote one is no longer supported (the Adobe CS3 case is a notorious example), you can't get others working on your project remotely without a load of hassle and cost... and the "support engineers" are generally guys who failed to be good at anything that actually works so they move into tech support, marketing, etc. Mostly they are a waste of space unless they have a direct channel to God (the actual guy in the actual company which wrote the tool).

IMHO Java is shit. Everything I have used in Java was only just hanging together. The language has always suffered from a million of version dependencies so with every product you have to ship a gigabyte of java libs (because the Java you installed on your PC will be useless). Java is great for earning a lot of money in a big company because nobody else can maintain the product. In theory it is cross-platform but that is buggered by so many subtle version dependencies. Some of the worst examples are within ATC which uses vast Java applications which cost millions to write, have UIs from the DOS6.22 era, and nobody can do anything to fix or improve them.

But Eclipse was done in Java so we are stuck with it. Just reboot it fairly often

The box I am working on will be used by other coders and no way could I sell it with a paid devkit. Those days have long gone.

[DavidAlfa]

I remember a project with severe problems only in the "Release", so we had to setup a third stage in between to debug those problems.

Probably due crappy programming causing issues when enabling optimizations? That's the usual.
I like the IDE a lot. HAL and MX not so much. But you can use it as you like.
Lately I'm using just Low level libs for the cheap chinese arm chips, everything initialized by hand.

In the end it's just Eclipse with few addons to make it ready for ARM programming and debugging.

[SiliconWizard]

Many of these "IDEs" are based on Eclipse, but that's not like using bare Eclipse distributions. I don't think you can update the Eclipse part of it as you would with bare Eclipse (let me know if I'm mistaken about that though), so you're stuck with the version the vendor tool was released with, and if it contains bugs that the Eclipse team has long fixed in the meantime, you're stuck with them too.
Also, specific addons written by the vendor for supporting their parts may themselves add their batch of bugs.

As to Java-based software in general, I have my opinion too but this time I'll probably keep it to myself so as not to trigger a flamewar.

[DavidAlfa]

What are you afraid of? Java provides great portability at a huge performance/memory cost.
For me it's like Surströmming to programming languages.
The same thing on C++ would blast to orbit while using 256MB  .

[paulca]

What are you afraid of? Java provides great portability at a huge performance/memory cost.
For me it's like Surströmming to programming languages.
The same thing on C++ would blast to orbit while using 256MB  .

A 96 core server with 256Gb of RAM cost less than a Java developer does for 2 months and produces less serious runtime bugs, java devs are easier to find, and java an order of magnitude faster to write.  Java is, whether you like it or not, a better language for the largest portion of the industry.

[voltsandjolts]

Java is great for java developers and oracle.
PITA for everyone else.

[peter-h]

Presumably there is no way to build Cube IDE any other way today, is there? It's been written in Java and will always have the general portability and runtime version dependence of Java. They ship the entire runtime with it



but it still has various issues which cannot apparently be fixed because the whole tool is so complex. But maybe it has to be this complex... there is a lot of functionality. OTOH this is functionality which has accreted over years.

[paulca]

I'm not sure if that's correct.

Eclipse core is Java.  However a large part of the GUI has been ported to native C binded GTK+. 

CubeMX may, or may not be Java based.  It is basically the standalone app, but with it's entry point wrapped in the Eclipse plugin wrapper so it appears as a view.

The 3.7Gb folder is about 70% documentation and example projects.... for ALL platforms, including the ones you don't have.  Go browsing.  I'm not even sure it's go the firmware in it.  I moved it to another drive (a slow spinning network disk).   I can't find it now, must have deleted it.  Not to worry, it's 100% reference material.  Nothing more.  100% replaceable.  Delete, restore.

The Java JRE required to run eclipse is usually provided by Windows, which it comes packaged with these days.  A wiser developer will fix that. <wink>.  I don't know the size of the basic JRE these days, but it's not more than a 100Mb.

As a sanity inducing exercise for you.  Go create a new machine.  Even a VM. Create your dev environment on it from scratch.  Review it.  This will help you understand all your config overheads/complications.  It will also allow you to identify when it's the "upgrading" process or the new version of the IDE which has broken your build.  It will also help make you decouple your project from "A development environment.".   Even if it's multilple instances of Cube/Eclipse.  You absolutely need to spawn and rebuild a 'reference' IDE setup.  If all goes mamaries up ... rebuild the reference IDE and it still doesn't work. it's really broken.

[NorthGuy]

The 3.7Gb folder. 

Wow. I used lots of IDEs in the past. Now I rarely use them. Most of the time I use a text editor which has few features - like syntax highlight, compiling by a button press, show the output, find the location of an error, invoke a programmer, a few other things. That's basically all I need. Two files - 110k executable and 80k DLL. Roughly 200,000 times smaller than your Cube. I understand that other people want more functionality, but I can't imagine anyone needing 200,000 times more than I do.

[ataradov]

As it was pointed out, that size includes example projects generated for all possible MCUs. Nobody "needs" all of them, but at any given time any person may need one of them. Whether it is worth installing all of that by default is a matter of opinion. If you don't do that, then there will always be people complaining that they need extra steps to get their example projects.  And 3.7 GB is not that much.

Plain basic Eclipse is way smaller. It is still bigger than a basic text editor, but it does a lot more too. And again, it would depend on your needs if you need any of that.

I just looked at Harmony 3 directory on my computer, and it is 20 GB. But that includes a lot (not all though) core components and examples for majority of ARM-based MCUs. I don't have anything checked out for MIPS.

A lot of it is redundant code, of course. But storage is cheap and it is way better to have a dedicated project for each peripheral and each MCU rather than have a #define monstrosity. After all, a person really cares about the MCU they have, so it is better to get a clean example for that MCU only and ignore the rest.

[Perkele]

Eclipse CDT from 2021, with a support for MingW, folder size is 550MB.
It's a nice tool.
Helped me to figure-out some huge codebases relatively quickly.
And it had a good support for almost every crap that project leads pushed onto their slaves team members.
I can understand why embedded engineers and one-man-band people hate it, but in an "enterprise" environment it was really useful.

These days, having to use VSCode instead feels like going from Unimog back to horse and cart.
And that horse has a limp, flatulence, and diarrhea.

[DavidAlfa]

The size is not a problem.
Opening a project and freezing for 10 seconds in a fast 5GHz 8-core machine it is!

[NorthGuy]

The size is not a problem.
Opening a project and freezing for 10 seconds in a fast 5GHz 8-core machine it is!

They both are symptoms of the same - excessive complexity and poor design. Bugs are another symptom.

[paulca]

Eclipse CDT from 2021, with a support for MingW, folder size is 550MB.
It's a nice tool.
Helped me to figure-out some huge codebases relatively quickly.
And it had a good support for almost every crap that project leads pushed onto their slaves team members.
I can understand why embedded engineers and one-man-band people hate it, but in an "enterprise" environment it was really useful.

These days, having to use VSCode instead feels like going from Unimog back to horse and cart.
And that horse has a limp, flatulence, and diarrhea.

Yep.  I agree.  VSCode is nothing more than a code browser with a nice(?) plugin interface.  It's free, makes VS people feel at home and gives MS a better footing into the developer space they had been pissing off for a decade prior.  You can now sign up to a dozen different "online IDE" setups and online code review/interview systems, all of which use the "online" version of VSC.

There are a list of features in Eclipse (and VSC to be honest) which just wouldn't interest most "one man band" outfits.  Almost the entirety of the enterprise integrations will go unused.  Nothing to integrate with.  Although surely most of the wise use git at least.

Most embedded folks just like to install a full platform, pre-canned, just make it work, for MY MCU.  Understanding what goes into that is, at least today, often left in the pile "If I really, really have to..."

I'm pretty sure you can use a basic GNU cross compile stack with Makefiles, Autoconf etc without an IDE being involved.

This is how it would be handled in enterprise.  At least in the sense the build process has to be executable on a controlled environment (security/reproducability).  The developers can use whatever IDE they like.  In a team there may be one main IDE, but there is usually someone trying to be different.  So projects exist in two distinct layers.  What gets checked in and thus built on the build servers and what exists on the developers machine, in terms of tooling and techniques, which is entirely up to them.

If you separate your build and possibly deploy process from STMCube your reliance on it will drop significantly.  Your flexibility to "build, deploy and test" your way, in an automated fashion on a server running test harnessed MCUs... the world is your oyster.

While you rely entirely upon STMCube... you are a boat on their river.  Just get yourself a paddle.

I have not looked into cross compile build servers for STM32.  I have built the stack previously for Atmel AVR.  I did not put a build server on it, but it was a basic GNU cross compile stack so in theory any CI/CD platform which supports Makefile projects and shell script deployments should work fine.  Commit, push, build, deploy, test, fail, repeat.

[NorthGuy]

I don't see how integration is related to IDE. Integration is done through Git (or similar). Nobody cares (or even knows) what IDE you use, or if you ever use any. Look at Linux Kernel, for example. Their code base is huge and they have enormous number of developers working on it.

[DavidAlfa]

What do you call "integration"? Git is only one part.
It's also the toolchain, code editor, programming/debugging support... Install and go, that's what IDE stands for.

I tried PyOCD yesterday. Oh man, same broken crap like all Linux stuff.
F** Python mess, because you can't simply run pip update, you must issue a 30" long command to get it done.
Then the package is installed but can't be executed...not found.
After long search you find a 8-month old git issue, "we've fixed it but its not released yet". Ok....

Everything in Linux seem to need two days to set up, mastering in sed and Linux insides, several hours searching the errors...
This is what ** me up. It's *** 2023, stop relying on 300 external commands for everything.
People argue at Windows, but all I need is to install C++/.Net libraries, jdk... And they don't f** each other , they all live in peace.

That's why, though sometimes slow and buggy, I'm fine with cubeIDE or eclipse, it's stable enough, if something breaks I can simply reinstall it, instead waiting for the day something breaks in my mind and I run outside with a shotgun 

[NorthGuy]

What do you call "integration"?

I was replying to the posts about integrating a developer into an enterprise system.

[DavidAlfa]

Ah, sorry!