What’s new in STM32CubeIDE 2.0.0

@Wood.Andy ogh boy, if your porsche do 80mph in 2,7s , you sell it me and buy new for 2,6s... 

I'm throwing away one seat .

@mattias norlander 

but for be fair, remove MX isnt perfect. Now in version 1.x we can manage two different MX without big trouble, one in IDE and one standalone. Real projects require handle generator versions in time and isnt simple job.

Plus sentence about no refreshing is absurd, for example KEIL do this after MX generation or better say on every build check folder changes. IDE not doing this for years.

This is the worst decision I have seen for a LONG time.  In one clean swoop - ST have just rendered EVERY SINGLE tutorial useless (including their own).

https://www.youtube.com/watch?v=CfXH1DoZpRk 

I agree with @lbthomsen that this is a horrendous decision for STM32 adoption. Not only does it invalidate a lot of tutorials (and AI training data), but it is also a lot harder for beginners to get going. This single-handedly reverted 6 years of progress, and one is back to spend a lot of time on understanding the toolchain.

Personally, I am not using CubeIDE (but JetBrains CLion) but I am working with people who do, and it is going to be painful for many.

Compounding seems to be that there are new bugs in CubeMX code generation, which will exasperate the issue at hand. 
I suggest that you back track on this in a hurry, before there is irreparable harm to the brand.  

This update is regressive!! Can you provide an alternative update where CubeMX is integrated? It looks likely that i would not recommend to my team to upgrade pass 1.19. 

MM..1@

@Wood.Andy ogh boy, if your porsche do 80mph in 2,7s , you sell it me and buy new for 2,6s... 

I'm throwing away one seat .

I don't know what you are on but could you send me some?

@mattias norlander 

but solving that in time of 2.0.0 release was not possible.

Was it rushed - if so was the dead hand of the marketing department involved...

@christelle burguera 

Thank you for your suggestion.  I'm familiar with project importing and refreshing.  I think the problem I am seeing may have to do with the combination of FW_H7 v1.12.1 and CubeMX 6.16.0.  I've tried starting a project from scratch with this combination and I still run into trouble.  FW_v1.12.1 and CubeMX 6.15.0 work fine for same project  Problem seems tied to handling of PWR/LDO related #defines and some other stuff.  Not totally sure yet.  When I track down and repair one compile error, another is revealed.  

I'm unhappy about this change and will stick with IDE v1.19 for now.  Splitting up the tools does nothing but complicate my particular workflow.  I'm on a PC, I was not mix-matching my tool sets/processors, I was not experiencing slow speeds.  I chose to use STM's development tools with their processors specifically to uncomplicate my universe.  

I was having a bit of trouble understanding how to use the tools separately.  Found information in combination of the example projects described at end of CubeIDE manual and by watching tutorial designed for STM32CubeIDE add-in for Visual Code.  Might want to make this information more prominent for folks using STM32CubeIDE unless you are planning to obsolete it.  Ahemm.  

While you are re-doing MX...

Would it be possible for a H7 to make LWIP actually work 'out of the box' like F4 does without having to go and edit all the memory regions and linker?

It would actually be a very good use of your time as far as I am concerned ;)

Thanks

Andy.

@Wood.Andy : 

"Was it rushed - if so was the dead hand of the marketing department involved..."

Yes and no. CubeIDE has since day1 been rushed... What do I mean? CubeIDE is tightly coupled to the STM32 MCU/MPU roadmap and product launch schedule. Why? Mainly because CubeMX is integrated inside CubeIDE.

• CubeMX has to strictly follow ST MCU product launch schedule. Makes sense.
• An IDE (generally speaking) has to pay more attention to up-stream open-source driven projects like Eclipse, CDT, JREs, GCC, CMake, Ninja, GDB, OpenOCD, ..., which are the key bricks on an IDE
  • In case of a CVE we need to be able to act quickly and not be blocked by following ST MCU product roadmaps.

My point is that IDE releases, generally speaking, should not be be tied to MCU product launch schedule. Let's compare ourselves with Arduino IDE, they solved this issue more than a decade ago by abstracting device support into stand-alone SDKs. CubeIDE cannot do that. Why?

• CubeIDE is hostage to CubeMX.
• CubeMX in terms is depending on ~20 CubeFW packages (similar to Arduino SDKs) to generate code into IDE projects (IDE: CubeIDE, EWARM, MDK-ARM).
• If there is a bug in a new "CubeMX" version packages that is being integrated into CubeIDE, then users will suffer and complain about the IDE

The bug report will be filed against CubeIDE on our forum or via other support channels and it can take more than a week before the right engineer even reads the bug report because the bug was tagged with "CubeIDE" not "CubeMX". Users struggle to understand which tool is doing what. Even inside ST most engineers make the wrong assumption about the origin of a bug. Re-routing bug reports to the right team takes time/cost money. Ultimately customers are frustrated because ST is not responsive/reactive enough. This is no surprise to me at all...

Let's for a moment imagine that there is a bug in CubeMX or CubeFW. What happens inside ST is that CubeIDE team have to abandon their initial roadmap plans and instead quickly provide a bunch of internal builds of CubeIDE integrating a bug fixed CubeMX version so that validation campaigns can start.

As an end-result you see an IDE-team which is not at all able to improve edit / compile / debug of an IDE. Mostly because we are focused on delivering MX inside IDE when it could be a stand-alone tool.

The next question that begs to be asked is: Is this bug scenario that I am painting 2 paragraphs above frequent in our releases or not? Well, I invite you to read the CubeIDE release note dating back to 1.0 in 2019. Let's be honest: Every release when CubeIDE is not forced to push a patch update due to bugs coming from integrated tools is a big surprise.

A few hours ago I learned that MX 6.16.1 is under preparation to fix some regression bugs. Unfortunate, but not a surprise at all. I am curious to see if MX and IDE with 2.0.0 is "de-coupled" enough that the MX 6.16.1 will not force an IDE update. If so, great news! 

In conclusion: The integration costs a looooot more than what is visible to our user base. As a consequence there is no feature development and very limited bug fixing in CubeIDE. I am not saying that removing the integration of MX inside CubeIDE means we can/will bring a lot of new features. The future direction is still VS Code. But the waste of resources... :( 

All that said, the interoperability in CubeIDE 2.0.0 is not good enough. But this is also not the end of the journey. 

The lessons learned so far from reading a lot of feedback

• End-user frustration would have been reduced if we had a video tutorial coming along with CubeIDE 2.0.0 release showing how to work with stand-alone tools.
  • For example users now struggled to understand where the starting point for a project is, and later how to import it back into the IDE... 
• Automatic updates should have been turned off inside CubeIDE to let users "by default" stay in CubeIDE 1.19. That would have granted us time to assist the transition to 2.0.0 in a more smooth way. And let people explore 1.19 side-by-side with 2.0.0.
  • The whole idea of updating the IDE given that CubeMX is integrated inside is crazy! MX integration is the reason why I would always recommend people to install IDE versions side-by-side. Leading to 3.5GB installation each time. you need to mitigate code generation risks, at least until you have tested a new version. Overwriting the old version by updating is madness and easily proven by our release history.
• The CubeIDE project explorer does not automatically update itself when CubeMX has re-generated code. We were not able to address this in time. And no chance to delay the release since CubeIDE is still a bit hostage to MCU roadmap.
• ioc-file association. Since many users coming from CubeIDE 1.19.0 does not have MX stand-alone installed the ioc-file inside CubeIDE 2.0.0 will open in a text editor instead of in MX. It has a logical explanation, but since our communication probably reaches less than 10% of our user base, most people will be surprised. Ideally we want IDE to be able to launch the right version of stand-alone MX by reading ioc-file MX version information... But that has to be explored further down the roadmap.
• 6 years of video tutorials flushed down the toilet? No, not at all, the vast majority of video tutorials are equally valid/valuable. It is just the entry point between the tools that have changed. All the clicks inside MX are the same regardless if integrated or stand-alone version. But in stand-alone mode you can actually use the full height and width of your screen ;)

Next step:  See how fast we can arrange a video tutorial or an article.

Feel free to report more ideas on how we can improve the "interoperability".

Kind regards, Mattias

Hi Mattias

I can understand the reasoning to 'decouple' them as it means you don't have to test IDE when you add more CPU's.

But you will get push back from users when you remove functionality that is seen as making their lives harder.

So we will have to grin and bear it ;)

But please not VS Code... I will take early retirement first!

Thanks for the explanation...

Andy.