Zephyr RTOSの開発環境構築手順の解説を複数回にわたりお届けします。今回は2回目となります。
Zephyr RTOSは、マイコンを搭載した機器を動かすためのソフトウェア基盤です。例えば、掃除ロボット、ネットワークカメラ、ウェアラブル端末、スマートメーター、産業用センサーなどでは、内部のマイコンがセンサー情報を取得したり、モーターを制御したり、通信を行ったりしています。
Zephyr RTOSは、こうしたマイコン向け製品のソフトウェア開発を効率化するために利用されます。
前回のコラムでは、Zephyr RTOSの開発環境を構築するというテーマの元、ホストマシンのセットアップからZephyr RTOSの構築、書き込みまでを行いました。今回のコラムは、開発環境をWindowsネイティブからWindows + WSL2(Ubuntu)を使用して環境構築を行い、評価ボードを書き込んでみます。
1. この記事でわかること
この記事では、Windowsパソコン上にWSLを利用してZephyr RTOSの開発環境を構築する方法を紹介します。
Zephyr RTOSは、センサー、スマート家電、ウェアラブル機器、産業機器などの組み込み製品で利用できるオープンソースのRTOSです。
RTOSは「Real-Time Operating System」の略で、決められた時間内に処理を実行することを重視したOSです。スマートフォンやパソコン向けのOSとは異なり、センサー処理、通信、モーター制御などを、決められたタイミングで安定して実行する用途に向いています。
WSLは「Windows Subsystem for Linux」の略で、Windows上でLinux環境を利用するための機能です。Zephyrの開発ではLinux向けのツールやコマンドを使う場面が多いため、Windowsパソコンを利用している開発者でも、仮想マシンを用意せずにLinuxベースの開発環境を構築できます。
この記事でわかることは、Windowsを使っている技術者がLinux環境を別途用意せずにZephyrのサンプルアプリケーションをビルドするまでの流れを確認できます。
また、NXP社やSTMicroelectronics社のマイコンを使ったIoT製品開発において、Zephyrを検討する際のポイントも説明します。
製品とZephyrの関係は以下になります。
この記事から得られる成果は以下となります。 （クリックで展開します）
- Windows上にZephyr開発環境を構築できる
- WSLを利用するメリットと注意点が分かる
- Zephyrのサンプルをビルドできる
- NXP・STマイコンとの関係を理解できる
- 製品開発で検討すべき課題が分かる
- 技術サポートを依頼する際の相談内容が分かる
2. 全体の流れ
Zephyr RTOS開発環境を構築し、イメージファイルをビルドして評価ボードに書き込み、機能確認するまでの全体の流れは 以下の通りです。前回の記事ではWindowsネイティブの開発環境を構築しNXPの評価ボード(FRDM-IMX93)、STMicroelectronics社の評価ボード(NUCLEO-L476)、Seed社の評価ボード(XIAO nRF54L15)を使用しました。
手順① 事前準備をする： ホストマシンのセットアップ
手順② 開発環境を構築してみよう： Zephyr SDKで開発環境を構築
手順③ ビルドしてみよう： とりあえず「Hello world」をビルド
手順④ 書き込みをしてみよう：生成されたイメージをボードに書き込む
手順⑤ 開発環境を構築してみよう：Visual Studio Codeでビルド
手順⑥ 機能を確認してみよう：GPIOの制御など
前回のコラムではWindowsネイティブの開発環境で手順①～④までを紹介しました。本コラムでは、Windows + WSL(Ubuntu)の開発環境を構築し、別の評価ボードを含めた手順①～④ (「1.事前準備をする」、「開発環境を構築してみよう」、「3.ビルドをしてみよう」、「4.書き込みをしてみよう」)までを紹介し、手順⑤は次回以降のコラムで紹介します。
3. 開発環境の変更と今回用意するもの
Zephyr RTOS自体はWindowsネイティブ(Windowsのみ)でも動作しますが、Zephyr RTOSはLinux環境を第一ターゲットとして開発されているツール(west、cmake、DeviceTreeコンパイラ、Kconfigなど)が多く、Windowsネイティブ環境ではビルド速度やパス処理、Python依存関係で軽微なトラブルが発生しやすい状況です。
また、Zephyr SDKのバージョンも上がり、実際の開発現場や公式サンプル、OSSコミュニティはLinux環境を前提に説明されることが多いため、今回の記事からWindows + WSL(Ubuntu)を前提とした内容を記載します。
Windowsネイティブ vs Windows + WSL2 比較
| 項目 | Windowsのみ | Windows + WSL2(Ubuntu) |
|---|---|---|
| 初期構築 | △ | ○ |
| 公式手順との一致 | △ | ◎ |
| サンプル実行 | ○ | ◎ |
| westコマンド利用 | ○ | ◎ |
| Zephyr SDK利用 | ○ | ◎ |
| Git/Repo管理 | △ | ◎ |
| CI環境との一致 | × | ◎ |
| Matter(CHIP)対応 | × | ◎ |
| 実機書き込み/デバッグ | ◎ | △ |
| VS Code連携 | ○ | ◎ |
| トラブル情報の豊富さ | △ | ◎ |
| おすすめ度 |
★★☆☆☆ 実機書き込みメインで 軽い書き換えのみなら可 |
★★★★★ 今後の開発や機能拡張を 見据えるなら必須級 |
各項目の比較詳細は以下になります。 （クリックで展開します）
-
1. 初期構築
Windowsのみ：CMake, Python, Ninja, Git などのPATH設定や長パス制限（260文字制限）のレジストリ解除が必要で手数が多め。
Windows + WSL2(Ubuntu)：Ubuntu側で apt install を実行し、環境依存なくすんなり完了。
※ただしWSL2自体のセットアップが初回のみ必要。 -
2. 公式手順との一致
Windowsのみ：Windows用ガイドも用意されているが、パス区切り（\）やPowerShell固有の記法で読み替えが必要な場面がある。
Windows + WSL2(Ubuntu)：公式ドキュメントの基本（Linux向け）手順がそのまま100%使える。 -
3. サンプル実行
Windowsのみ：qemu_x86 や native_sim（PC上の仮想実行環境）の動作制限・不具合に遭遇しやすい。
Windows + WSL2(Ubuntu)：native_sim や QEMU エミュレータが高速かつ完全なPOSIX互換で問題なく動作する。 -
4. westコマンド利用
Windowsのみ：動作はするが、Windows特有のファイルロック問題やPython仮想環境のPATH・権限周りでエラーが起きやすい。
Windows + WSL2(Ubuntu)：Bash/Zsh上で何の問題もなくスムーズに動作。 -
5. Zephyr SDK利用
Windowsのみ：7-Zip解凍やWindows用インストーラを使う。動作はするが環境変数の反映にハマることがある。
Windows + WSL2(Ubuntu)：tar で展開し ./setup.sh を実行するだけ。CMake package registry登録も極めて安定。 -
6. Git/Repo管理
Windowsのみ：改行コード（CRLF vs LF）問題や、大文字小文字の区別（NTFSの仕様）に起因するビルドトラブルが稀に発生。
Windows + WSL2(Ubuntu)：完全なLinux環境のため、LF改行・大文字小文字問題が起きず、パーミッション管理（chmod）も正常動作。 -
7. CI環境との一致
Windowsのみ：GitHub ActionsやGitLab CIなど、一般的なCIランナー（大半がLinux）とコマンドやビルド挙動がズレやすい。
Windows + WSL2(Ubuntu)：ローカルのWSL2で通ったビルドコマンドがCI上（Linux Docker環境等）でも100%同じ挙動を示す。 -
8. Matter(CHIP)対応
Windowsのみ：Matter SDK（connectedhomeip）やGN/NinjaツールチェーンはWindows非対応、または極めて構築困難。
Windows + WSL2(Ubuntu)：Matter開発はLinux必須。WSL2環境であれば問題なくビルド・開発が可能。 -
9. 実機書き込み/デバッグ
Windowsのみ：簡単（USB機器を直接認識）。
Windows + WSL2(Ubuntu)：要設定（usbipd-winを使ったUSB転送が必要）。 -
10. VS Code連携
Windowsのみ：C/C++拡張機能で普通に使用可能。
Windows + WSL2(Ubuntu)：「WSL」拡張機能でネイティブ同様の操作感。 -
11. トラブル情報の豊富さ
Windowsのみ：「Windows特有のエラー」に関する情報量が少なく、自己解決のハードルが高い。
Windows + WSL2(Ubuntu)：全世界でZephyrコミュニティの大半がLinuxベースのため、Web検索でエラー解決しやすい。
3.1. WSLのメリットと制約
WSLのメリットと制約は以下になります。 （クリックで展開します）
- Windows上でLinuxコマンドを利用できる
- 仮想マシンより導入しやすい
- 開発環境を標準化しやすい
- USBデバイスやデバッガの扱いに注意が必要
- Windows側とWSL側のファイル連携に注意が必要
- 企業ネットワークやプロキシ環境では追加設定が必要になる場合がある
3.2. WSLに移行する際の唯一の注意点（ハードウェア接続）
Windows + WSL環境の懸念点は以下になります。 （クリックで展開します）
開発PCと評価ボードなどのマイコン実機(J-LinkやST-Link、USB-UARTシリアル変換器)などの物理デバイスの認識に注意が必要になります。
- 対応策: Windows側に usbipd-win というツールをインストールすることで、WindowsのUSBポートをWSL（Ubuntu）側にアタッチできます。
- 運用Tips: west build やコード編集・シミュレーションテストはすべてWSL2内で完結させ、書き込み（west flash）やOpenOCD/J-Linkデバッグの段階で usbipd を繋ぐ構成が一般的です。
4. 対応するハードウェアを知る
Zephyr RTOSは、複数のマイコンや開発ボードに対応しています。
NXP社やSTMicroelectronics社のマイコンを使った製品開発においても、Zephyr RTOSをソフトウェア基盤の候補として検討できます。
Zephyr SDKを使用してZephyr RTOSのビルドファイルを出力する方法は、Zephyr公式サイト「Getting Started Guide」で紹介されています。Zephyr RTOSをサポートしている対応アーキテクチャは以下の通りです。
Zephyrをサポートしている対応アーキテクチャ
| アーキテクチャ | 代表的なMCU | 主なメーカー | 主な用途・特徴 |
|---|---|---|---|
| ARM Cortex-M | STM32、 Kinetis/MCX、 nRF52/nRF53、 RA/RX | ST、 NXP、 Nordic、 Renesas | IoT、 組込み、 低消費電力 |
| ARM Cortex-A | i.MX、 RZ | NXP、 Renesas | 高性能MPU、 産業機器 |
| ARM Cortex-R | R-Car | Renesas | リアルタイム、 安全性重視 |
| RISC-V | HiFive、 ESP32-C3、 GD32V | SiFive、 Espressif、 GigaDevice | IoT、 組込み |
| x86 / x86-64 | Quark SE C1000 | Intel | テスト、 PCクラス開発環境 |
| ARC (Synopsys) | EM/HS | Synopsys | IoT、 DSP用途 |
| Xtensa | ESP32 | Espressif | IoT、 無線通信 |
| MIPS | － | － | 組込み用途 |
| その他 | RP2040 | Raspberry Pi | IoT、 教育用途 |
この記事では、STM32L476、i.MX93、nRF54L15を搭載した評価ボードでの環境構築方法を紹介します。
本記事で使用する評価ボード
| メーカー | MCU | 評価ボード名 |
|---|---|---|
| STマイクロエレクトロニクス | STM32L476 | NUCLEO-L476RG |
| NXPセミコンダクターズ | i.MX93 | FRDM-IMX93 |
| Nordic セミコンダクター | nRF54L15 | XIAO nRF54L15 |
- 参考URL：Getting Started Guide [外部リンク]
- 参考URL：Supported Boards and Shields [外部リンク]
- 参考URL：Hardware Support [外部リンク]
実際の製品開発では、マイコンの選定だけでなく、以下のような検討が必要です。 （クリックで展開します）
- 必要な処理性能
- RAM・Flash容量
- 通信機能
- 消費電力
- セキュリティ要件
- 開発期間
- 量産時の調達性
- 既存ソフトウェア資産との互換性
Zephyrは開発効率化に役立つ一方、製品化にはハードウェア、デバイスドライバ、通信、電源、デバッグ、量産工程などを含めた総合的な検討が必要です。
5．手順①：事前準備をする
ホストマシンのセットアップを行います。ホストマシンの必要要件は下記になります。
ホストマシン必要要件
| 項目 | 必要要件 |
|---|---|
| OS | Windows ※WSL2が動作するPCであること |
| HDD(空き容量) | 推奨10GB以上 |
| メモリ | 推奨8GB以上 |
| USB | USB2.0 or 3.0 を1つ以上搭載 ※ホストマシンと評価ボードを接続し、書き込みを行う用途として想定しています |
上記の要件を満たせばホストマシンとして問題ありません。ただし、HDD容量はZephyr SDKで数GBを必要としています。また、WSL(Ubuntu)を立ち上げ、ビルドを行うと中間ファイルや生成ファイルを含めると、かなりのHDD容量を使用します。
また、開発環境を実行するには、インターネット接続が必要です。会社環境で使用する場合、Firewallの中からインターネット接続するためにProxy等の設定が必要になる場合があります。所属会社のIT部門へのご相談をお願いします。
Windows+WSLの構成は以下のようになります。
今回使用した開発環境は下記になります。
開発環境
| 項目 | 内容 |
|---|---|
| ホストOS | Windows 11 Pro |
| WSL | WSL 2 |
| Linuxディストリビューション | Ubuntu 26.04 |
| Zephyr | 4.0.0 |
| Zephyr SDK | 1.0.1 |
| Python | 3.14.4 |
| CMake | 4.2.3 |
| シリアルコンソール |
Windows：Teraterm Ubuntu：picocom |
5.1. 開発環境に必要なソフトウェア・ツールのインストール
Windows PCでZephyr開発環境を構築するには以下のソフトウェア、ツールが必要です。ソフトウェアとツールは最新版をインストールします。
必要なソフトウェア、ツール
| ソフトウェア、ツール | 説明 | 今回使用したバージョン |
|---|---|---|
| WSL (WSL2) | Windows上で Linux を仮想的に動かすことができるシステム環境 | 2.7.12.0 |
| Ubuntu | Linuxディストリビューションの一つ | 26.04.1 |
| Python | WestコマンドなどZephyrツールが動くために必要 3.12以上が必要 | 3.14.4 |
| Git | Zephyrのソースを取得するために必要 | 2.53.0 |
| CMake | ビルド設定ツール 3.28.0以上が必要（必須です） | 4.2.3 |
| Ninja | 高速ビルドシステム 必要なバージョンの明記はありません | 1.13.2 |
| Zephyr SDK | Zephyr公式のビルド環境 | 1.0.1 |
| usbipd-win | WindowsのUSBポートをWSL2（Ubuntu）側にアタッチする | 5.3.0 |
5.2. Windows
5.2.1. WSL2のインストール
Windows PowerShell を検索し、右クリックして「管理者として実行」を選択します。
「wsl --install」を入力して、WSL2のインストールを行います。インストールが完了したら、再起動を行い、「wsl -v」でバージョンが表示されることを確認します。下記は例となります。
wsl –install
wsl -v
WSL バージョン: 2.7.12.0
カーネル バージョン: 6.18.33.2-2
WSLg バージョン: 1.0.73.2
MSRDC バージョン: 1.2.7214
Direct3D バージョン: 1.611.1-81528511
DXCore バージョン: 10.0.26100.1-240331-1435.ge-release
Windows バージョン: 10.0.26200.91685.2.2. Ubuntuのインストール
Windows PowerShell内で「wsl --install -d Ubuntu」を入力してUbuntuのインストールをします。インストール後、Ubuntuの初期設定(ユーザー名、パスワード等)後、再起動を行います。
wsl --install -d Ubuntu
wsl --shutdown5.3. Ubuntu
5.3.1. 依存パッケージのインストール
ここからWSL(Ubuntu)のターミナル上で入力を行います。
パッケージリストを更新した上で、Zephyrのビルドに必要なツールをインストールします。
sudo apt update
sudo apt upgrade
sudo apt install --no-install-recommends \
git cmake g++ python3-dev python3-pip python3-venv \
ninja-build gperf dfu-util device-tree-compiler wget \
python3-tk xz-utils file make gcc-multilib g++-multilib libsdl2-dev libmagic1「python3 --version」でバージョンが3.8以上表示されることを確認します。下記は例となります。
python3 --version
Python 3.14.4「git -–version」でバージョンが表示されることを確認します。下記は例となります。
git --version
git version 2.53.0「cmake -–version」でバージョンが表示されることを確認します。下記は例となります。
cmake --version
cmake version 4.2.3「ninja -–version」でバージョンが表示されることを確認します。下記は例となります。
ninja --version
1.13.25.3.2. westのインストール
pipを最新化してから、westをインストールします。
pip install --upgrade pip --break-system-packages
pip install west --break-system-packages「pip -–version」でバージョンが表示されることを確認します。下記は例となります。
pip --version
pip 26.2.1 from /home/nexty/.local/lib/python3.14/site-packages/pip (python 3.14)PATHに ~/.local/bin を追加して、westコマンドが使用できるようにします。
echo 'export PATH="$HOME/.local/bin:$PATH"' >> ~/.bashrc
source ~/.bashrc「west -–version」でバージョンが表示されることを確認します。下記は例となります。
west --version
West version: v1.5.0ここまでの手順が事前準備となります。
6．手順②：開発環境を構築してみよう
WSLでZephyrプロジェクトのセットアップを行います。
6.1. Zephyrソースコードの取得とワークスペースの初期化
指定した場所にワークスペースの初期化を行います。
cd ~
west init zephyrprojectコマンドの内容を下記に記載します。
| コマンド | 内容 |
|---|---|
| west init <path> |
1. マニフェストリポジトリの取得 通常は「zephyrproject-rtos/zephyr」のGitリポジトリをクローンします このリポジトリは「west.yml」というマニフェストファイルがあります。Zephyr本体や依存する各種モジュール(HAL、ツール、サンプルコード)などの情報が含まれます 「west.yml」の詳細については本記事では取り扱いません 2. ワークスペース構造の準備 「west init」の時点ではZephyr本体以外のモジュール取得はしません 依存モジュールは次の「west update」で行います |
6.2. 依存モジュールの取得
west initで準備したワークスペースに依存モジュールを取得・更新を行います。
cd zephyrproject
west updateコマンドの内容を下記に記載します。
| コマンド | 内容 |
|---|---|
| west update |
1. マニフェストファイル (west.yml) の読み込み \zephyrリポジトリ内にある「west.yml」を参照します このファイルには Zephyr が依存する各モジュール(HAL、ドライバ、ツール、サンプルなど)のGitリポジトリ情報が記載されています 2. 依存モジュールの取得・更新 「west.yml」に記載された各リポジトリをクローン又は更新をします 例:(modules/hal/nxp、modules/hal/stm32、modules/lib/cmsis)などを取得します 3. ワークスペースの同期 すでに取得済みのモジュールがあれば「git fetch」「git checkout」を行い、マニフェストで指定されたバージョン(SHAやタグ)に合わせます これにより、Zephyr本体と依存モジュールのバージョンが常に整合性を保ちます |
また、Pythonの依存パッケージ（Zephyr本体が必要とするもの）をインストールします。
pip install -r zephyr/scripts/requirements.txt --break-system-packagesd zephyrprojectここで、Successfully installed ... と表示されれば、必要なパッケージのインストール自体は正常に完了しています。
途中で表示されている ERROR: pip's dependency resolver does not currently take into account all the packages that are installed... というメッセージは、システム側の既存パッケージ（pyopenssl など）の要求バージョンと、今回インストールされた cryptography のバージョンに若干のズレがあるという警告（コンフリクト通知）です。今回のZephyrの開発ビルドにおいては、この警告が原因でビルドが失敗することは基本的にありません。
そのため、このまま次のZephyr SDKのセットアップおよびビルドのステップへ進んで問題ありません。
ERROR: pip's dependency resolver does not currently take into account all the packages that are installed. This behaviour is the source of the following dependency conflicts.
pyopenssl 25.3.0 requires cryptography<47,>=45.0.7, but you have cryptography 49.0.0 which is incompatible.
Successfully installed Pillow-12.3.0 PyGithub-2.10.0 anytree-2.13.0 appdirs-1.4.4 argparse_addons-0.12.0 arrow-1.4.0 asn1crypto-1.5.1 ast-serialize-0.11.0 astroid-4.0.4 beartype-0.22.9 bincopy-20.1.1 bitarray-3.11.0 bitstring-4.4.0 boolean.py-5.0 canopen-2.4.1 capstone-5.0.9 cbor-1.0.0 cffi-2.1.1 charset_normalizer-3.5.1 clang-format-23.1.0 click-command-tree-1.2.0 click-option-group-0.5.9 cmsis-pack-manager-0.6.0 colorlog-6.12.0 coverage-7.16.0 crcmod-1.7 cryptography-49.0.0 deepmerge-2.1.0 dill-0.4.1 fastjsonschema-2.22.2 filelock-3.32.6 gcovr-8.6 gitdb-4.0.12 gitlint-core-0.19.1 gitpython-3.1.62 graphviz-0.21 halo-0.0.31 hexdump-3.3 hidapi-0.15.0 html5rdf-1.2.1 humanfriendly-10.0 importlib_metadata-8.9.0 importlib_resources-7.1.0 iniconfig-2.3.0 intelhex-2.3.0 intervaltree-3.2.1 isort-9.0.1 jsonschema-4.26.0 junit2html-31.1.4 junitparser-5.0.3 lark-1.3.1 librt-0.15.0 libusb-package-1.0.30.0 libusbsio-2.2.1 libuuu-1.5.243 license-expression-30.4.4 log_symbols-0.0.14 lpc_checksum-3.0.0 lxml-6.1.3 mccabe-0.7.0 mypy-2.3.1 mypy_extensions-1.1.0 narwhals-2.26.0 natsort-8.4.0 numpy-2.5.3 opencv-python-5.0.0.93 oscrypto-1.3.0 owlrl-7.6.2 pathspec-1.1.1 patool-4.1.0 platformdirs-4.11.8 plotly-7.0.0 pluggy-1.6.0 ply-3.11 polib-1.2.0 prettytable-3.18.0 psutil-7.2.2 pycparser-3.0 pyelftools-0.33 pylink-square-1.7.0 pylint-4.0.8 pynacl-1.6.2 pyocd-0.45.1 pyshacl-0.40.1 pytest-9.1.1 python-can-4.6.1 python-debian-1.1.1 python-dotenv-1.2.3 python-magic-0.4.27 pyusb-1.3.1 rdflib-7.6.0 regex-2026.9.3 requests-2.34.2 reuse-6.2.0 ruamel.yaml.clib-0.2.14 ruff-0.14.2 semantic_version-2.10.0 semver-3.0.4 setuptools_scm-9.2.2 sh-2.4.0 sly-0.5 smmap-5.0.3 sortedcontainers-2.4.0 spdx-python-model-0.0.6 spdx-tools-0.8.5 spdx3-validate-0.0.7 sphinx-lint-1.0.2 spinners-0.0.24 spsdk-3.11.0 spsdk-mcu-link-0.6.14 spsdk-pyocd-0.3.10 t61codec-1.0.1 tabulate-0.10.0 termcolor-3.3.0 tibs-0.5.7 tomlkit-0.15.1 tqdm-4.70.0 tree-sitter-0.25.2 tree-sitter-cmake-0.7.2.post1 tzdata-2026.3 unidiff-1.0.0 uritools-6.1.3 vermin-1.8.0 wasmtime-24.0.0 wcwidth-0.8.3 wrapt-1.17.3 x690-1.0.0.post1 xmltodict-1.0.4 yamllint-1.38.06.3. Zephyr SDK 1.0.1 のインストールとセットアップ
Zephyr SDKのアーカイブをダウンロードして展開を行います。ARMアーキテクチャのコンパイルには、GNUツールチェーンが含まれる gnu バンドル、またはすべて入ったものを使用します。ここでは標準的な gnu バンドルをホームディレクトリ（~）にダウンロードして展開します。
cd ~
wget https://github.com/zephyrproject-rtos/sdk-ng/releases/download/v1.0.1/zephyr-sdk-1.0.1_linux-x86_64_gnu.tar.xz
tar xvf zephyr-sdk-1.0.1_linux-x86_64_gnu.tar.xz展開されたディレクトリに移動し、セットアップスクリプトを実行します。これにより、CMakeパッケージレジストリへの登録やツールチェーンのパス設定が行われます。
cd zephyr-sdk-1.0.1
./setup.shセットアップの途中でtoolchain等のインストールの問い合わせがありますが、すべてインストールしておきます。
Install GNU toolchain [y/n]? y
Install LLVM toolchain [y/n]? y
Install host tools [y/n]? y
Register Zephyr SDK CMake package [y/n]? y
Create symbolic links for old Zephyr bisectability [y/n]? y
~~~~~略~~~~~~
Creating links for old Zephyr bisectability ...
All done.
Press any key to exit ...6.4. udevのインストール
ホストマシンとベンダーのボードをUSB接続する場合、各ベンダーから提供されているUSBドライバやデバッグプログラマをWSLから認識させやすくするために、udevルールを適用しておきます。
sudo cp ~/zephyr-sdk-1.0.1/hosttools/sysroots/x86_64-pokysdk-linux/usr/share/openocd/contrib/60-openocd.rules /etc/udev/rules.d/
sudo udevadm control --reload7．手順③：ビルドしてみよう
前項で構築した開発環境でビルド(west build)してみます。
対象のボードはNUCLEO-L476RG、FRDM-IMX93、XIAO nRF54L15ですが、最初にNUCLEO-L476RGをビルドしてみます。
7.1. サンプルプロジェクトへ移動
サンプルプロジェクトの「Hello World」をビルドしてみます。サンプルプロジェクトに移動します。
cd ~/zephyrproject7.2. ビルドを実行します
west build -p always -b nucleo_l476rg zephyr/samples/hello_worldビルドが成功するとイメージファイル build/zephyr/zephyr.elfを生成します。
コマンドの内容を下記に記載します。
| コマンド | 内容 |
|---|---|
| west build -b <board> |
1. CMakeのラッパー ZephyrはCMakeベースのビルドシステムを使っています 「west build」はCMake を直接叩く代わりに、Zephyr向けに最適化されたラッパーとして動作します 2. ビルドディレクトリの管理 「west build -b <board>」を実行すると、指定したボード用にビルドディレクトリを作成します デフォルトでは「/build」ディレクトリが生成され、そこにビルド成果物(ELF, HEX, BINなど)を出力します 3. ボードやアプリケーションの指定 「-b」オプションでターゲットボードを指定します ソースディレクトリを指定しない場合はカレントディレクトリをアプリケーションとして扱います 本記事ではソースディレクトリを指定していませんので、カレントディレクトリにビルドをしています 4. インクリメンタルビルド 既存のビルドディレクトリがある場合、差分のみ再ビルドします。そのため、ビルド時間は短くなります。 「west build -p always」を使うとクリーンビルド(再生成)を強制できます。 |
ビルドが終わった状態で再度ビルドを行おうとすると下記のメッセージが表示される場合があります。
ninja: no work to do.これは既にビルドが終了しているというメッセージですが、何らかの理由で再ビルドを行いたい場合があると思います。その場合、強制ビルドを行います。
「-p always」をつけてビルドを行います。
west build -p always -b nucleo_l476rg8．手順④：書き込みをしてみよう
前項でビルドを行い、イメージファイルを作成しました。本項では実際にボードを使用して書き込みを行います。ホストマシンとボードを接続します。ここでは、USBで接続をしています。
WSLからWindows側に接続されたUSBデバイス（NUCLEOのST-LINK）を直接操作するには、usbipd-win などのツールを使用して、Windows側からWSLへUSBデバイスをアタッチ(パススルー)しておく必要があります。
8.1. usbipd-winのインストール
WindowsのPowerShell(管理者権限)でusbipdのインストールを行います。
winget install --interactive --exact dorssel.usbipd-winコマンドの内容を下記に記載します。
| コマンド | 内容 |
|---|---|
| winget install --interactive --exact <package> |
Windows パッケージ マネージャー（WinGet）を使用してアプリケーションを対話型モードかつ完全一致でインストールするためのコマンドです。 --interactive インストーラーを対話型モードで実行します。ユーザーの入力を求める画面やインストーラー自体のUIが表示されます。 --exact 指定したパッケージ名やIDの完全一致を要求します。大文字と小文字も区別されます。 <package> dorssel.usbipd-winをインストールします。 |
会社ネットワークの状況等でインストールできない場合は、最新のインストーラーをダウンロードし、インストールを行います。
8.2. デバイスをWSLにアタッチ
WindowsのPowerShell(管理者権限)で接続されているUSBデバイスのバスIDを確認します。
usbipd listコマンドの内容を下記に記載します。
| コマンド | 内容 |
|---|---|
| usbipd list |
Windowsホストに接続されているUSBデバイスの一覧と、共有（Share）や接続（Attach）の状態を表示します。 表示される主な項目 BUSID: デバイスを識別する番号（例: `2-1`） VID:PID: ベンダーIDとプロダクトID DEVICE: デバイスの名称 STATE: 状態（`Not shared`、`Shared`、`Attached` など） |
ここで、対象ボードのバスIDを確認します。(ここでは1-1となります)
Connected:
BUSID VID:PID DEVICE STATE
1-1 0483:374b ST-Link Debug, USB 大容量記憶装置, STMicroelectronics STL... Not shared
5-1 058f:6387 USB 大容量記憶装置 Not shared
5-3 25a7:fa61 USB 入力デバイス Not shared
5-4 10d7:b012 Generic Bluetooth Adapter Not shared対象のバスIDを指定してWSLにバインドとアタッチをします。
usbipd bind --busid 1-1
usbipd attach --wsl --busid 1-1
usbipd list コマンドの内容を下記に記載します。
| コマンド | 内容 |
|---|---|
| usbipd bind --busid <バスID> |
WindowsホストからWSLへUSBデバイスを共有(バインド)するために、設定するコマンドとなります <バスID> BUSIDを指定します |
| usbipd attach --wsl --busid <バスID> |
WindowsホストからWSLへUSBデバイスを制御できるようになります <バスID> BUSIDを指定します |
ここで、対象ボードのバスID(ここでは1-1)が「Attached」であることを確認します。
Connected:
BUSID VID:PID DEVICE STATE
1-1 0483:374b ST-Link Debug, USB 大容量記憶装置, STMicroelectronics STL... Attached
5-1 058f:6387 USB 大容量記憶装置 Not shared
5-3 25a7:fa61 USB 入力デバイス Not shared
5-4 10d7:b012 Generic Bluetooth Adapter Not shared8.3. usbutilsのインストール
WSL側から書き込みを行うので、usbutilsを行い、WSL側から評価ボードが認識できることを確認します。
sudo apt update && sudo apt install -y usbutils
lsusbここで、STMicroelectronics ST-LINK/V2.1が認識できました。
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 002: ID 0483:374b STMicroelectronics ST-LINK/V2.1
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub8.4. NUCLEO-L476RGへ書き込みを実行
USBデバイスが正しくWSLに認識されたら、WSL側から書き込みを行います。
cd ~/zephyrproject
west flash --runner openocd8.5. NUCLEO-L476RGの動作確認
書き込みが完了したら、動作確認を行います。この時の確認方法はWindows側で確認する方法とWSL側で確認する方法があります。
Windows側で確認する場合は、PowerShell(管理者権限)でWSL側へのアタッチを解除(detach)します。
usbipd detach --busid 1-1コマンド入力後、Tera Term等でCOMポート(STMicroelectronics STLink Virtual COM Portなど)を開き、ボードのリセットボタンを押します。
WSL側で確認する場合は、接続されているシリアルデバイスを確認(通常は/dev/ttyACM0 など)し、シリアル通信ツールをインストールして接続します。
ls -l /dev/ttyACM*
sudo picocom -b 115200 /dev/ttyACM0コマンド入力後、ボードのリセットボタンを押します。
下記のようなメッセージの出力を確認します。
*** Booting Zephyr OS build v4.4.0-14708-g042104ba7e2d ***
Hello World! nucleo_l476rg/stm32l476xx無事、NUCLEO-L476RGでZephyrの起動が確認できました。
8.6. XIAO nRF54L15へ書き込みを実行
これまでの開発環境の構築でZephyr開発環境は出来ていますので、NUCLEO-L476RG と同じ流れでビルド及び書き込みができます。ただし、XIAO nRF54L15はマルチコア構成(M33 + RISC-V)ですので、ビルドを行う際にボード名の指定を行う必要があります。
cd ~/zephyrproject/zephyr
west build -p always -b xiao_nrf54l15/nrf54l15/cpuapp samples/hello_worldデバイスをWSLにアタッチします。
usbipd list
usbipd bind --busid 1-1
usbipd attach --wsl --busid 1-1
usbipd listWSL側から評価ボードが認識できることを確認します。
lsusbここで、Seeed Studio XIAO nrf54 CMSIS-DAPが認識できました。
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 003: ID 2886:0066 Seeed Technology Co., Ltd. Seeed Studio XIAO nrf54 CMSIS-DAP
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hubXIAO nRF54L15 は SAMD11 CMSIS-DAP を内蔵していますので、そのまま書き込みます。
west flash8.7. XIAO nRF54L15の動作確認
書き込みが完了したら、WindowsまたはWSL側でボーレート 115200 で接続し、ボードのリセットボタンを押します。
下記のようなメッセージの出力を確認します。
*** Booting Zephyr OS build v4.4.0-14708-g042104ba7e2d ***
Hello World! xiao_nrf54l15/nrf54l15/cpuapp無事、XIAO nRF54L15でZephyrの起動が確認できました。
8.8. FRDM-IMX93へ書き込みを実行
同様にFRDM-IMX93にビルド及び書き込みを行います。FRDM-IMX93はマルチコア構成(M33 + A55)ですので、ビルドを行う際にボード名の指定を行う必要があります。また、今回はM33コアでビルドを行います。
cd ~/zephyrproject/zephyr
west build -p always -b imx93_evk/mimx9352/m33 samples/hello_worldCortex-M33のビルドを行い、既にFRDM-IMX93のeMMCにインストールされているLinux (U-Boot)からZephyrを起動します。U-BootはA55コアで動作しますので、A55コアからM33コアでZephyrを動作させることになります。SDカードにビルドをしたzephyr.binを入れ、ホストマシンとFRDM-IMX93を接続します。
FRDM-IMX93のeMMC内にLinuxが無い場合は、NXPの公式サイトからLinux BSPをダウンロードしてSDカードに展開し、zephyr.binを同じフォルダに入れておきます。
8.9. FRDM-IMX93の動作確認
書き込みが完了したら、WindowsまたはWSL側でボーレート 115200 で接続します。このボードはA55コア出力とM33コア出力の2つあり、シリアルポートも２つ接続しておきます。
A55コアのU-Boot起動時に以下のコマンドでZephyrを動作させる例です。
setenv loadaddr 0x80400000
load mmc 1:1 ${loadaddr} zephyr.bin
cp.b ${loadaddr} 0x201e0000 ${filesize}
bootaux 0x1ffe0000コマンドの内容を下記に記載します。
| コマンド | 内容 |
|---|---|
| setenv <variable> <address> |
<variable> 環境変数を設定します <address> 0x80400000 はメモリ上のロード先アドレス 以降のコマンドで ${loadaddr} と書くと、このアドレスが参照されます |
| load <device> <address> <filename> |
<device> MMC（SDカードやeMMC）からファイルをロードします mmc 1:1 → デバイス番号1のパーティション1を指定します <address> ${loadaddr} → 読み込んだ内容をRAMのアドレス 0x80400000 に配置します <filename> zephyr.bin → 読み込むファイル名 |
| cp.b <address> <address> <filesize> |
<cp.b> メモリコピーをバイト単位で行います <address> コピー元: ${loadaddr} (0x80400000) <address> コピー先: 0x201e0000 <filesize> サイズ: ${filesize}（直前のロードで自動的に設定されるファイルサイズ） → 読み込んだ zephyr.bin を別のメモリ領域に転送します |
| bootaux <address> |
U-Bootの特殊コマンドで、セカンダリCPU（Auxiliary core）を起動します <address> 引数 0x1ffe0000 は起動アドレス → メインCPU上のU-Bootから、別のコア（例えばCortex-Mコア）にファームウェアを渡して起動します。 |
M33コア側で下記のようなメッセージの出力を確認します。
*** Booting Zephyr OS build v4.4.0-14708-g042104ba7e2d ***
Hello World! frdm_imx93/mimx9352/m33無事、FRDM-IMX93でZephyrの起動が確認できました。
9．次回について
次回は、本記事で作成した開発環境をVisual Studio Codeで構築して、GPIOなどを動かしてみます。
10．おわりに
今回はZephyrの開発環境を構築する方法について解説しました。今回の記事では開発環境を構築し、Hello Worldをビルドして複数のボードでZephyrが動作しているところを確認してみました。
次回の記事では、開発環境をVisual Studio Codeに統合して、任意のコードを動かしてみます。また何かセンサー等を動作させ、実務に近づけた記事を作成予定です。
当社は、NXP社およびSTMicroelectronics社の製品を取り扱う代理店として、マイコンや周辺デバイスの選定だけでなく、開発環境の構築や技術検討も支援しています。
Zephyr RTOSを利用した組み込み開発では、ソフトウェアだけでなく、マイコン、センサー、通信IC、電源、デバッグ環境を含めたシステム全体の検討が必要です。
当社では、部品選定と技術課題を切り分けず、製品開発の初期段階からご相談いただけます。
また、ネクスティエレクトロニクス開発部隊では、STマイクロエレクトロニクス社やNXPセミコンダクターズ社の製品開発や技術サポートを行っていますので、お気軽にお問い合わせください。
11．お問い合わせ
Zephyr RTOSやNXP・STマイコンの開発でお困りではありませんか？
以下のようなご相談に対応しています。
- NXP社・STMicroelectronics社マイコンの選定
- Zephyr RTOSの導入可否検討
- Windows、WSL、Linux開発環境の構築
- 開発ボードでのサンプル動作確認
- センサーや通信デバイスの接続
- Device Tree、Kconfig、ドライバ設定
- ビルド、書き込み、デバッグのトラブル対応
- 試作から量産を見据えた構成検討
- 既存製品へのZephyr導入検討
「まだ製品仕様が決まっていない」「どのマイコンを選べばよいか分からない」といった段階でもご相談いただけます。
※1：Zephyr及びZephyrロゴはThe Linux Foundationの商標です。
