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
