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

 

[Ozone]

> These are all reasons against any IDE.

Yes, there are.

My company extensively uses CI now, and IDEs are only getting in the way of automated builds on remote servers. Especially if you want to support several architectures and thus several toolchains / IDEs.
We are using make files instead, which are easier to automate and deploy.

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

[vybor]

It's seems you don't know Eclipse.

It's not possible to open one workspace twice.3 windows

But it is possibe to open new window (menu Window -> New Window) and open in it different file or perspective. Second, third, forth window can be dragged to other monitors. 

How your company develop Eclipse-based tools and don't know Eclipse at end user level?

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

Wow, I totally understand your frustration! I ran into the same issue trying to open .ioc files after the update. Rolling back to 1.19.0 is a good workaround for now. It's a shame when updates introduce workflow hiccups like this. Hopefully, ST is listening. I wonder if there's a workaround involving a specific plugin or perhaps a tool like Sprunki that could bridge the gap until a proper fix is released. Fingers crossed for a better 2.1.0!

[Andrew Neil]

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

 

---

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

 

 

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

---

@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 + @unknown 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 ...