@mrburnette
The problem with sloeber sending the bin was because I had not specified a com port.
Which I did not believe was needed since I am using an stlink clone.
I traced the compile and send chain to see what was happening.
The stm32 package always sends the com port regardless how the data is sent.
I believe this was done to align parameters being sent to batch files and scripts, so the same parm number always does the same function.
The arduino ide defaults to the first com port so there is always a baseline.
Sloeber does not, once I specified a com port even though I am not using one, it worked.
It did this because an unchosen com port is a blank string, which lower the parameter count by one.
I see this sort of thing a lot in my work.
The stm32 addon for arduino was designed for arduino.
Built with the features and design of that environment in mind.
Intended to expand on that particular thing to do one particular job.
Yet there is also a lack of sanity checking parameters.
In this case, because arduino always has a com port set, there was no need seen to check if one had been chosen, or if the string was blank.
As for the discussion of alternative ide’s, try taking a step back for a moment, see from another perspective.
Nearly all of my work is inspecting other peoples projects and work.
I work in several languages, on several architectures, and various types of hardware.
Normally it is in 8/16/32 bit assembly for various subsystems, or some version of basic, or a version of pascal, or a version/type of shell scripting.
Ladder programming, sequence/relay controls, electrical signal conversion, protocol conversion.
Lately I have had to add C & C++ to that pile, of which the latter has been as much hassle as the rest combined, including the former.
Yet I do not claim to have any real depth of knowledge of any of them.
Then there is the hardware side, which is a different mess.
Do you know what they have in common?
Patterns.
A good ide will help you see the patterns, without trying to show everything at once.
That is what I do, look at the patterns.
So anything that helps me find/see the patterns without flooding me with irrelevant at the moment garbage, is good.
Especially if I can keep a visual theme on the screen that visually demarks what things are.
I can use those horrid dark theme things, but it is hard.
By the time I turn my monitor up far enough to see with them, it is like my monitor is set for optical weapons research.
That level of bright also gives me headaches very quickly, so a nice pleasant win2k type theme that works at low monitor brightness is appreciated.
My customers can be broken into two over all categories, those with a good project index, and the other 99% of them.
One customer even claimed to have made their firmware smaller by reducing the number of source lines, their bin wasn’t nearly so compact though.
Yet had these last few little bugs that needed to go away, and they just couldn’t find them.
Their code looked like someone had snuck some assembly language into an obfuscated C contest.
It compiled great, but wasn’t designed for humans to read.
Once I fixed that, one line one job, the number of lines had gone up, dramatically.
Then I had to unwrap dense logic in convoluted code written in nothing but C shorthand.
Once I got that done, I found an alarming number of places where parentheses were misplaced.
Only once I started getting them straightened out, did I find the war of | vs ||, & vs &&, = vs ==, and some more, real C/C++ programmers are likely shaking their heads having seen the same many times.
A quarter of their dense code was to make up for mystypes, and the resultant faulty logic.
They actually fixed their own code, once I showed their programmers their own code formatted for humans rather than compilers.
Turned out they actually knew their own stuff well, but had gotten so hung up one reducing the number of lines to make it more compact, that it was no longer readable.
I didn’t ask who started the mania with reducing line counts, but their management did have a shake up a short while later.
I can agree that in some ways an ide can be training wheels.
Those are not always a bad thing though.
Your job as a programmer is to communicate.
With the machine through programming, and with other people through the program and machine functioning.
There is no need to carry the entire thing on your head, that is what reference material is for.
That way you can be familiar with the structure, without having to memorize every detail, just have them there to check.
The arduino ide is designed as a side door, not a garage door, and certainly not a freight door.
Its design and features reflect that.
I bumped into its intentional limitations rather quickly because it is designed to hide the things that I actually use.
Hiding those things though, is a help for a lot people getting started.
The largest problem I had to overcome when I started, was thinking there is only one answer, only one way to do a thing.
The differences between people are where new things come from.
Celebrate those differences, use them.
Now I am off to test out the ide mentioned while I was preview/editing this comment.
Janus.