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]

Thanks for your feedback @vybor! 

CubeMX was developed 5 years before the CubeIDE was even started. CubeMX is a Java/Swing based application. It is not an Eclipse/RCP applicatoin and consequently not at all a module which can be easily fit into the Eclipse/CDT based CubeIDE. The MX integration into Eclipse is a nightmare. Over the year we have improved the stability, UX and performance a lot. But it is still a bunch of duck-tape keeping the beast together.

Meanwhile new EU/Global CRA legislation is emerging in the world putting more pressure on software companies to manage cyber resilience and vulnerabilities. The more software bricks integrated into one monlithic package the higher risk/cost.

But let me instead try to reply to your points (the way I interpret them, sorry if I missunderstood):

• Yes, Eclipse has good plug-in structure we know the framework well and some of our developers have the rank of Eclipse/CDT contributors (up-stream merge permission in the community source tree). Trust me, we know Eclipse. We know the main contributors behind and we meet with them on a regular basis. CubeMX is however not an Eclipse/RCP application.
• RAM usage etc... I guess you are hinting at the "performance and stability" rationale behind the split? 80% of our user base is on Windows, based on your screenshots, I assume that you are too. Good for you! Thanks to the larger CubeIDE user share on Windows we have over the years received and fixed more bug reports on Windows. Meanwhile the Linux user base is more fragmented... They are using various distributions, versions and window managers... The number of combinations to support?! We have no chance to validate all that. Nor setup environments to fix those bugs. And Eclipse/CDT is normally running fine on top of most Linux distributions. It is often the CubeMX/IDE integration bridge (the duck-tape) that is bringing the bad performance/stability (we have looked for options).
• Screenshot with multiple windows. If CubeMX was an Eclipse plug-in, we could probably allow users to open multiple ioc-file at the same time in one single Eclipse window instead of the awkward work-around of opening a bunch of "new windows". You can do it. But it raises the questions: "If you are willing to go that far, why is it so painful to have one or several stand-alone MX tools opened?" (question is sincere)
• I also saw your post in another thread: "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.", source.
  No doubt that generated code is not necessary optimized for footprint or speed, but more as a simple getting started. And furthermore, over the years CubeMX releases have lead to some code generation regressions requiring patch releases (also forcing patch releases of CubeIDE due to the MX integration). This is why I always recommend users to use CubeMX as a copy-paste tool. Use it for prototyping. When starting the real projects focused on firmware or application code development, copy the driver and init code you need across into an empty project skeleton relying on a GNU Makefile or CMake file structure. This cuts your project dependency both vs CubeMX but also vs CubeIDE and its native .cproject files (.cproject file locks you into the STM32CubeIDE tool). Yes, by following my suggestion, you lose a bit of  beginner-friendly "GUIs", but you also gain in terms of tool flexibility, tool independence and you prepare your project for efficient CI-system integration. Five years from now, when you are tired of CubeIDE/Eclipse, you can easily migrate to any IDE of your choice because you chose Make/CMake instead of native CubeIDE .cproject format.

I am not bashing against CubeIDE nor CubeMX. They are great tools. I consider them great tools. But they need to be used in the right way at the right time.

I have written many replies on the topic of the "MX/DE split"... :) Feel free to click on my profile and go through the different latest replies to see more of the rationale behind... None of the arguments will, isolated, convince anyone that the split was necessary. But when you combine get the picture it is evident that we should never have engaged on the "integration" form the start.

 

Furthermore, there will be more tools coming in the future, and integrating them all into CubeIDE will not scale at all.

Thanks for sharing your opinions. I am not sure if any of these arguments will reason with you. But maybe the arguments will reason with someone else reading this thread...

 

Kind regards, Mattias

[vybor]

Eclipse 4 allows use any graphic library for GUI (Swing, SWT, JavaFX). Not big problem to convert standalone GUI app to set of Eclipse plugins. Eclipse development may be more simple due to uderlying OSGi platform with a lot of fuctionality. One don't have to invent wheel.

OSGi platforms in ERP / electronic commerce deploys hundreds of bundles from many subsystems. These system serves thousands of requests from thousands of clients per second. You make problem from deploing two. CubeIDE/CubeMX is very little system with no load.

Eclipse based application runs in 2005 on computer with Pentium 3 and 2 GB of RAM. Now om my home PC 32 GB of RAM.

As to resource consumption, integrated IDE/MX application consume less memory than two separate application. First case require one JVM, second require two JVM. And second app loads a lot of common plugins second time. Communication of two subsystems in one process (address space) is much more efficient than between two processes.

Separation is bad solution from any point of view.

[Pavel A.]

@vybor Please consider that CubeMX isn't used exclusively with CubeIDE (Eclipse). Many customers migrate to VS Code or use other IDEs (IAR, Keil, Segger...). All these users don't benefit from integration of CubeMX at all.

We started with the standalone CubeMX long before the [integrated] CubeIDE, with other Eclipses: Atollic and SW4STM32, Keil, IAR and what not. It worked very well then, and we don't miss the separation in version 2.x.

Few remaining wrinkles should be easy to fix (for one, the default project mode in CubeMX is IAR, so the user must remember to select CubeIDE every time. Impossible to make the project C++ right at the creation)

Suggest you to get two monitors, keep CubeMX on one and the editor/IDE on another. Enjoy.

 

[vybor]

Strange position. Instead of attract users to use ST tool CubeIDE company stimulate them to switch to tools of other vendors. Without integrated Device Configuration Tool there is no reason to use CubeIDE. As standalone IDE Keil is better. ST can close CubeIDE project.

CubeIDE 1.x has one competitive advantage - integrated Device Configuration Tool wich make iterative development easy. ST kill it by own hands. I press Ctrl-S buttons in Device Configuration Tool  window and have updated files in CubeIDE window. No more movements. Yes, I have two monitors and after IDE start I create new window and have CubeIDE on first monitor and Device Configuration Tool on second.

ST has strange approach to write code - a lot of unnecessary code and data movement. Look at initialisation code from CubeMX, it is terrible.

[Andrew Neil]

Hey @vybor - please can we keep this thread to the topic of separating CubeMX from CubeIDE ?

You already have a separate thread for your gripes about the generated code.

 

---

@vybor wrote:

Without integrated Device Configuration Tool there is no reason to use CubeIDE.

---

I disagree.

CubeIDE remains a good IDE - comparable to any other chipmaker's free offering.

 

---

@vybor wrote:

As standalone IDE Keil is better. .

---

I find that questionable, but you're welcome to use it if you wish!

[JeronymJ]

Split from CubeIDE 2.0 does not open .ioc files - which is solved - to keep discussion of the pros & cons in one place.

---

It used to be separate years ago. So going back in time to make it worse again? ...
Terrible dicission and no reasonable explanation.

I am downgrading back. to previous version and hope you in ST get reasonable again.

[McClean]

Oh.. i dont believe it! The version 2.0 suxx. How can st ruin a fine solution without any need? 

[vybor]

ST software team is deceiving customers. Two separate applications require more resources than one integrated.

Separated solution require one more JVM and load some common resources second time. ST needs new software team. Any way, it's not serious to worried about two hundred dollars to add 32 GB of RAM to developer workstation.

[fred bar]

I would not go that far. The software team does what product managers plan to do. Problem is not how it is done, which would be on their shoulders. Problem is the direction the product is headed to, which is above them.
Anyhow, i always felt eclipse was a bad choice, VC is not a better choice. If only they used netbeans at the beginning, and now switched to a being a jetbrains clion plugin, we would all be in much better hands and using much better technical solutions.

[vybor]

Cube is sample of total negligence.

Look at MCU/MPU selector. It is student's work.

When main window had started user even don't start select a MPU. Nevertheless, table in right-botton side contains

all the MCUs. It is wastefull use of resources.

All MCUs has prefix STM32. User have to type useless 5 symbols. After each new symbol request is made and two

lists is updated and filled with new items. Very long at begining. Now one use long lists for scrolling while searching. If items not fit in visible area, user enter next symbol to narrow presented list. 

Presented MCUs product info is useles, when developer starts CubeMX to develop product, he know about target MCU much more than presented in CubeMX selection window. All this functionallity can be safelly removed.

Now there is bad selection process

1 user enter s - app handle request and filled two list with all 4876 MCUs. Useles info, too long to scroll.

2 user enter t - the same

3 user enter m - the same

4 user enter 3 - the same

5 user enter 2 - the same

6 user enter H - 387 MCUs are found. too long to scroll.

7 user enter 5 - 131 MCUs are found. too long to scroll.

8 user enter 0 - 13 MCUs are found. At this step there is convenient list to select from

In good GUI search proccess must start from step 6. 3 symbols to enter. Now one have to enter 8.

 

[vybor]

Problem of CubuMX is terrible product architecture. 

It not use OSGi possibilities. It is old home made product. It is a mess of plain jars with old classpath headache.

Dynamic OSGi platform is exelent base for product like CubeMX. It has functional to add, update and remove separate bundles. No need to invent wheel and spend money and time.

Bad interface, when parameters are edited in tiny window, which must be scrolled, a big area is occupied by useless at the time pinout view. GUI must be redesigned to be more dynamic.

ST had several years to make CubeMX good and stable Eclipse RCP application which can be used as standalone app to be used with any IDE. And can be used in CubeIDE without problem.

ST used OSGi very badly, export and import directives in manifests do not use version ranges. It is amateur level.

[vybor]

OSGi is exelent base if used right.

CubeMX does not use OSGi. It is not Eclipse RCP application.

CubeIDE is badly made Eclipse RCP application.

JetBrain use Java for C/C++ IDE and it is work fine.

Look at MANIFEST.mf files in CubeIDE. They are terribly bad.

Eclipse 4 does not impose any restrictions on the graphics library used.

OSGi is one of the best and usefull Java specification.

[Andrew Neil]

Note that STM32CubeIDE 2.1.0 has now been released

 

[Andrew Neil]

This is more adequately described as "The Cheese has moved!".

 

 

 

Stolen from this post by @Pavel A.