Unbiased Review of the new and "improved"(?) STM32CubeMX2

[Niclas Hedhman]

@lbthomsen of STM32World has published a review of the new STM32CubeMX2, what is good (not so much), indifferent and BAD (a lot). He tries to get it working, browse through the features, and has a lot of opinion on this matter.  https://www.youtube.com/watch?v=61r83TTzDfk

End of the day, IF you plan to use future STM32 families (starting with STM32C5) you have no choice than to use CubeMX2 AND the very painful migration from HAL to HAL2 (not compatible, maybe some future tool can assist in such migration). Even if migration is possible, then you will have the pleasure to support multiple versions of YOUR code on old vs new MCU families. Have FUN.

For the people without perfect vision (like myself), embrace yourself for 4 pixels font sizes, and contrast-free dark-white-on-white-backgrounds text. Lovely! At least there is plenty of white space around the text that can sooth your soul.

Now is the best time for experienced STM32 shops to leave HAL, CubeMX and go Bare Metal ;)

[TDK]

Another comparison:

In STM32CubeMX, it takes 2 mouse clicks to assign a pin as a GPIO output. Click the pin, click "GPIO_Output". Done. The clicks are even right next to each other. And you can see the pin is an output, as well as additional configurations when you hover over it. Easy.

In STM32CubeMX2, to assign a pin as an output:

• Click the pin.
• On the right side of the screen, click "GPIO"
• Click the Gear button next to GPIO to see options. This changes the view from Pinout to GPIO.
• In the middle of the screen, first find the pin you were working on, then click "Mode" and then select "Output".
• Click "Pinout" to return to the pinout view.

6 clicks!! And it shows you all pins so you have to remember which one you want to change. And even after all of that, there is no way to see at a glance on the pinout view that the GPIO is an output. How is a tooltip that explains that you can drag and drop signals more important than whether the pin is an input or an output?

Assigning pins as input and output has to be among the most common scenarios ever. Yet the new STM32CubeMX2 is comparatively awful at doing it and presenting that information.

[Niclas Hedhman]

Here I must defend CubeMX2, though.

Right click and you get this pop-up;

And can select GPIO with a second click. Edit Label is an extra "hover" (click not needed). I can live with that.

[TDK]

You can select "GPIO", yes, but you still need to configure it as output, hence the additional 4 clicks.

[MorkBeck]

Hi
Thank you for your feedback. We appreciate your input and have recorded the user experience concerns you raised. We are actively reviewing these points and will address them as resources allow. We recognize that some tasks currently require multiple steps, and we will prioritize improvements in this area as development progresses.

Please continue to share your suggestions. This is the initial release of the application, and we are committed to enhancing the user experience in future updates.

[v_dimitrov]

@MorkBeck 

Hello, 

I'd like to point out that in MX2 - the MCU choice filtering is very limited compared to the remarkable system used in MX1. Should you choose to remove the C5 and other MX2-supported MCUs from MX1 - the product choosing and comparison process would become hell. Please think about implementing the same system in MX2 as a redundancy. 

The new tool has great potential in my opinion, you could also add GPIO configuration in the detailed view, albeit not the full set of settings in order to address the above user concerns.

[MorkBeck]

@v_dimitrov 

Hello,

Instead of adding the finder functionality to STM32CubeMX2, we have determined that users typically know which microcontroller unit (MCU) they will use when they access the MCU selector screen. If you need assistance selecting the appropriate STM32 device for your product, you can use the updated MCU portfolio available here: 

https://www.st.com/content/st_com/en/stm32-mcu-developer-zone/mcu-portfolio.html 

[TDK]

> Instead of adding the finder functionality to STM32CubeMX2, we have determined that users typically know which microcontroller unit (MCU) they will use when they access the MCU selector screen.

If users knew which MCU they will use, they don't need an MCU selector at all. This is tenuous logic at best.

If you continue with the MX/MX2 split and segregating new MCUs to be MX2-nly, it will cause an inconsistent software system and a reluctance by users to switch to a new/unknown software with far fewer features. This will cause newer chips to be less readily adopted.

[Ozone]

> If users knew which MCU they will use, they don't need an MCU selector at all. This is tenuous logic at best.

In a commercial environment, this is most often the case.
Required interfaces and internal resources determine the type and package for a project first, hardware and software development start after that.
This is what I observed in every instance. Most later mid-project changes of MCU type were caused by code or RAM size issues.

[Uwe Bonnes]

I seem, MCU Finder still does not know about STM32C5.

[v_dimitrov]

Instead of adding the finder functionality to STM32CubeMX2, we have determined that users typically know which microcontroller unit (MCU) they will use when they access the MCU selector screen. 

I can attest to the opinion of TDK. 

Our company's product is cost sensitive so price is not being available is a lot of additional workload for me as an engineer to cross reference it against our suppliers or STM. Of course, STM's shop doesn't even allow for sorting by price so CubeMX was the only good place to pick the best suitable MCU. 

I'd guess most high volume products would share the same opinion. We use a lot of STM parts so I'm well aware of your portfolio, but if I were someone looking for a new supplier this would be a big negative.

This leaves us relying on distributors' websites to compare them, but they don't have the interfaces filtering flexibility of CubeMX. Of course, while we're there we'd notice ST is not the only MCU manufacturer.

>Required interfaces and internal resources determine the type and package for a project first, hardware and software development start after that.

Even if we disregard price  - unfortunately MCU portfolio on st.com is a bit buggy. I'll give you an example - target MCU - something with one CAN interface. By default it shows all MCUs, regardless of interfaces, but when you take a look it says "CAN Total - 1 to 3" even though search results are MCUs with 0 to 3. If you put it at 2 to 3 - it shows C5 (2 CAN) but not C092 (1 CAN). 

I mean if price wasn't an issue we'd just use H5/H7 everywhere.