Raspberry piのDebug Probeを使う(Arduino IDE)

中身はラズピコのDebug Probeを使ってみる、もう一枚ラズピコでファームインストでも良いけど、かさばらないでスマートだから専用品の方が良い

Debug Probeの公式ページは、

https://www.raspberrypi.com/documentation/microcontrollers/debug-probe.html

<動作環境>

M1 MacBook Air/Arduino IDE 2.3.3

USBケーブルはswdの場合にはどちらもダウンロードはデバッガ経由なのでターゲットは電源供給だけで問題ないそうです、実際にはどちらからのダウンロードも使うから最初からデータ転送できるケーヌルにしとけば良いと思いますが、macからの見え方は、

Arduino IDEのToolsの設定は、デバッガーポートが認識されている状態では以下のような選択と見え方です

一点ハマったのは、デバッグ用のglobeボードの捺印のあるコネクタにswd信号はつながっていない事、wでない普通のボードはつながっているのかもしれないけど(ケーブルの色はオレンジ:SWCLK、黒:GND、黄色:SWDIOに対応してます)

でPCB上のviaにピン立てて受けにしてケーブル接続

swdインターフェースがアクティブならば、オレンジと黄色のledが点灯状態になって、Arduino IDEのデバッグも機能します

P.S. 2024/12/1

デバッガーのswdコネクタの半抜け注意

何故か急に繋がらないなと思ったら、コネクタが半抜け状態、この状態では最初にorange/yellow ledが点灯してすぐに消える(エラーになる)

奥まで押し込んだら回復、

<追記:2024/12/24>

デバッグできない(一度止めるとエラー出た)ので、何かと調べるとシリアルポートの設定をこのようにしないといけなかった

% ls /dev/cu.*
/dev/cu.Bluetooth-Incoming-Port	/dev/cu.usbmodem11102
/dev/cu.ESP32			/dev/cu.usbmodem11201

となっているから、デバッグ用にシリアルポートは正しく設定しましょう、このポートはmacのリブートなどで変わるんだろうね

 

admin

ラズピコ wでのLチカから始める

すでにもう1年以上経過しましたが、

ラズパイPico WのRust

のフォローで、embassyを使ったサンプルプログラムでLチカを動かしてみた、とはいっても、ほぼ

https://qiita.com/Azi/items/422c654bb476e0abf118

の手順に則っています、Cargo.tomlのライブラリ版数を最新にしたのと、ソースファイルは通常通りsrcディレクトリ直下に配置しています

全体的に感じるのは、Lチカだけなのに環境構築は作業項目多いし、コードの分量も結構あるということで、MicroPyhtonやArduino言語に比較すると事前の手間がかかるということ

ディレクトリ構成はこんな感じで、config.tomlのrunnerはデバッガ使わないときには修正必要です

build.rsの役割は、

//! This build script copies the `memory.x` file from the crate root into
//! a directory where the linker can always find it at build time.
//! For many projects this is optional, as the linker always searches the
//! project root directory -- wherever `Cargo.toml` is. However, if you
//! are using a workspace or have a more complicated build setup, this
//! build script becomes required. Additionally, by requesting that
//! Cargo re-run the build script whenever `memory.x` is changed,
//! updating `memory.x` ensures a rebuild of the application with the
//! new memory settings.

memory.xはテキストファイルで、picoのメモリの使い方(マッピング)を指定するファイルに見えます

pico用のサンプルプログラムは、

https://github.com/embassy-rs/embassy/tree/main/examples/rp

に他の機能用のサンプルも存在するのでやってみるか

気づきは、① ビルドのオプションで–releaseを指定してもバイナリサイズは変わらないということ、組み込み用のバイナリだとそうなるのかもしれない、② targetディレクトリのサイズが巨大であること、今回の事例でも2.3GB程度の容量になっています

いずれにしろサンプルプログラム動かしてみるのはまだしも、実際にオリジナルのコードを書いたときにはデバッグ環境が必須だから、そこも当たり始めないと組み込みでは使い物にはならない

一番ポピュラーなのはラズパイ財団から出ているデバッグプローブを使うことだろう

https://www.switch-science.com/products/8708

 

admin

systemdサービス起動時の遅延時間設定

Rust版の震度計のアプリを起動時にssd1306の画面が乱れたままで復旧しないことがある、システム起動後の起動では問題ないからspiの初期化が一番怪しいけれども、ともかくもハードウェアに関連するだろうことは間違いない

でsystemdの起動を遅らせれば良いだろうから、そのための設定をググってもなかなか当たらないからPerplexity Labsに聞いてみると、ExecStartPre=/bin/sleepで時間設定すれば良いと言われたのでやってみたら正解

まあ、seismic起動前にsleepで30秒待てと言っているだけなので、ExecStartPreは本来実行したいコマンドの前に実行する処理を記述しているだけなのですが

$ sudo systemctl daemon-reload

$ sudo systemctl enable seismic.service

で設定を有効化して、電源オフ後の再起動では問題ないようです、30秒というのはsshでログインしようとしてログインが可能になるタイミングからさらに10秒近く経過ですが、この時点では全てのサービスがレディになると考えればよさそうです、本来的には時間待ちではなくてどれかのサービス起動後に起動というのが正しそうですが

[Unit]
Description = measure 

[Service]
ExecStartPre=/bin/sleep 30s 
ExecStart=/home/pi/rust/seismic
Restart=no
Type=oneshot

[Install]
WantedBy=multi-user.target

Python版では起動に失敗していたので、serviceファイルで待ち時間設定ではなく、コードの最初で20秒sleep入れてたけど、やり方としてはserviceファイル記述がはるかにスマート

 

admin

ラズパイのGPIO割り込み検出とsystemd設定について

ラズパイにseismicサービスを組み込む時に関連したメモ

① 現状Rust(rppal)ではGPIOで割り込みを検出する手段は提供されていない様子

作ればいいんだろうけど、今の所クレートは存在していないから、従来通りそこだけはPythonのサービスを起動、以下のソースで個別にサービス定義して起動時に実行させておく

#
# wait switch push interrupt and issue shutdown command
#
import time
import datetime
import os
import sys
import RPi.GPIO as GPIO
import subprocess

# Shut down sw is assigned to GPIO17
# GPIO initialize
SHUTDOWN = 17

GPIO.setwarnings(False)
GPIO.setmode(GPIO.BCM)
GPIO.setup(SHUTDOWN, GPIO.IN)
GPIO.setup(SHUTDOWN, GPIO.IN, pull_up_down=GPIO.PUD_UP)

def handle_sw_input():
# wait key inout event
    def switch_callback(gpio_pin):
        subprocess.call('sudo shutdown -h now', shell=True)
#
    GPIO.add_event_detect(SHUTDOWN, GPIO.FALLING,bouncetime=500)
    # when the sw was pushed, call the 'call back routine' 
    GPIO.add_event_callback(SHUTDOWN, switch_callback) 
    return

handle_sw_input()

while True:
    time.sleep(100)

② 今更ですが。/lib/systemd/systemのserviceファイルを変更した時には、以下の処理が必要(既存ファイルの書き換え替えが反映されなかった)

・サービスを登録する(編集したときの反映時にも必要)

$ sudo systemctl daemon-reload

$ sudo systemctl enable seismic.service

 

admin

表示まで含めてRustで実装

ssd1306への表示データをchannel使って別スレッドに送って、その別スレッドでssd1306に震度データを表示させるような構成にして、Python版からRust版に置き換え完了

 

ただし、シャットダウンスイッチを扱うコードはまだ作成していないので、それを追加しないとスタンドアロンで運用はできない

https://github.com/chateight/seismic/blob/main/Rust_version/main_disp.rs

Cargo.tomlの中身は、

[package]
name = "seismic_refatoring"
version = "0.1.0"
edition = "2021"

[dependencies]
chrono = "0.4.38"
rppal = "0.19.0"
linux-embedded-hal = "0.4.0"
embedded-graphics = "0.8.1"
machine-ip = "0.2.1"
ssd1306 = "0.9.0"

震度計プロジェクトも概ね終わりかな

 

admin

 

今の簡易震度計算ロジックの精度の検証

Rustで記述したPython版の震度計算ロジックの精度検証のために、公開データを使って計算させてみた

https://www.data.jma.go.jp/eqev/data/kyoshin/jishin/2401011610_noto/index.html

ここから波形データをcsv形式でダウンロードできるので、外部ファイル読み込みでデータを取り込ませて計算させた

コードは以下のリンクから、

https://github.com/chateight/seismic/tree/main/Rust_version

気象庁の参考震度情報と比較してもほぼ一緒と言えるレベルなので、実用上は問題ないと言えます

あえて修正が必要と思えるのは、

① 加速度センサーと震度波形データのスケール合わせ

② 実際のハードでは加速度計の出力におよそ30Hzの一次ローパスフィルタが入っているので実際の波形データを前処理してみるか

ぐらいですが、まあみたところそこまで必要のなさそうなレベルです、実際の地震計は設置だけでも大変なレベルなのに、それを自宅の部屋で使おうというぐらいだから

P.S. 2024/11/14

微妙に違和感あったので、見直すとVectorでFIFOで使っているのにわざわざリングバッファ扱いでポインタ使って正しくない場所からadc_data持って来ていたので修正

 

admin

震度計のPythonコードをRustに書き換え

ラズパイzeroで作った震度計のコードをRustで書き換えてみた、

https://github.com/p2pquake/rpi-seismometer/blob/master/seismic_scale.py

とりあえず変更点は何もなく置き換えたつもり、

https://github.com/chateight/seismic/tree/main/Rust_version

x/y/zに200.0の固定値を与え続けて、M1 Macで動作させた実行初期の出力される値はこんな感じで、小数点以下二桁目から値が違うのはまだロジックが完全に一致していない可能性がある、実用的には何の問題もないのだけれども

% python -u "/Users/usamiryuuichi/python/seismic.py"
2024-11-08 19:49:45.068661 scale: 0  frame: 0
2024-11-08 19:49:45.169671 scale: 0  frame: 20
2024-11-08 19:49:45.269686 scale: 0  frame: 40
2024-11-08 19:49:45.369185 scale: 4.141110582455145  frame: 60
2024-11-08 19:49:45.469702 scale: 5.676822095241448  frame: 80
2024-11-08 19:49:45.569745 scale: 5.676822095241448  frame: 100
2024-11-08 19:49:45.669175 scale: 5.676822095241448  frame: 120
2024-11-08 19:49:45.769694 scale: 5.676822095241448  frame: 140


% cargo run --release
    Finished `release` profile [optimized] target(s) in 0.01s
     Running `target/release/seismic`
time: 2024-11-08 22:28:28.151209 UTC, scale: 0, frame: 0
time: 2024-11-08 22:28:28.252217 UTC, scale: 0, frame: 20
time: 2024-11-08 22:28:28.351601 UTC, scale: 0, frame: 40
time: 2024-11-08 22:28:28.451895 UTC, scale: 4.18249, frame: 60
time: 2024-11-08 22:28:28.552350 UTC, scale: 5.681231, frame: 80
time: 2024-11-08 22:28:28.652210 UTC, scale: 5.681231, frame: 100
time: 2024-11-08 22:28:28.751913 UTC, scale: 5.681231, frame: 120
time: 2024-11-08 22:28:28.852249 UTC, scale: 5.681231, frame: 140

次のステップの能登の地震波形から、気象庁の震度データ波形と簡易計算結果とを比較してみること、簡易方式は30Hzあたりでアナログ的に一次のLPF掛けてるから、波形データに対して同等の前処理が必要かもしれないし、近似度がそれほでないデータならそれはおそらく無意味

 

admin

別のスレッドにメッセージを送る(@Rust)

現在のRustは非同期処理は得意な分野で(OS開発にも使われるぐらいだから当然)、非同期処理だけで書籍があるぐらい奥も深い

ここでは単純に別のスレッドにメッセージを送ることだけをやってみた

Rustではスレッド間通信はクロージャーを使うようで、rust-lang.orgのサンプルコードを多少変えています

//
// https://doc.rust-lang.org/std/thread/fn.spawn.html
//
use std::thread;
use std::sync::mpsc::channel;
use std::time::Duration;

fn main() {
    // チャネルを作成
    let (tx, rx) = channel();

    // レシーバースレッドをspawn
    let _receiver = thread::spawn(move || {
        let value: String = rx.recv().expect("Unable to receive from channel");
        rcv(value.clone());
    });

    // センダースレッドをspawn
    let _sender = thread::spawn(move || {
        tx.send("Hello, thread".to_owned())
            .expect("Unable to send on channel");
    });

    // センダースレッドの終了を待つ
    //sender.join().expect("The sender thread has panicked");

    // レシーバースレッドの終了を待つ(但し、rcv関数の終了を待たない)
    //receiver.join().expect("The receiver thread has panicked");

    println!("reach to the end");
    thread::sleep(Duration::from_secs_f32(1.5));
}

fn rcv(value: String) {
    thread::sleep(Duration::from_secs_f32(1.0));
    println!("recieved : {}", value);
}

このコードではsenderもreceiverも終了を待たないようにしていますが、その場合にはrcv関数の方が時間が遥かにかかるので、main関数の最後の時間待ちがないとrev()の実行は途中で打ち切られます

今回のケースでは相互にデータをやり取りや完了を待つわけではなく、main関数からrcv関数にメッセージを送りたいだけなのでこのような構成で十分です

さらに言えば、senderスレッドを別に起こさなくとも直接tx.send()を実行しても構いません

もし完全に非同期処理が必要ならばasync/awaitの出番ですが、これはgolangと結構類似しているように思います

 

admin

Rustでspi経由でmcp3204からのデータを読み取る

最初このクレートを使おうと思いましたが、

https://github.com/trashware/mcp3xxx-rs

開発が5年前で、かなり古くて依存先のrppalの版数が0.11.0までになってます、rppalではspi経由のデータやり取りはコマンドストリームの送信と結果のストリームが全二重で処理できるから、別に直接ビット列を用意すればクレート使わなくても良いわけで、最終的に以下のコードで読み取りできました

Cargo.tomlではrppalは最新版を指定しています

use rppal::spi::{Bus, Mode, SlaveSelect, Spi};
use std::thread;
use std::time::Duration;

const CHANNEL_0: u8 = 0x06 | 0x00; // Command byte for single-ended mode

fn main() {
    // Create a SPI object
    let spi = Spi::new(Bus::Spi0, SlaveSelect::Ss0, 1_000_000, Mode::Mode0).unwrap();

    // Define the buffers for reading and writing
    let mut read_buffer = [0u8; 3];
    let write_buffer = [CHANNEL_0, 0x00, 0x00];

    // Poll the sensor every n seconds
    let poll_rate = Duration::from_secs(1);
    loop {
        // Perform the SPI transfer
        spi.transfer(&mut read_buffer, &write_buffer).unwrap();

        // Extract the 12-bit ADC value
        // Note: MCP3204 returns 12-bit data, but the second byte contains status bit(0) and the MSB of the result.
        let msb = (read_buffer[1] & 0x0F) as u16;
        let lsb = read_buffer[2] as u16; // Convert third byte to u16
        let result = (msb << 8) | lsb;

        println!("Sensor value: {}", result);      

        println!("{:08b}, {:08b}", read_buffer[1], read_buffer[2]);

        thread::sleep(poll_rate);
    }
}
[dependencies]
rppal = "0.19.0"

spi上のストリーム情報はデバイスの仕様から、SGLモードを使うので1バイト目にはstartビットと合わせて6を指定すれば良いことになります

コードサンプルではch0の読み取りを行なってますが、このビット列を変更することで他のチャネル情報も取得できます

以下は実行した時の様子

$ ./adc_rppal
Sensor value: 2867
00001011, 00110011
Sensor value: 2867
00001011, 00110011
Sensor value: 2867
00001011, 00110011
Sensor value: 2867
00001011, 00110011
Sensor value: 2868
00001011, 00110100

 

admin

VMwareのUbuntuがクラッシュした

Intel MacのVMwareのUbuntuが立ち上がらなくなった、「コピーしますか」とかいうポップアップ出ていてそれが関連するかどうかだけれども、ともかくも身動き取れなくなったからSSDにバックアップしていた仮想マシンバックアップをコピー戻してで修復、区画は大きめに取っていても実際のサイズでコーピーが終了するようだ、つまり全領域の復元はやらないということ

ついでにVMwareのアップデートも適用、Ubuntu20系のサポートは来年5月までだからそれほど残り時間はない

 

admin