Cube/MX frustration

[osama2]

Posted on August 05, 2015 at 23:18

Hi STM32Cube/MX users,

I've been using Stm32_StdPerihLib for years in dozens of successful projects. Now, after ST decided to replace SPL wir Cube I was ready to give it a try.My first impression was very positive - I like the graphical clock tree and peripheral configuration and the middleware integration.However, after having worked with Cube for some time I've encountered several limitations that leave me very disappointed:- CubeMX has a total static view on things: just the configuration on the screen and that's it. No dynamic clock switching, power saving or peripheral reconfiguration. Not even a simple thing such as runtime configuration of an ADC channel is supported, the code is not in the libriary. With SPL all of this was possible. I started to copy code snippets from SPL into my Cube project - what an irony...- It's almost impossible to customize the generated code. Imagine a USB descriptor with a real serial number - it's not possible. A hard-coded string is generated instead. Yes, You can modify the generated code but it will be overwritten each time You regenerate code, making diff and version control Your best friends to recover overwritten fixes.- GPIO pin labels can be entered in the GUI but I see no place where they show up in the generated code. Using GPIO_PIN_x makes the (GPIO initialization-) code hard to read and maintain. Why not have a include file that maps GPIO_PIN_x to the configured label?- Hard coded numbers can be found everywheiere. This is very bad style not even a first year student would be allowed something like HAL_ConfigurePeripheral(hPeriph, 1, 3000, 2000, 139).- Long lasting bugs in the firmware library (such as the RTC wakeup timer interrupt flag not being reset) are not fixed. Don't You try to fix it yourself - Your fix is gone after regeneration.- IDE project files (in my case Keil uVision) are overwritten and have errors. I use two configurations (DEBUG, RETAIL with different compiler Settings). In the brave new cube world, a project has only *one* configuration. Period.To make a long story short:After some weeksof programming around Cube's limitations, tracking down lost fixes due to overwritten code and guessing the meaning of numeric values, I think that Cube is not yet ready for production. It is good for a kick start on an eval board but not for mission critical series products.My wish list:- More flexibility and runtime hardware reconfiguration functions. The functionality that was in SPL sets the target for Cube.- Support for dynamic clock switching- Support for power management- More chances to customize the code, especially the initialization code and the middleware- A code generator that honors modifications instead of overwriting them- Overall code style improvement (&sharpdefine and friends)- Use of pin name labels instead of generic GPIO_PIN_xNow that SPL is discontinued and cube is IMHO not yet ready for production, what should I do?Thanks,Osama #idiocracy

[Tesla DeLorean]

Posted on August 06, 2015 at 03:40

I'd up vote but the forum doesn't allow that for top posts.

The irony here is that SPL code for the L4 and F7 exists, and is used by the ST-LINK Utilities for external loaders.

[John F.]

Posted on August 06, 2015 at 09:03

'' SPL code for the L4 and F7 exists''

Really? ST need to stop this conceit of Cube / HAL. It's actively driving away engineers who've developed with STM32 since the first devices. If SPL code for the L4 and F7 exists can we get it? If not, why not?

[qwer.asdf]

Posted on August 06, 2015 at 10:10

>

Now that SPL is discontinued and cube is IMHO not yet ready for production, what should I do?

I am doing my latest project using

https://github.com/libopencm3/libopencm3

, I find it good enough, it's being actively developed and it's open source, you can contribute to the development if something is missing. F7 and L4 support is still missing, but I'm sure it will come eventually.

[yhuang]

Posted on August 06, 2015 at 14:24

Cube/HAL is nothing wrong, especially for new embedded developers. SPL users may need some time practices penitently. Cube/HAL may use more weak functions for

flexibility

and add more examples for feasibility. It is too early to make a judgement whether Cube/HAL is good or not. Cube/HAL Team well done!

[Tesla DeLorean]

Posted on August 06, 2015 at 15:16

It is too early to make a judgement whether Cube/HAL is good or not.

No it's not. It has to be good when it leaves the factory floor, not at some random time in the future.It might be fine if you follow an ''abandon and forget'' development strategy, but some of us deal with customers that expect products to work now and in the future, and perhaps years/decades into the future. They don't want to deal with a continuous stream of updates fixing issues, or to be told to throw it away and buy the new widget.

[osama2]

Posted on August 07, 2015 at 11:00

That's my point: it's good for beginners and kick-starting on evalboards but when it goes to series development, it's lacking a lot of necessary functionality.

[uc2013135191]

Posted on August 20, 2015 at 16:12Well I am a beginner and I really like the SPL vs the Cube. The cube well has new stuff dealing with the Nucleo boards that I sometimes like to use and has more portability yes. But I didn't find particularly hard to port code written with SPL from a F0 series for F4 series. I'm just not gonna hope that the Cube get's better. I am using it now, learning it now. When I need to use it, it works and I don't run into ''hidden'' bugs. + I need to make school projects and sometimes people ask me to make some pieces of code - it needs to work right away! I can't waste time picking bugs.Yea the GUI is kinda useful but I don't think right now it's good. I mean it's good for beginners to start playing but after that it doesn't feel useful. And I am not against GUI code generators, I used one for other platform that I found really well made - and of course the libraries didn't have these bugs!The only problems I had with the SPL were:

1. No L4 for me :(
2. No F7 for me 
3. Changing the ADC channel being used had to be done in registers.

I will use the cube and advise it to my friends when it matures and gets the bugs ironed out.