はい、承知いたしました。STM32開発環境にVS Codeを選ぶ理由と、その導入・設定方法について、詳細に解説する記事を約5000語で執筆します。
STM32開発環境にVS Codeを選ぶ理由と導入・設定方法
はじめに：STM32開発環境の現状とVS Codeの立ち位置
マイクロコントローラー開発の世界は、特定のメーカーが提供する統合開発環境（IDE）を利用するのが一般的です。STMicroelectronics社の提供するSTM32シリーズの場合、公式IDEであるSTM32CubeIDEが広く利用されています。STM32CubeIDEは、CubeMXによるピン設定やクロック設定、コード生成機能、コンパイラ、デバッガーなどが一つに統合されており、STM32開発を始める上で非常に強力で便利なツールです。
しかし、開発者の好みやプロジェクトの要件によっては、公式IDE以外の選択肢も考えられます。特に、軽量性、柔軟性、カスタマイズ性、そして他の開発作業（例えばPCアプリケーション開発やWeb開発など）との統一性といった点を重視する場合、Visual Studio Code（VS Code）が有力な候補となります。
VS Codeは、Microsoftが開発する無料のソースコードエディタですが、豊富な拡張機能によってIDE並みの機能を実現できます。本来、組み込み開発に特化したツールではありませんが、適切な拡張機能と外部ツールを組み合わせることで、STM32開発環境としても非常に快適に利用できます。
本記事では、なぜ多くの開発者がSTM32開発にVS Codeを選ぶのか、その理由を深掘りし、実際にVS CodeをSTM32開発環境として構築するための具体的な導入・設定方法について、詳細かつ網羅的に解説します。公式IDEであるSTM32CubeIDEとの違いにも触れながら、VS Codeベースの開発環境の魅力をお伝えします。
なぜSTM32開発にVS Codeを選ぶのか？
公式IDEがあるにも関わらず、なぜVS CodeをSTM32開発に利用する開発者が増えているのでしょうか。その主な理由を以下に挙げます。
-
軽量かつ高機能なエディタとしての優秀さ:
VS Codeは起動が速く、動作も非常に軽快です。大規模なプロジェクトでもサクサクとコードを編集できます。一方、コード補完（IntelliSense）、シンタックスハイライト、定義ジャンプ、リファレンス検索、コードフォーマットなど、開発効率を高めるためのエディタ機能は非常に充実しています。これらの基本性能の高さは、開発中のストレスを軽減し、生産性を向上させます。 -
豊富な拡張機能によるカスタマイズ性:
VS Codeの最大の強みは、膨大な数の拡張機能が公開されていることです。これにより、特定の言語やフレームワーク、ツールに対応したり、UIや操作性をカスタマイズしたりすることができます。STM32開発においても、C/C++の強力なサポート、組み込みデバッグ機能、MakefileやCMakeとの連携など、必要な機能を拡張機能として追加することで、専用IDEに匹敵、あるいはそれ以上の開発体験を得ることができます。 -
クロスプラットフォーム対応:
VS CodeはWindows、macOS、Linuxといった主要なOSに対応しています。これにより、開発者は使い慣れたOSで開発を進めることができます。また、チーム内で異なるOSを使っている場合でも、共通の開発環境を構築しやすいというメリットがあります。 -
優れた操作性と統一されたUI:
VS Codeは直感的で分かりやすいUIを備えています。キーバインドや設定も柔軟に変更可能で、開発者の好みに合わせた環境を構築できます。PCアプリケーションやWeb開発など、他の開発にもVS Codeを利用している場合、組み込み開発でも同じ環境を利用できるため、操作に迷うことがなく、開発ワークフローを統一できます。 -
強力なデバッグ機能（Cortex-Debug拡張機能）:
STM32のようなARM Cortex-M系のマイクロコントローラー開発において、VS CodeのCortex-Debug拡張機能は非常に強力です。標準的なブレークポイント、ステップ実行、変数ウォッチ、レジスタ表示、メモリダンプといった機能はもちろん、RTOSタスク情報の表示や、SWV (Serial Wire Viewer) を利用したprintfデバッグなど、組み込み開発特有の高度なデバッグ機能もサポートしています。様々なデバッグプローブ（ST-Link, J-Linkなど）やデバッグサーバー（OpenOCD, ST-Link GDB Serverなど）に対応している点も強みです。 -
オープンソースコミュニティの活発さ:
VS Code本体はもちろん、多くの拡張機能はオープンソースで開発されています。これにより、問題が発生した際にコミュニティの情報を参照したり、自ら貢献したりすることが可能です。情報が入手しやすく、困ったときに解決策を見つけやすい環境です。 -
他のツールとの連携:
VS Codeは特定のベンダーのツールセットに縛られません。STM32開発においては、STMicroelectronics純正のSTM32CubeMX（プロジェクト生成）、Arm GCC（コンパイラ）、MakefileやCMake（ビルドシステム）、OpenOCDやST-Link GDB Server（デバッグサーバー）、GDB（デバッガー）といった、組み込み開発で広く使われている様々なツールと連携して動作します。これにより、特定のツールに依存しない、より汎用的で柔軟な開発環境を構築できます。 -
コスト:
VS Code本体は無料です。多くの強力な拡張機能も無料で利用できます。必要な外部ツール（Arm GCC, OpenOCDなど）も、通常は無料またはオープンソースで入手可能です。これにより、開発環境にかかるコストを大幅に抑えることができます。
これらの理由から、VS Codeは特に以下のような開発者に向いています。
- 普段からVS Codeを愛用しており、開発環境を統一したい開発者。
- 軽量でサクサク動くエディタを好む開発者。
- 特定のベンダー製IDEに縛られず、自由なツール選択をしたい開発者。
- 高度なカスタマイズを行い、自分にとって最適な開発環境を構築したい開発者。
- コストを抑えたい個人開発者や学生。
もちろん、STM32CubeIDEのような公式IDEも多くのメリットがあります。特に、STM32CubeMXとのシームレスな連携や、STが提供するライブラリとの高い親和性は魅力的です。VS Codeを選ぶということは、これらのメリットと引き換えに、自分でツールを組み合わせ、設定を構築する必要があるという側面も理解しておく必要があります。しかし、一度環境を構築してしまえば、その後の開発効率と柔軟性において大きなメリットを享受できる可能性が高いのです。
VS Codeを使ったSTM32開発に必要な要素
VS CodeをSTM32開発環境として機能させるためには、VS Code本体に加えていくつかの外部ツールが必要になります。これらはSTM32CubeIDEのような統合環境では一つにまとまっていますが、VS Codeの場合はそれぞれを独立してインストールし、連携させる設定を行います。
必要な主な要素は以下の通りです。
- VS Code本体: 開発の中心となるコードエディタ。
- VS Code拡張機能:
- C/C++: C/C++言語のIntelliSense、コードナビゲーション、フォーマットなどを提供。Microsoft公式のものなど。
- Cortex-Debug: ARM Cortex-M/Rプロセッサ向けのGDBデバッグインターフェース。ブレークポイント、ステップ実行、変数ウォッチなどの機能を提供。
- ビルドツール連携:
- Makefile Tools: Makefileプロジェクトのビルド、タスク実行などをサポート。
- CMake Tools: CMakeプロジェクトの構成、ビルド、実行などをサポート。（MakefileまたはCMakeのどちらか、あるいは両方）
- その他: Git連携、TODOリスト管理、コードスニペット、ファイルアイコンなど、開発効率やUIを向上させるための様々な拡張機能。
- ツールチェーン (Compiler, Assembler, Linker):
- Arm GNU Toolchain (Arm GCC): STM32のようなARMプロセッサ向けのGCCベースのクロスコンパイラ。C/C++ソースコードをターゲットの機械語に変換し、実行可能なファームウェアイメージ（.elf, .hex, .binファイルなど）を生成します。無償で利用可能です。
- ビルドシステム:
- Make: Makefileを解釈してビルドプロセスを実行するツール。STM32CubeMXがデフォルトでMakefileベースのプロジェクトを生成するため、Makeが広く使われます。
- CMake: より複雑なプロジェクトやクロスプラットフォーム開発に適したビルドシステムジェネレータ。CMakeLists.txtからMakefileやNinjaビルドファイルなどを生成します。
- デバッガー:
- GNU Debugger (GDB): GCCツールチェーンに付属する標準的なデバッガー。Cortex-Debug拡張機能がGDBと連携してデバッグ機能を提供します。
- デバッグプローブ/サーバー:
- ST-Link: STM32 Nucleo/Discoveryボードに搭載されている、または単体で購入できるデバッグプローブ。ターゲットのSTM32チップとPCを接続します。
- OpenOCD (Open On-Chip Debugger): 様々なデバッグプローブ（ST-Link, J-Linkなど）とターゲットチップを仲介し、GDBと連携するオープンソースのデバッグサーバー。
- ST-Link GDB Server: STMicroelectronicsが提供する、ST-LinkとGDBを連携させるためのGDBサーバー。OpenOCDの代替として利用できます。
- STM32CubeMX:
ピン配置、クロック設定、周辺機能の設定、ミドルウェアの選択などをGUIで行い、C言語の初期化コードやMakefile/CMakeLists.txtなどのプロジェクトファイルを生成するツール。VS Codeでの開発においても、プロジェクトのひな形作成に非常に有用です。
これらの要素を一つずつ導入し、VS Code上で連携するように設定していくのが、VS CodeによるSTM32開発環境構築のプロセスとなります。
VS Codeを使ったSTM32開発環境の導入方法
ここでは、VS Code本体と必要な外部ツール、拡張機能のインストール手順を解説します。OSによってインストール方法が若干異なる場合があるため、Windows、macOS、Linuxそれぞれについて補足します。
1. VS Code本体のインストール
VS Codeの公式サイトから、お使いのOSに応じたインストーラーをダウンロードして実行してください。インストールオプションはデフォルトで問題ありません。
https://code.visualstudio.com/
2. VS Codeに必要な拡張機能のインストール
VS Codeを起動し、左側のアクティビティバーにある拡張機能アイコン（四角いアイコン）をクリックします。検索窓に拡張機能名を入力して検索し、「Install」ボタンをクリックしてインストールします。
- C/C++:
C/C++で検索。Microsoft提供のものをインストール。IntelliSense、デバッグサポートなどが含まれます。 - Cortex-Debug:
Cortex-Debugで検索。Marus Hochによって提供されているものをインストール。ARM Cortex-M/Rデバッグの中核となります。 - Makefile Tools:
Makefile Toolsで検索。Microsoft提供のものをインストール。Makefileプロジェクトのビルドやタスク実行に便利です。 - （CMakeを使う場合）CMake Tools:
CMake Toolsで検索。Microsoft提供のものをインストール。CMakeプロジェクトを扱う場合に必要です。 - その他:
Git Graph: Gitのコミット履歴を視覚的に表示。Todo Tree: ソースコード中のTODOコメントなどを一覧表示。Material Icon Themeなど: ファイルアイコンを見やすく変更。
これらの拡張機能は必須ではありませんが、開発効率や快適性を向上させます。
3. ツールチェーン (Arm GNU Toolchain) のインストール
Arm GCCは、開発ターゲットであるSTM32のアーキテクチャ（ARM Cortex-M）向けのコンパイラ、アセンブラ、リンカ、標準ライブラリ、デバッガー（GDB）などが含まれるツールセットです。
Arm Developerウェブサイトから、最新版の Arm GNU Toolchain をダウンロードします。
https://developer.arm.com/tools-and-software/open-source-software/developer-tools/gnu-toolchain/gnu-rm
「Downloads」セクションから、お使いのOSおよびアーキテクチャ（64-bitなど）に合ったgcc-arm-none-eabi-*-*-*-install.exe (Windows) またはアーカイブファイル (macOS/Linux) をダウンロードします。
- Windows: ダウンロードした
install.exeを実行し、指示に従ってインストールします。インストール先のパスを覚えておいてください（例:C:\Program Files (x86)\GNU Arm Embedded Toolchain\10.3-2021.10）。インストール後に、このインストールディレクトリ内のbinフォルダ（例:C:\Program Files (x86)\GNU Arm Embedded Toolchain\10.3-2021.10\bin）をシステムのPATH環境変数に追加することを強く推奨します。これにより、どのディレクトリからでもarm-none-eabi-gccなどのコマンドを実行できるようになります。PATHの設定方法はOSによって異なりますので、「Windows PATH 環境変数 設定」などで検索してください。 - macOS: ダウンロードした
.tar.bz2ファイルを解凍し、適当な場所に配置します（例:/Applications/ArmGNUEABIToolchain/). その後、シェルの設定ファイル（~/.bash_profile,~/.zshrcなど）に、解凍したディレクトリ内のbinフォルダへのパスを追記します。例:export PATH="/Applications/ArmGNUEABIToolchain/10.3-2021.10/bin:$PATH". 設定ファイルを再読み込みするか、ターミナルを再起動して変更を適用します。 - Linux: ダウンロードした
.tar.bz2ファイルを解凍し、適当な場所に配置します（例:/opt/ArmGNUEABIToolchain/). その後、シェルの設定ファイルにパスを追記します（macOSと同様）。あるいは、多くのLinuxディストリビューションではパッケージマネージャー（apt, dnf, pacmanなど）でArm GCCをインストールできますが、バージョンが古い場合があるため、公式サイトからダウンロードするのが確実です。
インストール後、ターミナル（またはコマンドプロンプト）を開き、arm-none-eabi-gcc --versionと入力して、正しくインストールされPATHが設定されているか確認してください。バージョン情報が表示されれば成功です。
4. ビルドツール (Make) のインストール
STM32CubeMXはデフォルトでMakefileベースのプロジェクトを生成するため、ビルドにはMakeツールが必要です。
- Windows: Windowsには標準でMakeコマンドはありません。MinGW-w64やMSYS2といった環境をインストールするか、Make単体のバイナリを入手する必要があります。
- MinGW-w64: https://mingw-w64.org/doku.php/download/mingw-builds などからインストーラーを入手・実行し、インストール時に
mingw32-makeを選択します。インストール後、MinGWのbinディレクトリをPATHに追加します。Makefile Tools拡張機能の設定で、makefile.makePathにmingw32-make.exeのパスを指定する必要があります。 - MSYS2: https://www.msys2.org/ からインストーラーを入手・実行し、MSYS2環境を構築します。MSYS2ターミナルを開き、
pacman -S makeコマンドでMakeをインストールします。VS CodeからMSYS2環境のMakeを呼び出すように設定します。 - Chocolatey: パッケージマネージャーChocolateyを使っている場合、
choco install makeでインストールできます。 - 公式Binaries: http://gnuwin32.sourceforge.net/packages/make.htm からバイナリを入手し、PATHに追加する方法もありますが、依存関係に注意が必要です。
一般的には、MinGW-w64かMSYS2を導入するのがおすすめです。本記事では、MinGW-w64をインストールし、mingw32-make.exeを使用することを想定して説明を進めます。Makefile Tools拡張機能の設定（後述）で、使用するMakeコマンドのパスを正しく指定してください。
- MinGW-w64: https://mingw-w64.org/doku.php/download/mingw-builds などからインストーラーを入手・実行し、インストール時に
- macOS: macOSにはXcode Command Line Toolsをインストールすることで標準で
makeコマンドが利用可能になります。xcode-select --installを実行してインストール済みか確認してください。 - Linux: ほとんどのLinuxディストリビューションには標準で
makeコマンドがインストールされています。もしインストールされていなければ、パッケージマネージャー（apt, dnfなど）を使ってインストールしてください。例:sudo apt update && sudo apt install make.
インストール後、ターミナル（またはコマンドプロンプト）でmake --version（Windowsの場合はmingw32-make --versionなど、インストールしたコマンド名）と入力して確認してください。
5. デバッグサーバー/ツールのインストール
デバッグには、ターゲットのSTM32チップと通信するためのデバッグサーバーが必要です。主にOpenOCDかST-Link GDB Serverを利用します。
- OpenOCD: 多くのデバッグプローブをサポートするオープンソースツールです。
- Windows: https://gnutoolchains.com/arm-embedded/openocd/ や https://github.com/openocd/openocd/releases などからWindows版バイナリを入手・解凍します。解凍したディレクトリ内の
binフォルダをPATHに追加すると便利です。または、デバッグ設定（launch.json）でOpenOCD実行ファイルのフルパスを指定します。USBドライバー（Zadigなどを使ってWinUSB/libusbドライバーに変更する場合あり）が必要になることもあります。 - macOS/Linux: パッケージマネージャーでインストールするのが一般的です。例:
brew install openocd(macOS, Homebrew),sudo apt install openocd(Linux, Debian/Ubuntu).
インストール後、ターミナルでopenocd --versionと入力して確認してください。
- Windows: https://gnutoolchains.com/arm-embedded/openocd/ や https://github.com/openocd/openocd/releases などからWindows版バイナリを入手・解凍します。解凍したディレクトリ内の
- ST-Link GDB Server: STMicroelectronicsが提供する、ST-Link専用のGDBサーバーです。OpenOCDよりも設定が簡単な場合があります。
- STMicroelectronicsの公式サイトから「STM32CubeProgrammer」をダウンロード・インストールします。CubeProgrammerにはST-Link GDB Serverが含まれています。
https://www.st.com/en/development-tools/stm32cubeprg.html - インストール時にST-Linkドライバーも一緒にインストールされます。
- インストール後、インストールディレクトリ内に
ST-LINK_gdbserver.exe(Windows) や実行ファイル (macOS/Linux) が含まれています。デバッグ設定（launch.json）で、このGDBサーバー実行ファイルのフルパスを指定します。
- STMicroelectronicsの公式サイトから「STM32CubeProgrammer」をダウンロード・インストールします。CubeProgrammerにはST-Link GDB Serverが含まれています。
どちらのデバッグサーバーを使用するかは好みに依ります。ST-Linkを主に使用する場合はST-Link GDB Serverも便利ですが、J-Linkなど他のプローブも使う可能性があるならOpenOCDの方が汎用的です。本記事では両方の設定例を示します。
6. STM32CubeMXのインストール
ピン設定や初期化コード生成のために、STM32CubeMXをインストールしておきます。
STMicroelectronicsの公式サイトからダウンロード・インストールします。Java Runtime Environment (JRE) が必要になる場合があります。
https://www.st.com/en/development-tools/stm32cubemx.html
インストール後、プロジェクトの生成方法については後述します。
これで、VS CodeをSTM32開発環境として利用するための基本的なツール群のインストールが完了しました。次に、VS Code上でこれらのツールを連携させるためのプロジェクト設定方法について解説します。
VS CodeでのSTM32プロジェクト設定方法
VS CodeでSTM32開発を行う際のプロジェクト設定は、主に以下の3つの設定ファイル（.vscodeディレクトリ以下に配置）を作成・編集することで行います。
c_cpp_properties.json: C/C++拡張機能（IntelliSense）のための設定ファイル。インクルードパス、マクロ定義、コンパイラパスなどを指定します。tasks.json: VS Codeのタスクランナー設定ファイル。ビルドコマンド（MakeやCMakeなど）の実行方法を定義します。launch.json: デバッグ設定ファイル。Cortex-Debug拡張機能と連携し、デバッガー（GDB）やデバッグサーバー（OpenOCD/ST-Link GDB Server）の設定を行います。
これらの設定を行う前に、まずはSTM32CubeMXを使ってプロジェクトのひな形を生成します。
1. STM32CubeMXでのプロジェクト生成
VS Codeでの開発には、MakefileまたはCMakeベースのプロジェクトが適しています。STM32CubeMXでは、これらのプロジェクト形式を生成する機能があります。
- STM32CubeMXを起動し、使用するSTM32チップまたは開発ボードを選択してプロジェクトを開始します。
- 必要なピン配置、クロック設定、周辺機能の設定を行います。
- 「Project Manager」タブに移動します。
- 「Project Name」と「Project Location」を設定します。
- 「Toolchain / IDE」のドロップダウンリストから、「Makefile」 または 「STM32CubeIDE」 を選択します。（STM32CubeIDEを選択した場合でも、生成されるプロジェクトはGCCコンパイラとMakefileベースであり、VS Codeで利用可能です）。CMakeを利用する場合は、「Other Toolchains (GPDSC)」を選択し、追加設定が必要です。（本記事ではMakefileベースを主に解説します）
- 「Generate Code」ボタンをクリックしてプロジェクトファイルを生成します。
生成されたプロジェクトディレクトリには、Core、Drivers、STM32CubeIDE (または MDK-ARM, EWARMなど、Toolchain設定によるが、GCC/Makefileベースの場合も同様の構造)、Makefile (または CMakeLists.txt)、.iocファイルなどが含まれています。VS Codeはこのディレクトリを開いて作業します。
2. VS Codeでプロジェクトを開く
生成されたプロジェクトディレクトリをVS Codeで開きます。
「File」→「Open Folder…」からプロジェクトディレクトリを選択します。
3. .vscodeディレクトリと設定ファイルの作成
プロジェクトディレクトリのルートに、.vscodeという名前の隠しディレクトリを作成します。
この.vscodeディレクトリ内に、以下の設定ファイルを作成します（ファイル名は正確に指定）。
.vscode/c_cpp_properties.json.vscode/tasks.json.vscode/launch.json.vscode/settings.json(必要に応じてワークスペース固有の設定を記述)
これらのファイルは、VS Codeをプロジェクトのディレクトリで開いたときに自動的に読み込まれます。
4. c_cpp_properties.jsonの設定
このファイルは、C/C++拡張機能がコード補完やエラーチェックを行うために必要な情報（インクルードパス、プリプロセッサ定義など）を指定します。
生成されたプロジェクトのインクルードパスは、チップやCubeMXの設定によって異なります。典型的な例を以下に示します。${workspaceFolder}はプロジェクトのルートディレクトリを示します。
json
{
"configurations": [
{
"name": "STM32",
"includePath": [
"${workspaceFolder}/Core/Inc",
"${workspaceFolder}/Drivers/STM32F4xx_HAL_Driver/Inc",
"${workspaceFolder}/Drivers/STM32F4xx_HAL_Driver/Inc/Legacy",
"${workspaceFolder}/Drivers/CMSIS/Device/ST/STM32F4xx/Include",
"${workspaceFolder}/Drivers/CMSIS/Include",
// CubeMXでFreeRTOSなどを有効にした場合はそのパスも追加
// "${workspaceFolder}/Middlewares/Third_Party/FreeRTOS/Source/include",
// "${workspaceFolder}/Middlewares/Third_Party/FreeRTOS/Source/CMSIS_RTOS",
// "${workspaceFolder}/Middlewares/Third_Party/FreeRTOS/Source/portable/GCC/ARM_CM4F" // 例：STM32F4, GCC, FPUありの場合
],
"defines": [
"USE_HAL_DRIVER",
"STM32F401xE", // 例: STM32F401シリーズの場合
// CubeMXで指定した他の定義も追加 (例: HSE_VALUE, HSI_VALUE, VECT_TAB_OFFSETなど)
],
"compilerPath": "arm-none-eabi-gcc", // PATHが通っていればこれでOK。通ってない場合はフルパスを指定。
"cStandard": "c11",
"cppStandard": "c++11",
"intelliSenseMode": "gcc-arm",
"compilerArgs": [
"-mcpu=cortex-m4", // 例: STM32F4シリーズの場合
"-mfpu=fpv4-sp-d16", // FPUありの場合
"-mfloat-abi=hard" // FPUありの場合
]
}
],
"version": 4
}
name: 設定の名前。任意ですが分かりやすい名前にします。includePath: ヘッダーファイルがあるディレクトリのパスをリストで指定します。プロジェクトの構造や使用するライブラリに応じて正確なパスを指定する必要があります。CubeMXが生成するMakefileを確認すると、コンパイルオプションとして指定されているインクルードパスが見つかりますので、それを参考にすると良いでしょう。defines: プリプロセッサ定義をリストで指定します。チップファミリー（例:STM32F401xE）や、HAL/LLドライバーを使用することを示す定義（USE_HAL_DRIVERやUSE_LL_DRIVER）、クロック源の値（HSE_VALUEなど）などが含まれます。これもMakefileを参考にします。compilerPath: 使用するC/C++コンパイラの実行ファイルパスを指定します。PATHが通っていればarm-none-eabi-gccと指定できます。通っていない場合はフルパスを指定します（例:"C:/Program Files (x86)/GNU Arm Embedded Toolchain/10.3-2021.10/bin/arm-none-eabi-gcc.exe"）。cStandard/cppStandard: 使用するC/C++の標準規格を指定します。intelliSenseMode: IntelliSenseエンジンのモードを指定します。ARM GCCを使っている場合はgcc-armが適切です。compilerArgs: コンパイラに渡す追加の引数を指定します。CPUアーキテクチャ (-mcpu) やFPU関連のオプション (-mfpu,-mfloat-abi) は重要です。これらもMakefileのコンパイルオプションを参考にします。
この設定を正しく行うことで、VS Code上でコード補完やエラーチェックが適切に機能し、開発効率が大幅に向上します。
5. tasks.jsonの設定
このファイルは、ビルドやクリーンなどのタスクをVS Codeから実行できるように定義します。ここでは、Makeコマンドを実行するタスクを定義します。
json
{
"version": "2.0.0",
"tasks": [
{
"label": "Build", // タスク名
"type": "shell",
"command": "make", // 実行するコマンド
"args": [
"-j" // Makeのオプション（例: 並列ビルド）
// DebugビルドやReleaseビルドを選択する場合、引数を追加することが可能
// "BUILD_TYPE=Debug" など、Makefileの変数で制御する場合
],
"options": {
"cwd": "${workspaceFolder}" // 実行ディレクトリ（プロジェクトルート）
},
"group": {
"kind": "build",
"isDefault": true // デフォルトのビルドタスクとする
},
"presentation": {
"reveal": "always", // 実行時にターミナルを表示
"panel": "new" // 新しいターミナルパネルで実行
},
"problemMatcher": "$gcc" // GCCのコンパイルエラーを解析してVS Codeの「問題」ビューに表示
},
{
"label": "Clean", // クリーンタスク
"type": "shell",
"command": "make",
"args": [
"clean" // Makeのcleanターゲットを実行
],
"options": {
"cwd": "${workspaceFolder}"
},
"group": "build",
"presentation": {
"reveal": "always",
"panel": "new"
}
}
]
}
label: タスクの名前。VS Codeのコマンドパレット（Ctrl+Shift+PまたはCmd+Shift+P）で「Run Task」を選択したときに表示されます。type:shellはシェルコマンドとして実行することを意味します。command: 実行するコマンドを指定します。Makefile Tools拡張機能をインストールしている場合、makeコマンドを指定すれば拡張機能がMakeのパスを自動的に解決しようとしますが、確実に実行するためにフルパスを指定することも可能です（例:"C:/msys64/usr/bin/make.exe"や、MinGWの場合は"mingw32-make"）。settings.jsonで"makefile.makePath"を設定している場合は、ここにmakeと記述すればその設定が優先されます。args: コマンドに渡す引数をリストで指定します。Makefileのターゲット名（cleanなど）やオプション（-jなど）を指定します。options.cwd: コマンドを実行するカレントディレクトリを指定します。${workspaceFolder}はプロジェクトルートです。group.kind: タスクの種別。buildとすることで、VS Codeのビルド関連コマンド（例:Ctrl+Shift+BまたはCmd+Shift+Bでデフォルトビルドタスク実行）の対象となります。group.isDefault:trueにすると、そのグループのデフォルトタスクになります。presentation: タスク実行時のターミナルの表示方法を設定します。problemMatcher: コンパイルエラーや警告の形式を指定し、VS Codeの「問題」ビューに一覧表示できるようにします。GCCを使っているので$gccを指定します。
この設定を行うことで、VS Codeのメニューやショートカットから簡単にビルドやクリーンを実行できるようになります。
6. launch.jsonの設定（デバッグ設定）
このファイルは、デバッグセッションを開始するための設定を定義します。Cortex-Debug拡張機能と連携し、デバッガー（GDB）、デバッグプローブ、デバッグサーバーなどを指定します。
デバッグサーバーとしてOpenOCDを使用する場合と、ST-Link GDB Serverを使用する場合の例を示します。
a) OpenOCDを使用する場合の例
json
{
"version": "0.2.0",
"configurations": [
{
"name": "Cortex Debug (OpenOCD)",
"type": "cortex-debug",
"request": "launch",
"program": "${workspaceFolder}/build/${workspaceFolderBasename}.elf", // ターゲットプログラムのパス (.elfファイル)
"executable": "${workspaceFolder}/build/${workspaceFolderBasename}.elf", // Cortex-Debug 1.5以降はこちら
"cwd": "${workspaceFolder}",
"svdFile": "${workspaceFolder}/Drivers/CMSIS/Device/ST/STM32F4xx/SVD/STM32F401.svd", // 使用するチップのSVDファイル
"toolchainPath": "arm-none-eabi-gcc", // GDBやObjdumpなどのツールチェーンパス
"device": "STM32F401RE", // 使用するチップ名（Cortex-Debugが表示で使用）
"debugServer": "OpenOCD",
"servertype": "openocd",
"serverpath": "openocd", // PATHが通っていればこれでOK。通ってない場合はフルパスを指定。
"configFiles": [ // OpenOCDの設定ファイル
"interface/stlink.cfg", // ST-Linkを使用する場合
"target/stm32f4x.cfg" // STM32F4シリーズを使用する場合
// チップやボードに合わせて適切なcfgファイルを指定
],
"searchDir": [ // OpenOCDがcfgファイルを検索するディレクトリ
"C:/openocd/share/openocd/scripts" // OpenOCDのscriptsディレクトリのパス
// macOS/Linuxの場合は /usr/local/share/openocd/scripts など
],
"runToEntryPoint": "main", // main関数から実行開始
"showDevDebugOutput": "none", // デバッグ出力表示レベル (none, full)
// Optional settings
"overrideLaunchCommands": [
"monitor reset halt", // デバッグ開始時にリセット＆停止
"monitor program \"${workspaceFolder}/build/${workspaceFolderBasename}.elf\" verify", // プログラムを書き込み＆ベリファイ
"monitor arm semihosting enable", // semihostingを有効にする場合
"tbreak main", // mainで一時ブレークポイント設定（runToEntryPointと併用しない）
"continue"
],
"overrideRestartCommands": [
"monitor reset halt",
"tbreak main",
"continue"
],
"postRestartCommands": [
"break main" // リスタート後にmain関数でブレーク
],
"postLaunchCommands": [ // デバッグ開始後に実行するGDBコマンド
"break main" // main関数でブレーク
],
"rtos": "FreeRTOS" // FreeRTOSを使用する場合（変数ビューにタスク情報などを表示可能）
}
]
}
name: デバッグ設定の名前。VS Codeのデバッグビューのドロップダウンリストに表示されます。type:"cortex-debug"を固定で指定します。request:"launch"（デバッグ開始時にプログラムを書き込み・実行）または"attach"（すでに実行中のプログラムにアタッチ）を指定します。通常は"launch"です。program/executable: ビルドして生成された実行可能な.elfファイルのパスを指定します。通常はbuildディレクトリ以下にプロジェクト名と同じ名前で生成されます。${workspaceFolderBasename}はプロジェクトディレクトリの名前です。cwd: デバッガーの作業ディレクトリ。通常はプロジェクトルート${workspaceFolder}です。svdFile: 使用するSTM32チップのSystem View Description (SVD) ファイルのパスを指定します。このファイルがあると、VS Codeの変数ビューでレジスタ情報を分かりやすく表示できます。SVDファイルはSTM32CubeMXが生成するCMSISパッケージに含まれています。正確なパスを指定してください。toolchainPath: Arm GCCツールチェーンのbinディレクトリのパス、またはarm-none-eabi-gccのパス。PATHが通っていれば"arm-none-eabi-gcc"でOKです。device: 使用するチップ名。SVDファイルやOpenOCD設定と一致させる必要はありませんが、Cortex-Debugが表示のために使用します。debugServer/servertype: 使用するデバッグサーバーの種類を指定します。OpenOCDの場合は"OpenOCD"/"openocd"です。serverpath: OpenOCD実行ファイルのパス。PATHが通っていれば"openocd"でOKです。通っていない場合はフルパスを指定します。configFiles: OpenOCDに読み込ませる設定ファイル（.cfgファイル）のパスをリストで指定します。通常は、使用するインターフェース（例:interface/stlink.cfg）とターゲットチップファミリー（例:target/stm32f4x.cfg）のファイルを指定します。これらのファイルはOpenOCDのインストールディレクトリ内のscriptsフォルダにあります。searchDir: OpenOCDがconfigFilesで指定された.cfgファイルを検索するディレクトリを指定します。OpenOCDのscriptsフォルダのパスを指定します。runToEntryPoint: デバッグ開始時に実行を停止させたいエントリーポイントを指定します。"main"を指定すると、main関数が始まる直前で停止します。overrideLaunchCommands: デバッグセッション開始時にGDBに渡すコマンドをリストで指定します。OpenOCDを介してターゲットをリセットしたり、プログラムを書き込んだり、Semihostingを有効にしたりするためのコマンドを指定します。これらのコマンドはmonitor <serverコマンド>のように、OpenOCDに送られます。プログラム書き込みコマンドは必須です。overrideRestartCommands: デバッグセッションを再起動する際に実行するコマンドです。postRestartCommands: デバッグセッションを再起動した後にGDBに渡すコマンドです。postLaunchCommands: デバッグセッション開始後にGDBに渡すコマンドです。よく使うのは、特定の関数でブレークポイントを設定するbreak <function>コマンドです。rtos: 使用しているRTOSを指定すると、Cortex-Debugがタスク情報などを取得・表示できます。例えばFreeRTOSなら"FreeRTOS"を指定します。
b) ST-Link GDB Serverを使用する場合の例
json
{
"version": "0.2.0",
"configurations": [
{
"name": "Cortex Debug (ST-Link GDB Server)",
"type": "cortex-debug",
"request": "launch",
"program": "${workspaceFolder}/build/${workspaceFolderBasename}.elf", // ターゲットプログラムのパス
"executable": "${workspaceFolder}/build/${workspaceFolderBasename}.elf", // Cortex-Debug 1.5以降はこちら
"cwd": "${workspaceFolder}",
"svdFile": "${workspaceFolder}/Drivers/CMSIS/Device/ST/STM32F4xx/SVD/STM32F401.svd", // SVDファイル
"toolchainPath": "arm-none-eabi-gcc", // GDBパス
"device": "STM32F401RE", // チップ名
"debugServer": "ST-Link", // ST-Link GDB Serverを使用することを示す（Cortex-Debugの内部識別子）
"servertype": "stlink", // ST-Link GDB Serverを使用することを示す
"serverpath": "C:/ST/STM32CubeProgrammer/bin/ST-LINK_gdbserver.exe", // ST-Link GDB Server実行ファイルのフルパス
"runToEntryPoint": "main",
"showDevDebugOutput": "none",
// Optional settings
"overrideLaunchCommands": [
// ST-Link GDB Serverは通常、起動オプションでプログラム書き込みなどを指定するため、
// ここには特別なコマンドは不要なことが多い
],
"overrideRestartCommands": [
"load", // プログラムを再ロード（書き込み）
"enable breakpoint",
"monitor reset", // ターゲットをリセット
"break main",
"continue"
],
"overrideRestartTarget": "reset", // リスタート時にターゲットをリセット
"postLaunchCommands": [
"break main"
],
"rtos": "FreeRTOS"
}
]
}
ST-Link GDB Serverを使用する場合、servertypeを"stlink"に設定し、serverpathにST-Link GDB Server実行ファイルのフルパスを指定します。OpenOCDのように個別の.cfgファイルを指定する必要はなく、設定は比較的シンプルになります。プログラムの書き込みやリセットなどの操作は、ST-Link GDB Serverの起動オプションや、Cortex-Debugが内部的に発行するGDBコマンド（load, monitor resetなど）によって行われます。
どちらの設定方法を選ぶかは、使用するデバッグプローブや好みに依存します。OpenOCDは汎用性が高い一方、ST-Link GDB ServerはST-Linkとの連携がシンプルです。
これらの設定ファイルを作成・編集することで、VS CodeでSTM32プロジェクトをビルドし、デバッグ実行できるようになります。
7. settings.jsonの設定 (ワークスペース固有の設定)
ワークスペース固有の設定を.vscode/settings.jsonに記述できます。これは必須ではありませんが、例えば特定の拡張機能の設定やエディタの挙動を、プロジェクトごとに変更したい場合に利用します。
json
{
"makefile.makePath": "mingw32-make", // WindowsでMinGWのmakeを使う場合など
"files.associations": {
"*.h": "c", // .hファイルをCとして扱う（C++プロジェクトの場合など）
"*.c": "c"
},
"C_Cpp.default.includePath": [], // ワークスペースで指定する場合、グローバル設定を上書きしないように空にすることが多い
"C_Cpp.default.defines": [],
"C_Cpp.default.compilerPath": ""
// その他、プロジェクト固有で変更したい設定があれば記述
}
makefile.makePath: Makefile Tools拡張機能で使用するMakeコマンドのパスを指定します。tasks.jsonのcommandでフルパスを指定する代わりにこちらで設定することも可能です。files.associations: 特定の拡張子のファイルを指定した言語として扱わせる設定です。C_Cpp.default.*: C/C++拡張機能のデフォルト設定。.vscode/c_cpp_properties.jsonで設定を記述している場合は、これらのデフォルト設定を上書きしないように空にしておくことが推奨されます。
8. ビルドの実行
tasks.jsonでビルドタスクを設定したら、VS Codeからビルドを実行できます。
- コマンドパレットから:
Ctrl+Shift+PまたはCmd+Shift+Pを開き、「Run Task」と入力して選択します。定義したタスクのリストが表示されるので、「Build」を選択します。 - ビルドショートカットから:
Ctrl+Shift+BまたはCmd+Shift+Bを押します。tasks.jsonで"isDefault": trueに設定したビルドタスクが実行されます。
ビルドの進行状況はVS Codeのターミナルパネルに表示されます。エラーや警告があれば、「問題」ビューに一覧表示され、クリックすると該当箇所にジャンプできます。
9. デバッグの実行
launch.jsonでデバッグ設定をしたら、VS Codeからデバッグを開始できます。
- デバッグビューから: 左側のアクティビティバーにあるデバッグアイコン（虫のようなアイコン）をクリックしてデバッグビューを開きます。上部のドロップダウンリストから、実行したいデバッグ設定（
launch.jsonで定義したname）を選択します。緑色の再生ボタンをクリックすると、デバッグセッションが開始されます。 F5キー: デバッグビューで選択されている設定でデバッグを開始します。
デバッグセッションが開始されると、GDBサーバーが起動し、ターゲットに接続、プログラムが書き込まれ、指定したブレークポイントやrunToEntryPointで実行が停止します。VS Codeのデバッグビューでは、変数、ウォッチ式、コールスタック、レジスタ、周辺機能レジスタなどを確認できます。ブレークポイントの設定、ステップ実行（ステップオーバー、ステップイン、ステップアウト）、コンティニューなどが可能です。
CMakeを使った開発について
STM32CubeMXは、CMakeベースのプロジェクトを生成することも可能です（「Other Toolchains (GPDSC)」を選択し、追加設定が必要）。CMakeは、より柔軟でクロスプラットフォームなビルドシステムを構築したい場合に適しています。
CMakeTools拡張機能 (ms-vscode.cmake-tools) をインストールすると、VS Code上でCMakeプロジェクトを簡単に構成、ビルド、デバッグできるようになります。
- STM32CubeMXでCMakeプロジェクトを生成: 「Toolchain / IDE」で「Other Toolchains (GPDSC)」を選択し、必要な設定を行います。生成されたプロジェクトには
CMakeLists.txtファイルが含まれます。 - VS Codeでプロジェクトを開く: 生成されたプロジェクトディレクトリをVS Codeで開きます。
- CMakeToolsの設定: 初回起動時またはCMakeLists.txtを開いた際に、CMakeTools拡張機能がプロジェクトを検出して構成を促します。コンパイラとしてArm GNU Toolchain（Arm GCC）を選択します。
settings.jsonでcmake.buildDirectoryなどを設定すると、ビルド生成物をどこに置くかなどを制御できます。 - ビルド: VS Codeステータスバーに表示されるビルドボタンをクリックするか、コマンドパレットから「CMake: Build」を実行します。
- デバッグ: デバッグ設定(
launch.json)は、基本的にMakefileの場合と同様です。programやexecutableのパスは、CMakeのビルドディレクトリ（通常はbuildやcmake-build-debugなど）内の.elfファイルを指定します。
CMakeを使用する場合、ビルドタスク(tasks.json)はCMakeTools拡張機能が提供する機能を利用するため、自分でMakeタスクを記述する必要はなくなります。より高機能なビルドワークフローを構築できますが、CMake自体の学習コストはMakefileより高いかもしれません。
高度な設定やカスタマイズ
VS Codeを使ったSTM32開発環境は、さらに様々なカスタマイズや機能追加が可能です。
- 複数ターゲットの管理: 同じプロジェクト内でDebugビルドとReleaseビルドなど、複数のビルド設定を切り替えたい場合、MakefileやCMakeLists.txtで設定し、
tasks.jsonのargsやproblemMatcherを調整したり、複数のビルドタスクを定義したりします。デバッグ設定も、Debug/Releaseビルドで異なる.elfファイルを指定するなどで複数の構成を定義できます。 - スニペット: よく使うコードパターン（GPIO初期化、タイマー設定など）をスニペットとして登録しておくと、入力の手間を省けます。
- キーバインド: よく使うコマンドに独自のショートカットキーを割り当てることができます。
- Git連携: VS Codeには標準でGitとの強力な連携機能があります。ソースコードのバージョン管理が容易に行えます。Git Graphなどの拡張機能で履歴表示を視覚化することも便利です。
- コードフォーマッター/リンター:
clang-formatやcpplintなどのツールと連携させることで、コードのスタイル統一や静的解析を行うことができます。C/C++拡張機能の設定や、Code Formatter拡張機能などを利用します。
これらの機能を活用することで、より効率的かつ快適な開発環境を構築できます。
VS Codeを使った開発のメリット・デメリットのまとめ
改めて、VS CodeをSTM32開発に利用する際のメリットとデメリットをまとめます。
メリット:
- 軽量・高速: 起動が速く、動作が軽快。
- 高機能なエディタ: 優れたコード補完、ナビゲーション、編集機能。
- 豊富な拡張機能: C/C++サポート、強力なデバッグ機能、ビルドツール連携など、必要な機能を自由に追加。
- 高いカスタマイズ性: UI、キーバインド、設定などを柔軟に変更可能。
- クロスプラットフォーム: Windows, macOS, Linuxに対応。
- 統一された開発体験: 他の開発（Web, PCアプリなど）と環境を統一できる。
- オープンソースと活発なコミュニティ: 情報が得やすく、問題解決が容易。
- コスト効率: VS Code本体と多くのツールが無料。
- 柔軟なツール連携: ベンダーに縛られず、好みのコンパイラ、ビルドシステム、デバッガーを組み合わせ可能。
デメリット:
- 環境構築の手間: 公式IDEのように全てが統合されているわけではなく、各ツールを個別にインストールし、VS Codeで連携させる設定を手作業で行う必要がある。特に初心者にはハードルとなる可能性がある。
- 公式サポート: STMicroelectronicsの公式サポートはSTM32CubeIDEが中心。VS Codeに関する直接的なサポートは期待できない（ただし、Cortex-Debugなどの拡張機能はコミュニティや開発者がサポートを提供）。
- STM32CubeMXとのシームレスな連携は限定的: STM32CubeMXでプロジェクト生成や設定変更を行った際、手動でVS Codeの設定ファイル（
c_cpp_properties.jsonなど）を更新する必要が生じる場合がある（生成されるMakefileやコンパイルログを見て手動でパスなどをコピーする必要がある）。 - デバッグ機能のセットアップ: Cortex-Debug拡張機能は強力ですが、OpenOCDやST-Link GDB Serverなどの外部デバッグサーバーのインストールと設定が必須であり、この部分のトラブルシューティングが必要になる場合がある。
これらのメリット・デメリットを踏まえ、ご自身の開発スタイルや経験レベルに合った環境を選択することが重要です。環境構築の手間を厭わず、より自由でカスタマイズ性の高い開発環境を求める開発者にとって、VS Codeは非常に魅力的な選択肢となるでしょう。
他の開発環境との比較 (STM32CubeIDE)
STM32CubeIDEは、STMicroelectronicsがEclipseベースで提供する公式の統合開発環境です。VS Codeと比較すると、以下のような特徴があります。
- 統合性: STM32CubeMXの機能（ピン設定、クロック設定、コード生成）がIDE内に統合されており、非常にシームレスに連携します。設定変更後のコード生成やビルドが容易です。
- STM32に特化: STM32シリーズの開発に特化しており、関連するツールやライブラリ（HAL/LLドライバー、ミドルウェアなど）との連携がスムーズです。
- 公式サポート: STMicroelectronicsによる公式サポートが受けられます。
- 初心者向け: 全てがパッケージングされているため、組み込み開発初心者でも比較的簡単に開発を始められます。
- Eclipseベース: Eclipseを使い慣れている開発者には馴染みやすいですが、VS Codeに比べて起動や動作がやや重いと感じる場合があります。
- 柔軟性: VS Codeに比べて、使用するツールや設定の自由度は限定的です。
VS Codeは、個別のツールを組み合わせて柔軟な環境を構築するスタイルであり、STM32CubeIDEは、STが提供する統合された環境を利用するスタイルと言えます。どちらが優れているというわけではなく、開発者の経験、プロジェクトの要件、個人の好みに応じて最適な方を選択すべきです。
VS Codeは、既に他の用途でVS Codeを使い慣れており、開発環境を統一したい開発者や、より軽量でカスタマイズ性の高い環境を求める開発者に特に適しています。
まとめ
本記事では、STM32開発環境としてVisual Studio Codeを選ぶ理由から、その導入、そして最も重要な設定方法について、詳細に解説しました。
VS Codeは、軽量で高機能なコードエディタとしてだけでなく、C/C++、Cortex-Debugといった強力な拡張機能と、Arm GNU Toolchain、Make/CMake、OpenOCD/ST-Link GDB Serverといった外部ツールを組み合わせることで、STM32開発においても非常に快適で柔軟性の高い開発環境を構築できます。
環境構築には、公式IDEに比べてやや手間がかかる側面はありますが、一度構築してしまえば、その後の開発効率やカスタマイズの自由度において大きなメリットを享受できるでしょう。特に、c_cpp_properties.json、tasks.json、launch.jsonといった設定ファイルの記述がVS Codeでの組み込み開発の鍵となります。本記事で示した設定例を参考に、お使いのチップや環境に合わせて適切に設定を行うことで、VS CodeでのSTM32開発をスムーズに始められるはずです。
もちろん、STM32CubeIDEのような公式ツールも強力な選択肢であり、どちらの環境にも一長一短があります。ご自身の開発スタイルやプロジェクトのニーズに合わせて最適なツールを選択し、快適なSTM32開発ライフを送ってください。
VS Codeを使いこなすことで、STM32開発の可能性がさらに広がることを願っています。