IDE Version 2.0.0 - why remove MX ?

[jcslb]

Why, oh why have you separated IDE and MX such that .ioc files can no longer be opened in IDE?

I cannot imagine any benefits and it makes the IDE significantly worse, such that I've felt compelled to revert to version 1.19.0 ( go to Help -> About STM32CubeIDE -> Installation Details -> Installation History -> select version -> Revert)

I couldn't find any other means of feeding back my strong dislike of this change other than a post like this. I hope version 2.1.0 comes out soon and re-integrates MX and IDE!

[mattias norlander]

@Andrew Neil, indeed the split leads to 2x tools to download and install. The fix is however not to integrate everything into one installer. If we have a single installer including everything, a single bug in any of the integrated tools would require an update of the huge installer. And again, how many % actually needs that update?

The solution is to have a look at how other more modern programming languages are sourcing libraries and tools. The trend in modern programming languages is to leverage package managers and project manifest files to solve both the initial getting-started friction but also the updateability of individual tools and the of locking of the tool environment  per project in larger teams.

Arm Keil Studio is a good example of a new IDE environment which is tackling these getting-started issues in a good way leveraging vcpkg as package manager. Have a look at this project tool manifest file:

https://learn.arm.com/learning-paths/embedded-and-microcontrollers/vcpkg-tool-installation/config_creation/

In the link above you will see that the vcpkg-configuration.json mainly lists CLI build tools.
But nothing prevents this type of package manager to set dependencies on CubeMonitor, CubeProgrammer, TouchGFXDesigner, etc...

This is how modern programming languages offer stream-lined workflows... and a kick-ass getting-started experience! And they do it without jeopardizing silicon vendor maintainability, end-user updatability and  end-user reproducibility. It is a win-win-win.

We are not there yet... But we have the basic bricks to get there. Our response to vcpkg is the cube bundle manager, which has been introduced with our VS Code extensions. It has the potential to solve all these issues, but it will take a bit of time. In the future we can imagine that a beginner arriving at the doorstep of STM32 world can start by just cloning an ST example project on a machine containing ZERO ST Cube tools. The example can bring a small bat-file (example_install.bat?). Executing the bat-file can download/install CubeIDE, CubeProg, CubeMonitor, TGFXDesigner, ... on his machine by a single click while this guy is enjoying a cup of coffee. We are not there yet. But this is the potential.

"Thumbs up" if this sounds like a compelling future vision?! :)

[Andrew Neil]

I wasn't suggesting that there be just 1 installer to install everything;

rather, a facility to bundle bundle together a set of required tools, download them together, and then install them together

Which does sound like the "Package" idea ...

[mattias norlander]

Ahh. Then I think we are on the same page here! :)

[Leon3]

I read this link about the reasons for splitting. When I understand correctly, the main reason is that in fact two products need to be maintained and this is where, thinking out of the box, I see another solution.

Why not use a single product, the MX plugin. By doing so this plugin can be used for CubeIDE and for the stand alone product. All that needs to be created is a container application using the same plugin.

When I understand correctly, CubeMX is a stand alone application which is a different product from the CubeIDE plugin. By moving to changing CubeMX to a basic container for the same plugin this solves a lot I think.

[mattias norlander]

Hi @Leon3 ,

Thanks for sharing ideas. Not sure I follow fully. My reply may thereby completely miss your point... I will share anyway :)

If I understand your idea, that would be to ensure that CubeMX (regardless if stand-lone or inside CubeIDE) is delivered as a plug-in inside a "container". The problem is that CubeMX was developed more than 10 years ago in Java/Swing framework. The CubeIDE project started after that based on Java/Eclipse/CDT/SWT. Two frameworks which are not compatible. We use a lot duck tape to "integrate" them together... Since they are relying on two different frameworks, the marriage is challenging... Re-implementing MX in Java/Eclipse/SWT would cost a lot.

As a side-note, ST has another IDE targeting our Automotive MCUs called Stellar Studio:

https://community.st.com/t5/automotive-mcus/stellarstudio-8-0-0-officially-pushed-compliant-for-java21-and/td-p/833937

In Stellar Studio, the "MX" equivalent tool was developed as an Eclipse plug-ins. This solves the "integration issues" of not having two heterogenous GUI/widget frameworks. That was a deliberate design-choice from the start. They even provide target support packages / SDKs using Eclipse P2 update mechanism. The way an Eclipse-based IDE should work. In CubeIDE, we cannot leverage these update mechanisms, because CubeMX is in-charge of bringing target support, drivers/middleware/etc in a way which is not maintainable or updateable at all without heavy release work.

... I keep repeating myself walking into the same rant again with slightly different words.
Thanks for brining this idea to the table (if I understood it well, if not please elaborate in a PM). We are always interested in ideas!

[Kiboxxx]

OK to sum things up: ST wants to cut costs. End of story.

[mƎALLEm]

Nothing to do with costs...

[ben2ben]

lets not hire more engineer to fix this

lets just remove it. Management at its peak!

[Andrew Neil]

It's not removed - it's just separated.

 

It doesn't seem unreasonable to do this so that the engineers can do actual useful stuff,  rather than just deal with the added complications which integration brings - to little benefit..

[Andrew Neil]

There's a vote here in favour of the split !

[fpgiovanini]

Why, instead of improving and making the user's life easier, is the goal to make it more difficult,
susceptible to errors, and with senseless changes?

Besides the uncontable software bugs, an update every 3 months.

Give me a break.

[vybor]

Separation IDE and MX is bad idea.

Anyway, developer should have option to select integrated or separated tools.

Eclipse has good module structure and no problem to add addition plugins.

[tom9900]

这两天我在安装stm32CubeIDE,版本2.0.0，发现里面没有MX,以为安装有问题，原来是版本的问题

Translation:

Over the past couple of days, I've been installing STM32Cube IDE, version 2.0.0, and noticed that MX was missing. I initially thought there was an issue with the installation, but it turns out it was a version compatibility problem.

[vybor]

ST throw out single competition advantage. Without integrated Device Configuration Tool remain no reason to use CubeIDE.

On other side, ST code generator generate bad code. One can use it as start point to write own code only. To see used registers of perifery device without reading manuals.