Siriuth's Diary: Raspberry pi 4b

ラベル Raspberry pi 4b の投稿を表示しています。すべての投稿を表示

2022年5月6日金曜日

raspberry pi 4b: w1_master_driver w1_bus_master1: Family 0 for 00.400000000000.46 is not registered.

GW最初に寝かせていたraspberry piをmotionだけ一時的に使いたかったので電源を入れてみたところ、SDカードが不調になったので別のSDカードにインストールして動かしていたのですが、syslogを今まで見かけたことのないエラーが繰り返し表示されていた。

そのログは起動時は問題ないが、起動後にエラーが繰り返している様子。

May  4 13:30:34 rasp4b4g kernel: [    7.687656] w1_master_driver w1_bus_master1: w1_search: max_slave_count 64 reached, will continue next search.

May  4 13:40:25 rasp4b4g kernel: [   58.337671] w1_master_driver w1_bus_master1: Attaching one wire slave 00.800000000000 crc 8c
May  4 13:40:25 rasp4b4g kernel: [   58.346399] w1_master_driver w1_bus_master1: Family 0 for 00.800000000000.8c is not registered.
May  4 13:41:28 rasp4b4g kernel: [  121.919916] w1_master_driver w1_bus_master1: Attaching one wire slave 00.400000000000 crc 46
May  4 13:41:28 rasp4b4g kernel: [  121.928212] w1_master_driver w1_bus_master1: Family 0 for 00.400000000000.46 is not registered.
May  4 13:42:19 rasp4b4g kernel: [  172.702498] w1_master_driver w1_bus_master1: Attaching one wire slave 00.c00000000000 crc ca
May  4 13:42:19 rasp4b4g kernel: [  172.710612] w1_master_driver w1_bus_master1: Family 0 for 00.c00000000000.ca is not registered.
May  4 13:43:35 rasp4b4g kernel: [  249.143787] w1_master_driver w1_bus_master1: Attaching one wire slave 00.200000000000 crc 23
May  4 13:43:35 rasp4b4g kernel: [  249.149572] w1_master_driver w1_bus_master1: Family 0 for 00.200000000000.23 is not registered.
May  4 13:40:25 rasp4b4g kernel: [   58.337671] w1_master_driver w1_bus_master1: Attaching one wire slave 00.800000000000 crc 8c
May  4 13:40:25 rasp4b4g kernel: [   58.346399] w1_master_driver w1_bus_master1: Family 0 for 00.800000000000.8c is not registered.
May  4 13:41:28 rasp4b4g kernel: [  121.919916] w1_master_driver w1_bus_master1: Attaching one wire slave 00.400000000000 crc 46
May  4 13:41:28 rasp4b4g kernel: [  121.928212] w1_master_driver w1_bus_master1: Family 0 for 00.400000000000.46 is not registered.
May  4 13:42:19 rasp4b4g kernel: [  172.702498] w1_master_driver w1_bus_master1: Attaching one wire slave 00.c00000000000 crc ca
May  4 13:42:19 rasp4b4g kernel: [  172.710612] w1_master_driver w1_bus_master1: Family 0 for 00.c00000000000.ca is not registered.
May  4 13:43:35 rasp4b4g kernel: [  249.143787] w1_master_driver w1_bus_master1: Attaching one wire slave 00.200000000000 crc 23
May  4 13:43:35 rasp4b4g kernel: [  249.149572] w1_master_driver w1_bus_master1: Family 0 for 00.200000000000.23 is not registered.
May  4 13:44:39 rasp4b4g kernel: [  312.726603] w1_master_driver w1_bus_master1: Attaching one wire slave 00.a00000000000 crc af
May  4 13:44:39 rasp4b4g kernel: [  312.736281] w1_master_driver w1_bus_master1: Family 0 for 00.a00000000000.af is not registered.
May  4 13:45:17 rasp4b4g kernel: [  350.645643] w1_master_driver w1_bus_master1: Attaching one wire slave 00.600000000000 crc 65
May  4 13:45:17 rasp4b4g kernel: [  350.656778] w1_master_driver w1_bus_master1: Family 0 for 00.600000000000.65 is not registered.
May  4 13:45:57 rasp4b4g kernel: [  391.145835] w1_master_driver w1_bus_master1: Attaching one wire slave 00.e00000000000 crc e9
May  4 13:45:57 rasp4b4g kernel: [  391.154513] w1_master_driver w1_bus_master1: Family 0 for 00.e00000000000.e9 is not registered.
May  4 13:47:00 rasp4b4g kernel: [  454.127072] w1_master_driver w1_bus_master1: Attaching one wire slave 00.100000000000 crc 9d
May  4 13:47:00 rasp4b4g kernel: [  454.135840] w1_master_driver w1_bus_master1: Family 0 for 00.100000000000.9d is not registered.
May  4 13:47:40 rasp4b4g kernel: [  493.277022] w1_master_driver w1_bus_master1: Attaching one wire slave 00.900000000000 crc 11
May  4 13:47:40 rasp4b4g kernel: [  493.284808] w1_master_driver w1_bus_master1: Family 0 for 00.900000000000.11 is not registered.
May  4 13:48:55 rasp4b4g kernel: [  568.486570] w1_master_driver w1_bus_master1: Attaching one wire slave 00.500000000000 crc db
May  4 13:48:55 rasp4b4g kernel: [  568.494303] w1_master_driver w1_bus_master1: Family 0 for 00.500000000000.db is not registered.
May  4 13:49:47 rasp4b4g kernel: [  620.475808] w1_master_driver w1_bus_master1: Attaching one wire slave 00.d00000000000 crc 57
May  4 13:49:47 rasp4b4g kernel: [  620.484518] w1_master_driver w1_bus_master1: Family 0 for 00.d00000000000.57 is not registered.
May  4 13:50:13 rasp4b4g kernel: [  646.925677] w1_master_driver w1_bus_master1: Attaching one wire slave 00.300000000000 crc be
May  4 13:50:13 rasp4b4g kernel: [  646.933426] w1_master_driver w1_bus_master1: Family 0 for 00.300000000000.be is not registered.
May  4 13:51:03 rasp4b4g kernel: [  696.325929] w1_master_driver w1_bus_master1: Attaching one wire slave 00.b00000000000 crc 32
May  4 13:51:03 rasp4b4g kernel: [  696.335037] w1_master_driver w1_bus_master1: Family 0 for 00.b00000000000.32 is not registered.
May  4 13:51:42 rasp4b4g kernel: [  735.565958] w1_master_driver w1_bus_master1: Attaching one wire slave 00.700000000000 crc f8
May  4 13:51:42 rasp4b4g kernel: [  735.574970] w1_master_driver w1_bus_master1: Family 0 for 00.700000000000.f8 is not registered.
May  4 13:52:34 rasp4b4g kernel: [  787.545977] w1_master_driver w1_bus_master1: Attaching one wire slave 00.f00000000000 crc 74
May  4 13:52:34 rasp4b4g kernel: [  787.553953] w1_master_driver w1_bus_master1: Family 0 for 00.f00000000000.74 is not registered.
May  4 13:53:36 rasp4b4g kernel: [  850.006573] w1_master_driver w1_bus_master1: Attaching one wire slave 00.080000000000 crc c2
May  4 13:53:36 rasp4b4g kernel: [  850.014503] w1_master_driver w1_bus_master1: Family 0 for 00.080000000000.c2 is not registered.
May  4 13:54:30 rasp4b4g kernel: [  903.266685] w1_master_driver w1_bus_master1: Attaching one wire slave 00.880000000000 crc 4e
May  4 13:54:30 rasp4b4g kernel: [  903.274555] w1_master_driver w1_bus_master1: Family 0 for 00.880000000000.4e is not registered.
May  4 13:55:07 rasp4b4g kernel: [  941.107598] w1_master_driver w1_bus_master1: Attaching one wire slave 00.480000000000 crc 84
May  4 13:55:07 rasp4b4g kernel: [  941.116282] w1_master_driver w1_bus_master1: Family 0 for 00.480000000000.84 is not registered.
May  4 13:55:58 rasp4b4g kernel: [  991.797850] w1_master_driver w1_bus_master1: Attaching one wire slave 00.c80000000000 crc 08
May  4 13:55:58 rasp4b4g kernel: [  991.805829] w1_master_driver w1_bus_master1: Family 0 for 00.c80000000000.08 is not registered.
May  4 13:57:15 rasp4b4g kernel: [ 1068.479304] w1_master_driver w1_bus_master1: Attaching one wire slave 00.280000000000 crc e1
May  4 13:57:15 rasp4b4g kernel: [ 1068.488104] w1_master_driver w1_bus_master1: Family 0 for 00.280000000000.e1 is not registered.
May  4 13:58:18 rasp4b4g kernel: [ 1131.990488] w1_master_driver w1_bus_master1: Attaching one wire slave 00.a80000000000 crc 6d
May  4 13:58:18 rasp4b4g kernel: [ 1131.999217] w1_master_driver w1_bus_master1: Family 0 for 00.a80000000000.6d is not registered.
May  4 13:59:22 rasp4b4g kernel: [ 1195.491899] w1_master_driver w1_bus_master1: Attaching one wire slave 00.680000000000 crc a7
May  4 13:59:22 rasp4b4g kernel: [ 1195.500845] w1_master_driver w1_bus_master1: Family 0 for 00.680000000000.a7 is not registered.
May  4 14:00:02 rasp4b4g kernel: [ 1235.942504] w1_master_driver w1_bus_master1: Attaching one wire slave 00.e80000000000 crc 2b
May  4 14:00:02 rasp4b4g kernel: [ 1235.951466] w1_master_driver w1_bus_master1: Family 0 for 00.e80000000000.2b is not registered.
May  4 14:01:05 rasp4b4g kernel: [ 1299.103551] w1_master_driver w1_bus_master1: Attaching one wire slave 00.180000000000 crc 5f
May  4 14:01:05 rasp4b4g kernel: [ 1299.112035] w1_master_driver w1_bus_master1: Family 0 for 00.180000000000.5f is not registered.
May  4 14:01:45 rasp4b4g kernel: [ 1338.304235] w1_master_driver w1_bus_master1: Attaching one wire slave 00.980000000000 crc d3
May  4 14:01:45 rasp4b4g kernel: [ 1338.312876] w1_master_driver w1_bus_master1: Family 0 for 00.980000000000.d3 is not registered.
May  4 14:02:34 rasp4b4g kernel: [ 1387.584971] w1_master_driver w1_bus_master1: Attaching one wire slave 00.580000000000 crc 19
May  4 14:02:34 rasp4b4g kernel: [ 1387.594343] w1_master_driver w1_bus_master1: Family 0 for 00.580000000000.19 is not registered.

ある程度抜き出してみたが、w1と言われて心当たりがありそうなのはone wire絡みなのか？と言うところ。初期設定でインタフェースは有効にした記憶があるが、まだプログラムは動かしていない。物理的につながっているのはI2Cと、ただのIOポートにぶら下がっている温度計だけのはず。なんにしても今までこんなエラーの記憶は全くない。なので検索してみるとraspberry pi 公式のアーティクルがヒットした。

w1_master_driver w1_bus_master1: Family 0 for 00.200000000000.23 is not registered. - Raspberry Pi Forums

細かいt頃が全く分からないものの、、最終的にはraspi-configで1wireインターフェースをオフにするということ。フォーラム内ではなぜか直接/boot/configを修正する感じになっていた。

インタフェースをオフにしてデバイスが使えなくても今は問題がないので、早速インタフェースをオフに。そして再起動。

ログを見る限りエラーは出なくなった。4bだとone wireが使えないのか接続すればエラーが無くなるのかはよくわからない、

2021年3月10日水曜日

以下のパッケージは保留されます

raspberry pi でapt upgradeをしていて引っかかるパッケージが出てきました。

pi@rasp4b4g:~ $ sudo apt upgrade
パッケージリストを読み込んでいます... 完了
依存関係ツリーを作成しています
状態情報を読み取っています... 完了
アップグレードパッケージを検出しています... 完了
以下のパッケージは保留されます:
raspberrypi-ui-mods
アップグレード: 0 個、新規インストール: 0 個、削除: 0 個、保留: 1 個。

この先日rasp3bをアップデートしててやたらと紐づいたパッケージがインストールされていた時に見かけたパッケージ名です。

ざっくりと「以下のパッケージは保留されます」で検索すると、debianのケースのブログ記事が上がっていました。念のために詳細を調べてアップデートのテストを行ってエラーが出ないことを確認した上で、dist-upgradeさせるのがよさそうです。

pi@rasp4b4g:~ $ sudo apt list --upgradable
一覧表示... 完了
raspberrypi-ui-mods/testing 1.20201210+nmu1 all [1.20200611 からアップグレード可]
N: 追加バージョンが 1 件あります。表示するには '-a' スイッチを付けてください。
pi@rasp4b4g:~ $ sudo apt list --upgradable -a
一覧表示... 完了
raspberrypi-ui-mods/testing 1.20201210+nmu1 all [1.20200611 からアップグレード可]
raspberrypi-ui-mods/now 1.20200611 all [インストール済み、1.20201210+nmu1 にアップグレード可]

pi@rasp4b4g:~ $ sudo apt -s dist-upgrade
パッケージリストを読み込んでいます... 完了
依存関係ツリーを作成しています
状態情報を読み取っています... 完了
アップグレードパッケージを検出しています... 完了
以下のパッケージが自動でインストールされましたが、もう必要とされていません:
lxplug-volume
これを削除するには 'sudo apt autoremove' を利用してください。
以下のパッケージが新たにインストールされます:
gui-pkinst lxplug-volumepulse pi-printer-support printer-driver-escpr
以下のパッケージはアップグレードされます:
raspberrypi-ui-mods
アップグレード: 1 個、新規インストール: 4 個、削除: 0 個、保留: 0 個。
Inst gui-pkinst (0.2 Raspberry Pi Foundation:testing [armhf])
Inst lxplug-volumepulse (0.4 Raspberry Pi Foundation:testing [armhf])
Inst pi-printer-support (1.1 Raspberry Pi Foundation:testing [all])
Inst printer-driver-escpr (1.7.8-1~bpo10+1 Raspberry Pi Foundation:testing [armhf])
Inst raspberrypi-ui-mods [1.20200611] (1.20201210+nmu1 Raspberry Pi Foundation:testing [armhf])
Conf gui-pkinst (0.2 Raspberry Pi Foundation:testing [armhf])
Conf lxplug-volumepulse (0.4 Raspberry Pi Foundation:testing [armhf])
Conf pi-printer-support (1.1 Raspberry Pi Foundation:testing [all])
Conf printer-driver-escpr (1.7.8-1~bpo10+1 Raspberry Pi Foundation:testing [armhf])
Conf raspberrypi-ui-mods (1.20201210+nmu1 Raspberry Pi Foundation:testing [armhf])
pi@rasp4b4g:~ $ sudo apt dist-upgrade
パッケージリストを読み込んでいます... 完了
依存関係ツリーを作成しています
状態情報を読み取っています... 完了
アップグレードパッケージを検出しています... 完了
以下のパッケージが自動でインストールされましたが、もう必要とされていません:
lxplug-volume
これを削除するには 'sudo apt autoremove' を利用してください。
以下のパッケージが新たにインストールされます:
gui-pkinst lxplug-volumepulse pi-printer-support printer-driver-escpr
以下のパッケージはアップグレードされます:
raspberrypi-ui-mods
アップグレード: 1 個、新規インストール: 4 個、削除: 0 個、保留: 0 個。
752 kB のアーカイブを取得する必要があります。
この操作後に追加で 892 kB のディスク容量が消費されます。
続行しますか? [Y/n] y
取得:1 http://archive.raspberrypi.org/debian buster/main armhf gui-pkinst armhf 0.2 [127 kB]
取得:2 http://archive.raspberrypi.org/debian buster/main armhf lxplug-volumepulse armhf 0.4 [19.4 kB]
取得:3 http://archive.raspberrypi.org/debian buster/main armhf pi-printer-support all 1.1 [2,272 B]
取得:4 http://archive.raspberrypi.org/debian buster/main armhf printer-driver-escpr armhf 1.7.8-1~bpo10+1 [281 kB]
取得:5 http://archive.raspberrypi.org/debian buster/main armhf raspberrypi-ui-mods armhf 1.20201210+nmu1 [323 kB]
752 kB を 3秒で取得しました (249 kB/s)
changelog を読み込んでいます... 完了
以前に未選択のパッケージ gui-pkinst を選択しています。
(データベースを読み込んでいます ... 現在 221614 個のファイルとディレクトリがインストールされています。)
.../gui-pkinst_0.2_armhf.deb を展開する準備をしています ...
gui-pkinst (0.2) を展開しています...
以前に未選択のパッケージ lxplug-volumepulse を選択しています。
.../lxplug-volumepulse_0.4_armhf.deb を展開する準備をしています ...
lxplug-volumepulse (0.4) を展開しています...
以前に未選択のパッケージ pi-printer-support を選択しています。
.../pi-printer-support_1.1_all.deb を展開する準備をしています ...
pi-printer-support (1.1) を展開しています...
以前に未選択のパッケージ printer-driver-escpr を選択しています。
.../printer-driver-escpr_1.7.8-1~bpo10+1_armhf.deb を展開する準備をしています ...
printer-driver-escpr (1.7.8-1~bpo10+1) を展開しています...
.../raspberrypi-ui-mods_1.20201210+nmu1_armhf.deb を展開する準備をしています ...
dpkg-query: パッケージ 'raspberrypi-ui-mods' はまだインストールされていません
Use dpkg --contents (= dpkg-deb --contents) to list archive files contents.
raspberrypi-ui-mods (1.20201210+nmu1) で (1.20200611 に) 上書き展開しています ...
lxplug-volumepulse (0.4) を設定しています ...
printer-driver-escpr (1.7.8-1~bpo10+1) を設定しています ...
gui-pkinst (0.2) を設定しています ...
raspberrypi-ui-mods (1.20201210+nmu1) を設定しています ...
新バージョンの設定ファイル /etc/xdg/lxpanel/LXDE-pi/panels/panel をインストールしています ...
新バージョンの設定ファイル /etc/xdg/openbox/lxde-pi-rc.xml をインストールしています ...
ユーザ `root' をグループ `lpadmin' に追加しています...
ユーザ root をグループ lpadmin に追加
完了。
ユーザ `pi' をグループ `lpadmin' に追加しています...
ユーザ pi をグループ lpadmin に追加
完了。
The desktop has been updated.
To apply the updates, please reboot your Pi, and then select one of the options on the Defaults page in Appearance Settings.
pi-printer-support (1.1) を設定しています ...
shared-mime-info (1.10-1) のトリガを処理しています ...
cups (2.2.10-6+deb10u4) のトリガを処理しています ...
Updating PPD files for escpr ...
pi@rasp4b4g:~ $

解放されるパッケージと追加されるパッケージを見る限りraspberrypi-ui-modsの機能の追加変更で、紐づいたパッケージが変わったみたいです。パッケージ名からボリュームとプリンターへの対応が変わったみたいですね。

なぜアップデートを掛けたかといえば、Raspberry pi 4B 4Gモデルが、原因不明のダウンが発生しているからなんです。それがちょうど昨日の夜中に発生し、最初はネットワークダウンかと思っていたのですが、LAN回線を抜き差ししてもネットワーク越しから反応せず、USBキーボードを接続しても、キーボードのNUMLOCKなどが反応せず。死亡確定です。

前回この謎のダウンが発生した時も、USBカメラのランプがついていたので内部は動いているのだろうと思っていましたが、半月ほど経ってから電源を入れなおして再起動させたのですが、その時に温度ロガーやmotionの記録が残っていなかったのでシステムダウンしていたことが分かったのですが。残念なことにログはRamへ残しているだけなので原因は不明です。

なので、淡い期待を持ってアップデートしてみました。システムダウンについて検索してみると、raspberry pi 4bは電源周りや温度上昇によるダウンがあるだけで、ソフトウェア的な記事は見つけることができませんでした。電源や温度上昇に関するファームウェアアップデートがあるので、ファームウェアを更新することで安定するかもしれませんが、残されたてはファームウェア更新ぐらいでしょうか。

2020年8月7日金曜日

実行時間の計測

全体でどのくらいの負荷がかかっているのか気になったのでどんな手段があるのか検索してみました。

Linuxでシェルレベルの時間計測は３つの方法がありそうです。

timeコマンドを利用する
dateコマンドを利用する
bashで利用可能なSECONDS変数を利用する

timeコマンドは秒単位ですが小数点を表示しているのでミリ秒程度の精度はあるようです。dateコマンドとSECONDS変数は秒単位となります。

コマンドレベルで利用するのに便利なのはtimeで、シェルスクリプトで利用するなら表示形態によってdateコマンドかSECONDS変数を利用するか変わるのではないでしょうか。

試しに実行してみました

pi@rasp4b4g:~/gpioread $ time ./dht2 -h
未知のオプションが指定されました。

dht ver.0.1 debugコードコミコミ版

指定可能なオプション
--debug : デバッグ情報の表示
--gpio n : GPIOピン番号(デフォルトはGPIO5番).
--type x : DHT11かDHT22を指定する。(デフォルトはDHT11)大文字、小文字の判別はしない。
        指定された型の手順でセンサーから読込み、湿度、温度を出力するが、
        読込んだデータをもとに判定しできる限り出力する。
        ただし、その時のリターンコードはエラーとなる。
--oneread : 無指定時はセンサーから2回読込み、2回目に取得した値を出力する。
        このオプションが指定されるとセンサーからの読込を1回だけに限定する。
        センサーがスリープしていた場合はスリープ前の値が出力される。

real    0m0.010s
user    0m0.000s
sys     0m0.011s

最初からなんか数字がおかしい感じなので調べてみると

real > user + sys

という関係になると思いますが、0.001sずれている結果に。

気を取り直して、同じような状態になるようにオプションをつけてcで作成したものとpythonとで比較したいと思います。

pi@rasp4b4g:~/gpioread $ time ./dht2 --oneread
temperature : 35.6
humidity : 60.0

real    0m0.044s
user    0m0.001s
sys     0m0.043s
pi@rasp4b4g:~/gpioread $ time python3 ./dht.py --onetime --nodirect
DHT results.
Conversion : DHT11V1.3
Temperature : 35.5 C
Humidity    : 60.0 %

real    0m0.257s
user    0m0.136s
sys     0m0.052s

実行時間で比較すると0.2s程度python側の方が時間がかかっているようです。実行時間が長いpythonでは確実に割り込みによって実行時間が伸びている感じがします。

この差の大小を考えるには運用方法とそれぞれの利点と欠点を比較する必要がありますね。
個人レベルとしては、

ソースファイルと実行ファイルが分かれていないので、管理コストがかなり低い。
ほとんどのことがpythonだけで完結する。
ライブラリなども動的にリンクさせて実行できる。

といったpythonの利点がかなり有利なのでpython以外の選択肢はない気がしていますが、それでも常駐させるような形のものをpythonで書くのはどうかという部分も引っかかっています。

この数字はその時の判断材料となりそうです。

c側のコマンドがサンプリングバッファを利用しない形に対応していないので --nodirectとして実行していますが、先日書き換えた結果どのくらい効果があったのか見てみたいと思います。

pi@rasp4b4g:~/gpioread $ time python3 ./dht.py --onetime
DHT results.
Conversion : DHT11V1.3
Temperature : 35.6 C
Humidity    : 60.0 %

real    0m0.246s
user    0m0.134s
sys     0m0.042s

時間にして0.257s - 0.246s = 0.011s まぁこんなものでしょうｗメモリー操作なら数メガ単位の操作にならなければ、個人レベルのデータ量であればそこまで気にする必要はなさそうです。

2020年8月5日水曜日

無駄にpython側でもダイレクトにdataformatへ格納する処理を作ってみた

スクリプト的に流れが気に入らなかったので、結局pythonでもドライバで実装したサンプリング配列を作らないで直接dataformatを作成する処理を実装することに。

ついでに異常値に色付けなども行ってみました。

ドライバを介さないと途端に割り込み処理による取りこぼしが発生していました。

pi@rasp4b4g:~/gpioread $ python3 ./dht.py --debug --nodriver
Output for debugging.
gpio_no : 5
No driver is used.
OSError : 1 IsNoDriver
Sampling is performed without using a driver.
respons low  : 82
respons high : 87
data low     : 51 ～ 55
data high '0': 23 ～ 26
data high '1': 69 ～ 72
data format : 3F 00 23 06 68
2nd read.
OSError : 1 IsNoDriver
Sampling is performed without using a driver.
respons low  : 85
respons high : 89
data low     : 43 ～ 113
data high '0': 21 ～ 29
data high '1': 66 ～ 73
data format : 2F 00 23 06 68
CRC Error.
ErrorCode :  2  retry.
OSError : 1 IsNoDriver
Sampling is performed without using a driver.
respons low  : 82
respons high : 87
data low     : 48 ～ 133
data high '0': 21 ～ 29
data high '1': 65 ～ 72
data format : 3F 00 23 06 D0
CRC Error.
ErrorCode :  2  retry.
OSError : 1 IsNoDriver
Sampling is performed without using a driver.
respons low  : 88
respons high : 87
data low     : 48 ～ 58
data high '0': 21 ～ 29
data high '1': 65 ～ 72
data format : 3F 00 23 06 68
DHT results.
Retry count : 2 time(s)
Conversion  : DHT11V1.3
Temperature : 35.6 C
Humidity    : 63.0 %

不完全とはいえ、こうなると割り込み停止させるためにメモリマップドレジスタに展開されている割り込み停止処理も入れておきたくはなります。個人的にはそれよりドライバをちゃんと登録して、再起動時にも読み込まれるようにするのが先の様な気がしますｗ

サンプリングせずにダイレクトにビットを格納してみると…

作業としてはあまり大変そうではなかったので、コピペして切り張りして試してみました。

最初、ちょっと間違えてLOW信号の長さを見てしまったため、FFFFFFFFFFになってしまいましたが、見直してすぐに正しい処理が流れてよかったｗ

インターバルのデバッグもそのままコピーしたのでログから実行時間を比べてみました。

2020年8月4日火曜日

サイクルカウントのウェイトを作成してGPIOのPull Up/Downを実装してみました。

150Cycleのウェイトループが作れるようになったのでドライバ側でpull up/downの実装も行ってみました。これで一歩踏み込んだ形になります。

ただし、データシート上に記載してありましたが、pull up/downの設定値はcpuから見えなくなるため、設定値はソフト側で管理する必要があるとのこと。なので、これを行うとRpi.gpioの内部バッファと実際値のズレが生じてRpi.gpoiでうまく機能しなくなる可能性があります。

実装中に色々と新たな発見というか記載を見かけて色々な部分を書き換えながら実装していましたが、一番気になったのがioremapでアクセスできるようになったメモリーに対してアクセスするためにioread/iowriteといった関数を通す必要があるらしいという点。

2020年8月2日日曜日

ARMのサイクルカウンタ

先の投稿でARMなにがしの手順はあったのですが、結局Raspberry piで使えるのかどうか確認するのにえらい手間取りました。

そもそもARMでの開発をするためのバイブルなんて一切ないので。

昔は書店に行って「やっぱりない」と言うことがとても多く、無駄なお金を使っていましたが、今ならアマゾンとかあるので、、、

だからポチるのか？と言われれば、まずは下調べからしないと痛い目を見そうですし、そもそもARMの種類ってよくわかんないんですよねｗ気づけば64bitだとか。

とりあえずダイレクトで検索して見るとバイブルっぽいPDFがいくつかありました。

さらに、Raspberry pi 2bで採用されているARMv7の仕様書っぽい感じのものがありました。

https://static.docs.arm.com/ddi0406/c/DDI0406C_C_arm_architecture_reference_manual.pdf

英語なので細かい所はさっぱりですが、コードとその場のノリでなんとなく必要なことが見えてきました。

少なくてもRaspberry pi 2bなら ARM Coretex-A9と同じ手順で行けそうな気配がしてきました。

Raspberry pi 3bとかはARM Coretex-A53とかA72とか互換性はどんな風になってるのか想像できません…下位互換性なCPUでも結構維持されていなかったりするのであれなんですが、そもそもの拡張のされ方とか内容と型番を覚えるのが苦手なので正直つらいですｗ

パフォーマンスカウンタが複数設定できそうなところとかが良くわかってませんが、一つ一つ確認したところポイントは変わっていないのが確認できました。

まぁ最悪カーネルパニックになるだけなので、とっとと試したいと思います。

ARM LinuxのユーザプログラムからCortex-A9のサイクルカウンタを利用する

ソースファイルなどを準備して、まずは…権限付与ドライバからいきましょうかね。

pi@rasp4b4g:~/pmon $ ls
Makefile  pmon_ca9.h  pmuser.c  test.c
pi@rasp4b4g:~/pmon $ make
make -C /lib/modules/5.4.51-v7l+/build M=/home/pi/pmon modules
make[1]: ディレクトリ '/usr/src/linux-headers-5.4.51-v7l+' に入ります
  CC [M]  /home/pi/pmon/pmuser.o
  Building modules, stage 2.
  MODPOST 1 modules
  CC [M]  /home/pi/pmon/pmuser.mod.o
  LD [M]  /home/pi/pmon/pmuser.ko
make[1]: ディレクトリ '/usr/src/linux-headers-5.4.51-v7l+' から出ます
pi@rasp4b4g:~/pmon $ ls
Makefile        modules.order  pmuser.c   pmuser.mod    pmuser.mod.o  test.c
Module.symvers  pmon_ca9.h     pmuser.ko  pmuser.mod.c  pmuser.o

ドライバが作れる環境なのと、すこしmakeを調べたので手直しすべき部分はあっさりとクリアｗ

さて…

pi@rasp4b4g:~/pmon $ gcc -o test test.c
pi@rasp4b4g:~/pmon $ ./test
Illegal instruction

権限がないと、例外が発生するのも確認。

pi@rasp4b4g:~/pmon $ sudo insmod ./pmuser.ko
pi@rasp4b4g:~/pmon $ ./test
time = 94, x = 500500
pi@rasp4b4g:~/pmon $ ./test
time = 105, x = 500500
pi@rasp4b4g:~/pmon $ ./test
time = 94, x = 500500

無事動作確認が取れました！

ARM Cortex-A72の4bで行けたから2b以降なら大丈夫でしょう(ただし32bit環境)…ということで。

これで…150サイクルが実現できて、ドライバ内で処理が完結しやすくなります。

pi@rasp4b4g:~/pmon $ sudo rmmod pmuser

で削除するか再起動をお忘れなく…

湿度が下がってかなり楽にはなったけど、温度が上がってくるときになることは…

昨日から関東上空に停滞続けていた梅雨前線の中央が消滅したと同時に湿度が下がりようやく梅雨明けしました。

昨日の午前中はまだ若干部屋の中の湿度が高めだったのですが、午後からはようやく夏の気候になりました。それでも日本の夏は湿度高めですが…

気温が低くても湿度が高いと体感温度はかなり上がってしまうので、正直２週間ほど前の状態よりは体感温度は低く感じますが、温度計を見ると結構上がってました。

そこで気になるのは…そうですRaspberry piの本体温度ですｗ

2020年8月1日土曜日

気になる部分を書き換え中に気付いたこと

今日はraspberry pi 4bで動かしていますが、気になったこと。

python側もサンプリング時のループ回数を表示させてみたところ、cで試していた時とは違った違いが出てきました。dhtセンサーの値を2連続で取得しているのですが、１回目と2回目の差が出てきています。

array('I', [11, 82, 88, 53, 25, 54, 70, 54, 24, 54, 24, 54, 24, 54, 24, 54, 25, 53, 72, 54, 24, 54, 24, 54, 24, 54, 24, 54, 24, 54, 24, 54, 24, 54, 26, 53, 25, 54, 24, 54, 70, 54, 24, 54, 24, 54, 24, 54, 24, 54, 25, 54, 25, 54, 24, 54, 24, 54, 24, 54, 24, 54, 70, 54, 71, 54, 25, 54, 24, 54, 70, 54, 71, 54, 24, 54, 24, 54, 70, 54, 70, 54, 72, 54])
array('I', [104, 805, 852, 526, 236, 527, 687, 526, 235, 526, 236, 526, 236, 526, 236, 527, 236, 526, 697, 526, 236, 526, 236, 526, 236, 526, 236, 526, 236, 526, 236, 526, 236, 526, 246, 526, 236, 526, 236, 526, 695, 526, 236, 526, 236, 526, 236, 526, 236, 526, 245, 527, 235, 527, 236, 526, 236, 526, 236, 526, 238, 527, 687, 526, 688, 526, 246, 526, 236, 526, 687, 526, 688, 526, 235, 527, 235, 526, 688, 526, 687, 527, 694, 526])

2nd read.
array('I', [8, 82, 87, 55, 24, 54, 70, 54, 24, 54, 24, 54, 24, 54, 24, 54, 24, 54, 72, 54, 24, 54, 24, 54, 24, 54, 24, 54, 24, 54, 24, 54, 24, 54, 25, 54, 25, 53, 25, 54, 70, 54, 24, 54, 24, 54, 24, 54, 24, 54, 25, 54, 25, 53, 25, 53, 25, 54, 24, 54, 24, 54, 70, 54, 71, 53, 72, 54, 24, 54, 70, 54, 71, 54, 24, 54, 70, 54, 24, 54, 24, 54, 25, 54])
array('I', [29, 328, 347, 215, 96, 214, 280, 214, 96, 215, 96, 214, 96, 215, 96, 214, 96, 214, 284, 215, 96, 214, 96, 215, 96, 214, 96, 214, 96, 215, 96, 214, 96, 214, 100, 215, 96, 214, 96, 215, 280, 214, 96, 214, 96, 214, 96, 215, 96, 214, 100, 215, 96, 214, 96, 214, 96, 215, 96, 214, 96, 215, 280, 214, 280, 214, 284, 215, 96, 214, 280, 214, 280, 215, 96, 214, 280, 215, 96, 214, 96, 214, 100, 214])

順番にサンプリングのデータ、サンプリング時のウェイトループのループ回数とありますが、サンプリングのデータはほぼ同じような数字となっていますが、ループ回数が大きく違います。

ドライバを呼び出さない場合も比べてみると、

array('I', [6, 82, 88, 52, 23, 55, 69, 54, 23, 54, 23, 54, 23, 54, 23, 54, 69, 54, 23, 54, 23, 54, 23, 54, 23, 54, 23, 53, 25, 53, 25, 51, 26, 51, 25, 54, 23, 54, 23, 54, 71, 54, 23, 53, 25, 51, 25, 53, 23, 53, 25, 54, 23, 52, 25, 53, 23, 54, 23, 54, 23, 55, 69, 53, 25, 51, 72, 54, 23, 53, 69, 54, 70, 55, 23, 54, 23, 53, 70, 55, 71, 52, 72, 54])

array('I', [1, 24, 33, 19, 8, 20, 26, 20, 8, 20, 8, 20, 8, 20, 8, 20, 26, 20, 8, 20, 8, 20, 8, 20, 8, 20, 8, 20, 9, 20, 9, 19, 9, 19, 9, 20, 8, 20, 8, 20, 27, 20, 8, 20, 9, 19, 9, 20, 8, 20, 9, 20, 8, 19, 9, 20, 8, 20, 8, 20, 8, 21, 26, 20, 9, 19, 19, 20, 8, 20, 26, 20, 26, 20, 8, 20, 8, 19, 26, 20, 26, 19, 27, 20])

2nd read.

array('I', [0, 81, 87, 53, 26, 52, 72, 51, 27, 51, 25, 51, 25, 51, 26, 52, 70, 58, 19, 58, 25, 51, 25, 51, 25, 50, 25, 52, 25, 51, 25, 52, 26, 51, 26, 57, 19, 59, 18, 59, 64, 58, 19, 52, 25, 57, 19, 59, 20, 52, 26, 58, 19, 58, 19, 57, 25, 51, 25, 51, 26, 51, 71, 51, 26, 52, 72, 57, 18, 58, 70, 51, 72, 51, 26, 53, 25, 52, 70, 51, 71, 52, 72, 52])

array('I', [0, 8, 12, 7, 3, 7, 10, 7, 3, 7, 3, 7, 3, 7, 3, 7, 10, 8, 2, 8, 3, 7, 3, 7, 3, 7, 3, 7, 3, 7, 3, 7, 3, 7, 3, 8, 2, 8, 2, 8, 9, 8, 2, 7, 3, 8, 2, 8, 2, 7, 3, 8, 2, 8, 2, 8, 3, 7, 3, 7, 3, 7, 10, 7, 3, 7, 10, 8, 2, 8, 10, 7, 10, 7, 3, 7, 3, 7, 10, 7, 10, 7, 10, 7])

サンプリングのブレ幅はありますが、こちらもループ回数が半減していました。

それぞれの４番目のデータを見てみます。

ドライバで求めた値 53 562 / 55 215

python内で求めた値 52 19 / 53 7

562 ÷ 215 ≒ 2.6

19 ÷ 7 ≒ 2.7

もうちょい正確にいってみましょうかｗ

1μ秒単位のループ回数比で計算してみると

562÷53≒10.60

215÷55≒3.909

10.6÷3.9≒2.711

19÷52≒0.3653

7÷55≒0.1272

0.3653÷0.1272≒2.871

それぞれ回数の低い方基準の数字ですが、こんな感じに。0.16の差は何かというのは気になりますね。レジスタアクセスでキャッシュが効いてないアクセスがあるのが原因か、pythonの実行処理がキャッシュ前提の効率化がうまく行っているのかはわかりません。

このぐらいの数字で心当たりがあるとすれば、CPUクロックの変動ぐらいしかなさそうなので、確認してみます。

pi@rasp4b4g:~/gpioread $ cpufreq-info -p
600000 1500000 ondemand
pi@rasp4b4g:~/gpioread $ cpufreq-info -f
600000

1500000÷600000＝2.5

原因はおそらくこれかな…cではそのまま実行されるので、クロック変動しないままサンプリング処理を終えていましたが、pythonはおそらくオーバーヘッドの処理が重たいのでクロックアップ状態のままサンプリングを行って、２秒の待ち時間があることでクロックダウンしたのではないかと推測。記憶を辿ると、3bでcで連続で試したときもリトライ時の方が処理速度が落ちていたときがあったような気がします。

2020年7月31日金曜日

ドライバで気になっていること

ドライバでちゃんと動作しているのか確認するために色々見ていたところ、メモリーアクセス時のアライメントはどうなっているのか？という点

試しにGPIOレジスタ周りで実際に表示させてみたところ

[250867.394720] f0abd000 00008900

[250867.394733] f0abd000 00008900
[250867.394749] f0abd001 00677069
[250867.394764] f0abd002 69006770
[250867.394778] f0abd003 70690067
[250867.394790] f0abd004 00024000

アドレスとその内容を出力させてみると、4バイトごとの時には正しくアクセスできているようですが、アライメントからずれているとどうも前後ではない部分にアクセスしている感じ。

気になるのはその「どこか」の内容がそれなりにずれているのも気になります。