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 ;)

[unsigned_char_array]

I don't understand how companies can still release software in 2026 that has unreadable fonts on high resolution monitors. Are their test engineers running the programs on VGA resolution monitors or something?

[lbthomsen]

No it' the opposite - force the developers to use relatively small low resolution monitors and they will make effective use of screen realestate.  Give them plenty of screen, plenty of storage and plenty of ram and they will use it.

//Lars...

[unsigned_char_array]

Obviously it needs to be tested on various screen resolutions, screen sizes and aspect ratios. And with various scaling settings (including fractional scaling).

[TDK]

> I don't understand how companies can still release software in 2026 that has unreadable fonts on high resolution monitors.

It's because both the people developing the software and the people in charge of making decisions about it don't actually use the software.

That's how you end up with bad decisions like this in the end product.

[Ozone]

I had my reasons to stick with mostly the SPL as template, and bare metal / direct register access otherwise.

[Brenden_PLUS]

Haven't done a deep dive on this but it seems pretty wild that that they would break one of the best features of stm32 chip which is there HAL abstraction layer.  So i would be very interested to know for what reason they wanted or needed to do this?

Guide for migration

* https://www.st.com/en/development-tools/hal2-migrator.html

Don't care to much mostly because i switched to using zephyr RTOS.  Which stm32 chips have great support for.  

[Emil Damkjaer PETERSEN]

Hi,

Thank you for your feedback on the user experience. We intend to address these issues to improve your experience in future releases. The following changes are planned for upcoming releases:

• Make text easier to read, including on small screens.
  • We are aware of the issue with small font sizes and are working on a solution.

• Address contrast issues.
• Please provide specific information about the affected areas, including whether the issue occurs in dark mode.

• Resolve scaling issues.
• We are aware that the user interface can appear distorted on smaller resolutions. We plan to add features to make the user interface more responsive and scalable.

• Improve zoom and panning functionality.
• The zoom and panning functions can be unclear depending on the cursor location. We are working to make navigation easier.

•  Installation issues on Linux
• Ware have identified the problem, and will see what is possible in terms of a solution

If any issues are missing from this list, please inform us. We value your feedback.

For the migration from HAL1 to HAL2, we understand that it may have been perceived as a painful experience, and this is certainly not what we want for our users.

We would really appreciate your feedback on the areas that were challenging for you, so we can improve the migration support that we offer.

It is also worth noting that the HAL2 update is designed to require minimal investment for porting, both through the changes made to the APIs and through the supporting tools and guides. Furthermore, we have continuously worked with external companies, partners, and customers to ensure that the migration effort is acceptable and straightforward. For additional validation, consulting companies that were not involved in building the migration tools and guides were contracted and provided the following statement:

“STM32 HAL2 makes developing with the STM32C5 and other family members faster and more efficient. It is much lighter, closer to hardware functions, and porting our code to other STM32 MCUs is extremely easy.”

To help with the migration, we have created the STM32Cube HAL1 to HAL2 migration tool and guide:
https://www.st.com/en/development-tools/hal2-migrator.html

It consists of:

• A tool that can analyze your application code and identify the HAL1 API calls that need to be migrated, along with links to documentation explaining how to migrate each specific API call
• A migration user guide, examples, and a checklist designed to assist you throughout the migration process

For more insight into why we have introduced HAL2, I encourage you to have a look at the post https://community.st.com/t5/developer-news/stm32cube-ecosystem-for-stm32c5-series/bc-p/887410/highlight/true#M417.

Best Regards,

Emil

[Niclas Hedhman]

---

@Emil Damkjaer PETERSEN wrote:

• Address contrast issues.
• Please provide specific information about the affected areas, including whether the issue occurs in dark mode.

• Resolve scaling issues.
• We are aware that the user interface can appear distorted on smaller resolutions. We plan to add features to make the user interface more responsive and scalable.

• Improve zoom and panning functionality.
• The zoom and panning functions can be unclear depending on the cursor location. We are working to make navigation easier.

•  Installation issues on Linux
• Ware have identified the problem, and will see what is possible in terms of a solution

If any issues are missing from this list, please inform us. We value your feedback.

For the migration from HAL1 to HAL2, we understand that it may have been perceived as a painful experience, and this is certainly not what we want for our users.

We would really appreciate your feedback on the areas that were challenging for you, so we can improve the migration support that we offer.

---

Contrast; The web world is obsessed with low contrast web pages, fonts with tiny lines and similar "good looking" nonsense. Without regard to people (and we are a huge percentage) with non-perfect vision, where these "good looking" only means that we need to strain the eyes, zoom in much more than would be necessary and in general be quite annoyed by it.
The Pin Assignment is laughable, and no idea who somebody could approve to release that. The Clock tree at least has some numbers in black, but most other text is smaller and "softer" contrast and I need to zoom in a lot. In dark mode the white is "bluring"

Isn't ST large enough to have expertise on Section 508 (Accessibility Regulation)? When I was in charge of a small product (12 devs in the whole company), we still had someone who knew Section 508 in detail.

And I don't even consider myself "impaired". A regular guy, with glasses, a bit of astigmatism and somewhat poor night vision. But "dark-white-on-white-background" is horrible.

Panning; When panning the clock tree with the "Pan tool" it works somewhat ok. Panning with the middle-mouse-button and for me it moves to the right all by itself when the button is pressed.
Panning with the "Pan Tool"; For clock tree, no issues. In Pin Assignment, there is a massive delay between mouse and what happens on screen. Lag is in the order of half a second, maybe more.

Panning/Zooming in general; Go look at CAD packages, and learn. Be consistent, but it could be as simple as;
Scroll wheel -> Zoom
Alt + Scroll -> Pan right/left
Ctrl + Scroll -> Pan up/down
Right Button -> Pan freely

(taken from KiCAD)

Installation; as mentioned in the video, why does the installer need those dependencies? Again it seems to be "web mindset", and a "Oh, let's just do it in HTML".  Request; make a non-UI installer for Linux. An installer that only asks for a location and to view license(s) is meaningless for Linux users.

"Minimal investment" -> So ST offers to do that for $5000 for every customer, right?  I thought not. I am even considering a "HAL2AbstractionLayer" for people to keep using their old HAL-based code, and it will work with HAL2 MCUs. In FACT, why hasn't ST done this? Since it is "Minimal Investment", it should be a piece of cake.

[TDK]

Just as a comparison for readability. Here are two chips side by side on the same monitor. The STM32CubeMX text is large and legible. The STM32CubeMX2 text is TINY. Probably half-size. And this is true even though the left chip has more pins!

Also, as @Niclas Hedhman mentions, the bizarre white on slightly darker white color scheme is apparent. There appear to be 4 different shades of white to light gray in the image. The left one looks like a chip. The right one looks like the beginning stages of a UI project. In particular the "shadow" effect behind the chip makes it looks like a powerpoint slide more than a usable tool. I don't need lightning bolt symbols, I need readable text.