FAQs
cancel
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for 
Search instead for 
Did you mean: 

New STM32 VSCode extension V2.0.0 released

Nawres GHARBI
ST Employee

‎2024-04-03 06:07 AM

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

Labels:
23 REPLIES 23
mattias norlander
ST Employee

‎2024-04-04 02:46 AM - edited ‎2024-04-04 06:38 AM

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:

mattiasnorlander_0-1712223394274.png

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
Senior

‎2024-04-25 01:25 AM

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

0 Kudos
Nawres GHARBI
ST Employee
In response to ACapo.1

‎2024-04-25 01:27 AM


Hello @ACapo.1 , 

it will be supported in the coming releases

ACapo.1
Senior

‎2024-04-25 01:43 AM

Hi @Nawres GHARBI 

Super, thanks very much for the prompt reply.

Andy

0 Kudos
MM..1
Chief II

‎2024-05-11 03:33 AM

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.

0 Kudos
LaloRiojas
Associate

‎2024-05-24 05:05 PM

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

 

0 Kudos
Pavel A.
Evangelist III
In response to LaloRiojas

‎2024-05-25 02:44 PM - edited ‎2024-05-25 02:51 PM

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
Chief II

‎2024-05-26 03:03 AM

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

0 Kudos
mattias norlander
ST Employee
In response to LaloRiojas

‎2024-05-27 06:00 AM

Hi LaloRiojas,

I read your reply multiple times. Each time I make a new interpretation as to what you are really looking for :)
Consequently I am hesitant to reply. But hopefully @Pavel A. made the right interpretation and answered your question.

There is one remaining question:

@LaloRiojas wrote:

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

 

The standard ways for MCU tooling has been Eclipse + CDT managed projects for the last 10-15 years. STM32Cube ecosystem today is huge. with code generators and example projects. I may agree with you that the best thing would probably be if we could just "convert" all these assets to CMake. But that is not possible.

That said, we do intend to create a "project converter" tool allowing users to take a CubeIDE (.cproject/.project) and convert it into CMake to simplify the journey from CubeIDE to VS Code. But we must build the pyramid from the bottom and we have more pressing issues to address first.

Top