New STM32 VSCode extension V2.0.0 released

[Nawres GHARBI]

Changelog

Version 2.0.0

• V2.0.0 implies a breaking change: CMake project generation has been moved from VS Code to STM32CubeMX v6.11.0 (and later).
  • VS Code solution no longer has dependency on STM32CubeIDE (.cproject-files)
  • VS Code solution no longer relies on STM32CubeIDE provided toolchains and debugger tools
  • VS Code solution no longer has dependency on vcpkg,
• Added support to import STM32CubeMX v6.11.0 CMake projects and bootstrap edit/compile/debug in VS Code
• Added support to create empty projects
• Depends on STM32CubeCLT v1.15.0 for empty project creation, build and debug tools
• Documentation update: The User Guide has increased coverage
• Better OS platform support

 

https://marketplace.visualstudio.com/items?itemName=stmicroelectronics.stm32-vscode-extension

[mattias norlander]

To make a very small comparison of the "free IDE offering" from ST, let's summarize the situation like this:

• STM32CubeIDE:
  • Fully-featured IDE.
  • Full STM32Cube ecosystem integration.
  • Integration of tools such as MCUFinder, CubeMX leads to slow performance.
• VS Code extension:
  • Lightweight and fast "IDE", but limited in terms of debug features
  • CMake-based build system which is de-couple from the IDE - more efficient CLI/CI workflows
  • Today heavily relying on open-source and third-party extensions

It is fully up to the user to select which free IDE offering they want to use.

The latest version of STM32CubeMX (6.11.0) brings CMake project generation. Supporting CMake opens the door to "IDE freedom" in a development team, where each developer on and individual basis can choose which IDE they want to use assuming it has CMake support. The "holey grail" in a development-team is typically that all developers produce identical build results. This means that the compiler and build system is well-defined and frozen in the team! Which editor and debugger each developer want to use is more of a personal choice.

One way of squeezing out maximum "developer efficiency" given the current state of the free ST IDEs is to combine VS Code and STM32CubeIDE:

• Use VS Code to edit and compile your project and for simple / quick debug sessions
• Use CubeIDE as a compliment for advanced debug only

This dual-usage is fully possible by:

1. Starting your CMake project from STM32CubeMX or from VS Code (empty project).
2. Import and work with the project inside VS Code. All editing and compilation done inside VS Code (or CLI)
3. Then use the elf-importer inside STM32CubeIDE to benefit from the advance debug features only (not for edit/compile)

Step#3 is accomplished by this wizard in STM32CubeIDE:

Full source code look-up, c-line / assembly instruction stepping and hyper-linking to symbols/code will work despite that the actual c-code is not imported in the CubeIDE project.

 

[ACapo.1]

Will multi project boards ever be supported using this extension and cmake, currently the cmake and makefile options are greyed out in STM32CubeMX?

STM32H7S78 is an example.

Thanks

Andy

[Nawres GHARBI]

Hello @ACapo.1 , 

it will be supported in the coming releases

[ACapo.1]

Hi @Nawres GHARBI 

Super, thanks very much for the prompt reply.

Andy

[MM..1]

All this sound excelent, but how with for example TouchGFX generated project. Here exist IAR KEIL IDE gcc folders, but is real import this here? For me edit mode only for GUI files is perfect.

[LaloRiojas]

Is there a way to still have  CUBEIDE .ioc files for configuration in addition to cmake?If not...

I actually genuinely enjoyed .ioc files and the GUI on the CUBEIDE. I wish i was still able to still use the .ioc files to configure hardware and middleware and have the cmake available for engineers who don't want to actually write code on the IDE. I think it was a bad choice to break the CUBEIDE support to for v2 of the extension.

Also in the extension description it mentions that you can still use this extension with CUEBIDE projects but with some extra manual configuration but I am unable to find how to set that up. 

I really think there need to be a standard way to convert CUBEIDE projects to cmake that is officially supported by the IDE such that you can build the project with CMAKE and manually flash/debug with CLI tools like openocd and gdb or optionally use the CUBEIDE makefile structure or whatever it uses

 

[Pavel A.]

Of course you can (and should) keep the .ioc files.

>  it mentions that you can still use this extension with CUEBIDE projects but with some extra manual configuration but I am unable to find how to set that up.

As @mattias norlander wrote here and in earlier threads: CubeIDE can create a lightweight project from existing .elf file for debugging it in the CubeIDE debugger. Actually this project is an "unmanaged" Eclipse CDT project. You can enhance it, add various settings to assist editing, add the build command and so on.

> I really think there need to be a standard way to convert CUBEIDE projects to cmake that is officially supported by the IDE 

This would be great; hopefully the "Eclipse for MCU" project or the general Eclipse CDT will develop full CMake backend integration some day. If you are motivated to help with development or sponsorship, you are welcome.

 

[MM..1]

Thanks Nawres for info, but more efficient will be compare and show pros and cons for main vscode extensions:

1. STM 2.0.1

2. STM 3.2.6

3. Platfomio platform STM 17.x 

 

Next to pros and cons is import capability. For example TouchGFX generated projects have gcc makefile and IDE .cproject , what now works ? From tickets here i see nothink works in first ST extension.

 

And remark to end i try install CubeCLT result is over 2GB space on disk, but i maybe plan only build one type cortex...

[mattias norlander]

---

@MM..1 wrote:

And remark to end i try install CubeCLT result is over 2GB space on disk, but i maybe plan only build one type cortex...

---

Agreed. In fact a lot of tooling that we develop today is kind of "clunky" in terms of download and installation size. And as a customer you may just use 1-2 out of a gazillion of features. We have some prototype solutions that will solve this in a much better way in the future.

[ACapo.1]

There is an advantage of the ioc editor in STM32CubeIde, it actually works on Macs.

The standalone STM32CubeMX refuses to start unless you give it full superuser Disc Access, something I guess most people are unwilling to do as there is no way a normal application needs that level of access!

[Pavel A.]

@LaloRiojas 

> what would you recomend for a system we can all be happy with 

IMHO, a good consultant or coach is a solid way to productivity and happiness of the team. The customer gets all needed tools installed and configured, build system and version control running, Windows/Linux issues settled. Whoever needs .ioc or cmake or a good debugger gets it. Everyone get what they need (or want).

 

@mattias norlander 

> We are considering ripping out the integration of MX and let users rely purely on MX and IDE as stand-alone tools.

This will be a painful move after all the efforts invested into the integration, but IMHO the right move, hope you won't regret it. This will enable unification with the Eclipse for MCU project, stuff from ARM, partners, and other cool things, like AI assistants. Time of painful changes for many of us ((

 

[mattias norlander]

”Time of painful changes for many of us”

Indeed… “impact analysis” started. Large companies are not going to complain, they use MX mainly to copy-paste code into their own projects. But, students, small companies and Makers may complain. And 6 years of documentation and tutorials… :grinning_face_with_sweat:

[ypiotrp]

Hi,

Is there a way to convert a project created with STM32CubeIDE (based on generated Makefiles) to project that could be built with CMake using VSCode Extension?

Regards,
Piotr

[mattias norlander]

It is planned, but far from delivery. We will read the .project/.project files and convert them. First target is towards CMake! That said, it is probably not realistic this year.

[Southbranch]

So far I tend to like the VS Code Extension a lot  :)

However, I can't make the full switch to use it until it supports TouchGFX, or the other way around, until TouchGFX is provided with an option to generate CMake and update the project code in the same way as it does for STM32CubeIDE with Make.

Any such plans?

[mattias norlander]

Request noted, you are not alone to ask, but too few request at this point to gain high priority.

Maybe you can create a separate post in TouchGFX forum section and ask for CMake, then encourage other developers to like your post to fight for prio. That would be my recommendation!
We are customer request driven, even though it may not always seem that way. :upside_down_face: