本稿はChatGPTと壁打ちしながらプログラムを作成し、その流れをベースにChatGPTに原稿を作成してもらったものです。ご承知ください。

はじめに

組み込み Rust で、ある程度規模のあるプログラムを書こうとすると、次のような壁にぶつかることがあります。

GPIO、I2C、PWM などのペリフェラルを
複数の struct にどう渡せばよいのか分からない
参照（& / &mut）で渡そうとすると借用が衝突してしまう
結果として main 関数にすべての処理が集まり、巨大になってしまう

本稿では、この問題がなぜ起きるのか、そして HAL がどのような思想を前提として設計されているのかを整理します。

結論を先に述べると、

pac::Peripherals は「保持し続ける」ためのものではなく、
必要なペリフェラルを所有権ごと抜き出して使い、
それ以降は戻さないという使い方を前提として設計されています。

この点を理解することが重要です。

1. なぜ参照で渡そうとして詰まるのか

まず、多くの人が最初に考える設計は次のようなものではないでしょうか。

struct Board<'a> {
    pac: &'a mut pac::Peripherals,
}

あるいは、

struct Device<'a> {
    i2c: &'a mut I2C0,
}

しかしこの設計は、少し規模が大きくなるとすぐに破綻します。

同じ pac を複数の struct が &mut で借用できません
ある struct が I2C を使っている間、他が何もできなくなります
初期化順やライフタイムが複雑になります

これは Rust の制約が厳しいからではなく、
HAL が想定している使い方と逆方向に設計してしまっていることが原因です。

2. HAL が前提としている考え方

HAL の API をよく見ると、次のような特徴があります。

let dp = pac::Peripherals::take().unwrap();

let i2c = I2C::new(dp.I2C0, ...);
let pwm = Pwm::new(dp.PWM, ...);

ここで重要なのは、以下の点です。

pac::Peripherals の各フィールドは 参照ではなく move されます
一度 move されたフィールドは 二度と使えません
HAL は「取り出して使い、戻さない」ことを前提に設計されています

これは偶然ではなく、HAL は次の思想に基づいています。

物理的に 1 つしか存在しないハードウェア資源は、
プログラム上でも 1 つの所有者しか持てないようにする。

3. 所有権を「抜き出す」という感覚

この挙動は、Rust の通常のコレクション型で考えると理解しやすくなります。

Vec の例

let mut v = vec![10, 20, 30];
let x = v.remove(0);

このとき、

x が 10 を所有します
v はもう 10 を持っていません
同じ要素を同時に触ることはできません

pac::Peripherals も同じ構造です

let dp = pac::Peripherals::take().unwrap();
let i2c = I2C::new(dp.I2C0, ...);

これは感覚的には、

巨大な Vec<Peripheral> から、
I2C という要素を remove() している

のとほぼ同じです。

I2C を所有する i2c が生成されます
dp は I2C を失います
所有権は一方向に移動し、戻りません

4. Board パターン：pac を「保持しない」構造

この思想を踏まえると、Board の役割は明確になります。

pac::Peripherals を保持することではありません
初期化時に pac を分解し、完成した HAL 型だけを保持します

Board の例

pub struct Board {
    pub i2c: hal::I2C<pac::I2C0>,
    pub led: hal::gpio::Pin<Output<PushPull>>,
}

impl Board {
    pub fn new(pac: pac::Peripherals) -> Self {
        let pins = Pins::new(
            pac.IO_BANK0,
            pac.PADS_BANK0,
            pac.SIO,
            &mut pac.RESETS,
        );

        let i2c = I2C::new(
            pac.I2C0,
            pins.gpio4.into_mode(),
            pins.gpio5.into_mode(),
            400.kHz(),
            &mut pac.RESETS,
        );

        let led = pins.gpio25.into_push_pull_output();

        Self { i2c, led }
    }
}

ここで重要なのは、

Board は pac::Peripherals を 一切保持していない
pac は new() の中で完全に消費されます
以降は「完成済みの部品」だけが残ります

という点です。

5. I2C を使った具体例

I2C は複数デバイスで共有されることが多いため、
この思想が特に重要になります。

単一デバイスの場合

struct Display {
    i2c: I2C<pac::I2C0>,
}

impl Display {
    fn new(i2c: I2C<pac::I2C0>) -> Self {
        Self { i2c }
    }
}

I2C の所有権は Display に完全に移動します
他の場所から I2C を触ることはできません

複数デバイスで共有する場合（概念）

I2C 自体の所有権は 1 箇所に集約します
各デバイスは排他的に借用します

このときに使われるのが、

shared-bus
critical_section::Mutex<RefCell<I2C>>
RTIC / embassy の Mutex

などです。

ここでも pac は一切登場しない点が重要です。

6. なぜこの設計が必要なのか

もし HAL が次のように設計されていたらどうなるでしょうか。

I2C を参照で自由に渡せる
pac を clone できる

その結果、

複数ドライバが同時に同じレジスタを操作する
初期化順の競合が起きる
割り込みとの競合が発生する
未定義動作に陥る

といった問題を コンパイル時に防げなくなります。

これを避けるため、HAL は

所有権を move する設計

を採用しています。

まとめ

pac::Peripherals は 保持するための構造体ではありません
各ペリフェラルを 所有権ごと抜き出して使うことが前提です
HAL の API は、この使い方を自然に強制するよう設計されています
Board は pac を持たず、完成済み HAL 型だけを束ねます
I2C などの共有は、pac とは別のレイヤで解決します

この思想を理解すると、

なぜ参照で渡そうとするとうまくいかないのか
なぜ main 関数が巨大になりがちなのか
なぜ HAL の example があの形になっているのか

を、一貫した形で説明できるようになります。

終わりに

これまで私は電子工作ではずっとArduinoを使っていたのですが、PCアプリ開発ではRustを使っていましたので、マイコンでもRustを使えないかと思っていました。
しかし、実際に組み込みRustに挑戦してみたのですが、本稿の冒頭のようにペリフェラルをうまくモジュールに分配することができず、無駄に大きなmain関数になってしまい、挙げ句の果てにはgpioをグローバル変数にし、そのアクセスを全部unsafeで囲うような無様なプログラムとなってしまったのです。

この反省のもと、今度はChatGPTの助けを借りて本稿で書かれているような書き方をすることで、ようやく満足いくようなプログラム構造に到達することができました。
このときの壁打ちの様子をベースにして、ChatGPTに原稿まで作成してもらったのが本稿です。まだまだ、組み込みRustが手の内になったというにはほど遠いレベルではありますが、これをきっかけに少しずつ組み込みでもRustを使っていくつもりです。
組み込みRust開発で、同じようなところで悩んでいる方の参考になれば幸いです。