How do I create debug and release profiles for a project?

[KMill]

So I have an STM32 project in VSC and when I first set up this project and started debugging, I vaguely remember being asked by VSC to create a launch.json file.

Now it seems I can build a ‘debug’ session, and launch it, and debug with all the usual features like step-in, step-out, continue, and so on. But how do I now add a ‘release’ build, which strips debug info and allows me to program a device without debugging it?

 

[I am trying to be a good citizen and get along with STM32 for VSC, but so far it seems like i) A retrograde step ii)A mix of modern UI’s and very old looking Java (MX) and iii)You need a science degree in CMAKE to understand anything. ]

My launch.json looks like this:

{
    // Use IntelliSense to learn about possible attributes.
    // Hover to view descriptions of existing attributes.
    // For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
    "version": "0.2.0",
    "configurations": [

        {
            "type": "stlinkgdbtarget",
            "request": "launch",
            "name": "STM32Cube: Launch ST-Link GDB Server",
            "origin": "snippet",
            "cwd": "${workspaceFolder}",
            "preBuild": "${command:st-stm32-ide-debug-launch.build}",
            "runEntry": "main",
            "imagesAndSymbols": [
                {
                    "imageFileName": "${command:st-stm32-ide-debug-launch.get-projects-binary-from-context1}"
                }
            ]
        }
    ]
}

 

[Cartu38 OpenDev]

​@KMill 

Thanks this line 

"imageFileName": "${command:st-stm32-ide-debug-launch.get-projects-binary-from-context1}"

used binary (flashed one) at debug session launch time is dynamic.

It relies on your active project context. Active context is mastered by CMake Tools extension:

Elect the one you want to shoot for !

If you dislike this you can just hard code kind it:
 

 

[Cartu38 OpenDev]

​@KMill 

Since you're a "good citizen" here, I’d love it if you could elaborate on your points: "i) A retrograde step, ii) A mix of modern UIs and very old-looking Java (MX), and iii) You need a science degree in CMake to understand anything."

Whether or not I agree, all feedback matters. Explicit comments are the only way we can drive progress.

Feel free to share more—don't be shy!

[KMill]

The VSC is good editor, mayeb not as good as Xcode, but a pretty nice modern looking editor for code.

But then you have to jump to CUBE MX for device configuration. It has a UI very fiurmly stuck in the late 90’s early 2000’s. And it has to jump out to Java to do it. In fact on modern macOS machines when you launch Cube MX from within VSC the dock shows the app-name as “java”.

 

Project settings are a opague - you only know what you are doing if you know what you are doing. No UI to guide. And yes I hear you, UI’s aren’t everything and require tons of maintenance, but it’s quite a step back from project configuration pages in things like Xcode on mac. 

I call it a retrograde step because it feels like they jumped from CubeIDE to VSC in order to take advantage of the great editor and file handling, but everything else feels cludgy and bolt-on.  There’s no doubt that CubeIDE was past it’s time but at least everything was in one place and had a consistent look and feel.

[Cartu38 OpenDev]

​@KMill 

Thanks for sharing your extra thoughts—much appreciated! I might share some of your comments.

CubeMX is still Java-based, yes. ST is making a good move toward new technologies with MX2, but the complete STM32 portfolio isn't supported there yet.

 

I feel like VS Code has a more 'DIY' DNA, which might explain the lack of UI polish.

To all community fans, what are your thoughts on this? I'm interested to get extra feedback.