STM32Cube embedded software now on GitHub

[nuclearcat]

Problem is that it is not only printf %f, it is about whole newlib faulty implementation.
Anything that uses internally malloc might give you unexpected surprise. Anything it means something not very obvious, like printf.

Here is one more example of ultimately shitty code in Cube:
https://github.com/gmgunderground/STM32-RTOS-USB-HowToFix/blob/master/README.md
Not only faulty malloc, but also doing malloc in interrupt? Oh my...

[shangaoren]

IMO default malloc and printf should never be used in embedded targets, CUBE MX or not.

And even HAL and LL sucks CUBE MX still be an handfull tool to map pins when you are routing a circuit and when building your system drivers as a summary of your wiring.
even if it is not a perfect soft, a bit slow and with some functions not very usefull it still a good helper

[nuclearcat]

IMO default malloc and printf should never be used in embedded targets, CUBE MX or not.

And even HAL and LL sucks CUBE MX still be an handfull tool to map pins when you are routing a circuit and when building your system drivers as a summary of your wiring.
even if it is not a perfect soft, a bit slow and with some functions not very usefull it still a good helper

printf is just convenient way of debugging. It is better to avoid in production, but if you just want to debug something silly and software crash on that - this is ridiculous.
About malloc - AFAIK it is very bad habit to use dynamic memory allocation in interrupt routine, and even calling any other complex functions from it.

[radioactive]

Maybe things are different with STM32H7 series and others, but I had a very good experience after I got to V1.4 (not the lastest available).  The only thing I found less than expected was the SPI drivers.  I still was able to make it work.  Of course,  the CubeMX software is intended to just get you going on your project with minimal pains of low-level driver initialization and configuring pins.  If you don't use it to allocate your pins before layout, I think you are crazy.  It saved me a lot of grief compared to what would have happened in the past without it on the STM32H7 part.  I highly recommend that you use it before you do any kind of layout for the more complex parts.  If you are just working with the older STM32F4 parts that you already know, then by all means just use the legacy drivers that you know and the layout and pinouts that you know.  Please quit making the guys trying to help you feel like shit.  If you don't like it, don't use it.  STM32M0 != STM32H7.  For me, the STM32CubeMX is excellent.  The HAL drivers still need some work as of V1.4, but now that I know there is an update, I will check it out.

[Karel]

CubeMX is great for pin allocation and clock/pll setup.
But I never use the code generated from it.
Sometimes I let it generate the code so that I can have a look at it,
but I always write my own implementations that don't suffer from abstraction.
Most of the time I hate abstraction. For me, it makes the code difficult to read.
But I guess that, for people with less knowledge of C and electronics, it looks attractive.

[nuclearcat]

Seems they don't think so. After all, a lot of money is spent on this product, and ultimately customers pay this money in the form of added value.
While idea is great, implementation is shitty as hell.

While digging Cube code, found this "pearl".
https://www.st.com/en/embedded-software/x-cube-iota1.html
Implementation of most flawed and scandalous cryptocurrency in Cube.
Relatively latest news: https://www.coindesk.com/iota-being-shut-off-is-the-latest-chapter-in-an-absurdist-history
And it was obvious from the beginning, the one who made this decision -  flushed to the toilet ST reputation and company money.

It would be better if they spent these "human hours" to fix fundamental flaws of Cube core functionality and improving low-quality code.
Either we are observing death of the ST, or there a "hype-enabled" manager who is driving company(or department responsible about Cube) straight to the wall.
I wonder if investors are aware about such idiotic moves.

[shangaoren]

printf is just convenient way of debugging. It is better to avoid in production, but if you just want to debug something silly and software crash on that - this is ridiculous.
About malloc - AFAIK it is very bad habit to use dynamic memory allocation in interrupt routine, and even calling any other complex functions from it.

Be carefull a printf is not negligeable, the execution overhead created by printf can hide or create bugs, on multitask system it is dangerous, it is more reliable to use debugger functionnality such as RTT from segger

[Dubbie]

After you use a debugger you will never go back to printf
It just screws all your timing up.

[nuclearcat]

After you use a debugger you will never go back to printf
It just screws all your timing up.

If i have board with SWO routed/free and debugger (J-Link or proper ST-Link with SWO) under hand - it is great, better and preferable.
But sometimes, for example, it is just printf for temperature i got from DS18B20, and it is convenient to get it simplest way possible, over trivial USB-TTL.

[westfw]

After you use a debugger you will never go back to printf
It just screws all your timing up.

It screws up your timing in a DIFFERENT WAY than using a debugger...

printf is just convenient way of debugging. [but I agree that malloc() is a bad idea.]

Some implementations of printf() use malloc() (or at least cause malloc() to be included in your binary.)

on multitask system [printf] is dangerous

You mean like the multitasking, multiuser operating systems that printf() was first developed for?  That seems to be a bit of an overstatement!(of course, printf() probably either blocks (freezing all tasks) or allows other tasks to run, both of which CAN be problems.)

Implementation of most flawed and scandalous cryptocurrency in Cube.

Um.  Are we going to down-rate library quality due tomoral incorrectness and hindsight into the usefulness of the algorithms implemented?  I think that's going too far.  Presumably ST said "implement something that shows off the crypto accelerator on these chips"?

I had a very good experience after I got to V1.4

I've heard that "recent" versions of the ST code are better than the older code.  It might be too late to fix their reputation, though.  (There's a lesson there!)

[thm_w]

Abstraction is wonderful

After you use a debugger you will never go back to printf
It just screws all your timing up.

I agree that I dislike straight printf debugging. But there can be value in using both, specifically printf for logging to a PC or file system over long periods of time.
You can use DMA as well.

[lucazader]

I personally use printf debugging extensively. and build the delays that it brings into the overall software arch.
One thing i find important to make printf less detrimental to program performance is to copy the printf string to a fifo buffer and then when the processor is not busy (eg in an idle task in an rtos) the data will slowly get printed out. this was the software is blocked for the least amount of time in critical areas as the memcpy is pretty snappy.

The main reason that i rely on this however is more to do with the products i work on. I mostly deal with motor control and hitting a break point while controlling a motor (especially if you are commutating a bldc motor) can cause lots of fun things to happen (eg motor stops spinning and dumping a lot of power into a motor) and or control loops get out of wack etc. So quite often i have to rely on not using the debugger.

I do agree with westfw that the more recent cube hal releases have been getting better in a slow but steady way (for the most part). But unfortunately there is a bit of a bad reputation from the earlier releases that they will have to try and get around.

(edit to correct spelling of westfw)

[nuclearcat]

Um.  Are we going to down-rate library quality due tomoral incorrectness and hindsight into the usefulness of the algorithms implemented?  I think that's going too far.  Presumably ST said "implement something that shows off the crypto accelerator on these chips"?

Yes, definitely!
I think you agree that there is a million and another one reputable and useful way for "crypto accelerator show-off"?
Particularly showing an example by implementing deeply flawed Curl-P hash used exclusively in IOTA.
https://eprint.iacr.org/2019/344.pdf (also there was discussion between cryptographers how bad it is).
Ah yes, Keccak that is used in Curl-P is not "cryptoaccelerated" in STM32. It's SHA-3, and max STM32F4/7 have - SHA-2.

And (giggling), all this code heavily bundled with printf+FreeRTOS "explosive kit", just check their sources.
I don’t even know what the purpose of writing this code was.
Scandalous cryptocurrency with known to be flawed crypto, includes printf that they are unable to fix for almost year and it will hang this code at random moment...
One thing i know, they show that there is absolute mess in ST Microelectronics "Cube department".
This is seems some kind of shitshow.

[Jeroen3]

Printf is amazing for behavioral tracing. Printf is horrible for driver debugging.
Use the tools where they work best.

If you have any recent toolchain the use of printf will not use malloc.
In fact, it won't even do anything! You'd have to implement the system calls first. eg: int fputc(int ch, FILE *f) and int ferror(FILE *f).
http://infocenter.arm.com/help/topic/com.arm.doc.dui0378g/chr1358938931411.html

For ARM, none of stdio function depend on malloc, which is the relevant lib here.
http://infocenter.arm.com/help/topic/com.arm.doc.dui0378g/chr1358938930615.html

For GCC I don't know where to find the docs.

[nuclearcat]

Printf is amazing for behavioral tracing. Printf is horrible for driver debugging.
Use the tools where they work best.

If you have any recent toolchain the use of printf will not use malloc.
In fact, it won't even do anything! You'd have to implement the system calls first. eg: int fputc(int ch, FILE *f) and int ferror(FILE *f).
http://infocenter.arm.com/help/topic/com.arm.doc.dui0378g/chr1358938931411.html

For ARM, none of stdio function depend on malloc, which is the relevant lib here.
http://infocenter.arm.com/help/topic/com.arm.doc.dui0378g/chr1358938930615.html

For GCC I don't know where to find the docs.

STM32CubeIDE using gcc. And newlib/gcc printf, if you have %f - will use malloc. (probably %s too)

[Jeroen3]

Only when using asprintf though, which is exactly what you expect it to do.
https://sourceware.org/git/?p=newlib-cygwin.git;a=blob;f=newlib/libc/stdio/vfprintf.c;h=1aaf05aa44a2fc1442405d8d6739c70fc66091a3;hb=HEAD

[nuclearcat]

I'm not entirely sure why printf crashes(i stopped using cube), but it is explained in long thread i sent before ( https://community.st.com/s/question/0D50X0000BB1eL7SQJ/bug-cubemx-freertos-projects-corrupt-memory ).
It can be also because of reentrant function issues, but anyway, i believe mentioned issues is essential functionality and should be fixed ASAP.

[shangaoren]

It screws up your timing in a DIFFERENT WAY than using a debugger...

printf on embedded system go most of the time to UART, debugger (on arm target) use serial wire interface which is way more faster than UART ...

on multitask system [printf] is dangerous

You mean like the multitasking, multiuser operating systems that printf() was first developed for?  That seems to be a bit of an overstatement!(of course, printf() probably either blocks (freezing all tasks) or allows other tasks to run, both of which CAN be problems.)

Multitask doesn't mean desktop, RTOS are common on embedded targets .... that's not an operating system and not multi user ...

[nuclearcat]

https://community.st.com/s/question/0D50X0000BsRNNV/stm32cubeprogrammer-execute-fail-with-could-not-find-or-load-main-class-comstappmain
And one more. Just each god damn "Cube" software kit i download and expecting to work, wont be really working out of the box.

[robermeyer]

I use CUBE IDE to configure the cpu pin out and assign peripherals before layout.  I generate functional self test for the initial board bring up before the software guys are even bothered with new projects.  We have done this for many boards with no issues.  Our programmers are very talented and wasting their time optimizing and bitching about the style of STs HAL or LL code because it can be better makes no sense to me.  There is always plenty of functional code to write and debug that can be written anyway the talented programmers find productive.  Reinventing the drivers and init code because it can be better and faster makes no sense if it works the way it is.  Design cycles are too short to rewrite the ton of code ST has already provided for free.
Personally I am amazed at the huge effort ST has in maintaining Cube considering the number of different CPUs they have in production.

[nuclearcat]

I use CUBE IDE to configure the cpu pin out and assign peripherals before layout.  I generate functional self test for the initial board bring up before the software guys are even bothered with new projects.  We have done this for many boards with no issues.  Our programmers are very talented and wasting their time optimizing and bitching about the style of STs HAL or LL code because it can be better makes no sense to me.  There is always plenty of functional code to write and debug that can be written anyway the talented programmers find productive.  Reinventing the drivers and init code because it can be better and faster makes no sense if it works the way it is.  Design cycles are too short to rewrite the ton of code ST has already provided for free.
Personally I am amazed at the huge effort ST has in maintaining Cube considering the number of different CPUs they have in production.

https://www.eevblog.com/forum/microcontrollers/stm32h7b3-warning-cubeide-1-3-all-projects-are-in-a-broken-state/msg3099437/#msg3099437
Then you have to read about H7 story as example, where this particular board wont pass such functional self-test in Cube, because you got "old generation" cpu, that got significant changes, but no changes in part number, so even ST own HAL fail to work with it.
Also, check libopencm3, which is really amazing, and where guys managed to keep relatively unified API for several different ARM vendors and processors.
While Cube get fixes for one MCU, and intentionally wont get same fix for another, without any reasonable explanation.
ST has really great MCUs till now, and Cube was(and probably still) cool about looking to idea how things should work, configure peripherals and clocks, but not more.
Moreover, i suspect this messy code in it helping to hide serious problems.
For example, recent find that at least some STM32L0 have issues with SPI and it needs "to be set specific I/O configuration".
It is mentioned VERY indirectly in 2.6.3 in ES0255 (Errata Sheets, STM32L052x6/8 device limitations).
Cube also does solve this "automagically", without any comments or reference:

Code: [Select]

  initStruct.Mode = GPIO_MODE_AF_PP;
  initStruct.Pull = GPIO_NOPULL  ;
  initStruct.Speed = GPIO_SPEED_HIGH;
  initStruct.Alternate = SPI1_AF ;

  HW_GPIO_Init(RADIO_SCLK_PORT, RADIO_SCLK_PIN, &initStruct);
  HW_GPIO_Init(RADIO_MISO_PORT, RADIO_MISO_PIN, &initStruct);
  HW_GPIO_Init(RADIO_MOSI_PORT, RADIO_MOSI_PIN, &initStruct);
Without this "magic", their own ST branded boards not working properly and getting data corrupted.

So seems many , embedded developers run a bunch of code and have no idea what this code does and why.
And actually they have no choice. Either copy unreliable pieces of initialization code from Cube (and get bugs like mentioned before, like malloc), or get such undocumented problems with hardware.

After what i experienced, these examples, i would really think that it is bad idea to use cube code for anything meaningful, even self-tests.
More than that, when i got used to high quality code in opensource, where any strange tricks are commented and documented, seeing this pile of poorly documented magic mixed with .a binaries dumped on github is far from something that should be praised.
It's cool to reuse code like libopencm3, if license permits, but cube? Hell no, it's ticking bomb.