Is ST Cube IDE a piece of buggy crap?

[nctnico]

That obviously has knock on effects on your CPU.  That memory churn is extremely CPU intensive.  So an older, weedier laptop or something on a Celery stick moving multiple gigabytes of page files around in memory takes tangible time.

I don't have that problem with Eclipse. First thing I do is disable paging / swapping to disk and make sure there is enough physical memory. Disabling paging to disk makes a PC much faster (especially on Windows which tries to put as much on disk as possible in order to not use as much ram as possible  )

[paulca]

I tend to end up with this "split" affair.

I tested and it seems the cube projects are pretty clean, I left the .settings/ folder behind everything else was needed.   As a top tip, create your own code style file and add it to the repo, then nobody has an excuse for horror merges.

[peter-h]

My .settings directory contains



which suggests all but one are fossils, and the one contains

Code: [Select]

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<project>
<configuration id="com.st.stm32cube.ide.mcu.gnu.managedbuild.config.exe.debug.346995266" name="Debug">
<extension point="org.eclipse.cdt.core.LanguageSettingsProvider">
<provider copy-of="extension" id="org.eclipse.cdt.ui.UserLanguageSettingsProvider"/>
<provider-reference id="org.eclipse.cdt.core.ReferencedProjectsLanguageSettingsProvider" ref="shared-provider"/>
<provider-reference id="org.eclipse.cdt.managedbuilder.core.MBSLanguageSettingsProvider" ref="shared-provider"/>
<provider class="com.st.stm32cube.ide.mcu.toolchain.armnone.setup.CrossBuiltinSpecsDetector" console="false" env-hash="-1504631925663965107" id="com.st.stm32cube.ide.mcu.toolchain.armnone.setup.CrossBuiltinSpecsDetector" keep-relative-paths="false" name="MCU ARM GCC Built-in Compiler Settings" parameter="${COMMAND} ${FLAGS} -E -P -v -dD &quot;${INPUTS}&quot;" prefer-non-shared="true">
<language-scope id="org.eclipse.cdt.core.gcc"/>
<language-scope id="org.eclipse.cdt.core.g++"/>
</provider>
</extension>
</configuration>
</project>
and I have no idea what that is about

[DavidAlfa]

If/when I get a reply on the Embitz forum I will give it a try, but I won't risk it unless I am fairly sure it won't trash it.

What's the point? If the IDE works, it'll keep working even if it's no longer updated, no matter if it's 2022 or 2035.
The rest of your questions are easily answered by trying yourself.

- emBitz is not eclipse-based, so it use different  project files, the stuff from Eclipse keeps unaltered, the only changes will be what you do in the source files.
  In any case, just make a small blinky project in CubeIDE, then import it into emBitz, and see what happens.
- Open emBitz, go to debug, interfaces, EBLink (GDB server replacement), there's a field to adjust the ST-Link speed.
- Same about testing emBitz in W64 x64 (it worked in a Virtualbox Win64 x64 machine).

[peter-h]

I did a search. It came up before here
https://www.eevblog.com/forum/microcontrollers/embitz-is-coming-back-soon/

I don't understand the comments about it not supporting an RTOS. How does an IDE support an RTOS? I know Cube has some RTOS support but I tried it and it doesn't do anything; apparently one has to add some hooks into one's code to get something useful there (a real time display of tasks, etc, but I have that already via an http server).

[DavidAlfa]

I guess it's CubeMX library (Part of Cube IDE) what supports RTOS (Reentry etc), otherwise, as you say, the IDE is irrelevant.

[peter-h]

I have never used MX. I thought it was just a "code generator". It seems to be useful for quickly generating some config code, and that is useful (in view of the 2000 page RM, etc) but once you got a project running there is no need for it.

I agree that an IDE does not in principle need updating, and that is my philosophy too (I still use a PCB design tool from 1998 - Protel PCB 2.8 ) but in this case I am doing a product which will have some support for user-written modules, and I can't really tell people to do that.

[nctnico]

AFAIK CubeMX is also included into CubeIDE as a code generator / project dressing tool. I don't know a better term than 'project dressing' for a process that just selectively copies source files into a project.

[peter-h]

Yes, it comes with Cube.

You can regard MX-generated code in the same light as spending a day googling for various register names and see what code different people use to set them up. This is what 73.5% of coders spend 93.5% of their time doing

And 99.1% of them never post a solution anywhere because it was developed in company time

The difference is that while 72.6% of code which google comes up with (mostly github but also various other "tutorial" sites) doesn't actually work, 82.8% the MX-generated code does actually work

[paulca]

and I have no idea what that is about

I looks like it's configuring an STM32 extension relating to C/C++.

The important part is it doesn't contain any absolute paths.  As I left it behind, I expect it will recreate it or I'll find an extension failed somewhere.  It's usually the .settings/ folders which trigger extensions and plugins and cause issues importing between IDEs.

It's usually only the first few weeks in a project there are issues sorting out the git repo and every ones different choice of IDE.  Usually various version/variants of eclipse and InteliJ, although I tend to edit some files outside eclipse in vim as I'm usually making immediately and small changes to a DB script I immediately have to commit, push, login, build and deploy to run.  Remembering to keep the three or four repos in sync is just a penalty of working in a high secure environment where your only point of contact outside your dev machine is through BitBucket and some heavily restricted web front ends.

Anyway.  It looks like Cube's projects are fairly clean.  You might have teething troubles between different versions of Cube IDE, but it should be fine.

Leave the workspace folder to eclipse.  Consider it almost ephemeral.  If/when it gets corrupted or Eclipse needs upgraded, it's often better to just fresh install it in a fresh empty workspace and import your projects.  Protect that hierarchy, forget the workspace.

For more intense work.  Splitting the workspace or importing projects into more than one workspace can allow you to run 2 copies of eclipse.   I've done this for a while, while times witching 2 projects under pressure.

[paulca]

As a general tip for Java.  Eclipse as well, but more "optional".

Download and install your own JRE and JDK.  Make a folder, C:\Java under it put the jre and jdk and rename the folders to just jdk, jre.  If you need Java 8 (Pre-Oracle) where most OSS stopped.  Have jdk8, jdk11, jre8, jre11.  Set your JAVA_HOME in your environment yourself.

This means if you ever need to set your JAVA_HOME and classpaths manually, you don't need to reference C:\Program Files\Java\some1241.5132 version.  Not least because it has a SPACE in it and not forgetting that Java is subject to automatic updates and the path will change.  Also means you don't have to rely on the auto updaters changing your JAVA_HOME and when it does cause issues you know where it is and what it is.

[peter-h]

Unfortunately, that approach is ridiculous in the requirement for a whole new level of PC software architecture knowledge.

Cube is an application (a "program") which should start up and run as one expects. Even just the need for this



24 thousand files!

shows how far the "art of programming" has come. Who can ship an install package which dumps 24000 files to your PC?

Admittedly this includes the ST libraries but still...

[newbrain]

I don't understand the comments about it not supporting an RTOS. How does an IDE support an RTOS?

E.g., during debugging, it can show additional info per thread. GDB is thread aware, but not all IDE can show the extra info, or single step per thread etc. etc.
See below a picture of VS code with Cortex-debug extension, using gdb and my gdbstub as gdbserver, running on a Teensy 4.1, showing per thread stack trace.

In the second picture, how it could appear with no threads (exactly the same code running on the Teensy).

[paulca]

24 thousand files!

It is most likely the source code for the libraries, including all the comments, the headers, the documentation, the firmware (debug archives of with symbols etc.).  (As an aside I remember making my first Linux boot disc from source code.  I laughed when I seen the "mini" GLibc came out at 87Mb.  A quick google and "lightbulb".  "strip" to remove unnecessary text symbol and all the locale stubs etc. etc. and one 400k so.

I'm not justifying the bloat, but it's real.  Disk space is cheap.  Engineers are expensive.  It is probably, for example, far, far easier to manage sending you a complete, full set of everything, for every board you open a project for, when they only differ by 2% of files, than to manage sending you ways to layer/overlay etc.  Trust me.  I've been there using sparse hierarchical build repos.  You don't want to go there.  It's better to duplicate and buy a bigger disc.

It's funny how code reuse has multiplied the amount of code we write by a factor of over 1000.  (I can find a source for that, but it's a bit hyperb-ollox ).

Also, if your install is older than about a year.  I would make a fresh install of the IDE.  A clean workspace and only import the projects you are working on.

All of the above "blobs" of files for each board class, will also be "per version" and I doubt they delete the old ones.

[newbrain]

24 thousand files!

It is most likely the source code for the libraries

I was going to say that was the cause, but decided to check.
Now, not so sure about it.

My STM32CubeF7* directory contains by itself:

Code: [Select]

31 805 Files, 7 477 Folders
I don't have the STM32CubeIDE installed, but taking my MCUxpresso (NXP equivalent, just as hideous🤮) install:

Code: [Select]

19 652 Files, 2 067 Folders
So, not far from peter-h result with STM32CubeIDE.
Note that this install includes zipped SDKs for some MCUs, but they are one zip file per MCU, so just a drop in the ocean.
Actual SDKs are elsewhere.

As a point of comparison, my VS Code, excluding extensions:

Code: [Select]

1 175 Files, 474 Folders
Pretty lean, one would think, until they look at the extensions directory (I may have far too many...):

Code: [Select]

39 077 Files, 6 422 Folders(might include some caching and DBs)

Full Visual Studio 2022 (CE):

Code: [Select]

33 409 Files, 4 465 FoldersThis might include some Windows SDK, though.

*Pet peeve of mine:

• Cube, by itself, it's the whole collection of all tools and libraries.
• STM32CubeXXX is the support package for STM32XXX MCU, e.g. STM32CubeF7
• STM32CubeMX is the stand alone configuration tool
• STM32CubeProgrammer is...the programmer
• ...you get the drift...
• STM32CubeIDE is the Eclipse based monstrosity peter-h has an abusive relationship with.

Calling everything Cube when talking of a specific piece just confuses and slightly annoys me.

[paulca]

The current cube has the MX part integrated into Eclipse.  As is the debugger and the programmer and everything else. With the annoying exception of no "UART Monitor" by default.

[newbrain]

The current cube has the MX part integrated into Eclipse.  As is the debugger and the programmer and everything else. With the annoying exception of no "UART Monitor" by default.

I know.
[pedant mode]the current STM32CubeIDE has the MX part...[/pedant mode]

[paulca]

I might have to become a bit more familiar with it.  I want to use a "Blue Pill" board as a real live ARM core to play with ASM.  Having a hardware debugger in the core obviously gives me single step, live register access.

This all works and I can call my ASM from C and call C functions from ASM.

The trouble is it uses the gcc ASM.  I was just getting happy learning some NASM.  Especially the funky "32bit literal" register load macros etc. etc. etc.

So, I'm going to attempt to add NASM to it's build chain....

[paulca]

A few determinations.

The folder, C:\Users\You\STMCube will contain your "Respostory" folder.  It is here it keeps BOTH the zip file for each board types firmware, but the unzipped copies too.

That is all the source code for all the hal drivers, demos, docs, the works.

This at least can be moved to a cheaper drive in "Window->Preferences".  I moved mine to network.  It's slow, but it's only really needed at project start up or upgrade time.

It seems every time you enable something in MX, it copies code it needs from the FW Repo into you project.  The nice part about that is, you can freely edit all the FW and driver code.... or remove it if you choose.

Not yet sure on the C:\ST folder and if any of it can be off loaded from C:\

[peter-h]

The above workspace/data/config location changed within the last year; can't recall which Cube version.

I did document a procedure for creating an exact copy of a project on another machine, involving making a copy of the project (say c:\projectname) and a copy of c:\st, and back then I didn't copy over anything from c:\users\st...whatever, and that worked, obviously only with the exact same Cube version.

Later I abandoned this procedure because it seemed pointless, in favour of the Import procedure described above.

One thing which used to screw up a Cube project pretty well was if you had Cube running and then externally deleted the project source files Cube would notice they went missing and you had a load of fun setting it all up again. But now the Import procedure covers this too. The external deletion is used when the project had been worked on extensively on another machine. You have to exit Cube before doing such a deletion.

[paulca]

Yes.  hmmm.

Unfortunately parts of CubeMX IDE get really upset about network paths.  Unzipping firmware for example causes it issues.  Building projects from the already unzipped firmware on network drives produces partially built projects.

This is not uncommon in windows apps, "network drives" are not as transparent as they should be at times.  It's not just build timestamps which can be taken care of, it's something odd about how some applications/APIs handle file transactions which causes them to get corrupted on a network drive.

It's odd as it's fine with the workspace on a network drive, but not it's firmware folder.

The reason this is important to me is that SSD space is expensive.  Things like multi-giga byte firmware template archives have no place on local or virtual SSDs.  They go on cheap bulk spinning metal.  Seems I might not have a choice.  I'm going to try and hide the network-ness of the drive by mapping it through a Windows library folder like C:\Documents but I expect that will probably fail and write straight through the library reference to the C:\Documents physical folder anyway.

The other option of course, as network bandwidth is cheap, is to just delete the contents of the repo and re-download it all when I run MX.  Sounds tedious.

I suppose I could use a new SSD anyway.


EDIT:  On corruption while unzipping and file transactions.  A likely culprit is case sensitivity or lack of it.  I have seen cases where applications, from windows writes two different files,  say, "File1" and also "file1", the underlying linux filesystem is like "Okay.", but when Windows asks for "File1" expecting "file1" things go very wrong.

[peter-h]

Windows is not case sensitive but Unix is and this issue was noticed when a colleague was compiling my project on a linux machine; a few things, apparently ex ST, needed to be renamed.

[paulca]

Yea and today I wasted an hour trying to get Blinky to work on a new board.  An STM32F030F4C6.  It generates the project fine and it runs, but there is no SysTick interrupt firing.  I can see the interrupt handler in the start ASM, but it never gets called.  Nor does the Default handler.  It's like nobody switched on the SysTick interupt timer, however I can see it doing so in Hal_Init().  It did this before, the first time I used this board and I fixed it, but I can't remember how. 

[peter-h]

I did wonder where the 1kHz tick gets initialised on my project and eventually I found it, in osKernelStart(); in FreeRTOS. That part was originally set up by someone else.

The code to start it looks like this

Code: [Select]


/*
 * Setup the systick timer to generate the tick interrupts at the required
 * frequency.
 */

__attribute__(( weak )) void vPortSetupTimerInterrupt( void )
{
/* Stop and clear the SysTick. */
portNVIC_SYSTICK_CTRL_REG = 0UL;
portNVIC_SYSTICK_CURRENT_VALUE_REG = 0UL;

/* Configure SysTick to interrupt at the requested rate. */
portNVIC_SYSTICK_LOAD_REG = ( configSYSTICK_CLOCK_HZ / configTICK_RATE_HZ ) - 1UL;
portNVIC_SYSTICK_CTRL_REG = ( portNVIC_SYSTICK_CLK_BIT | portNVIC_SYSTICK_INT_BIT | portNVIC_SYSTICK_ENABLE_BIT );
}

MX generated code uses huge interrupt handlers which step through every possible interrupt source without regard for which interrupts were actually enabled. It works "ok" on a 168MHz CPU but you would never write your own ISRs that way. Oh well, a consequence of software generating software

[paulca]

I ended up finding even more issues with the network drives.  Things like parts of the project appearing and disappearing.

Went to local disk for the workspace and set a project up and...  my SysTick worked.

On HAL libraries and in-efficiencies.  I'm not so sure.  I'm playing with an STM32F030F4 which has 16Kib Flash and 4Kib SRAM.

With RTC enabled, an I2C and an SSD1306 display I'm at 91% FLASH and 70% RAM.

I even tried saving RAM by defaulting the clock config, but, no, the RCC_OscSetup function still takes up 1.6Kib of Flash!

Even trying to enable TIM4 and using Sleep instead of Delay resulted in 103% flash.

So it's bad, but it's not that bad.  It does seem to only pull in what you use.

I've kicked out all the test functions.  I only loaded one font, the smallest one I can live with. 

A "Release" build will bring it down to 80% flash, it's just I can't then debug that TIM4 to make it work.

There is some bloat in the Init functions that could be thinned out, a lot of conditional stuff that I can't see changing at runtime, so why bother checking, etc.   I'll comment out loads of it and see if it still works

The idea was a little battery powered "How many sleeps to Santa" device for my 5 yo.  However, looking at it and that little RTC has gained 4 minutes extra time in an hour.  So, it's not going to work.  Was still fun for a Saturday afternoon.  It also pulls 9mA.  If I sleep it and let SysTick wake it, it pulls 10mA LOL  Which gives it a 10 day life on an 18650.  Unsoldering the power LED and I might get that down to half that.  I still need more than 20 days... and an accurate clock.