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!

[RobK1]

STM32CubeIDE 2.0 release - early heads-up! - STMicroelectronics Community

[Andrew Neil]

---

@jcslb wrote:

I cannot imagine any benefits !

---

See the explanation already linked by @RobK1 

---

@jcslb wrote:

it makes the IDE significantly worse

---

Does it?

I guess it could be a minor inconvenience at the start of a project, or when the hardware config needs to be changed, but I think that is a tiny part of the work of the IDE ?

And this is the way Keil & IAR (and other) IDE users have always had to do it.

Just my 2p.

[mƎALLEm]

Hello,

There are two main reasons: flexibility and performance:

[mfgkw]

These are all reasons against any IDE.

I am in fact not a fan of an IDE. Nearly all work suits better for me with standalone tools like EMACS, the toolchain and gdb.

The only exception where I was persuaded to an IDE was STM32Cube. And this was exactly because of the integration with CubeMX. (Even here I used EMACS to edit longer passages of source code, but at least I used an IDE.)

When CubeMX is not integrated anymore I see no real reason to use the enbeloved Eclipse. And return to flexibility and performance...

[mattias norlander]

Hi,

The main reason is the cost this integration brings inside our organization. MX is released 3 times per year in-sync with silicon launches. But, internally, a new version of MX is integrated into CubeIDE every week. Every week end-to-end test campaigns are executed to validate the progress of upcoming STM32 product launches. Amazing amount of R&D-hours are spent on just integrating and validating MX+IDE.

The end-users benefits from this integration are mainly: Download a single tools and no need to ALT-TAB between MX and IDE. 

Meanwhile the integration brings cost and risks:

• Mixing apples and pears: Over time most STM32 developers learns that working with stand-alone MX and IDE is a good insurance to mitigate  tool related update risks and thereby frustration and project delays. Have a look at the CubeMX release history, many patch releases has been provided to fix code generation issues. The IDE features are rarely suffering from regressions. The IDE release cycle is completely hostage to MX.
• MCU roadmap: ST has an aggressive MCU roadmap ahead of us. Tightly integrated tools like CubeIDE 1.X in combination with aggressive MCU roadmap is both a huge risk. Due to MX integration there is a real risk that CubeIDE is not ready in-time for an STM32 product launch. In any other IDE, target support is the simple part.
• Integration cost: All R&D-effort spent on integration/validation could have been spent on feature and bug fixes.
• 2x IDEs: Developers are more and more asking for VS Code and we need to split our R&D-bandwidth across two IDEs (Eclipse + VS Code).
• Technical risks: The integration of Java/Swing and Java/SWT has been an exciting journey full of GUI surprises across our releases. Unclear how long this integration bridge will be maintained (not under ST control).

We have spoken to many customers in-advance of splitting these tools. Both small and large companies. The split is a bit more appealing to larger companies, and a bit less to small companies and beginners. IAR, Keil, VS Code, and CLion users are already exercising these workflows. And many CubeIDE users already realized that using MX and IDE in stand-alone mode allow them individual tool updates/freeze providing a good "risk approach" towards STM32 development.

The saved R&D bandwidth can help us secure that we can offer 2x IDEs in-sync with new STM32 product launches. Hopefully we can even fix a bug or two in the category of edit/compile/debug. That would be cool!

If I am correctly informed, CubeMX 6.16.0 contained some code generation bugs. Therefore, a bug fix release of MX will follow. In the integrated CubeIDE 1.X world, this would have forced a re-integration, re-validation and re-delivery of CubeIDE as well. Causing ST R&D-team a few weeks of delays or lost focus. Which could have been spent on real value-add! By splitting the tools we will hopefully not have to provide a patch release on CubeIDE as a consequence of CubeMX issues. That would be an amazing long-term win! ;)

We are not aiming to re-integrate CubeMX into CubeIDE.
We must get back on the track where our R&D-dollars are spent on tool innovation, not tool maintenance. 
We understand that this will hurt some developers, and for this we are sorry! The "interoperability journey" between stand-alone tools can still be improved.

Kind regards, Mattias

[Andrew Neil]

---

@jcslb wrote:

I cannot imagine any benefits 

---

In the IDE, you can only have one IOC view open - you can't see two side-by-side.

You can't open two IDEs in the same workspace, but you can open multiple CubeMX instances.

In the IDE, I don't find it practical to have an IOC and code view open side-by-side - it gets too cramped.

But, with a separate CubeMX, I can have MX on one monitor, and the IDE on another.

---

@jcslb wrote:

I've felt compelled to revert to version 1.19.0 ( go to Help -> About STM32CubeIDE -> Installation Details -> Installation History -> select version -> Revert)

---

You can download previous versions from the website:

You can install & use multiple versions at once.

[mattias norlander]

To further discuss @Andrew Neil's last point about separate versions of IDEs/Mx...

In the integrated era of CubeIDE 1.x, I would strongly recommend against "updating" a single installation of CubeIDE. I would always recommend developers to install multiple CubeIDE versions side-by-side, allowing them to safely migrate projects, preserving the old environment until the migration is successfully. After that developers may uninstall previous versions. The reason for this recommendation is mainly the CubeMX integration.

CubeMX integration is the major risk when updating CubeIDE. Evidences? Five out of the last six patch releases of CubeIDE are not related to IDE bugs, they are related to issues in CubeMX.

Another important point is that these bug fixes may be super important for those it concerns... But often the bug fix is completely irrelevant to 99% of the user base. 99% of the user base are not using the impacted STM32 device, or not using the impacted middleware, or not using MX at all, just a simple empty or makefile project and cherry-picking code from ST outside the control of MX. Despite that the entire user base is paying the price.

Stand-alone tools improves these updatability issues slightly. Updatability can be improved further, but we have to move step-by-step. The separation of the two tools was a milestone which suddenly makes CubeIDE no longer being a hostage to CubeMX and the STM32 product roadmap. This is good news for our IDE(s).

[KnarfB]

This update is significant, and I appreciate ST’s perspective as explained by @mattias norlander - even if it means adjusting some of my own habits

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

Are EDA tools integrated? No. Is there a single IDE that satisfies everyone? Definitely not.

hth

KnarfB

[Andrew Neil]

As @mattias norlander explained, it's not just a "hiccup" - it is a change of policy.

---

@Jerem0arker wrote:

I wonder if there's a workaround 

---

You can get Eclipse (ie, CubeIDE) to open a specific external application when you double-click a certain filetype in the Project Explorer.

So, for .ioc files, you could have it open the standalone CubeMX application - see  this post (by @TDK ) on how to start an external editor from the Project Explorer.