CubeIDE forcing you to login to ST is complete [...]

[JDoe.2]

I don't care if the title of this post breaks some sort of forum usage rule, I just need to make it absolutely plain that I am sick and tired of every last company on Earth insisting I have an account with them and use it whenever I so much as breathe, drink a glass of water or, Chtuluh forbid ! update a HAL library for a microcontroller.

I believe there are more than enough bugs in CubeIDE, let alone actual necessary features that are missing, to keep your developers occupied forever. You did not need to waste everyone's time forcing people to login to ST. This feature brings nothing, helps no one but yourselves, and was asked by absolutely nobody, ever. So please, may I suggest you rethink this stupid, bordering on evil new addition to CubeIDE, and remove it with the next version ?

FYI, some of us work in companies where our computers are not, must not and cannot be, connected to the internet. It's already tough enough installing some of your HAL libraries (the patches) while being offline, we do not need the additional hassle of a login system that does nothing useful anyway.

A tool has to be convenient. If my screwdriver required an internet connection so as to snitch on how many turns I do in each direction depending on my GPS location, I'd start considering switching to fingernails or rocks.

You are welcome to try and make a case as to why you need me to log in to download updates to stuff you provide free of charge. I do need a good laugh.

Oh and I haven't checked on my last CubeIDE ticket... did you finally fix the bug where CubeIDE is confused when launching firmware on a target with Flash banks swapped ? Because that would sure be of actual use to the legions of programmers doing FOTA.

[Harvey White]

It is likely we are dealing with a pushme-pullyou (See Doctor Dolittle).  One head at either end.  (No, don't ask).

The statistics and the like, with logins, are not being done by engineering, but by marketing.  Marketing says that they must have this data to determine how their products are used, and how to direct engineering to make new products and services.  To not have this information is to completely abandon the customer and not be responsive to the market.

The other head is engineering, which, since marketing is in charge, can only look to see where it has been.  It is concerned with such silly things as making the product better, more desirable, and actually work to do what the customers want.  However, since engineers (and programmers) never drive a company, the proper thing to do is to make sure that the products are marketplace driven, not feature (as in working) driven.  Since marketing likely does not read this forum, possibly cannot understand the questions nor the solutions, and certainly doesn't find answers to what it wants to know in a morass of technical details........ well....

[Pavel A.]

Marketing, why not. So many clones are around; obviously ST does not want them to use their tools and libraries easily.

[Tobe]

Maybe some have other ideas as just tracking? Today it is a login, but tomorrow it could be a login with a monthly payment... Just like the boiling frog: heat the water slowly.

[JDoe.2]

Yeah, those clones are a problem for everybody (not just ST but anyone buying an STM32 now could receive a fake chip). That being said, a login won't help. It's too easy to create a fake e-mail account and sign-up.

I remember when AMD and Cyrix and later VIA started making x86 processors. It did cut into Intel's x86 marketshare (of 100% :-D) but they didn't start requiring developers to create accounts to use a compiler. ST could implement hardware solutions to create an authenticity test in their chips if they really felt the need.

@Tobe now that is a scary thought. I like the idea that there's a free toolchain for STM32. But I don't think ST will want us to pay for CubeIDE... because then they'd have to provide customer service. Don't know about you, but if I have to pay anyway then I'm not sure CubeIDE is going to be my first choice. IAR and Keil have left me mostly with good memories, it wouldn't take much to send me back into their arms. And then ST can kiss goodbye to all that juicy usage data they are no doubt stealing from us.

[Tobe]

They probably cant force you to pay for cubeIDE, since its opensource i believe. But all the other tools taht come with. Updates and more. Wasnt he talking about cubeMX?

[Piranha]

How does a login into a free account stops anyone from doing anything? But your argument can be destroyed completely with one simple fact - exactly the same firmware packages are available on ST's own official GitHub page without any registration!

[Pavel A.]

@Piranha There may be slight differences between github and zip downloads. Someone from ST explained this not long ago. Some examples and components encumbered by 3rd party licenses are only in the zip packages available via login. The ST libraries in source form anyway have copyrights in the text.

[Oskar_H]

I don't think the ST tools will ever be sold or within a renewable subscriptions process like MS do with their products. The force of this ST SW ecosystem is to be free and largely used by customers to test-and-try examples, make their choice for an MCU, then buy an eval board and develop a more or less complex application for it.

When SW tools are free, they have to make their users buy the HW for the business model to stay profitable.

In return, these tools need to be qualitative enough not to make the users feel they have been fooled by this model.

[CBerg]

I second with that: HAL is bashed to heavy IMHO. Yes, the SPI drivers e.g. are somewhat bloated, but you are always free to switch to the LL drivers if you have the need for more speed. Yes, that's quite an effort for the developer, but i guess it's also unfair to expect the manufacturer to provide you an almost finished solution for every case. It's the developers job to do the heavy thinking.

I can also state that the customer support from ST is pretty good. I had one (potential) project crushing bug last month and the support agent helped me out with a workaround within a few days. That saved me a lot of headache. So from my experience I can't complain, and those who do may evtl. consider, that software-issues with your blinky sketch are not necessarily an apropriate task for the customer support ;)

Back to topic: engineers simply don't like to be constantly monitored. A forced login is some kind of survilance and logging in with your CommunityID makes that survilance personal. It feels like some supervisor is sitting on my shoulder and whatching every mouseclick. I simply don't like that. That's like a survilance camery controlled by someone else in your bathroom. An anonmous ID - created during installation - would do the same job, if it's used for statistics (which MCUs do I prefer, how big are my projects, which peripherals to I use).

I have no objections against providing such data - anonymously. If e.g. some Managing guy at ST gets the idea to drop U(S)ART for some reason (most likely to save cost ...) the collected data would most probably show immediately that this would be a very bad idea.

[Harvey White]

This has several subjects to address:

On the topic of drivers.  Look at the drivers for an AVR or simpler processor.  The hardware is simple enough that writing low level drivers for I2C are reasonable to do (and I've done some). 
On the other hand, the hardware for the I2C interface (for an example) has a lot of modes, and drivers provided by the manufacturer are highly recommended.  A purist would say "go write your own".  I am not a purist.  If the manufacturer cannot write decent drivers for their own hardware, then what?

The LL drivers are just enough to load registers.  You need to figure out what the registers do.  OK...  HAL drivers?  They need to document them, not so much how to use them, but what their assumptions are.  Are their effective mutexes to keep the hardware safe from multiple uses?  There needs to be in an operating system environment.  Are they provided by HAL?  I'm not sure.

I have drivers which encapsulate the HAL drivers.  They are operating system dependent (FreeRTOS), C++ classes that enable programmed NSS, address lines, R/W lines, mutex protection, and changing clockrate for different chips, etc. Changing for a different operating system simply requires changing mutex access.

Should ST have provided them?  Nope. Should it tell me how the HAL drivers were designed?  Yep.

As far as monitoring goes, it seems to split into two different subjects:

1. Monitoring logins and requiring logins to access data:  enough has been said here to indicate that most people seem to be bothered enough to complain, but not enough to quit using the product.  In the case of some environments, internet access is not possible for either security reasons or the simple "it's not here".  Since the content of GitHub and the manufacturer's download seems to be different, GitHub is not really sufficient if you want what ST has.
2. Constant update to refresh ST tools:  Now I think that's a bit much at times.  The CubeMX application gets shut down at times to do some file structure changes on the project software.  Start it back up and it wants to make sure everything is up to date.  Annoying.  I know there are settings, but still....   

What would be nice to see is a plan from ST that acknowledges some of these issues, and whether or not they will be addressed, and how.  Note that this is NOT a product development state secret, since it is unrelated to how the product hardware (processors) will be designed, what's next, etc.

Making your customers feel better is a good business goal.