VS Code Workspace: AVR & STM32 Global/Project Settings

To set up a VS Code workspace for AVR and STM32 microcontrollers, start with a multi-root .code-workspace file that pulls in separate project folders—keeping things organized without clutter. Configure global settings in your user settings.json for shared toolchains like arm-none-eabi-gcc for STM32 and AVR GCC, plus extensions such as PlatformIO and Cortex-Debug to handle vscode stm32 and AVR builds universally. Then, drop project-specific .vscode folders into each project with tailored tasks.json, launch.json, and settings.json for per-microcontroller tweaks like defines, compiler paths, and debugging probes.

Contents

• What is a VS Code Workspace?
• Global Prerequisites: Toolchains and PATH
• Essential Extensions for AVR and STM32
• Global User Settings Configuration
• Creating a Multi-Root VS Code Workspace
• STM32 Project-Specific Setup
• AVR Project-Specific Setup
• Debugging Configurations Across Projects
• Best Practices and Troubleshooting
• Sources
• Conclusion

What is a VS Code Workspace?

Picture this: you’re juggling multiple microcontroller projects—say, an STM32F4 for motor control and an AVR ATmega328 for a simple sensor node. A VS Code workspace (specifically a .code-workspace file) lets you open them all at once in one window, with shared global settings for your toolchains and extensions, but isolated per-project configs. Why bother? It saves you from constantly switching folders or duplicating setups. No more “wait, where’s my arm toolchain path again?”

This approach shines for embedded work. Global stuff handles the heavy lifting (like where your compilers live), while each project’s .vscode folder overrides for specifics—like STM32 CubeMX defines or AVR fuse settings. It’s flexible, scalable, and keeps your sanity intact when scaling to teams.

Global Prerequisites: Toolchains and PATH

Before diving in, grab the essentials. For STM32, download the ARM GCC toolchain (arm-none-eabi-gcc) from the official Arm site—version 10.3 or later works great. On Windows, add it to your PATH via System Properties > Environment Variables. Linux/Mac users? brew install arm-none-eabi-gcc or apt equivalents.

AVR needs avr-gcc and avrdude. Grab the WinAVR toolchain or use sudo apt install gcc-avr avr-libc avrdude on Linux. Test it: open a terminal and run arm-none-eabi-gcc --version and avr-gcc --version. If they spit out versions, you’re golden.

Pro tip: Pin these paths globally. Why fight relative paths later?

Essential Extensions for AVR and STM32

Extensions make vscode stm32 and AVR development smooth. Hit Ctrl+Shift+X and search/install these:

• C/C++ (ms-vscode.cpptools): IntelliSense magic.
• Cortex-Debug (marus25.cortex-debug): GDB for ARM cores.
• CMake Tools (ms-vscode.cmake-tools): Build system bliss.
• PlatformIO IDE (platformio.platformio-ide): Handles vscode platformio for both AVR and STM32—frameworks, libraries, uploads out of the box.
• STM32 for VSCode (bmd.stm32-for-vscode): CubeMX integration and ST-Link flashing.

Reload VS Code after. These live globally, so every workspace inherits them. The STM32 VS Code Extension Pack bundles several nicely.

Global User Settings Configuration

Global settings apply everywhere—perfect for toolchains. Open them with Ctrl+Shift+P > “Preferences: Open User Settings (JSON)”.

Here’s a starter settings.json snippet:

{
 "C_Cpp.default.compilerPath": "/usr/bin/arm-none-eabi-gcc",
 "C_Cpp.default.includePath": [
 "${workspaceFolder}/**",
 "/path/to/STM32Cube_FW/**",
 "/usr/avr/include/**"
 ],
 "cmake.configureOnOpen": true,
 "cmake.generator": "Ninja",
 "stm32-for-vscode.toolchainPath": "/usr/bin/arm-none-eabi-gcc",
 "platformio.ide.deploy.auto": false
}

Tweak paths to match your system. This sets compiler discovery for both AVR and STM32 projects upfront. Stack Overflow examples confirm this baseline works across OSes.

Save, and watch IntelliSense light up in any folder.

Creating a Multi-Root VS Code Workspace

Time to glue it together. Create a file like microcontrollers.code-workspace anywhere (your home dir? A shared repo?).

{
 "folders": [
 {
 "name": "STM32-Motor-Control",
 "path": "./projects/stm32-motor"
 },
 {
 "name": "AVR-Sensor-Node",
 "path": "./projects/avr-sensor"
 }
 ],
 "settings": {
 "terminal.integrated.defaultProfile.windows": "Command Prompt"
 }
}

Double-click to open. Boom—multi-root workspace with tabs for each. Global settings kick in automatically; project .vscode overrides them. Medium tutorials swear by this for mixed AVR/STM32 setups.

STM32 Project-Specific Setup

Inside your STM32 project folder (e.g., from CubeMX with Makefile generator), create .vscode/ and add these files.

settings.json (overrides for this project):

{
 "C_Cpp.default.defines": [
 "STM32F407xx",
 "USE_HAL_DRIVER"
 ],
 "C_Cpp.default.compilerArgs": ["-mcpu=cortex-m4"]
}

tasks.json (build with make or CMake):

{
 "version": "2.0.0",
 "tasks": [
 {
 "label": "STM32 Build",
 "type": "shell",
 "command": "make",
 "group": "build",
 "problemMatcher": ["$gcc"]
 }
 ]
}

CubeMX tip: Set Toolchain/IDE to Makefile, copy libs into project. ST Community guide nails this flow—builds fly.

AVR Project-Specific Setup

For AVR, PlatformIO shines (or raw avr-gcc). If using PlatformIO, drop a platformio.ini:

[env:uno]
platform = atmelavr
board = uno
framework = arduino
upload_protocol = usbasp

Then .vscode/tasks.json:

{
 "version": "2.0.0",
 "tasks": [
 {
 "label": "AVR Upload",
 "type": "platformio",
 "command": "run",
 "args": ["upload"]
 }
 ]
}

Raw avrdude? "command": "avrdude -c usbasp -p m328p -U flash:w:${workspaceFolder}/project.hex". Keeps it project-locked—no global pollution.

Debugging Configurations Across Projects

Debugging’s where it gets fun. Per-project .vscode/launch.json:

For STM32 (JLink or ST-Link):

{
 "version": "0.2.0",
 "configurations": [
 {
 "name": "STM32 Debug",
 "type": "cortex-debug",
 "request": "launch",
 "servertype": "jlink",
 "device": "STM32F407VG",
 "armToolchainPath": "/usr/bin/arm-none-eabi-",
 "executable": "./build/project.elf"
 }
 ]
}

AVR? PlatformIO handles it, or gdb with sim. Hit F5. Arm Learning Paths and Gist examples provide the exact keys.

Best Practices and Troubleshooting

• Use ${workspaceFolder} in paths—adapts per project.
• Version control .vscode but .gitignore sensitive paths.
• STM32 not building? Check CubeMX libs copied. AVR flashing fails? Probe drivers (zadig for ST-Link).
• Slow IntelliSense? Add excludes in settings.json.
• Multi-root lag? Limit folders to 5-10.

Stuck? PlatformIO abstracts most pain. Test incrementally—global first, then projects.

Sources

1. How to use VS Code with STM32 microcontrollers - STMicroelectronics Community
2. How to configure Visual Studio Code to build and debug STM32 projects - Stack Overflow
3. VS Code Setup for STM32 ARM Development - Medium
4. STM32 development on Visual Studio Code - GitHub Gist
5. stm32-for-vscode - Visual Studio Marketplace
6. STM32 extensions for VS Code - Arm Learning Paths
7. Using VS Code for embedded stm32 development - Medium

Conclusion

A VS Code workspace with global AVR/STM32 settings streamlines your embedded workflow—toolchains once, projects forever customized. Start with the multi-root file, layer in extensions and user settings, then tweak per-project .vscode for builds and debug. You’ll debug faster, scale easier, and wonder how you lived without it. Grab those toolchains, fire up a test project, and iterate—happy coding!