Author Topic: Is ST Cube IDE a piece of buggy crap?  (Read 164246 times)

0 Members and 1 Guest are viewing this topic.

Online SiliconWizard

  • Super Contributor
  • ***
  • Posts: 14462
  • Country: fr
Re: Is ST Cube IDE a piece of buggy crap?
« Reply #1000 on: October 30, 2023, 07:46:15 pm »
Peter.  To be honest.  I'd give up.  All of your posts in this thread just say you aren't cut out to be a developer.

That's probably true, but what he said about Java just above holds 100% true. Most Java apps are distributed with a compatible JRE that the app has been tested against, and a whole range of issues can occur if you use another JRE.
Java has never been all that stable in terms of compatibility, unless maybe you used only very basic libraries. Anything using fancy GUI Java libraries is a compatibility nightmare.

If you did my day job you'd go postal in weeks.

Don't know what your day job is, but certainly a pure software development position would make a lot of us go nuts very quick. It's become, uh, very special.
 

Offline peter-hTopic starter

  • Super Contributor
  • ***
  • Posts: 3694
  • Country: gb
  • Doing electronics since the 1960s...
Re: Is ST Cube IDE a piece of buggy crap?
« Reply #1001 on: October 30, 2023, 09:32:20 pm »
I think hiding a return() in a macro like that is crappy coding. It is OK in that function, but this code is generated for people to use as example in general.

Similar to having a macro in a .h file which actually generates executable code.

Re "cut out to be a dev" well obviously not, because a real dev

- comments nothing
- documents nothing
- uses esoteric pointer code which nobody else understands
- has no stake in the company staying in business (always on LinkedIn looking for his next job)
- could not care less if a product sells well for 10 years (never mind 25 like some of mine!) and has to be maintained after that time
- documents nothing

:)
« Last Edit: October 30, 2023, 09:50:47 pm by peter-h »
Z80 Z180 Z280 Z8 S8 8031 8051 H8/300 H8/500 80x86 90S1200 32F417
 

Offline NorthGuy

  • Super Contributor
  • ***
  • Posts: 3145
  • Country: ca
Re: Is ST Cube IDE a piece of buggy crap?
« Reply #1002 on: October 30, 2023, 10:25:01 pm »
because a real dev ...

Real programmer may or may not know the name of his spouse, but he knows all the ASCII codes.
 

Offline jgrossman

  • Regular Contributor
  • *
  • Posts: 63
  • Country: us
Re: Is ST Cube IDE a piece of buggy crap?
« Reply #1003 on: October 30, 2023, 11:34:02 pm »
I think hiding a return() in a macro like that is crappy coding. It is OK in that function, but this code is generated for people to use as example in general.

I agree in general, but that code is literally a HAL library. It's not generated for you to modify.
 

Offline DavidAlfa

  • Super Contributor
  • ***
  • Posts: 5898
  • Country: es
Re: Is ST Cube IDE a piece of buggy crap?
« Reply #1004 on: October 31, 2023, 08:29:37 am »
I still see no problem here.
Whats's the problem of inserting a return in a macro? Why would it be a bad coding practice?

this code is generated for people to use as example in general.
Absolutely not.
You should call the HAL function (SPI send, UART TX, whatever) and check the return code, not randomly call __HAL_LOCK, which is meant to be internally used by HAL, not by you!
It would be 100% your fault if you randomly call it without understanding what it does.
« Last Edit: October 31, 2023, 08:37:06 am by DavidAlfa »
Hantek DSO2x1x            Drive        FAQ          DON'T BUY HANTEK! (Aka HALF-MADE)
Stm32 Soldering FW      Forum      Github      Donate
 

Offline Karel

  • Super Contributor
  • ***
  • Posts: 2217
  • Country: 00
Re: Is ST Cube IDE a piece of buggy crap?
« Reply #1005 on: October 31, 2023, 09:01:00 am »
Re "cut out to be a dev" well obviously not, because a real dev

- comments nothing
- documents nothing
- uses esoteric pointer code which nobody else understands
- has no stake in the company staying in business (always on LinkedIn looking for his next job)
- could not care less if a product sells well for 10 years (never mind 25 like some of mine!) and has to be maintained after that time
- documents nothing

:)

It's not always the fault of the programmer. Often the company puts tight deadlines and doesn't want to spend
time & money for testing and documenting.
"Release quick, if people complain, we can fix it later with an update."

p.s.: I do use pointer arithmetic a lot, simply because I like it and because it's usually the most efficient way.
 

Offline NorthGuy

  • Super Contributor
  • ***
  • Posts: 3145
  • Country: ca
Re: Is ST Cube IDE a piece of buggy crap?
« Reply #1006 on: October 31, 2023, 01:52:35 pm »
It's not always the fault of the programmer. Often the company puts tight deadlines and doesn't want to spend
time & money for testing and documenting.

People used to have integrity and would refuse to do crap if asked to.

"Release quick, if people complain, we can fix it later with an update."

But then new update will have two new bugs for every bug fixed.

I had to upgrade my Mac to Monterey OS because Apple has changed their "notarization" rules. This covers about 5 years of updates. It has become very slow and acquired new bugs.


 

Offline peter-hTopic starter

  • Super Contributor
  • ***
  • Posts: 3694
  • Country: gb
  • Doing electronics since the 1960s...
Re: Is ST Cube IDE a piece of buggy crap?
« Reply #1007 on: October 31, 2023, 02:22:00 pm »
Quote
that code is literally a HAL library. It's not generated for you to modify

We will have to agree to disagree.

This is not the age of the Z80 when you had to read a few pages, and to get a working system you copied a Nascom 1 circuit - basically a CPU+EPROM+RAM and some latches for I/O.

This is the age of a 300 page DS and a 2000 page RM. Lots of people use Cube MX to generate code fragments (they are fragments really because MX is great for knocking up quick demos and then you have to do lots of real work to get a finished product) to save time and save many hours of googling to see how others did something e.g. drive the SPI controller.

Lots of times one picks up a function and uses the "body" of it. Yesterday I picked up the "HAL" function for the random # gen and put a mutex at the start and end of it (because it is called both by TLS and other user code) and a macro which contains a return() will obviously blow it up, because the mutex will never get released. I would not be randomly calling just hal_lock, obviously.

Everybody posting here is an expert (except me; I am learning from a low base and 40 years of asm) but this is a great way to get bitten in the bum.


« Last Edit: October 31, 2023, 02:27:18 pm by peter-h »
Z80 Z180 Z280 Z8 S8 8031 8051 H8/300 H8/500 80x86 90S1200 32F417
 

Offline jgrossman

  • Regular Contributor
  • *
  • Posts: 63
  • Country: us
Re: Is ST Cube IDE a piece of buggy crap?
« Reply #1008 on: October 31, 2023, 02:51:24 pm »
Quote
that code is literally a HAL library. It's not generated for you to modify

We will have to agree to disagree.

I guess to be more specific, what I meant was:

It's intended use is to be generated and used wholesale. They are not trying to provide a template, and so are free to do literally whatever. If you want to use it that way, you just have to be mindful of what it is you are taking. I think we agree that it is kindof poor form to hide a return behind a macro that, to me, is named is if to imply "wait until ready", not "if not ready, bail". Trailing on that:

I still see no problem here.
Whats's the problem of inserting a return in a macro? Why would it be a bad coding practice?

Nothing at all, as long is it isn't slightly misleading like __HAL_LOCK, where my first impression would be a wait until not-busy. __HAL_LOCK_OR_RETURN(), no problem there, clear as day what happens. Should you pay attention and understand what it is that means? Absolutely, but there can be friction in doing so where it is not obvious what something does.
« Last Edit: October 31, 2023, 02:53:55 pm by jgrossman »
 
The following users thanked this post: peter-h

Offline DavidAlfa

  • Super Contributor
  • ***
  • Posts: 5898
  • Country: es
Re: Is ST Cube IDE a piece of buggy crap?
« Reply #1009 on: October 31, 2023, 03:07:43 pm »
Well, yeah, I do most of the time, specially "__HAL_” stuff, before taking anything for granted I find its declaration and check what it does.
Hantek DSO2x1x            Drive        FAQ          DON'T BUY HANTEK! (Aka HALF-MADE)
Stm32 Soldering FW      Forum      Github      Donate
 

Offline peter-hTopic starter

  • Super Contributor
  • ***
  • Posts: 3694
  • Country: gb
  • Doing electronics since the 1960s...
Re: Is ST Cube IDE a piece of buggy crap?
« Reply #1010 on: October 31, 2023, 04:03:22 pm »
Quite apart from anything else, the whole HAL_LOCK "system" doesn't do anything useful. It gives the impression of a mutex or semaphore but it is actually just a "busy" flag around each function which is completely useless AFAICT. Lots of other people have commented accordingly over the years. Whenever I use any of these functions I always remove that stupid "lock".

Z80 Z180 Z280 Z8 S8 8031 8051 H8/300 H8/500 80x86 90S1200 32F417
 
The following users thanked this post: newbrain

Offline DavidAlfa

  • Super Contributor
  • ***
  • Posts: 5898
  • Country: es
Re: Is ST Cube IDE a piece of buggy crap?
« Reply #1011 on: October 31, 2023, 05:31:16 pm »
Its a mutex to prevent anything messing with the handler, for example in multithreaded systems, it does exactly what it should.
Hantek DSO2x1x            Drive        FAQ          DON'T BUY HANTEK! (Aka HALF-MADE)
Stm32 Soldering FW      Forum      Github      Donate
 

Offline newbrain

  • Super Contributor
  • ***
  • Posts: 1719
  • Country: se
Re: Is ST Cube IDE a piece of buggy crap?
« Reply #1012 on: October 31, 2023, 05:43:37 pm »
Its a mutex to prevent anything messing with the handler, for example in multithreaded systems, it does exactly what it should.
No it does not under any  non cooperative threading model (time slicing, preemptive, multi core etc.).

Checking and setting the lock flag should be an atomic operation, and it's clearly not.

It's just a place holder for a possible RTOS compliant HAL.
Nandemo wa shiranai wa yo, shitteru koto dake.
 

Offline DavidAlfa

  • Super Contributor
  • ***
  • Posts: 5898
  • Country: es
Re: Is ST Cube IDE a piece of buggy crap?
« Reply #1013 on: October 31, 2023, 05:48:07 pm »
Sort of. Still ST quality  :)
Hantek DSO2x1x            Drive        FAQ          DON'T BUY HANTEK! (Aka HALF-MADE)
Stm32 Soldering FW      Forum      Github      Donate
 

Offline NorthGuy

  • Super Contributor
  • ***
  • Posts: 3145
  • Country: ca
Re: Is ST Cube IDE a piece of buggy crap?
« Reply #1014 on: October 31, 2023, 06:46:01 pm »
Quite apart from anything else, the whole HAL_LOCK "system" doesn't do anything useful. It gives the impression of a mutex or semaphore but it is actually just a "busy" flag around each function which is completely useless AFAICT. Lots of other people have commented accordingly over the years. Whenever I use any of these functions I always remove that stupid "lock".

You can re-define the macro to nothing. Having an easy way to annihilate unneeded locks is a good thing.
 
The following users thanked this post: SiliconWizard

Offline paulca

  • Super Contributor
  • ***
  • Posts: 4044
  • Country: gb
Re: Is ST Cube IDE a piece of buggy crap?
« Reply #1015 on: November 01, 2023, 03:55:00 pm »
I just fresh installed Cube on Windows 10.

I cloned an old (year) project from git and opened the IOC.  It said I could upgrade it, so I said, "Aye on ya go then."

Then I hit Run.  Did the your STLink has a new firmware dance and .... it worked.

It worked.  Just worked.

Nothing to report here, nothing to see.
"What could possibly go wrong?"
Current Open Projects:  STM32F411RE+ESP32+TFT for home IoT (NoT) projects.  Child's advent xmas countdown toy.  Digital audio routing board.
 

Offline peter-hTopic starter

  • Super Contributor
  • ***
  • Posts: 3694
  • Country: gb
  • Doing electronics since the 1960s...
Re: Is ST Cube IDE a piece of buggy crap?
« Reply #1016 on: November 02, 2023, 09:13:15 am »
Yes; apart from Cube IDE occassionally changing the GCC tool version and introducing different default compiler/linker options which bring up new warnings, I have found Cube updates to "just work".

Occassionally I uninstall Cube totally and reinstall fresh, just to make sure.
Z80 Z180 Z280 Z8 S8 8031 8051 H8/300 H8/500 80x86 90S1200 32F417
 

Offline zapta

  • Super Contributor
  • ***
  • Posts: 6190
  • Country: us
Re: Is ST Cube IDE a piece of buggy crap?
« Reply #1017 on: November 03, 2023, 03:04:55 pm »
>> a macro which contains a return() will obviously blow it up, because the mutex will never get released

If you use C++, you can define mutexes that release automatically when leaving their scope. Very handy and safe IMO. Example:

https://github.com/zapta/daq/blob/main/controller/platformio/lib/data_queue/data_queue.cpp#L98

 

Offline zapta

  • Super Contributor
  • ***
  • Posts: 6190
  • Country: us
Re: Is ST Cube IDE a piece of buggy crap?
« Reply #1018 on: November 03, 2023, 03:19:03 pm »
TL;DR, using CubeIDE for configuration only and platformio for the rest.

A few months ago I started a STM32H7 project and had a dillema which IDE to use. My favorite IDE is platformio, for all MCUs, but realized the value of the CubeIDE value in generating the initial and updated configuration code from the .ioc file. As a result I setup an environment with a combination of the two. A CubeIDE project is used only for editing the .ioc file and generating the code, with no manual editing whatsoever, and a platformio project is used for the rest of the code development. I use a small python script to automatically update the platformio library when I make configuration changes in the CubeIDE project.

Overall it works great for me, being able to use the CubeIDE configurator with the platformio project.

This is the python script I am using. It does a few patches to the CubeIDE code to simplify having a separation between the CubeIDe files and the code files I edit in platformio.

https://github.com/zapta/daq/blob/main/controller/cube_ide/update_platformio.py

 

Offline peter-hTopic starter

  • Super Contributor
  • ***
  • Posts: 3694
  • Country: gb
  • Doing electronics since the 1960s...
Re: Is ST Cube IDE a piece of buggy crap?
« Reply #1019 on: January 08, 2024, 03:08:06 pm »
Just updated Cube IDE from v13 to v14 and the binary generated is identical. So thankfully they haven't changed the tools.

The random file opening issue (basically when you stop a running project, breakpoint, etc, a random .c file gets opened) has not been fixed. It still opens whichever .c file the CPU was executing at the time, which tends to be some bit of FreeRTOS in my case. The way to solve this has been worked out and documented but clearly ST don't want to do it.

Z80 Z180 Z280 Z8 S8 8031 8051 H8/300 H8/500 80x86 90S1200 32F417
 

Offline DavidAlfa

  • Super Contributor
  • ***
  • Posts: 5898
  • Country: es
Re: Is ST Cube IDE a piece of buggy crap?
« Reply #1020 on: January 08, 2024, 03:14:57 pm »
Documented where?
Hantek DSO2x1x            Drive        FAQ          DON'T BUY HANTEK! (Aka HALF-MADE)
Stm32 Soldering FW      Forum      Github      Donate
 

Offline peter-hTopic starter

  • Super Contributor
  • ***
  • Posts: 3694
  • Country: gb
  • Doing electronics since the 1960s...
Re: Is ST Cube IDE a piece of buggy crap?
« Reply #1021 on: January 08, 2024, 03:51:37 pm »
I believe there is a post somewhere here where somebody found a way
https://community.st.com/t5/stm32cubeide-mcus/jumping-to-random-file-after-pressing-run-button/td-p/246693/page/9

Basically it involves putting a bit of code into the debugger interface so that when the breakpoint (which can be a Stop i.e. not necessarily an explicit user BP) is taken, it checks whether there is a user breakpoint at that address and, if not, it carries on. Or some variation of that... the inner workings of Eclipse (as modified by ST) and the debugger interface are a mystery to me.
Z80 Z180 Z280 Z8 S8 8031 8051 H8/300 H8/500 80x86 90S1200 32F417
 

Offline peter-hTopic starter

  • Super Contributor
  • ***
  • Posts: 3694
  • Country: gb
  • Doing electronics since the 1960s...
Re: Is ST Cube IDE a piece of buggy crap?
« Reply #1022 on: January 30, 2024, 11:55:56 am »
ST may have done something to the random file opening issue
https://community.st.com/t5/stm32cubeide-mcus/jumping-to-random-file-after-pressing-run-button/m-p/633716/highlight/true#M23914

However I have forgotten the exact circumstances under which it was a really bad problem :)
Z80 Z180 Z280 Z8 S8 8031 8051 H8/300 H8/500 80x86 90S1200 32F417
 

Offline peter-hTopic starter

  • Super Contributor
  • ***
  • Posts: 3694
  • Country: gb
  • Doing electronics since the 1960s...
Re: Is ST Cube IDE a piece of buggy crap?
« Reply #1023 on: March 20, 2024, 03:43:46 pm »
Cube IDE is now v15. They changed the compiler etc version, and the generated code changes... gone from 483,332 bytes to 482,308 bytes! So (-Og) 1k less code :)



Sometimes a new GCC version changes the meaning of compiler/linker command line switches, but not this time, at least not for my project [NOTE at this point I did not test code execution; I just did a Build with ctrl-b]

Well, they broke the STLINK V3 debugger. Cube v15 offers up upgrade the debugger firmware and trashes it.

Encountered Error when opening C:\ST\STM32CubeIDE_1.13.2\STM32CubeIDE\plugins\com.st.stm32cube.ide.mcu.externaltools.cubeprogrammer.win32_2.1.200.202311302303\tools\bin\STM32_Programmer_CLI.exe
Error in STM32CubeProgrammer


and then



Does anyone know what this is? I now have two dead development systems and two dead targets which don't run even if the software is loaded using the ST Utility.

That "missing" ...CLI.exe file is in the right place, with the correct case too.

Update: downgrading to Cube 1.14.2 runs ok. The STLINK V3 upgraded using the firmware from Cube v1.15.0 also runs ok with Cube 1.14.2, which is just as well!

I am sure that GCC tools v12 break the code in some subtle way. Even loading the software using ST Utility produces a dead target. I will probably not spend much time on this since a) I do not need to just blindly keep upgrading Cube (it's actually a stupid idea to make work for yourself, since every tool update ought to need regression testing of the product) and b) I can't debug the target since the debugger also does not work with Cube v1.15!
« Last Edit: March 20, 2024, 08:10:51 pm by peter-h »
Z80 Z180 Z280 Z8 S8 8031 8051 H8/300 H8/500 80x86 90S1200 32F417
 

Offline DavidAlfa

  • Super Contributor
  • ***
  • Posts: 5898
  • Country: es
Re: Is ST Cube IDE a piece of buggy crap?
« Reply #1024 on: March 20, 2024, 08:25:07 pm »
Don't update, It always breaks things.
Instead, uninstall old, install new, delete workspace .metadata folder.
Hantek DSO2x1x            Drive        FAQ          DON'T BUY HANTEK! (Aka HALF-MADE)
Stm32 Soldering FW      Forum      Github      Donate
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf