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!

[Andrew Neil]

---

@KnarfB wrote:

CubeMX stands as a bridge between EDA tools and software development.

---

Indeed.

I can imagine that there are plenty of teams where CubeMX is used only by the "hardware" engineers, and soft/firmware engineers use only the "traditional" IDE parts ...

PS:

It might not even be a hardware/software divide.

In a team, I can see that it might be desirable to have just one person "in charge" of the .ioc file - so only that one person would use CubeMX.

The .ioc file format really isn't great (or even usable at all?) for file merging.

[mattias norlander]

@Andrew Neil + @Jerem0arker one idea to solve to improve the "interoperability" between MX and any IDE or when launching MX from the OS file browser would be the following:

1. The developer double-clicks on an ioc-file. MX is not immediately launched. Instead an MX-launcher-wrapper is associated to the ioc-file extension on the OS file system.
2. The MX-launcher-wrapper quickly reads the ioc-file and specifically the line: 

   MxCube.Version=6.13.0
   MxCube.Version.Locked=True

3. The MX-launcher-wrapper could read out which MX version it should launch. 
   1. If the project is using Locked=True we strictly launch MX 6.13.0 guaranteeing that no unintentional project updates will happen in larger teams. And instead helping the developer to download/install and launch MX 6.13.0 if that is what is used within this project.
   2. If the project is using Locked=False we will launch with MX 6.13.0 if available on the system. If not we offer the user with the help to download/isntall/launch 6.13.0 or to launch with a later version and thereby update the project...

This approach would be equally valid if the ioc-file is launched by a double-click from the file system or from inside CubeIDE or any other IDE... Interoperability is improved while guaranteeing that people do not accidentally launch the wrong MX version. As time passes, developers arrive/leave companies/projects, the risk of using the wrong tool versions increases.

The above is clearly a brainstorm. I am interesting to hear feedback on the topic of Tool updates and tool locking. Does the above proposal solve a real problem or not?

[Andrew Neil]

To be fair, I can see that having 2 separate apps is going to add some friction for getting started with STM32 - especially for beginners with little/no prior microcontroller development experience.

@mattias norlander perhaps ST could provide an installer which installs both apps (maybe also CubeProgrammer?) at once?

Perhaps even include options for other tools; eg, CubeMonitor ...

[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.

[Pavel A.]

>  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.

With more vivid imagination, one could expect the bat file to open a pre-made codespace on github ? Or fetch a docker container or devcontainer with everything installed? :))

Or better, they will feed the readme.txt in the example to their AI assistant and tell it to prepare everything.

[mattias norlander]

---

@Pavel A. wrote:

With more vivid imagination, one could expect the bat file to open a pre-made codespace on github ? Or fetch a docker container or devcontainer with everything installed? :))

---

I like where this is heading! :) ... There is no "one solution" fits all. --> Flexibility is key. But this idea is really nice!

[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!