Is ST Cube IDE a piece of buggy crap?

[peter-h]

you can compare the files you are working with, with any previous version

There is another way to do this which I saw working but never tried it myself: set up another project and then you can do a "diff" graphically.

I avoid multiple projects in Cube because it is easy to get into a mess, with some config applying to all of them.

[paulca]

Well, you need to install the right 'collaboration' plugin first (there are several different version control systems) but this is pretty simple to do. After that you'll have a nicely integrated version control system.

I just checked and it is a disappointment that the Cube eclipse does not come with git as standard.  Pretty much every other one does.

[newbrain]

What is nice about Eclipse (Cube) is that you can compare the files you are working with, with any previous version.

I honestly find Eclipse git plugin to be baroque, bloated, and incomprehensible, but that's just me and Eclipse == water and oil.
The same is of course possible with other IDEs, e.g. any git plugin supports it in VS Code.
In the one I use (Gitgraph) you can click on any commit (or the uncommited changes line) and ctrl-click on any other to get all the files changed between the two (and of course open them in a nice diff editor).

[peter-h]

and right away we are into complexity

Just like always.

For experts this is all simple.

I just backup the whole project. Not just the source code.

[voltsandjolts]

There is a learning curve, but once you're over that, and really start using it, you regret not tackling it sooner.

As I understand it, peter is developing an STM32 app which will be delivered to clients in source code form.
I can't imagine trying to manage that over the years ahead without using a VCS.

[nctnico]

There is a learning curve, but once you're over that, and really start using it, you regret not tackling it sooner.

I agree. A long time ago I just to work with a guy that was hell bound on not using version control. On top of that he never kept copies of old versions. So when there was a bug in the software in the field (which is always the case), customers would need to wait for months until the new version got finished which -hopefully- didn't had too many new bugs. We almost litterally had to twist his arm to get him to use version control.

But yes, there is a learning curve. So far I have used subversion and git and I must say I like git better (partly because it doesn't need a server).

[peter-h]

developing an STM32 app which will be delivered to clients in source code form.

Not really. They will be able to write some modules. I will supply them with a bare Cube kit, which compiles something like hello.c.

If one of these wants to use a VCS, they can. Nothing whatever to do with me

But I definitely don't want to support anything complicated like that. I will support them building hello.c and will support the API for accessing other product features. I will not support Cube and its 10000000 config options. That's simply impossible.

Also you have to think into the future. Cube, if you download it from ST, will change over time. It is impossible to support that. In reality I will try, but ultimately there may come a point where one has to say to a customer "this product builds with Cube v10.1.0, and you can find the 1GB installer at this URL".

I have another vaguely similar product running since 1995. It sold in large numbers, and still does to people who did their own code years ago, but the development environment - a HiTech H8/300 C compiler for which I bought a large quantity of reseller licenses, before Clyde Smith-Stubbs sold out to Microchip, who I see have now dropped those compilers anyway - now needs either DOS or a winXP DOS box, or (under win7+) a winXP VM, so this gets a bit ridiculous. But ultimately a VM with a complete dev kit inside it is the way sometimes. Unless VMWARE vanish (unlikely) or there is no VMWARE Player available for Windows v123.5 (unlikely) this will always run. There are VMs which give you DOS, win3.11, you name it, and they still run today.

he never kept copies of old versions.

That's dumb.

[paulca]

On the complexities and experts ... I agree.  I have battles about it in work periodically.  There are VCS experts who want to immediately deploy all the bells, whistles and advanced practices.  I mean these people exist in every engineering domain (I'm sure).  They are just those who engineer for engineerings sake.  Either that or they have learnt to do it one way and only one way and so they drive the project towards their comfort zone.  That or they just want to take dominance and control over an aspect of the project they want control over.
 Not based on practical need.  Asking on the internet for opinions and you'll get a million and 1.  Even start a basic, "First steps, help" in the beginner section on here will derail into detailed arguments over irrelevant details by pedants.

Keep it simple.  Don't do anything which means you lose cognitive control over it.  If a propoent of a particular advanced (or even intermediate) technique tries to force a pattern on you push back until you understand it well enough to give them a definitive "No" or "Yes".

Read the basic official how-to, getting started.  Then google to find other variants in tutorials.  Just the basics.  I highly recommend starting with the command line unless you are completely adverse to that interface.  When a GUI goes nuts and produces non-sense errors, the command line will still always be there to fix things.

I would actually suggest starting with (even a burner) GitHub or GitLab account.  Pointy-clicky-draggy-droppy yourself a repo on their site.

All you need to be able to do initially, is...

clone that repo locally.
copy your source code into it.
add and commit all of it.
push it.

Go elsewhere, clone it etc.

Realise you made a mess, committed a bunch of binaries in the Debug and build folders....  Delete the whole thing, repeat.

Everything else is learning curve, but the above provides benefits immediately.

When you are happy you are comfortable.  Switch the actual project IDEs over to point into the local repo.  Add the git plugin to the IDEs.  Start maintaining the git repo with care and proper hygene and it will save your arse on so many occasions.

When people start babbling at you about forks and recursive rebasing of releases, switch off.  None of it is needed until it is and if and when it is, you can learn then if you need those features.

I have lived through several iterations of "experts" enforcing overly complicated VCS structures only to see them degrade into chaos because only the experts who demanded it understood what was trying to be achieved.  One example was a team who thought every developer should have his own fork of the entire project and work on that through a sprint in isolation.  Then after the sprint and testing they would have a big merge-athon to bring all the forks together into a "Golden repo".  It lasted a year before it had blown up on them one too many times.

In other parallel developments the company switched to using BitBucket with integrated Jira.... which out of the box supported a much simplier, easier to understand and far more robust branching model.  I felt somewhat vindicated when most teams moved to adapting that, whlie our team just had to add "feature/" and "release/" to our existing model for full integration.  KISS!

[newbrain]

ead the basic official how-to, getting started.  Then google to find other variants in tutorials.  Just the basics.  I highly recommend starting with the command line unless you are completely adverse to that interface.  When a GUI goes nuts and produces non-sense errors, the command line will still always be there to fix things.

A word of warning: be careful in what you google, there is a lot of over-complex advice around.
If you find yourself in pinch do as paulca suggest: nuke it and restart.
If you follow some of those "repair" advice, you'll find yourself in situations impossible to get out from, without understanding how you got there. git is a sharp knife, it can do wonderful things, but you should keep your fingers far from the blade until you master it (I can now barely put mine on the dull side of the blade).

This is a resource that I found both funny and clear enough: Oh my git, it helped some people who were allergic to VCS in general, and git in particular. It's a gamified git course, but it uses the real thing.

And of course the basic resource to start with is the book.
Then you can move onto the full online documentation  .

But I have this nagging déjà vu feeling, as if I (and many others) had already wrote the same previously...to very scarce effect, AFAICS 

[Perkele]

My setup (really small team): git (new projects), svn (legacy projects).
Remote development server with RAID 1 mirroring.
Periodic "git bundle" backups onto a removable storage.

I like bundles, because they can be used in the same way as any remote repository.

[peter-h]

This is a funny one



Using /*    */ instead worked, after after that the original // worked also in that no more warnings get generated, but the little icon to the left of the "81" won't go away

[DavidAlfa]

It says "printf_", you commented "printf".

[eutectique]

... no more warnings get generated, but the little icon to the left of the "81" won't go away

Remove the trailing semicolon. Don't know about Cube, but this tricks SonarCloud.

[peter-h]

Nope...

It says "printf_", you commented "printf".

That I don't get either because it clearly refers to line 81, and the printf_ is in the declaration of printf.

[peter-h]

That issue exists on one Cube installation but not another. It also isn't linked to the file; Cube clearly keeps the locations of these markers elsewhere (well obviously, as .c files are just plain text).

V1.11.0 is out now. I uninstalled the old one, installed new, rebuilt the project, and the end result matches with the same CRC. So they haven't changed any of the tools. The version description doesn't mention that, either.

Will be interesting if any bugs have been fixed. Nothing listed in the release note DM00603738.pdf.

[Doctorandus_P]

What a horrible idea to redefine standard library functions and replace them with functions that do something else.

If you want to use a "tiny_print" then just call it "tiny_print" and be done with it.

I can even understand adding in a macro that throws an error if printf is ever used on a memory constrained system, but your kind of obfuscation is simply a bad idea.

[peter-h]

That printf is almost identical to the "classic 1990" printf which is just bloatware, using bignums to implement that "perfect IEEE float" stuff from the 1980s. Various threads on that.

It isn't an integer-only printf or some such.

[DavidAlfa]

HAL is great for the start, I mean, coming from much more simpler Pic/Avr, you'll get completely blown away by the endless registers, bits...
After some weeks/months doing stuff, analyzing the generated code, the HAL libraries, all the gears in your brain will slowly start spinning again.
Then switching to LL is much easier.
Still takes a considerable amount of work if you have a lot of code interfacing the hardware, but gets done eventually.
The savings vs time invested depends on your application, if you had to take a more expensive stm32 due running out of space and you're buying 1000s of them, might well deserve the effort, specially nowadays when the same thing with extra 128K flash might cost easily 2x, 3x more because it's hard to source.

Otherwise, it's not a miracle either, removing the HAL handlers and the bloat might save 20-30%, but it's not LZMA

I've been practicing LL by porting the soldering firmware, not yet done, but getting there.

As always with ST, there's a lot you must figure yourself!
Honestly, did zero RTFM, might have a look but I don't expect anything useful there!

[DavidAlfa]

Following the previous message:
Currently the difference is just 3-7%, and I'm not done yet, still lacking the flash programming functions, there's zero code for it in LL, not even macros!
Adding that, it'll probably get pretty close.

Does the effort worth 5% saving? It's up to you! My opinion? I don't think so.
Tweaking HAL, customizing the ISRs, removing unused checks, will be a much more efficient approach and get your job done in no time.

LL is nice for small devices, where the HAL handlers alone will eat 50% of the RAM.

[nctnico]

What a horrible idea to redefine standard library functions and replace them with functions that do something else.

If you want to use a "tiny_print" then just call it "tiny_print" and be done with it.

I can even understand adding in a macro that throws an error if printf is ever used on a memory constrained system, but your kind of obfuscation is simply a bad idea.

No. Please don't ever venture in this direction! Having non-standard printf sucks. You'll end up with tiny_printf(), medium_printf(), johns_printf(), ect which makes it hard to share code between projects and maintain it. Do you know which printf to use 2 years later? And people default to printf anyway so may not be aware they should be using a different function. And there are more reasons: compilers will check the parameters for printf() for you. For tiny_printf() not. And snprintf is very useful for copying & concatenating strings safely with an added 0 at the end (there is no other standard C library function which does that!).

So what is a better solution? Replace (typically) vuprintf() with a version that caters to your system's needs. You can actually make supporting types optional using a project specific define which is given as a compiler option or in an options.h (or whatever you like to call such a header file). You could even opt to emit a warning that says what the printf is configured for or not. The designers of C already where clever enough to make the symbols of the C library 'weak' to functions can be overridden without the linker throwing an error that there is a duplicate symbol.

In the past I have come across several projects that use non-standard printfs and maintaining these has been horrible and time consuming.

[peter-h]

The designers of C already where clever enough to make the symbols of the C library 'weak'

Except, with ST Cube, they didn't make them weak.

I posted various threads on that long saga previously

[DavidAlfa]

Good morning!
As I'll be playing with the HK32F030 soon, I decided to investigate how CubeIDE detects fake devices...
This is for personal use only, I'm not having any benefit from it, it's just for fun!

Lastest IDE versions have additional checks, the OpenOCD hack no longer works.
STLINK GDB server (ST-LINK_gdbserver.exe) has its own checks which will need additional research.

With this simple mod I was able to program and debug clones with JLink, or ST-LINK+OpenOCD (Didn't modify OpenOCD).
Tested with:
- STLink+OpenOCD: Air32F103
- J-Link: Air32F103, HK32F030M (HK needs specific flahs algorithms, only supported by J-Link)

Edit:
I moved the patching details inside the file so it doesn't become too obvious, just in case some ST guy searchs those strings.

[AVI-crak]

HK32F030 has 2k memory frames, standard printf() won't fit there, it needs at least 38k flash memory and 4k memory frames.
I have the cure https://github.com/AVI-crak/Rtos_cortex/blob/master/sPrint.h
printo("text", double, float, uint(8-16-32-64)_t, int(8-16-32-64)_t )
printo() is capable of executing when debugging in a stm32f030f4 memory frame (no flash resource), all functions are complete. There are also 2k, and that's enough.
Also, unlike printf(), printo() removes code when it's not needed. To print integers you need quite a bit ~ 200 bytes.

[DavidAlfa]

  Who said I was going to use printf? Searching non-existing problems?
This mcu is only going to togle some IOs and measure signals using input capture.

Anyways, it's always nice to know about it 

[westfw]

HK32F030 has 2k memory frames

“Memory frames”??  What’s that?