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]

---

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

[LaloRiojas]

Yes although i belive that a converter would be the best solution to this issue right now i think the most important thing is for there to be a way such that i can still use .ioc files in the IDE to manage middleware and hardware initilization but still build the project with CMake. the previous version of the STM vscode extension provided a way to do that by creating the project as a regular CubeIDE project with the .ioc file configuration and then the VScode extension would add the Cmake build method and the vscode language settings for C. The main problem is that creating a project with Cmake on the Cube IDE does not generate a .ioc file and now the vscode exension does not take regular CubeIDE projects and forces you to create the cmake project in the CubeIDE.

Currently my company is starting a new project and we at are a bit of a stand still with this. Some engineers really want the ease of the .ioc files for hardware configuration, middleware management (mainly freertos) and code generation while others want to have Cmake so that they can use other editors such as vscode/clion/vim etc. Debugging is not to big of an issue since gdb is very common across all environments but we do understand that it is easiest on CubeIDE.

what would you recomend for a system we can all be happy with such that the build system is with Cmake but without sacrificing .ioc file code generation. 

[mattias norlander]

---

---

What you write is true. In the best of world's, CubeIDE would have relied on CMake instead of CDT managed projects already 6 years ago when first introduced. But at that point CMake was not that dominant. Consequently we built a full Cube ecosystem with examples based on .cproject/.project files (CDT managed)... And the MX integration inside IDE relies on producing the .cproject/.project format style...

We are considering ripping out the integration of MX and let users rely purely on MX and IDE as stand-alone tools. The only down-side is that customer would need to download and install 2 separate tools. But suddenly the user can use MX to product Makefile, CMake or old-schoold "CDT managed" projects for CubeIDE. And you can update MX and IDE separately as you want... But it is a big direction change. Feedback would be interesting!

---

@LaloRiojas wrote:

what would you recomend for a system we can all be happy with such that the build system is with Cmake but without sacrificing .ioc file code generation. 

---

To reply to your concrete question: My recommendation is that your team:

• Relies on using MX-stand-alone to generate CMake projects. Now you can have true IDE freedom in the team while still relying on MX ioc-file for configuration of HW/middleware.
• I would probably rely on using VS Code as the "primary IDE" for development..
• But still use CubeIDE as my "heavy-duty debugger" when *** hits the fan. Rely on the "elf-file importer in CubeIDE to enable this use case. Have a look at CubeIDE User Guide and the chapter: "Import STM32 Cortex®-M executable".
• The down-side of this approach is that if a developer (by accident) double-clicks the ioc-file from inside CubeIDE, then I believe that the MX integration in the IDE will revert back the property : 
  • ProjectManager.TargetToolchain=CMake        <-- Replaced by "STM32CubeIDE". Ooooops!!!!
  • To ensure that this does not happen by accident, you can go into CubeIDE > View > Preferences > General > Editors > File associations.
    • Select the ioc-file.
    • Remove the associated editor
    • Add an association to the stand-alone STM32CubeMX application.
  • The down-side of this approach is that the MX integration uses this "file association" as part of the proejct wizard. As a result it is no longer possible to create new projects from inside the IDE. Only by using stand-alone MX.

This is by no means perfect. But given that the constraints are understood, I would still say that this is going to give you the best flexibility. Yet another issue we could solve, and we would solve if we removed MX integration from IDE...

Sorry for the inconvenience. Let me know your thoughts! :)

[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 ((

[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

[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]

”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:

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

[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: