ラズパイゼロのRustクロス環境使って、ssd1306を動かしてみる

以下のリンクのサンプルプログラムを動かしてみただけですが、

https://github.com/fmckeogh/ssd1306-raspi-examples/tree/master

クロス環境はVMware +Ubuntu(20.xx)の環境です

Rust(@Raspberry PI zero)のクロスコンパイル環境構築

Cargo.tomlはそのまま使い、examplesディレクトリのgraphics-i2c.rsをビルドしてラズパイにscpで転送して実行した結果は以下のようになります

ADCもFFTもどちらのcrateも存在しているようだから、PythonコードをRustで置き換えできそうです

admi

当然ながらzeroの能力ではRustのコンパイルには時間かかるので、クロス環境が必要です。以前Golang用のDocker(QEMU環境)では上手くいかなかった、おそらくlinkerの問題なのか、ので代替え案としてIntel MacのVMware環境でのUbuntuで環境作りました。

https://www.freecodecamp.org/news/embedded-rust-programming-on-raspberry-pi-zero-w/

を参考にしています。

いくつか修正が必要だったので、そこを記述します。

・ターゲットインストールのコマンドはtargetとaddが逆になってる

$ rustup target add arm-unknown-linux-gnueabihf configはobslete

・~/.cargo/configを使うのは古くて(obsoleteと言われる)コンパイル通らないから、.cargo/config.tomlに入れる（以下のように）てlinker対象ファイルはパスを通すかフルパスで指定

[target.arm-unknown-linux-gnueabihf]

linker = "/rpi_tools/arm-bcm2708/arm-rpi-4.9.3-linux-gnueabihf/bin/arm-linux-gnueabihf-gcc"

・hello worldのサンプルプログラムをcargo initで作成（sampleディレクトリに）してコンパイル

fn main() {
    println!("Hello, world! from Ubuntu compiler");
}

$ cargo build --release --target=arm-unknown-linux-gnueabihf

・バイナリをラズパイに転送（実行ファイルはsample/target/arm-unknown-linux-gnueabihf/release以下に存在）

$ scp release/sample pi@192.168.1.16:~/sample

・ラズパイで実行

$ ./sample

Hello, world! from Ubuntu compiler

ただし、

https://github.com/raspberrypi/tools

のページには、

These toolchains are deprecated. They are outdated and easily available from other sources (e.g. direct from Ubuntu apt). e.g.

sudo apt-get install gcc-arm-linux-gnueabihf

とあるので、このやり方の方がスマートなのかもしれない。

クロスコンパイルには他にはcrossとDockerを使うやり方もありますが、それほどのアドバンテージがあるようには思えないから当面この環境かな。

admin

rustはパッケージ管理が楽なのですが、それをさらに補強するツールがcargo-editです。

https://tkyonezu.com/開発ツール-言語/raspberry-pi-に-rust-をインストールする/

を参考にラズパイ zeroにrustインスト後にcargo-editをインスト、ツールのインストには流石にzeroなのでたっぷり時間かかって（二時間ぐらいか）完了、一度はエラー終了したので再度実行。

何が便利かというと、例えばcargo add xxxxでcrate xxxxの最新版を自動で探して（版数指定もできますが）Cargo.tomlに追加してくれます。

例えばrandを追加すると、

$ cargo add rand
    Updating crates.io index
      Adding rand v0.8.5 to dependencies

で、Cargo.tomlの[dependencies]にrandが追加されています。

admin

Beginning Rustは言語仕様を単に羅列するのではなく、なぜそのような仕様にする必要があるかを丁寧に説明していますが、ライフサイクル指定でもそれは同じことが言えます。

そもそも関数が返すことができる参照（リファレンス）とは、以下の二つのうちのどちらかだと、

① 静的オブジェクトの借用：以下のstr関数

② 引数の借用：以下のf関数

それ以外の関数の引数オブジェクト、関数内のローカル変数オブジェクト、関数内の一時的オブジェクトは関数から戻る時に破棄されるから参照にはなり得ない、したがってライフタイム指定が必要なケース（本来は関数の戻り時点で破棄されるオブジェクトを、戻り値の参照が破棄されるまでライフタイムを延命と同義）もある程度限定的ということになる。コードとしてライフタイム表記はスッキリ感がないし、

/* It prints:
Static object
13 12*/

fn main() {
    // borrowing of the static object
    fn str<'a>() -> &'a str {
        "Static object"
    }
    println!("{}", str());

    // borrowing of the augments
    // in this case x and y need to have different life time
    fn f<'a, 'b>(x: &'a i32, y: &'b i32) -> (&'a i32, bool, &'b i32) {
        (x, true, y)
    }
    let i1 = 12;
    let i2;
    {
        let j1 = 13;
        let j2;
        let r = f(&i1, &j1);
        i2 = r.0;
        j2 = r.2;
        print!("{} ", *j2);
    }
    print!("{}", *i2);
}

関数fで複数のライフタイムが必要な理由は、関数fを展開してみれば理由がわかる、つまり{}の外側にあるi1/i2と内側にあるj1/j2では本質的なライフタイムに差があるのだから、それを一律なライフタイムで規定しようとしても不可能だということを言っているだけ。

admin

コピーや複製はRustでは、オブジェクトの型に依存してデフォルトで実装されているもの（プリミティブ型）もありますが、性能を重視しているので基本は移動です。

代入のセマンティクには以下の三種類がありますが、

① 共有：本体は共有してアクセスポインタは個別に持つやり方、GCを持つ言語(Java, C#, Golang)では標準のようです

② コピー：C++のデフォルト実装が該当

③ 移動：Rustの標準、ただしプリミティブ型（オブジェクトの長さが変化しないのでスタックを使用する型）は例外

Rustでプリミティブ型以外のヒープ領域に保存されるオブジェクトは標準は移動ですが、コピー（コピーすることに意味があれば、DBのコネクションとかコピーは無意味だし害があるだろう）はcloneを実装すれば良いのですが、例えば構造体などはデフォルトでcloneを適用しようとしても、対象オブジェクトのメンバーは対象に含まれないからコンパイルは通りません。

以下のコードはコンパイルエラーになりますが、理由はderiveは構造体という型に適用されるだけで、その要素であるVec型には適用されないから。

回避方法は、以下のソースでコメントアウトしているCloneのカスタマイズが必要になります。

  |     #[derive(Copy, Clone)]
  |              ^^^^
  |     struct S {
  |         x: Vec,
  |         ----------- this field does not implement `Copy`

fn main() {
    #[derive(Copy, Clone)]
    struct S {
        x: Vec<i32>,
    }
    /*impl Clone for S {
        fn clone(&self) -> Self {
            S { x: self.x.clone() }
        }
    }*/
    let mut s1 = S { x: vec![12] };
    let s2 = s1.clone();
    s1.x[0] += 1;
    print!("{} {}", s1.x[0], s2.x[0]);

    //
    // same as above(this field(x: Vec) does not implement `Copy`)
    // Object members are out of target, Copy/Clone is applied only to struct S/S1
    //

    struct S1 {
        x: Vec<i32>,
    }
    impl Copy for S1 {}
    impl Clone for S1 {
        fn clone(&self) -> Self {
            *self
        }
    }
}

この辺りについては、

https://doc.rust-lang.org/std/marker/trait.Copy.html

の解説を読むのが良いと思います。

admin

Beginning Rustに出てくるコードですが、rustcに -Oというコンパイルオプションがありますが、以下のコードで-Oを指定しないと何回か実行するとその都度時間は変わってきますが、この程度の処理時間、

実行環境はM1 Mac 16GB/512GB、rustc 1.79.0です

5.14425ms 1.031666ms

ここでrustic -Oでコンパイルすると、

584.666µs 84ns

この数字はwhileループを丸々パス、全く処理しないでvdをクリアしているだけに見えます。

fn main() {
    use std::time::Instant;
    const SIZE: usize = 40_000;
    let start_time = Instant::now();
    let mut vd = std::collections::VecDeque::<usize>::new();
    for i in 0..SIZE {
        vd.push_back(i);
        vd.push_back(SIZE + i);
        vd.pop_front();
        vd.push_back(SIZE * 2 + i);
        vd.pop_front();
    }
    let t1 = start_time.elapsed();
    while vd.len() > 0 {
        vd.pop_front();
    }
    let t2 = start_time.elapsed();
    print!("{:?} {:?}", t1, t2 - t1);
}

で、コンパイラが手抜きをさせないように、毎回結果を使うように書き換えると、

    while vd.len() > 0 {
        sum += vd.pop_front().unwrap();
    }
    let t2 = start_time.elapsed();
    print!("{:?} {:?} {}", t1, t2 - t1, sum);

386.083µs 81.209µs 2933353333

こちらはまともそうに見えます。コンパイルオプションで処理時間が著しく異なるときは実はコードが冗長というケースもありそうだよねということです、

admin

プリミティブ型に、他の型にもあるだろうけれども、メソッドの追加定義は単純なimpl str/i32 ・・・のようなやり方ではできませんが、traitを介在したメソッド追加はできます。

以下Beginning Rustのコードからですが、traitを介在させることで、追加メソッドlenght()を定義しています。

fn main() {
    // "imple str" doesn't work as intended
    // primitive type doesn't allow adding some specific methods to it
    // to use tarit to adopt specific method lenght() for type "str"
    trait HasLength {
        fn length(&self) -> usize;
    }
    impl HasLength for str {
        fn length(&self) -> usize {
            self.chars().count()
        }
    }
    let s = "ۏe";
    print!("{} {}", s.len(), s.length());
}

trait経由でプリミティブ型にメソッド追加の一般的なやり方ですが、直接追加（今はできない仕様ですが、できたとしたら）と比較して可読性とか保守性が直接追加に比較して優位であるというところが理由なのだろう。

admin

Beginning Rustの第18章の最初の方に出てくるコードですが、

fn main() {
    print!("{} {}",
        [1, 2, 3].len(),
        <[i32]>::len(&[1, 2, 3]));
}

ここで最後の２行はドット記法あるいはメソッド記法の違いですが、メソッド記法では<[i32]>::の表現が出てきます。ここで、<[i32]>の意味はスライスのジェネリック型でi32型の要素を持つこと、::はlen()の引数の型指定です。なぜこのような記法が必要かというと、len()というメソッドは他にもあって型を明示的に指定しないとどのトレイトに属するメソッドかを判断できないかから。

またlen()の引数は参照で無いとコンパイルできません。スライスのメソッドlen()の解説は以下の通り、

https://doc.rust-lang.org/std/primitive.slice.html#method.len

ここでa.len()を最後の行のように書き直してもコンパイルできます、スライスの要素はi8でもカバーされるので、

    let a = [1, 2, 3];
    assert_eq!(a.len(), 3);
    assert_eq!(<[i8]>::len(&a), 3);

ドット記法は実はこのような変換は暗黙で実行されています。それゆえ先のソースコードで、

admin