STM32Cube embedded software now on GitHub

[Karel]

"STMicroelectronics is now publishing STM32Cube embedded software on GitHub,
to open the STM32 embedded software offer to collaborative and community-friendly development and leverage faster,
more efficient distribution of updates."

https://www.eletimes.com/stm32cube-microcontroller-development-software-from-stmicroelectronics-now-on-github

[chriva]

They should bury that software under a rock somewhere instead of making that cancer spread even more.

Beginners: For the mother of Hades, please do not use this junk. It'll only take a couple of minutes extra to do it the proper way.

[Scrts]

They should bury that software under a rock somewhere instead of making that cancer spread even more.

Beginners: For the mother of Hades, please do not use this junk. It'll only take a couple of minutes extra to do it the proper way.

It took me 4 hours to start using I2C, SPI and UART with interrupts. I did not ever use STM32 before. I think those libraries are great for beginners and I am not sure why not to use them if you don't need to meet specific speed goal.

[Jeroen3]

It's on github for some time now. They do not maintain it via github, so pull requests or issues will be ported to their internal tracking and removed.
At least is would make upgrading somewhat easier if you can handle the submodules dependencies via a mirror server. (never use submodules to a third-party url!)

I remember some topic here about a critical flaw in some driver that they fixed in the Fx hal and marked "solved" in the issue reports at the Fy hal with a mention that they fixed in Fx.... Yeah, that's not how it works.

But it looks like they are using github features now.
https://github.com/orgs/STMicroelectronics/projects/2

[newbrain]

But it looks like they are using github features now.
https://github.com/orgs/STMicroelectronics/projects/2

Nice! I've just opened an issue on the CEC library.
Let's see how it goes...It's only the third time I report it.

[thm_w]

They should bury that software under a rock somewhere instead of making that cancer spread even more.

Beginners: For the mother of Hades, please do not use this junk. It'll only take a couple of minutes extra to do it the proper way.

It took me 4 hours to start using I2C, SPI and UART with interrupts. I did not ever use STM32 before. I think those libraries are great for beginners and I am not sure why not to use them if you don't need to meet specific speed goal.

They can be good for beginners as you show, just ignore these kinds of gatekeeping posts.

[uer166]

They should bury that software under a rock somewhere instead of making that cancer spread even more.

Beginners: For the mother of Hades, please do not use this junk. It'll only take a couple of minutes extra to do it the proper way.

Amazing.. please don't spread this crap. That IDE is perfectly serviceable, even for large commercial projects. It's as much pain in the ass as any other vendor IDE.
It's great for hardware engineers specially who want to confirm the pin mapping and do board bringup easily without doing firmware for a living.

[chriva]

They should bury that software under a rock somewhere instead of making that cancer spread even more.

Beginners: For the mother of Hades, please do not use this junk. It'll only take a couple of minutes extra to do it the proper way.

Amazing.. please don't spread this crap. That IDE is perfectly serviceable, even for large commercial projects. It's as much pain in the ass as any other vendor IDE.
It's great for hardware engineers specially who want to confirm the pin mapping and do board bringup easily without doing firmware for a living.

It's buggy, it's slow, it's doing things that is wasting space, it's abstracting everything to kingdom come and makes porting a pain in the brown eye.

Could as well recommend "engineers" to use arduino and code "C++"

[lucazader]

Could as well recommend "engineers" to use arduino and code "C++"

That comment about c++ shows how archaic your views really are.
C++ is a great language to use with micros, just too bad vendors do not really support it nicely out of the box.

The STM32Cube is also a great set of tools to get a project up and running very quickly for the vast majority of use cases.
Sure there are some cases where it wont work perfectly. And others where you need to optimize more than can be done using a HAL.
But for most products that aren't produced in the 10's or 100's of thousands, it is likely going to be cheaper in the products development time to just throw a bigger/faster micro at the problem and save dev time than it would be to optimize everything to the nth degree.

I am pleased that these are now up on github.
Will allow for a much more transparent view of known bugs, what they are working on and what has been fixed.
We use the stm32cube and the st hal to great success at the company that I work for. I would also recommend other companies look into using it as well, depending on how they can fit it into their workflow.

[Karel]

C++ is a great language to use with micros, just too bad vendors do not really support it nicely out of the box.

No, it's not. C++ is a horrible language for multiple reasons.
You can read all about it and participate in the discussion here if you want:

https://www.eevblog.com/forum/chat/how-many-people-code-in-c-these-days-and-if-so-why/

[shangaoren]

C++ is a great language to use with micros, just too bad vendors do not really support it nicely out of the box.

No, it's not. C++ is a horrible language for multiple reasons.
You can read all about it and participate in the discussion here if you want:

https://www.eevblog.com/forum/chat/how-many-people-code-in-c-these-days-and-if-so-why/

stl is not good for embedded most of the time but the core of the language is good, maybe some times better than c, this is just a sterile debate, both language are good, there is just bad programmers.
As for my vision many C programmer do object oriented programming, which is just horrible to read in C  but performance and size will be similary for both languages if the program is well written

[Karel]

Please, let's not derail this thread and let's not divert from the topic.
If you have something to say about C vs C++, consider doing it here:

https://www.eevblog.com/forum/chat/how-many-people-code-in-c-these-days-and-if-so-why/

Thank you for your cooperation.

[newbrain]

The STM32Cube is also a great set of tools to get a project up and running very quickly for the vast majority of use cases.
Sure there are some cases where it wont work perfectly. And others where you need to optimize more than can be done using a HAL.

QFT.
I will also add that the HAL is not really worse than other vendors' libraries.

Digging into the NXP ones for the i.MX RT series I already found more bugs in some months than I did in the HAL in years, and the amount of layering and bloat makes the HAL pale in comparison (handles inside handles inside handles - sometimes as pointers, sometimes as nested struct, and sometimes even misaligned, so they use an array of 3 to hold 2 and bitwise & the address with a mask ).

Still, they are very helpful to put together something quickly - and very often good enough.

[Jeroen3]

Well, at least you can now easily report problems and suggest fixes.

Do not forget that what ST is making there is actually quite complicated to manage. Now imagine doing this surrounded by project managers rushed by deadlines.

[Karel]

... surrounded by project managers rushed by deadlines.

My biggest nightmare...

[dtodorov]

I'm using CubeIDE happily for a few months for hobby projects. Works a treat, no bugs, no major issues whatsoever.

[nuclearcat]

Here is example, why Cube and github "initiative" is garbage.
https://github.com/STMicroelectronics/STM32CubeF1/issues/6
Bug is reported, fixed in DIFFERENT chip firmware, and when user say WTF? they answer "don't even expect a fix". (Chip is not EOL).
IMO it is intentional sabotage.

Here is one more example:
https://community.st.com/s/question/0D50X0000BB1eL7SQJ/bug-cubemx-freertos-projects-corrupt-memory
Basically Cube have broken memory allocation and printf %f for many month, for many chips, solution is known, but they keep "discussing".
This is worst ever bug possible, that will cause race conditions, memory corruption and etc.
Conclusion:
If you make some kind of device based on this code, you will shoot yourself in the foot, since no one supports this code properly.
So yes, this piece of dried s**t is not suitable for anything else, than to check code snippets and get idea how to implement some kind of not very well-documented functionality.
(and at the same time remind yourself that there are programmers in the world who write such terrible code)

ST have cool hardware, but their "Cube*" is ugh, just awful.
It would be better if they pay&assist open source programmers (like opencm3 guys), and they can give customers MUCH better solutions.

[thm_w]

Here is example, why Cube and github "initiative" is garbage.
https://github.com/STMicroelectronics/STM32CubeF1/issues/6
Bug is reported, fixed in DIFFERENT chip firmware, and when user say WTF? they answer "don't even expect a fix". (Chip is not EOL).
IMO it is intentional sabotage.

The fix is posted there, support specifically said you can port it to the F1. It seems clear to me that internally they were told not to release any more FW for the F1. So yeah that part sucks. But its part of dealing with a company that wants to focus on profit. You can't support old devices forever, at some point they are let go.

I agree there are better ways to handle it though. There could be an "unsanctioned" or beta fork of the FW, where these fixes are implemented.

[nuclearcat]

Somehow yes, but how many such intentionally left unfixed bugs are in FW packages?
But one thing to defense of ST engineers - no one did PR, it would be interesting to see what the reaction would be.
If they want to play opensource, they should accept it.
If this is an imitation of opensource and interacting with community, it will be an interesting show.

And btw bug with printf %f hit many chips, not only "virtually EOL" F1, not fixed either.

[uer166]

And btw bug with printf %f hit many chips, not only "virtually EOL" F1, not fixed either.

The brand new G4 series that just came out has it and had us spend weeks tracking the crashes down. This is where ST support is garbage, I just don't necessarily think it's to do with anything about the STM32CubeIDE. The IDE itself is not at fault, but the shitty libraries that come from ST. You'll hit the same issues if you use those libraries without the IDE.

[thm_w]

That printf bug does sound hellish. I wonder if any sort of static analysis would catch it.
I like to use this lib where its possible instead: https://github.com/mpaland/printf

Mixing FreeRTOS into their own code just feels like a bad idea then. could be better off managed outside of the company via open source funding, etc.
At least the theory is with HAL they should know the abilities/limitations of their own hardware.

[lucazader]

mpaland's printf lib. Much smaller than the c stdlib implementation, especially if you want to print floats.

I also find it weird that they are hasting their own for lack of a better word "fork" of freertos.
Surely it would be better to pull in the official source, and then either patch it, or have a vendor specific support repo for it?

Will be interesting to see what they do when users start submitting PRs.
I dont think they wll actively accept them until they move their development fully out into the open on github. (if that would happen at all)
With their internal system not being tightly linked, and them only pushing snapshots it seems like it would be hard for them to manage except for manually coppying over a diff to their internal projects.

Would also be great for them to move the development out into the open as then when they patch a fix internall (but it hasn't passed release validation) users would still be able to see it, and use/test it out while they are waiting for a "stable" release.

[Psi]

I've not used STM32Cube in ages, so i'm not sure if my opinion is still valid but...

STM32Cube just went a little to far.
The goal of it seemed to be to hide away all the registers so idiots can code. (My guess is they were trying to do Arduino2.0 using their chip)
When the goal should have been a system to show how the registers can be used to do various tasks.

Ideally you want to get something working with the library then run an automated process to remove the library calls from source and replace with commented raw register calls.
So you can then look through and remove any crap that's not needed for your application.

It's not helped by the fact that the STM32 registers are not very human friendly at the best of times. Give me AVR registers any day.
And different library versions makes things a huge mess.

I really did like the concept of the GUI to graphically setup all the GPIO/Peripheral/Clock registers and click a button to get code for it. That makes a lot of sense. You can see exactly what your doing better in the app.
But it needed to be register based not library based, or at least have the option.

[lucazader]

I really did like the concept of the GUI to graphically setup all the GPIO/Peripheral/Clock registers and click a button to get code for it. That makes a lot of sense. You can see exactly what your doing better in the app.
But it needed to be register based not library based, or at least have the option.

In some ways they have this now (kinda, i haven't really used it so cant comment with authority).
But in the cube you can now generate the project using LL libraries. Which are mostly just macro abstractions of the direct register changes.
Its not available for all peripherals. but is for the most common ones.
It also isnt super obvious how to do this because the ui isn't that great (they should really get a ui/ux person to go over some of their stuff. i think it would help usability a lot with these things)
You can also mix and match, eg use HAL for uart, but use LL for gpio and clock.

I probably should check out how useable and good the LL hal is. from a little bit of playing around it does remove a lot of the code bloat so projects compile to smaller more optimized programs out of the box.

[Karel]

I like to use this lib where its possible instead: https://github.com/mpaland/printf

Thank you very much for sharing this 

I already wrote my own printf() implementation but it doesn't support float/double yet.
I'm going to try this one.