Arduino Nano と MCP2515 CANコントローラ（+ TJA1050 CANトランシーバ）

サイト

Arduino Nano と MCP2515 を使用して CAN 通信の送受信を試す予定なのでメモ。

参考

Ubuntu Server 24.04 のインストールメモと systemd-networkd から NetworkManager への移行

Linux サイト

Ubuntu Server 24.04 をインストールした。インストール自体は通常の手順で問題なし。ただし内蔵 ／ 外付け（USBタイプ）の Wi-Fi がいずれもデフォルト状態では動作しなかったため以下の通り無線 LAN 関係の設定を変更したのでメモ。

前提

機材

  • CHUWI HeroBox J4125
  • Archer T3U Nano
    • 内蔵の無線 LAN だと速度が出ないという記事があったので追加

参考

[ ID] Interval Transfer Bandwidth
[ 4] 0.00-10.01 sec 24.6 MBytes 20.6 Mbits/sec sender
[ 4] 0.00-10.01 sec 24.6 MBytes 20.6 Mbits/sec receiver

手順

  • Ubuntu Server 24.04 をインストール
  • インストール過程で有線 LAN 、無線 LAN の設定も実施しておく。インストール後に設定済みの状態になる効果があるので便利
  • インストール過程で [X] Install OpenSSH server とチェックを入れる。
  • デフォルトでは systemd-networkd になるが NetworkManager に切り替える（後述）

Netplan、systemd-networkd、NetworkManager

Ubuntu Server 24.04 において Netplan、systemd-networkd、NetworkManager は階層的な関係にある。

Netplan はフロントエンドとしてユーザ向けの設定ツールとして機能し、実際にネットワークを制御するバックエンド（レンダラー）として systemd-networkd または NetworkManager が動作する。

  • Netplan
    • ユーザが /etc/netplan/*.yaml に記述した設定を読み込み、バックエンド用の設定ファイルを生成・適用する
      • 現状では systemd-networkd の設定は生成するが NetworkManager の設定は管理しない様子？している？不明。今回は Netplan に NetworkManager の設定は委ねないことにした。
  • systemd-networkd
    • Ubuntu Server のデフォルトで初期状態では Netplan + systemd-networkd の組み合わせで設定が施され動作する
  • NetworkManager
    • Ubuntu Desktop のデフォルトで Ubuntu Server では初期状態ではインストールされない。 Ubuntu Server でも後述の通りインストールして使用することが可能。

役割の比較

機能 役割
Netplan フロントエンド。設定の抽象化インターフェース
systemd-networkd バックエンド
NetworkManager バックエンド

なお同機材で Ubuntu Desktop をインストールしたり Ubuntu Server のインストール過程で Wi-Fi の動作状況を見るに Ubuntu Server のインストーラで動作しているのは NetworkManager のように思われる（推測）

本機材における Netplan + systemd-networkd の問題

Ubuntu Server のインストール過程においては正常に Wi-Fi が接続され通信ができたがインストール後には接続ができなかった。状況を確認すると設定済みであるがずっと「接続試行中」のままで接続完了に移行しなかった。ルータ側が WPA3 （2.4GHz / 5GHz 両方とも）であることに起因する模様。ただし systemd-networkd が WPA3 非対応という情報は見つけられなかったので本環境におけるルータと子機（デバイス、ドライバ？）の組み合わせでの問題と思われる。

いずれにしてもインストール過程では接続できていた（接続完了し、DHCPでIPアドレスが取得できていた）ことを考えると設定やドライバ次第では接続可能であることはわかっていた。

systemd-networkd から NetworkManager への切り替え手順

Netplan でバックエンドを変更

/etc/netplan/*.yaml の書き換え

network:
  version: 2
  renderer: NetworkManager

適用

sudo netplan apply

cloud-init のネットワーク管理を無効化（この手順は不要かもしれない）

cloud-init が Wi‑Fi 設定を上書きしないよう無効化する

sudo bash -c 'echo "network: {config: disabled}" > /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg'

NetworkManager の設定

NetworkManager を有効化

sudo apt install network-manager
sudo systemctl enable NetworkManager
sudo systemctl restart NetworkManager

Wi‑Fi のデバイスを NetworkManager 管理にする

sudo nmcli device set wlp1s0 managed yes
sudo nmcli device set wlx000011112222 managed yes

確認

nmcli device status

当該デバイスが unmanaged ではなく disconnected になっていれば正しく管理対象になっている。

設定や接続メモ

有線LAN（enp1s0）を DHCP に設定

無線が何らかの事情で不調になったときに有線LANからネットワークアクセスができるように、DHCPとして設定しておく。通常は使用しないが設定は施しておく。

NetworkManager で DHCP の接続プロファイルを作成

sudo nmcli connection add type ethernet ifname enp1s0 con-name enp1s0
sudo nmcli connection modify enp1s0 ipv4.method auto
sudo nmcli connection up enp1s0

2.4GHz と 5GHz を別デバイスに固定して接続

2.4GHz（例：wlp1s0）、5GHz（例：wlx000011112222）

sudo nmcli dev wifi connect "SSID_24G" password "PASSWORD" ifname wlp1s0
sudo nmcli dev wifi connect "SSID_5G" password "PASSWORD" ifname wlx000011112222

これでデバイスごとに別SSIDへ接続するプロファイルが作成される。

接続プロファイル名の確認方法。

nmcli connection show

ここで NAME と DEVICE の対応が確認できる。

例：

NAME        TYPE  DEVICE
SSID_24G    wifi  wlp1s0
SSID_5G     wifi  wlx000011112222
enp1s0      ethernet enp1s0

固定IPを設定（Wi‑Fi）

2.4GHz（wlp1s0）、5GHz（wlx000011112222）

sudo nmcli connection modify "SSID_24G" \
  ipv4.addresses 192.168.1.101/24 \
  ipv4.gateway "" \
  ipv4.dns "192.168.1.1" \
  ipv4.method manual
sudo nmcli connection modify "SSID_5G" \
  ipv4.addresses 192.168.1.102/24 \
  ipv4.gateway 192.168.1.1 \
  ipv4.dns "192.168.1.1" \
  ipv4.method manual

※ 予備扱いとして 2.4GHz の方の gateway は空にしておく

5GHz を優先するためのルートメトリクス設定

NetworkManager は route-metric が小さいほど優先となる。

2.4GHz（予備扱い）、5GHz（優先扱い）

sudo nmcli connection modify "SSID_24G" ipv4.route-metric 200
sudo nmcli connection modify "SSID_5G" ipv4.route-metric 50

設定反映

sudo nmcli connection down "SSID_5G"
sudo nmcli connection up "SSID_5G"

sudo nmcli connection down "SSID_24G"
sudo nmcli connection up "SSID_24G"

sudo nmcli connection down enp1s0
sudo nmcli connection up enp1s0

優先状態の確認方法

ip route

例：

default via 192.168.1.1 dev wlx000011112222 metric 50
default via 192.168.1.1 dev wlp1s0 metric 200

→ 数値が小さい方が優先である。

参考

VPS（Ubuntu 24.04）上に Docker および VS Code Dev Containers を用いた Vue 3 + Vite の開発環境を構築

Linux ツール

Vue 3 + Vite の開発環境を整えた。従来はローカルの Linux マシン上あるいはローカルの Windows Hyper-V 上の Linux で構築していた。

今回 VPS 上に構築したのでメモ。主にディスク（ストレージ） の扱いとポート開放の手順が異なる。

構成

  • VPS
  • Ubuntu 24.04 LTS
  • 他のパソコンから VSCode Dev Container でアクセス

手順

VPS の用意

  • spec としては 2コア/2GB RAM 以上が必要そう
  • Swapメモリを設けて 1コア / 1GB RAM でも動作はしている

インストール

  • Ubuntu 24.04 を普通に

Docker のインストールと設定

Docker CE をインストール

sudo なしで Docker を使う

sudo usermod -aG docker $USER

Docker Compose（v2）の確認

docker compose version

（必要に応じて）データ用のディスクの用意

  • Oracle Cloud Infrastructure (OCI) で docker でデータが多くなってもインスタンスが起動できるようにブートボリューム（Boot Volume ）とデータのためのブロックボリューム（Block Volume）を分けてみた
  • 手順としては OCI 上でブロックボリュームを作成 → インスタンスにアタッチ → 起動してUbuntu 24.04 側でマウントとなる。以下に手順をメモしておく。
    • パーティション作成
    • ext4 のファイルシステム作成
    • マウント、fstab に記載して次回以降も利かせる

Docker のデータディレクトリを ext4 に移動（必要に応じて）

下記は /mnt/bvol に mount した例

Docker を停止

sudo systemctl stop docker.socket
sudo systemctl stop docker

データ移動

sudo mv /var/lib/docker /mnt/bvol/docker

シンボリックリンク

sudo ln -s /mnt/bvol/docker /var/lib/docker

Docker 再起動

sudo systemctl start docker.socket
sudo systemctl start docker

ポート開放

Vite（Vueのビルドツール）では標準で 5173 と 4173 のポートを使用する。これらは npm run dev で 5173、npm run build → npm run preview で 4173 が使用される。

VPS では標準ではポート開放がされておらず、VPS側でコントロールパネル等からの設定（外部からのアクセス許可の設定）とOS内でのファイアウォール（iptables）の両方で設定が必要なケースが多い。

以下では Oracle Cloud Infrastructure (OCI) での設定である。

  • OCIのイングレスルール(Ingress Rule)を設定する
  • iptablesに追加する

手順としては下記。

  • [コンピュート] → [インスタンス] → [インスタンスを選択] → [適用されている仮想クラウド・ネットワーク を選択] → [「セキュリティ」のカテゴリから適用されているセキュリティ・リストを選択] → [「セキュリティ・リスト」のカテゴリからイングレス・ルール]
  • イングレス・ルールの「宛先ポート範囲」に5173 と 4173 のポートを追加
  • iptables に設定を追加
  • 下記
sudo iptables -I INPUT 5 -p tcp --dport 5173 -j ACCEPT
sudo iptables -I INPUT 5 -p tcp --dport 4173 -j ACCEPT

// 確認
sudo iptables -L

// 適用
sudo netfilter-persistent save
  • あるいは下記
sudo nano  /etc/iptables/rules.v4

// 以下を追加
-A INPUT -p tcp -m state --state NEW -m tcp --dport 5173 -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 4173 -j ACCEPT

// 適用
sudo bash -c "iptables-restore < /etc/iptables/rules.v4"

参考

グローバルIPアドレスをインスタンスに設定（任意）

アクセスのためには固定のグローバルIPアドレスあるいはホスト名（FQDN）があった方が便利である。

Oracle Cloud Infrastructure (OCI) では予約済パブリックIPをインスタンスに設定することができる。

手順としては下記。

  • [コンピュート] → [インスタンス] → [インスタンスを選択] → [「ネットワーキング」の「アタッチされたVNIC」のリストの当該行の右端の「…」から「詳細を表示」] → [「IP管理」の「IPv4アドレス」のリストの当該行の右端の「…」から「編集」を選択]
  • パブリックIPタイプとして以下が選択できる
    • パブリックIPがありません（割り当てない）
    • エフェメラル・パブリックIP（一時的）
    • 予約済パブリックIP（固定）
      • 既存の予約済IPアドレスの選択
      • 新規予約済IPアドレスの作成
  • エフェメラル・パブリックIPが設定されている状態から予約済パブリックIPに直接変更できない場合があるので、いったん「パブリックIPがありません」を選択してパブリックIPを外し再度実施する

参考

swap がない場合（あるいは少ない場合）は作成して適用する

  1. 古いSwapファイルを削除する（必要に応じて）

    // 現在のスワップ設定を確認する
swapon --show
free -h
// 既存のSwapを無効化する 
sudo swapoff -a
// 古いSwapファイルを削除する（必要に応じて）
sudo rm /swapfile

  2. 新しいSwapファイルを作成する

    // 作成
sudo fallocate -l 4G /swapfile
sudo chmod 600 /swapfile
// 有効化
sudo mkswap /swapfile
sudo swapon /swapfile
// 確認
sudo swapon --show
free -h

  3. もし以前swapがなかった場合には永続化する

    echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab

Vue 3 + Vite の開発環境を Docker で構築

プロジェクトフォルダを作成

mkdir -p /mnt/bvol/vue-docker/workspace
cd /mnt/bvol/vue-docker

Dockerfile を作成

/mnt/bvol/vue-docker/Dockerfile ファイルを新設

FROM node:20

# 作業ディレクトリ
WORKDIR /work

# 必要ならグローバルツールを追加
# RUN npm install -g pnpm

# コンテナ起動時に /work に入る
CMD [ "bash" ]

Node 20 ベースで、後から自由にカスタマイズが可能。

docker-compose.yml を作成

/mnt/bvol/vue-docker/docker-compose.yml ファイルを新設

version: "3.9"

services:
  vue:
    build: .
    container_name: vue-dev
    working_dir: /work
    volumes:
      - ./workspace:/work
    ports:
      - "5173:5173"
      - "4173:4173"
    tty: true

補足：

  • workspace/ が ホスト側に永続化される
  • Vite の dev（5173）と preview（4173）が使える
  • Node バージョンは Dockerfile で自由に変更可能
  • Dev Container を使わない場合でも活用可

コンテナを起動

docker compose up -d

コンテナに入る

docker exec -it vue-dev bash

Vue プロジェクトを作成（初回のみ）

コンテナ内で

npm create vite@latest .
npm install

補足

  • 「.」を指定することで /work に直接作成される
  • ホスト側の /mnt/bvol/vue-docker/workspace に永続化される

開発サーバーを起動

npm run dev -- --host

ブラウザでアクセスを確認

http://<VPSのIP>:5173

preview（本番モード）を起動

npm run build
npm run preview -- --host

ブラウザでアクセスを確認

http://<VPSのIP>:4173

これで作成と動作確認が完了。

VS Code を使って Dev Container で接続

最終構成

/mnt/bvol/vue-docker
 ├ Dockerfile
 ├ docker-compose.yml
 ├ .devcontainer/
 │   └ devcontainer.json
 └ workspace/
     └ （Vue プロジェクト）

VS Code を使う場合は Dev Container からアクセス、 Docker だけ使う場合は docker compose up -d のどちらでも同じ環境が使用できる。

.devcontainer フォルダおよび devcontainer.json を作成

cd /mnt/bvol/vue-docker
mkdir .devcontainer

/mnt/bvol/vue-docker/.devcontainer/devcontainer.json ファイルを新設

{
  "name": "vue-docker-dev",
  "dockerComposeFile": "../docker-compose.yml",
  "service": "vue",
  "workspaceFolder": "/work",

  "customizations": {
    "vscode": {
      "extensions": [
        "Vue.volar",
        "Vue.vscode-typescript-vue-plugin",
        "esbenp.prettier-vscode",
        "mhutchie.git-graph"
      ]
    }
  }
}

補足

  • docker-compose.yml をそのまま利用
    • Dev Container は compose の vue サービスに接続する
  • workspaceFolder = /work
    • docker compose の設定に合わせている
  • VS Code の拡張機能も自動インストール
    • Dev Container 内で Vue 開発向けをいくつか初期状態で入れておく例

VS Code で Dev Container を開く

  • コマンドパレットから Dev Containers: Reopen in Container とし VS Code で /mnt/bvol/vue-docker を開く
  • これで下記となる。
    • docker-compose.yml の vue サービスが起動
    • /work が workspace として開かれる
    • ホスト側の workspace/ と同期
    • Node 20 の環境が Dockerfile で再現

補足

Vite の開発サーバーを外部公開

Vite はデフォルトだと localhost しか listen しない。外部からアクセスする場合のメモ。

package.json の dev スクリプトを修正

"dev": "vite --host"

または起動時にオプションを付与。

npm run dev -- --host

これで VPS の外からアクセス可能になる。アクセス URL は下記の通り、。

http://<VPSのIP>:5173

VS Code のステップ実行デバッグ設定

.vscode/launch.json を作成

{
  "version": "0.2.0",
  "configurations": [
    {
      "name": "Vite + Chrome Debug",
      "type": "chrome",
      "request": "launch",
      "url": "http://localhost:5173",
      "webRoot": "${workspaceFolder}/src"
    }
  ]
}

VS Code の「Run and Debug」から起動する。

Zephyr RTOS の開発環境を VSCode Dev Container で構築

Linux Windows ツール

Zephyr RTOS の開発環境を整えた。手元の環境とは切り離したかったが書き込み先のターゲット（基板）とUSBで接続して flash する必要があるため物理的にパソコンは必要となる。

そのため手元のパソコンに Linux をデュアルブートでインストールして環境を構築したのでメモ。ただし Linux のデュアルブート環境を可能な限り既存の Windows とは分離したかったのでその点についてもメモしておく。

つまり本記事は下記の内容を含む。必要な個所のみ参照してOK。

  • Ubuntu インストール、Windowsとの共存
  • Docker、Docker Compose で Zephyr RTOS の開発環境を構築
  • VSCode Dev Container 化

前提

環境は下記を対象

  • Zephyr RTOS の開発環境を既存の環境とは切り離して構築したい
  • 基板への書き込みを伴うのでUSB接続可能なパソコンが物理的に必要（VPSなどではビルドはできても書き込めない、あるいは別に書き込む手段が必要）
  • Linux で構築。ここは今回特に必須ではないが今回は Linux を採用。

最終構成

  • Linux PC
  • Zephyr RTOS の開発環境を Docker で構築
  • VSCode Dev Container 導入

手順

Linux PC の用意（方針）

  • Linux 環境の準備の仕方は特に問わないが、今回は物理的に Linux PC がある状態にしたかったのと、かつ環境を可能な限り既存の Windows とは分離したかったので下記の構成とした
  • ツール Rufus で Ubuntu の ISO ファイルを使ってブータブルUSB（インストーラのUSB）を作成し、次にそのUSBをPCに挿して別のUSBにUbuntuをインストール（インストール先のUSB）
  • ブートローダのインストール先をインストール先のUSBにすることで、Linux USB を挿している場合は Linux が起動、挿していないときは Windows が起動するようにした

Linux PC の用意（手順）

  1. 必要なものの準備

    • Linux PC: Ubuntu をインストールする先のPC（既存の Windows PC）
    • インストール用 USB: Rufus で作成する Ubuntu インストーラ用の USBメモリ（インストールのみ使用するので容量さえ十分であればOK）
    • インストール先 USB: Ubuntu を実際にインストールし、起動ディスクとして使用する USB ドライブ（十分な容量と高速な転送速度を持つUSBメモリを推奨）
    • Ubuntu ISO ファイル: インストールに使用する Ubuntu のディスクイメージファイル。任意のバージョンを公式からダウンロードして準備。

  2. インストールの実施

    • インストール元 USB の作成
      • Windows PC 上で、ダウンロードした Ubuntu ISO ファイルを使ってブータブル USB を作成する
    • Ubuntu のインストール
      • 作成したインストール元 USB を使用して PC を起動し、Ubuntu をインストールする
      • インストール元 USB とインストール先 USB の両方をターゲット PC に挿入し、BIOS/UEFI の設定またはブートメニューからインストール元 USB ドライブから起動するように選択
      • Ubuntu のインストーラーを起動してインストールを進める
      • インストール先をインストール先 USB ドライブに指定する
      • 重要：「ブートローダをインストールするデバイス」の選択項目で、必ずインストール先 USB ドライブ自体（例: /dev/sdb など）を選択すること。これにより、Windows のブートローダーに影響を与えない。

  3. 運用の仕方

    • Linux を起動したい場合: インストール先 USB を挿した状態で PC を起動する。PC のブート順設定によっては、USB ドライブからの起動を優先するように設定するか、起動時にBIOSでブートメニューを表示させて USB ドライブを選択する必要がある。
    • Windows を起動したい場合: インストール先 USB を抜いた状態で PC を起動します。通常通り Windows が起動する。

Docker のインストールと設定（方針）

  • Docker および Docker Compose をインストールする
  • この後 Docker 上に Zephyr RTOS の開発環境を構築する
  • ただし Linux を USBメモリにインストールした場合、USBメモリへの書き込みは比較的遅いことが予想されるので、Disk I/O のパフォーマンス低下を最小限に抑えるために、Windows がインストールされているパソコンのディスク（SSD）を下記の通り活用する

Docker のインストールと設定（手順）

  1. Windows 側で SSD の空き領域を作る（縮小）

    • Windows の「ディスクの管理」で C: ドライブを縮小して「未割り当て領域」を作成
    • BitLocker が有効でも問題なし
    • 未割り当て領域は暗号化されていない
    • この後 Ubuntu で ext4 にする

  2. Ubuntu に RDP（xrdp）と SSH サーバを導入（必要に応じて）

    • 手順省略

  3. Docker CE をインストール

  4. Docker Compose（v2）の確認

     docker compose version

  5. SSD の空き領域に ext4 パーティションを作成

    • GParted を使う（手順省略）

  6. ext4 パーティションを Ubuntu にマウント

    • マウントポイント作成

        sudo mkdir -p /mnt/ssd-ext4

    • マウント

        sudo mount /dev/nvme0n1p5 /mnt/ssd-ext4

    • 自動マウント設定（推奨）

        sudo blkid /dev/nvme0n1p5

      • 例：

          UUID="abcd-1234-ef56-7890"

      • /etc/fstab に追加

          UUID=abcd-1234-ef56-7890  /mnt/ssd-ext4  ext4  defaults  0  2

  7. Docker のデータディレクトリを ext4 に移動

    • Docker を停止

        sudo systemctl stop docker.socket
  sudo systemctl stop docker

    • データ移動

        sudo mv /var/lib/docker /mnt/ssd-ext4/docker

    • シンボリックリンク

        sudo ln -s /mnt/ssd-ext4/docker /var/lib/docker

    • Docker 再起動

        sudo systemctl start docker.socket
  sudo systemctl start docker

Zephyr RTOS の開発環境を Docker で構築

  1. Zephyr 用 Docker Compose プロジェクトを ext4 上に作成。ここでは例として zephyr-docker というフォルダ名とする。

     cd /mnt/ssd-ext4
 mkdir -p zephyr-docker/workspace
 cd zephyr-docker
    • 補足：

      • もし /mnt/ssd-ext4 に書き込み権限がない場合には下記を実施。

          sudo chown -R $USER:$USER /mnt/ssd-ext4

  2. docker-compose.yml を作成（常駐型コンテナ）

  3. /mnt/ssd-ext4/zephyr-docker/Dockerfile ファイルを新設

      FROM zephyrprojectrtos/ci

  RUN apt update && \
      apt install -y usbutils minicom && \
      apt clean

  4. /mnt/ssd-ext4/zephyr-docker/docker-compose.yml ファイルを新設

      version: "3.9"

  services:
    zephyr:
      build:
        context: .
        dockerfile: Dockerfile
      container_name: zephyr-dev
      working_dir: /work
      volumes:
        - ./workspace:/work
      tty: true
      stdin_open: true
      command: sleep infinity
      privileged: true
      devices:
        - "/dev/ttyACM0:/dev/ttyACM0"
        - "/dev/bus/usb:/dev/bus/usb"

  5. コンテナをバックグラウンドで起動

     docker compose up -d

Zephyr RTOS を使用して build と flash を実施（VSCode Dev Containerではない手順）

このあと VSCode + Dev Container での手順を実施するがこの時点で Linux で Docker コンテナ内で Zephyr RTOS を使用したビルドと書き込みが可能になるので手順をメモ、

  1. コンテナをバックグラウンドで起動

    • コンテナ起動

        docker compose up -d

    • ホスト側で Zephyr を clone

        cd /mnt/ssd-ext4/zephyr-docker/workspace
  git clone https://github.com/zephyrproject-rtos/zephyr.git

  2. コンテナに入って Zephyr プロジェクトを初期化

    • コンテナに入る

        docker exec -it zephyr-dev bash

    • コンテナ内で

        west init -l zephyr
  west update

  3. west のビルド（コンテナ内）

     west build -b qemu_x86 zephyr/samples/hello_world
 west build -t run

  4. 実機書き込み（必要な場合）

     west flash

VS Code + Dev Containers で Zephyr 開発環境を構築する手順

  1. 前提：環境
  2. Docker CE / Docker Compose 導入済み
  3. Dockerfile 及び docker-compose.yml で zephyr-dev コンテナを作成（設定）済
    • /mnt/ssd-ext4/zephyr-docker/ にあるとする
  4. zephyr-dev コンテナは docker compose up -d で常駐可能な状態

上記の状態から VS Code を IDE として使えるようにする手順を下記で示す。

  1. 前提：プロジェクトの場所

    • Dockerfile 及び docker-compose.yml を導入した Ubuntu 上の下記が VS Code で開くべきフォルダとなる。例えば下記。

        /mnt/ssd-ext4/zephyr-docker

  2. VS Code をインストール（Ubuntu に）

    • VS Code 本体をUbuntu にインストールして使用する場合には実施する
      • 具体的なインストール方法は省略
    • さらに別のパソコンの VS Code から Remote SSH と Dev Containers を組み合わせて接続する場合には Ubuntu 側に VS Code のインストールは不要

  3. VS Code 拡張機能をインストール

    • VS Code を開き、以下をインストールする
      • Dev Containers

  4. Dev Containers 用の設定ファイルを作成

    • プロジェクトディレクトリは下記とする（例）

        /mnt/ssd-ext4/zephyr-docker/

    • ここに .devcontainer/ を作成する

        mkdir /mnt/ssd-ext4/zephyr-docker/.devcontainer

  5. devcontainer.json を作成する

    • /mnt/ssd-ext4/zephyr-docker/.devcontainer/devcontainer.json ファイルを下記の内容で新設

        {
    "name": "Zephyr Dev",
    "dockerComposeFile": "../docker-compose.yml",
    "service": "zephyr",
    "workspaceFolder": "/work",
    "remoteUser": "root",

    "customizations": {
      "vscode": {
        "extensions": [
          "ms-vscode.cpptools",
          "ms-vscode.cmake-tools",
          "ms-vscode.remote-containers"
        ]
      }
    },

    "postCreateCommand": "west update"
  }
    • メモ
      • workspaceFolder /work は Docker コンテナ内のパス
      • 実体は Ubuntu 上の workspace/

  6. VS Code で Dev Container を開く

    • VS Code で Ubuntu 上のプロジェクトを開く

        /mnt/ssd-ext4/zephyr-docker

    • 左下の緑のアイコン → 「Reopen in Container」

    • VS Code が自動で下記を実施する

      • docker compose を読み込み
      • zephyr-dev コンテナに接続
      • /work をワークスペースとして開く
      • west update を実行

  7. west build を VS Code から実行する

    • VS Code のターミナルで下記を実施。これは実際にはコンテナ内で実行されることになる。

        west build -b qemu_x86 zephyr/samples/hello_world

    • 例:

        west build -b nucleo_l476rg --shield x_nucleo_idb05a1 zephyr/samples/hello_world
  west build -b nucleo_l476rg --shield x_nucleo_idb05a1 zephyr/samples/basic/blinky
  west build -b nucleo_l476rg --shield x_nucleo_idb05a1 ./zephyr/samples/bluetooth/direct_adv

  west build -b esp32_devkitc_wroom/esp32/procpu zephyr/samples/hello_world

  8. 実機書き込み（USB デバイスがコンテナ内で認識されている状態）

    • VS Code のターミナルで下記を実施

        west flash

    • openOCD 経由で書き込みの場合は下記

        west flash --runner openocd

    • USB デバイスの認識方法の確認の仕方

      • USB デバイスがホスト側で認識しているかの確認

          lsusb
  ls -l /dev/ttyACM*

      • docker-compose.yml に設定されている USB デバイスが合致しているかを確認すること

          services:
    zephyr:
      privileged: true
      devices:
        - "/dev/ttyACM0:/dev/ttyACM0"
        - "/dev/bus/usb:/dev/bus/usb"

  9. 実機の Zephyr Console ログの確認方法

     minicom -D /dev/ttyACM0 -b 115200

  10. コンテナを停止したいとき

   docker compose down

nRF54L15 最初に

サイト ツール

下記で2023年5月に nRF5340 について情報を集めた。 ki06.hatenablog.com

今回 nRF54L15 について再度整理する。

Seeed Studio XIAO nRF54L15 で nRF Connect SDK を使用して各種機能確認を進めているのでメモ。基本的には samples が充実しているのである程度理解や知識が進めば困ることはなさそう。

ただ nRF Connect SDK は Zephyr OS がベースであり、何もしならない状態ではまずの第一歩が少し難しそう。Web上に情報は多いので必要な情報は十分ありそうなのだが、多いがためにどの順序で見ていけばよいか悩むところ。

ということで各種情報をあとから見直すためのメモ。 まずは公式のイントロダクション動画や紹介動画、webセミナー（Webinar）から入るのが良いのではと思えるので、その順序で並べておく。

見る（BLE、nRF Connect for VS Code）

まず最初に、ひとまず開発環境の構築や開発ができるようになるための手順。

読む（学ぶ）

なんとなくわかったところで、実際に手を動かしてある程度手が動くようになるまでの手順や学習。

見る（Hands-on）

なんとなくわかったところで、実際の開発環境を見ながら（見せながら）各機能や使い方の紹介がされており、把握できる。

  • nRF Connect SDK Hands-on
    • https://www.youtube.com/playlist?list=PLx_tBuQ_KSqG-leiJDfOKf_ZmCqHnbi4r
    • ★後で見る★
    • nRF Connect SDK ではサンプルが充実しているのでサンプルを読み解いての理解や把握、学習も可能であるが、この Hands-on では（ある意味）各サンプルがどのように作成されているかをサンプルを例に説明ではなく説明しつつ結果的にサンプルと同等の機能を構築していくので、開発の過程を知る／把握するという意味で役に立つ
      • nRF Connect SDK hands-on, part 1: Rapid prototyping with nRF Connect SDK
        • Bluetooth LE が nRF Connect SDK によってどのようにサポートされているかの説明
        • クイックスタート
          • まずはデモを通して実際に Bluetooth LE が動作してスマートフォンと連動していることの紹介
          • ただし手順は実際に開発するときとは少し異なる（例を動作させるための Walk Through 的な意味合いが強い）ので見るのみでOKと思う
      • nRF Connect SDK hands-on, part 2: Sensors in nRF Connect SDK
        • ファイル構成と概観
          • Devicetree, Kconfig, CMake, overlay, src ファイル などの設定の存在とその役割の説明
          • Kconfig で設定を追加し、追加した設定について prj.conf にて値を指定あるいは y / n で選択（あるいはドライバで既に設定済みの Kconfig の設定値に対する設定）
        • センサの使用例を通して、ソフトウェアとハードウェアの設定が分離しており高い移植性を有していることを説明（及びスケーラビリティ）
        • 実際のセンサの使用例
          • センサ用の API が用意されているので上位のアプリケーションは移植性が高い
          • 最初に実際のセンサではなく"模擬" (Simulated sensor driver) で作成、Cファイルの作成と CMake への追加方法、各種 API を使用するためのヘッダファイルの追加方法など、実際に開発を行う手順を順次紹介している（参考になる）
          • 参考: Simulated sensor driver: https://docs.nordicsemi.com/bundle/ncs-latest/page/nrf/drivers/sensor_sim.html
          • 開発ボード上での I2C センサの接続箇所や overlay での設定の仕方

      • nRF Connect SDK hands-on, part 3: Send and receive data through Bluetooth LE

        • Bluetooth LE を使用して何ができるかの例の紹介も兼ねて、 nRF Connect SDK において Bluetooth LE を使うにはどのような手順や設定、ソースコードになるかを説明
        • Bluetooth LE を使用する手順を順を追って説明
          • nRF Connect SDK において Bluetooth LE の GATT により read / write の例
          • カスタム GATT の追加（DevAcademy の Bluetooth Low Energy Fundamentals 参考）
        • nRF Kconfig GUI の紹介
          • prj.conf を直接変更してもよいが階層的に把握ができる

      • nRF Connect SDK hands-on, part 4: Storing data on non-volatile memory

        • 不揮発性メモリへのデータの記録方法
        • SoC 内部の場合とSPI経由の外部の場合との、両方のデバイスの両方をカバー
        • Zephyr OS が提供する Non-Volatile Storage (NVS) を nRF Connect SDK でどのように使用するか

        • さらに Zephyr OS の Message Queues 及び処理用の別スレッドを用意するので Zephyr OS の Threads の使い方の説明にもなっている

        • Devicetree 上での "Partition" の設定の仕方や GUI 上での見え方などの説明

          • overlay での設定の仕方と c ソースファイル上の名称の関連
          • 記憶を Soc の内部と Soc の外部を切り替えるのに、どの設定ファイルがどのように変わるか（ハードウェアとソフトウェアの設定がどのように切り分けられているか）の把握

      • nRF Connect SDK hands-on, part 5: Power Optimization and the PPK2

      • nRF Connect SDK hands-on, part 6: Adding FOTA over Bluetooth LE

読む（中級）

  • nRF Connect SDK Intermediate
    • https://academy.nordicsemi.com/courses/nrf-connect-sdk-intermediate/
      • 最初に必要とはならないが、例えばカスタムボードの定義やデバイスドライバの作成をする場合には下記を参照。
      • 以下の章立て。必要な個所を参照すればよいと考える。
        • Lesson 1 – Zephyr RTOS: Beyond the basics
        • Lesson 2 – Debugging and troubleshooting
        • Lesson 3 – Adding custom board support
        • Lesson 4 – Pulse Width Modulation (PWM)
        • Lesson 5 – Serial Peripheral Interface (SPI)
        • Lesson 6 – Analog-to-digital converter (ADC)
        • Lesson 7 – Device driver development
        • Lesson 8 – Sysbuild
        • Lesson 9 – Bootloaders and DFU/FOTA

見る（Zephyr OS）

その次に、Zephyr RTOS を知って自在にコーディングや機能のつくり込みができるようになるための手順。

読む

その他（Bare Metal オプション）

下記は参考。nRF5 SDK から nRF Connect SDK への移行を促す記事について Bare Metal オプション が移行先として追記されている。

Update 28/08/2025: For nRF5 SDK users there is now nRF Connect SDK Bare Metal option for nRF54L Series, bringing architecture and API compatibility to ease the migration of codebase from nRF52 Series to nRF54L Series. More information:

その他

優先度は低いけれども情報を探しておいたのでメモ。