Is anyone using the STM32 VS Code Extension?

[betocool]

Hey all,

I'd like to get your thoughts and experiences with this. I'm currently still using VS code to edit CubeMX projects and the CubeIDE just for flashing to the device. I haven't updated CubeIDE since version 1.14.0 and so far it still works well for me.

I'm tempted to jump onto the STM32 VS Code extension but other than a few YouTube videos I've yet to see compelling arguments to do the switch. On the other hand, I also work with NRF52 devices on VS Code and their SDK as recommended by them so it wouldn't be too dissimilar I guess? NRF52 is also based on CMake, but it forces one to use the complete Zephyr stuff as well as DTS which I'm not a big fan of.

Basically, "Is VS Code STM32 Extension a buggy piece of crap?" or not 

Cheers,

Alberto

[Hawaka]

My experience is as follow: I use STM32CubeIDE with a ST probe/debugger at work, and I think it’s pretty good. I says that because I have tried multiple IDE and most of them are worst than STM32CubeIDE.

For home project, I use the VSCode STM because that was the only way to make it work with a DAPLink debugger.
In the beginning it was painfull to set everything up and understand how cmake works. The editor experience is ok, the debugging isn’t quite as good as STM32CubeIDE, but good enough for me (I cannot tell if it is because I use a non-ST probe or not).

I almost don’t use CubeMX, I configure most of the peripheral by hand and don’t really use the HAL function. Sometimes I generate a example project to see how something works, but that’s it.

To answer your question "Is VS Code STM32 Extension a buggy piece of crap?" I would say it is totally usable. Configuration at the start of a project is harder, but then it’s fine. You should use it for a week then decide, best way to know.

[JPortici]

How responsive is ST to problems in the VSCode extensions?

Microchip has gone the same route with their own VSCode extensions, having to learn a bit of CMake and all that stuff.
It took several months since the first betas became available, but to me it seems it's pretty usable at this point and can do about 98% of what MPLABX does (of course i still have a couple of specific things that won't let me migrate *all* project, just most, and some of the debugging tools and controls are simply not there because VSCode doesn't implement them) and that's just because after a bit they decided to listen to the users in the forum, and that helped improving the quality and solving bugs very fast.

[Hawaka]

I cannot say how responsive ST is. There is an update about once a month, but frankly I haven't seen an improvement.

I use the cortex-Debug extension, which is not from ST. I wish a would know more about extension to be able to fix some stuff myself.

[mark03]

How responsive is ST to problems in the VSCode extensions?

They were willing to engage with me on their discussion forums when I reported bugs with the extension.  I think it's a high priority for them right now.

I never used the old Cube IDE, nor any of the automatic code generation, HAL, or LL libraries.  My guess is that the VS Code extension makes a better experience on Linux, because ST is responsible for less of the total footprint, reducing unnecessary bloat (there's still plenty).  I'm reasonably satisfied with it after some start-up headaches.  The debugging experience is not great, e.g. the fault status registers are conveniently shown but there is no way to look at the fault *address* registers without adding a watch for *(0xe000e...).  Peripheral registers are shown but updates are super slow.  There's no way to reset the target while debugging, without reflashing your code too.  (I may actually hit the flash endurance limit on the H7 Nucleo board I'm prototyping with.)  Starting debug seems to get a little bit slower with each invocation, until once a week or so when I close VS Code and kill off orphan processes.  Text doesn't intelligently use the full width of the sidebar, forcing me to expand it wider than I should have to, in order to read the register contents.

For all of that, it's still VS Code, and still better than Eclipse, if you can hold your nose and not think about the fact that we've traded Java for Javascript and Electron    Shockingly, it seems a change for the better.

Honestly, I just want a nice project template for my chosen processor with all the CMSIS files and nothing else.  When I told them that they seemed puzzled.  Conclusion: if you really want simplicity, invest the time in a nice Makefile setup and use vim and gdb.  Failing that, I have found this to be a reasonable compromise     OTOH if you're stuck with the HAL and generated driver code, don't sweat it, because it doesn't matter so much which toolset you use; you'll still be debugging in the dark, the Microsoft way---trying a succession of potential fixes until something "works".  I see the new extension as more of a win for people who want their code to make sense.

[sal0ne]

Although you asked about VS Code, I prefer Jetbrains IDE's and CLion is now free for non commercial use and integrates with STM32.

https://www.jetbrains.com/help/clion/embedded-stm32.html

[krho]

CMake is abomination... There are better build systems (e.g Meson). And most big projects are moving to them.. the corpo always start using things when others move on.
Regarding VSCode extension.. I have mixed feelings.. e.g the Eclipse is ...

[JPortici]

They were willing to engage with me on their discussion forums when I reported bugs with the extension.  I think it's a high priority for them right now.

Good, it's always good when the actual developers have freedom to communicate with us users, shit gets fixed much more quickly as they get to know much more quickly

For all of that, it's still VS Code, and still better than Eclipse, if you can hold your nose and not think about the fact that we've traded Java for Javascript and Electron    Shockingly, it seems a change for the better.

Same experience with microchip. I never understood why corpos can't write java, yet are the ones that push it the most. One random guy reverse engineered the protocol communication for 4th gen tools, and with a python script, of all things, managed to achieve near ideal programming speed on a PICKIT4, when on the official tools 10 seconds of spinning wheel at every operation..
And in VSCode programming is fast, debugging is responsive, doesn't hang even 1% of the time than on MPLABX... though they say that the backend is still java, and it wants to allocate 2GB of RAM at launch because reasons (sigh)

[John Coloccia]

We use makefiles to build, but use the STM tools to configure the HAL if we decide to use anything from the HAL at all. Also the STM IDE for debugging when we need it.

Honestly, I tried the STM VSCode extensions for a couple of days, and then just uninstalled them. To be really blunt, I've found every Eclipse, or eclipse-like, or related, or whatever environment to be abysmally bad, and I have no idea how it's even a thing, or got to be a thing. And I'd like to think the extensions are bad because they have to be compatible with something that is also, fundamentally, bad.

I don't know. I feel like I'm in the minority with this opinion, but I honestly I don't know anyone that ever has anything nice to say.

[lombster]

I like the extension. I used it extensively for a few weeks and didn't open CubeIDE once. Just CubeMX to create the project and CubeProgrammer to flash the binary.