Extension provides its own toolchain (gcc, gdb, etc.) but does not configure paths

[mark03]

I am using the latest (pre-release, version 3.something) official extension, on Linux.

Creating a new empty project went fairly smoothly (see my other form post about missing CMSIS headers), but when I tried to build the project, cmake couldn't find the toolchain.

It turns out that cmake was trying to run "arm-none-eabi-gcc" and so on, assuming that they would be in the current PATH!  In fact, these executables are bundled with the extension and (on my Linux system) are located in

~/.local/share/stm32cube/bundles/gnu-tools-for-stm32/13.3.1+st.8/bin

No one (at least on Linux---not sure what Windows users do these days) is going to want to modify their system path to add a weird bin directory just for a single application.  The right way to tell cmake where to find the tools is to either modify *its* environment or give it full paths to each tool.  But the extension did not do this when it was installed---I think that is a bug because it is easy to automate.

Complicating matters further, there are several places that cmake can be told where the tools are, but it turns out some of them get overridden and hence don't work.  For example, google's AI suggests to add CMAKE_C_COMPILER with the full path in CMakeLists, but that didn't work.  I finally figured out that I needed to create a .vscode/settings.json file with the stanza

"cmake.environment": {
"PATH": "/home/mark/.local/share/stm32cube/bundles/gnu-tools-for-stm32/13.3.1+st.8/bin:${env:PATH}"
},

(Interestingly, after I made the file, the extension added a bunch more stuff to it, but it didn't get created as part of the install.)

Again, it seems like this would be trivial for the extension to do automatically as part of the installation, since it knows exactly where the toolchain is located.

Thanks,

Mark

[Cartu38 OpenDev]

Hopefully on my side toolchain & co are set Thanks STM32 extensions.

Have you some metadata added to the project ? Sounds the way the stuff is supported.

If not having them ? maybe setup project is helpful ?

[mark03]

My bundles.store.json looks like this:

{
  "bundles": [
    {
      "name": "st-arm-clangd",
      "version": "^19.1.2+st.3"
    },
    {
      "name": "gnu-tools-for-stm32",
      "version": "^13.3.1+st.8"
    },
    {
      "name": "stlink-gdbserver",
      "version": "7.10.0+st.3"
    }
  ]
}

(I installed ninja using my OS package manager because the STM32 VSCode extension also couldn't find its own ninja installation.  There's probably a way to fix that too but I didn't pursue it because installing my own ninja was an easier solution.  I also have cmake already installed on my system.)

On my computer, "Setup STM32Cube project(s)" is shown but it is grayed out.  I'm not sure what that means.  I don't have STM32Cube stuff installed separately.  I only installed the STM32 VSCode extension and the system bundles shown above.  We're not supposed to install Cube outside of that process, are we?

In any case, I don't think any of this really relates to the reason I posted here.  You seem to be explaining ways to get things working.  I already have things working.  The point is that the path should be configured automatically, because the extension already knows exactly what the path is---it put the binaries there, after all.

[TDK]

The expected way to use VSCode for STM32 is to use STM32CubeMX to generate the project as a makefile project which you then open in VSCode.

https://community.st.com/t5/stm32-mcus/how-to-use-vs-code-with-stm32-microcontrollers/ta-p/742589

[mark03]

Much of that tutorial is out of date and incorrect for v3 of the extension.  For example, there is no STM32CubeCLT anymore (the extension brings its own toolchain as a "bundle").  And there is no longer any place in the extension settings to configure paths.

My impression is that the VSCode extension is trying to be self-sufficient.  Obviously you will run CubeMX for things like pin planning, and code generation if using HAL, but you are never prompted to run it when creating a blank project, at least in the latest prerelease (v3).

I guess it would help if there were updated documentation.  They are working on it, but it is very very sparse at the moment.