AnsweredAssumed Answered

Cube/MX frustration

Question asked by Osama Dengler on Aug 5, 2015
Latest reply on Aug 6, 2015 by qwer.asdf
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 (#define and friends)
- Use of pin name labels instead of generic GPIO_PIN_x

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