Is ST Cube IDE a piece of buggy crap?

[Nominal Animal]

But all the "Re:" replies will still show the old subject, won't they? So...

Reply subjects prior to the change will show the old subject, yes; but any new posts after the change will have the new subject, including shown in the Subject: field when editing the post.

I personally do read entire threads, and exactly what I'm posting to, including the Subject: field when posting (and have even played a couple of gags with it on occasion when responding to obtuse original posters), so I see that as preserving the timeline and is completely acceptable to me, not a problem.

That is, I do not understand what the "But" and "So..." part is your response means.  To me, the change in the subject has been here and should always be a "narrowing", i.e. "focus" the thread better than it initially was, and not a change to something different.  Here, the suggestion was from "Is ST Cube IDE a piece of buggy crap?" to "Is ST Cube IDE the same piece of buggy crap as any other IDE out there?", which I do consider a "focusing", although others may disagree.

Thus, "focusing" a subject better via editing it a bit, having old subjects remain unchanged, and new subjects reflect the change in subject, is in my opinion perfect: response subjects show the topic the responder is responding to, discussion timeline information is completely retained and obvious, and nobody reading the posts (as long as they read the post subjects, too) is mislead in any way.  Assuming the subject change is a focusing and not a change to something unrelated or only vaguely related or opposite (topic switch-and-bait is evil!), that is.  I see the same done to positive effect on mailing lists as well, where threads are joined by mail ID references and not by similarity of subjects.  When a "subthread" focuses on some detail of the overall thread, the subject is often adjusted to reflect the focused subject, and makes it easier for others (who only typically look at the subjects to determine whether to read the message or not) to decide whether to participate or not.

[DavidAlfa]

That "no such file" error has magically gone away. Yes, a probable caching issue.

No compiler will search the included file elsewhere, so why are relying on some magic IDE fuzz to find the files automatically?
Setting the inlcude path takes 30 seconds, just do it properly?

[peter-h]

AFAICT is was already set. It is in the /Src directory where everything else, including some other .ini files, are. For some reason Cube decided to not see this file when doing a build. I checked the obvious e.g. was it excluded from the build. And you could always edit the file from within Cube.

So it seems to have been a makefile update process fault. Most of Cube is basically a makefile generator

Whenever changing files around one needs to do a Clean Project, Refresh project, and Index Rebuild.

[paulca]

Whenever changing files around one needs to do a Clean Project, Refresh project, and Index Rebuild.

This is common for files which produce no target.  They do not trigger a rebuild of the target.  C files etc have a target .o file to produce so do trigger build targets.

[peter-h]

Referencing the issue with RWX load permissions, a further back, the linker options supplied further back in this thread are invalid for GCC.



I am testing with Cube IDE 1.16.0 (GCC 12)

[paulca]

Related, but unrelated rant.  Just to share that it's not just Eclipse that's annoying.

InteliJ.  Since about 4pm yesterday it has insisted on rebuilding a project every 1 minute.  However IntelliJ is not using the Maven context and so is not running the code generator portion.  Thus it then fails compiling the unit tests because the reflection package is not available.  When it does this, it pops the build tab up and open the MockXXXTest.java file.

Googling for how to stop it or what might be causing it has not been productive.

I rebooted.  Reloaded the project and .... it started again.  Grrrrr......!!!!!!

[peter-h]

Due to some weird issues with "const" strings in main.c I thought about eliminating a compiler issue and installed Cube IDE v1.16.0 which also brings GCC v12.

Well, they have broken the SWV debugger interface, same as they did on 1.15.0. I have spent hours trying different settings, different debuggers...

The binary produced (I am building with -Og) is 472k versus 473k with GCC v11, FWIW. I can load it into my product using a web server which it has, and... the code doesn't run! But without a debugger there is little one can do. The SWV ITM debug console doesn't work without a working debugger! So I can't even do printf type debugs.

Going back to 1.14.1 and GCC v11.

I like their SOH too:

[peter-h]

There seems to be a certain level of resignation on the ST forum that 1.16.0 stops the debugger working They did the same on 1.15.0; fixed on 1.15.1. It doesn't look like they test the thing before release even in the most obvious way.

A serious Q: how do people developing something serious deal with this? The obvious answer is to freeze the toolkit (I froze at 1.14.1) and disable checking for updates, etc.

[DavidAlfa]

Error while attempting to show an error... 

[peter-h]

Can anyone guess what % of Cube IDE users are running on linux?

I am packaging my project for others to work on it in the future. The Windows one is easy. There are three linux distributions:



There are problems which surface. 1st one is obvious: no batch files in linux so any post-build process needs to be re-worked. Also filenames are case sensitive so that needs to be fixed and some of that involves editing a .project file which is tacky. I guess linux users are just used to fixing this stuff.

[DavidAlfa]

Linux bash is far more versatile and easy to use, porting batch to linux is pretty straightforward.

[ataradov]

There are problems which surface. 1st one is obvious: no batch files in linux so any post-build process needs to be re-worked.

Shell scripts are way better than Windows batch files. And porting a batch file to a shell script is generally trivial, but not the other way around.

Also filenames are case sensitive so that needs to be fixed and some of that involves editing a .project file which is tacky.

If I see a project with inconsistent file names, I just know it is bad in other aspects as well regardless of the OS. If you can't even name the files consistently,god known what you have inside those files.

I guess linux users are just used to fixing this stuff.

Not really. More and more dev stuff is oriented towards Linux recently. And the amount of dicking around came down a lot in the past decade.

And for distribution, select Generic or Debian.  Most companies do both.

[peter-h]

If you can't even name the files consistently,god known what you have inside those files.

I don't think so. It happens ex-ST too, with their own code. Easy to fix.

More and more dev stuff is oriented towards Linux recently

That was my Q really. What % use it? There seems to be plenty of "dicking around" still. Like having to set the executable attribute on a file from an FTP site, which previously lived under Windows.

And for distribution, select Generic or Debian.  Most companies do both.

I have downloaded v14.0 of all of these and will archive them, with some generic instructions.

[ataradov]

Like having to set the executable attribute on a file from an FTP site, which previously lived under Windows.

This is an FTP failure, it does not carry file attributes. TAT/GZ them and you will get all the attributes preserved on extraction.

I have downloaded v14.0 of all of these and will archive them, with some generic instructions.

Wait, I assumed you are preparing the archive. Those are just downloads from ST? Then why archive them? Let users download whatever they need for their system.

[peter-h]

The reason is that ST carry a given version, say 14.0, for only x months, after which you will have the task of sorting out a ton of compiler/linker errors/warnings, not to mention spend weeks on regression testing, because Cube IDE v 276 installs GCC v 74

One cannot do any development with these tools on the basis of downloading them from the mfg's website. They need to be archived. Both Cube and GCC are a moving target.

That's before one gets onto fun bits like v15.0 breaks the debugger interface, fixed in 15.1, but 15.1 is on the ST website for only a month or so.

[westfw]

Heh.  The two most common complaints from developers using packaged IDEs that include a compiler:

• "Why do you keep updating the compiler that causes my code to emit more warnings/errors?"
• "Why are you still using this OLD compiler that doesn't have <feature>?"

[peter-h]

Can anyone name a missing feature of ARM32 GCC 11 which arrives with GCC 12 and which is relevant to embedded development?

[westfw]

(I'll admit that I usually see the "too old" complaint about C++.  And in particular in the Arduino arena where they're still running C++11 and g++ 7.something.


I dunno.  I usually write pretty conservative C/C++, and I don't expect it to change out from under me, and I don't rush to use the latest features.)

[ataradov]

It is not necessarily about the features. Those new errors and warnings peter-h complains about actually highlight problems in the code. And new versions of the compilers are getting better and better at that. To the point where MISRA checkers are even more of a scam than they always were.

And for well-written code new versions of the compiler are generally not a problem. If switching compilers breaks your code, your code is crap.

[SiliconWizard]

If you don't have access to some expensive static analysis tools and compilers warnings don't quite cut it for you, I recommend checking your code at least with cppcheck. It's become a decent tool and certainly catches a lot more than GCC.

[peter-h]

The only issue I have seen over past few years has been changes to compiler or linker defaults, like e.g. that executable segment warning. That one is hardly appropriate to the embedded scenario and the fix is a PITA because, IIRC, you have to modify the linkfile which is a super dangerous thing to do on any nontrivial project. No code of mine ever got "broken" by a new compiler. But it is still time consuming because if you get stuff like this, you need to spend time dealing with it, just in case it means something, and it will be much harder if this task falls on somebody who did not write the original project.

The bigger thing is that a change of tools means re-doing all the product testing, and you have to ask yourself: why?? You have a working product, been selling for a year or more, and now somebody enforces a new compiler, on the grounds that "if it breaks the product the code is crap". In that context, that is the purist arrogant sort of thing which an employee, with zero stake in the company's business, might come up with. It's a terrible way to manage business risk. You need that tool change like you need a hole in the head.

[newbrain]

If you don't have access to some expensive static analysis tools and compilers warnings don't quite cut it for you, I recommend checking your code at least with cppcheck. It's become a decent tool and certainly catches a lot more than GCC.

That's a useful tool.
As a more comprehensive solution - still free - you can look at Ericsson's codechecker:
https://github.com/Ericsson/codechecker

It's still open source (Apache license), based on clang static analyzer and, in fact, cppcheck, and can use a number of other static analyzers.
It can be used directly on the command line to check a file/project or to store and visualize formatted reports (supports PostgresSQL).

[peter-h]

Are these for C or C++? I am only C.

[newbrain]

Are these for C or C++? I am only C.

Cppcheck and the clang ones are for both, but provide more C++ specific diagnostics.

For the other analyzers that codechecker can use, see the list at:
https://github.com/Ericsson/codechecker/blob/master/docs/supported_code_analyzers.md
which links to each one.

[peter-h]

I went to try the GCC analyser and - you might laugh - could not find any way to run it No apparent windows installer etc.

FWIW, I don't use the heap except as a one-off block allocator (for a product option) which is never freed, and I don't use pointers (other than explicit & and such passing variables to functions).