目次: Zephyr
前回の続きです。ZephyrのDevice Tree Overlay(2022年1月3日の日記参照)で独自のbindingsを定義(compatibleやプロパティの定義)する方法を紹介します。
前回はこんなノードを追加しました。
/* samples/hello_world/boards/qemu_riscv64.overlay */
/ {
resources {
compatible = "test-overlay";
value1 = <1>;
value2 = <10>;
};
};
ノードを追加しただけではエラーにはなりませんが、コードからvalue1の値を参照しようとするとビルドエラーになって怒られます。
詳細はZephyrのDevice Tree APIマニュアル(Devicetree API - Zephyr Project Documentation)が参考になります。
// samples/hello_world/src/main.c
#include <zephyr.h>
#include <sys/printk.h>
void main(void)
{
printk("Hello World! %s\n", CONFIG_BOARD);
printk("value1:%d\n", DT_PROP(DT_INST(0, test_overlay), value1));
printk("value2:%d\n", DT_PROP(DT_INST(0, test_overlay), value2));
}
$ ninja ... zephyr/include/generated/devicetree_unfixed.h:308:34: error: 'DT_N_S_resources_P _value1' undeclared (first use in this function); did you mean 'DT_N_S_resources _PATH'? 308 | #define DT_N_INST_0_test_overlay DT_N_S_resources | ^~~~~~~~~~~~~~~~ このあとも大量に怒られる……。
Zephyrはコード内でデバイスツリーの値を参照すると、ビルド時に全て解決される仕組みです。そのためデバイスツリーに不都合な点があるとビルド時に猛烈に怒られます。Zephyrのデバイスツリー処理はPythonとマクロマジックが駆使されていて、コンパイルエラーのメッセージからエラーの原因がすぐにわからないのが難点ですね……。
Linuxは実行時に参照、書き換えが可能なので、ZephyrとLinuxの大きく異なる部分と言えましょう。
問題の解決にはdts/*.yamlを追加する必要があります。ファイル名はcompatible名.yamlになります。このファイルもOverlayファイル同様に追加するだけでビルドシステムが勝手に感知して処理してくれます。便利ですね。
samples/hello_world/ ├──CMakeLists.txt ├──README.rst ├──boards │ └──qemu_riscv64.overlay ├──dts │ └──bindings │ └──test-overlay.yaml ★これ★ ├──prj.conf ├──sample.yaml └──src └──main.c
# samples/hello_world/dts/bindings/test-overlay.yaml
description: |
This binding provides AAA and BBB, something for CCC application in Zephyr.
compatible: "test-overlay"
properties:
value1:
type: int
required: true
description: |
Identity of AAA of something. This is ...
value2:
type: int
required: true
description: |
Identity of BBB of something. This is ...
追加したyamlファイルは非常にシンプルで、compatibleの名前と、value1, value2というint型のプロパティが必須だよ、ということを定義しただけです。
その他のbindingsの定義については、Zephyrのマニュアル(Devicetree bindings - Zephyr Project Documentation)をご覧ください。
ファイルを追加したら改めてビルド&実行しましょう。
$ ninja ... [123/123] Linking C executable zephyr/zephyr.elf Memory region Used Size Region Size %age Used RAM: 23700 B 256 MB 0.01% IDT_LIST: 0 GB 2 KB 0.00% $ ninja run [0/1] To exit from QEMU enter: 'CTRL+a, x'[QEMU] CPU: riscv64 *** Booting Zephyr OS build v2.7.99-3416-g7dac931e3662 *** Hello World! qemu_riscv64 value1:1 value2:10
うまく行きました。Device Tree Overlayとbindingsは同じCコードでボードごとに設定だけ変えたい場合に有用です。
この仕組みはtests下にあるコードでよく使われています。例えばGPIOのテストがわかりやすいでしょう。2つのポートが通信できるか?割り込みが正常に入るか?などがGPIOテストの内容です。
実際に動作させるにはボードごとに配線やピン設定が違いますから、ボードAはピン10と11を使う、ボードBは21と22を使う、というようにボードごとに違う設定を与える必要があります。
設定はコードに書かずにDevice Tree Overlayに逃がして、コードはテストしたい内容のみを記述することで設定もコードもすっきりする、ってわけです。
目次: 射的
以前、ガスブローバックタイプのエアガンを買ったのですが、家だとうるさいし狭いです。往来の人に危険が及ぶので公の場所(公園、河川敷など)で撃つのも厳禁!!です。というわけで単なる飾りと化していました。
さすがに置物にするのは勿体ないので、どこか撃てる場所はないだろうか?と思って探すと、秋葉原に7mのシューティングレンジのあるカフェ(バー?)がありました。末広町にあるトリガーハッピーというお店(お店のサイトへのリンク)です。
やってみた感想は「当たるけど当たらない」ですね。
エアガンの出来はとても良く、狙った方向に飛ぶので正しく狙えば当たります。けど、狙っている私が明後日の方向に狙いを付けているのでぜーんぜん当たりません。7m先と思われる9個の的を倒すのに16秒くらいでした。たぶん早い人は半分くらいのタイムでクリアできるんじゃないかな……。
結果はさておき、普段できない遊びでなかなか面白かったです。また行ってみるかー。
目次: 電池
今までニッケル水素電池(以降Ni-MH電池)の充電にはPanasonic BQ-391を使っていました。が、端子の一部が青く錆びてきたため、先日、跡継ぎとしてPanasonic BQ-CC87を購入しました。Amazonで2400円くらいでした。BQ-CC87はUSBでの充電、USBの出力(つまりモバイルバッテリー)もできる1台2役の優れものです。
通常の充電器の使い方だと継ぎ足し充電は避けるべきですが、BQ-CC87は継ぎ足し充電もできる(Panasonicのサイトへのリンク)とのことで、とても良い商品だと思います。が……どうも我が家の電池達と相性が悪くて困っています。
我が家にあるNi-MH電池は5種類あって、
どれを使ってもスマホやタブレットを充電しようとすると、一瞬だけ0.6Aくらい出力しますが、すぐに出力が停止します。運が良いと出力が続きますが、
こんな感じでまともに動作しているように見えません。うーん。
最初は機械側を疑ったんですが、新しいNi-MH電池を新たに4本買い(Panasonic EVOLTA BK-4HCD, 単4 930mAh)、スマホの充電を試したところ1A出力できました。機械は壊れていないようです。
ここから推測できることは、単純に我が家にある電池がヘタっているor BQ-CC87で使うには気合が足りないってことです。
もうひとつ困ったことにBQ-CC87は充電する場合も我が家の電池と相性が悪く、すぐに止まってしまいます。その結果DC出力も充電もできない、どうしようもない状態の電池がどんどん増えてしまいます。
うちの電池そんなにダメなの?困ったね。
目次: Zephyr
ZephyrはプロジェクトごとにDevice Treeを上書きできます。Device Tree Overlayと呼ばれたりもしますね。やり方は違いますがLinuxでも似たような仕組みがあります。
具体的にはsamples/hello_worldの下にboardsというディレクトリを作成し、ボード名.overlayというファイルを作成するだけです。Zephyrのビルドシステムが勝手に検知してくれます。便利ですね。
今回はqemu_riscv64向けに作りますからファイル名はqemu_riscv64.overlayになります。
samples/hello_world/ ├──CMakeLists.txt ├──README.rst ├──boards │ └──qemu_riscv64.overlay ★これ★ ├──prj.conf ├──sample.yaml └──src └──main.c
/* samples/hello_world/boards/qemu_riscv64.overlay */
/ {
resources {
compatible = "test-overlay";
value1 = <1>;
value2 = <10>;
};
};
Overlayが効いているかどうかはビルド後に生成されるzephyr/zephyr.dtsを見るとわかります。
/dts-v1/; / { #address-cells = < 0x1 >; #size-cells = < 0x1 >; compatible = "riscv-virtio"; model = "riscv-virtio,qemu"; flash@20000000 { bank-width = < 0x4 >; reg = < 0x20000000 0x2000000 0x22000000 0x2000000 >; compatible = "cfi-flash"; }; /* (略) */ chosen { zephyr,console = &uart0; zephyr,shell-uart = &uart0; zephyr,sram = &ram0; }; resources { /* ★追加された★ */ compatible = "test-overlay"; value1 = < 0x1 >; value2 = < 0xa >; }; };
Overlayのcompatibleとプロパティは適当です。当然compatibleに対応するコードはありませんが、今の段階ではエラーにはなりません。
デフォルトで無効化されているデバイスを有効にする(status = "okay"; を足したい)くらいであれば、Overlayファイルの追加だけでも十分に役立ちます。
しかしZephyrはもう少し複雑な機能も提供しています。次回は独自のcompatibleを扱う方法をご紹介したいと思います。
目次: GCC
目次: Linux
Linuxをデバッグするにはkgdbを使うと思いますが、QEMU + GDBでよりお手軽にデバッグができます。お手軽とは書いたものの、実際やったところQEMUでかなり苦戦したのでメモしておきます。
対象のアーキテクチャはAArch64を選びました。お好きなアーキテクチャを使っていただいて構いませんが、Linuxのコンフィグをどうするべきかと、QEMUの動かし方を知っているアーキテクチャにしてください。せっかくLinuxをビルドしても動かせなくて詰みます。
ツールチェーンの構築の方法は昔の日記(2018年7月15日の日記参照)で構築手段をご紹介しています。crosstool-ngはデフォルトだとGDBがビルドされなかった気がするので、
CT_DEBUG_GDB=y Debug facilities ---> [*] gdb --->
この変更が必要になると思います。
Linuxカーネルはlinux-nextを使いました。新し目のLTSカーネルなども十分動くはずです。コンフィグの変更点は下記のとおりです。
CONFIG_RANDOMIZE_BASE=n(gdbでデバッグするときは、アドレスをランダムに変えられると困るため) Kernel Features ---> [ ] Randomize the address of the kernel image CONFIG_DEBUG_INFO_REDUCED=n(yだとgdbで構造体などの情報が見えなくなるため) Kernel hacking ---> Compile-time checks and compiler options ---> [*] Compile the kernel with debug info [ ] Reduce debugging information CONFIG_MODULES=n(モジュールのインストールが面倒なので) [ ] Enable loadable module support ----
デフォルトのコンフィグだと、やたらと色々なドライバをビルドするので時間がかかります。グラフィクス系のドライバなどの明らかに不要なドライバは外しても良いと思います。
QEMUは様々なハードウェアを模倣できます。そのなかにRaspberry Pi 3bがありましたのでこれを使います。initrdイメージはbuildrootで作りました。
qemu-system-aarch64 \ -machine raspi3b \ -kernel arch/arm64/boot/Image \ -append "earlycon=pl011,0x3f201000 console=ttyAMA0" \ -dtb arch/arm64/boot/dts/broadcom/bcm2837-rpi-3-b.dtb \ -initrd ../buildroot/output/images/rootfs.cpio \ -serial stdio \ -s
起動してプロンプトまで表示されますが、キー入力を全く受け付けず操作不能になってしまいます。解決方法がわからなかったので諦めました。
ちなみに最近のlinux-nextを使う場合は、GPIOとpinctrlの初期化順を修正するパッチを当てないといけません。これを当てないとpinctrlが無効になってしまい、連鎖的にpinctrlに依存しているSDカードのドライバなども無効化され「rootfsがマウントできない!」とpanicになってしまいます。
この問題に気づくまでかなり時間がかかりました。バグだと思ってめっちゃ調べたのに、もうパッチがLKMLに投稿されていたという体験は、linux-nextを使っていると珍しくないですけどね。よりによってRaspberry Piだけで起きるバグをタイムリーに引くとは思わなかった……完全に油断してた。
Raspberry Piマシンの代わりにvirtマシンを使うことにしました。
今回はユーザーランドは動けばOKですから、Raspberry PiのディスクイメージRaspberry Pi OS Lite 64bit(公式ダウンロードサイト)を使用します。
QEMUで起動する場合virtioを使用します。QEMUのvirtマシンは残念ながらSDやmtdには対応していません。パラレルフラッシュはサイズが64MBまでのためにRaspberry Pi OSのイメージは大きすぎると言われ起動できません。
qemu-system-aarch64 \ -machine virt -cpu cortex-a53 -smp 1 \ -kernel arch/arm64/boot/Image -append "rw root=/dev/vda2" \ -drive file=2022-01-28-raspios-bullseye-arm64-lite_resize.img,format=raw,if=virtio \ -serial stdio \ -s
最後の -sオプションはGDBの接続をポート1234で待機するオプション -gdb tcp::1234の短縮形です。カーネルのブート部分などをデバッグする場合は、GDBを接続するまで停止していてほしいので -Sも一緒に付けると良いです。
前置きがだいぶ長くなりましたがこれでデバッグ環境が整いました。GDBをQEMUに接続するにはtarget remoteコマンドを使います。
$ aarch64-unknown-linux-gnu-gdb vmlinux GNU gdb (crosstool-NG 1.24.0.501_5bf4485) 10.2 Copyright (C) 2021 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "--host=x86_64-build_pc-linux-gnu --target=aarch64-unknown-linux-gnu". Type "show configuration" for configuration details. For bug reporting instructions, please see: <https://www.gnu.org/software/gdb/bugs/>. Find the GDB manual and other documentation resources online at: <http://www.gnu.org/software/gdb/documentation/>. For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from vmlinux... (gdb) b start_kernel Breakpoint 1 at 0xffff800009e10c64: file init/main.c, line 931. (gdb) target remote :1234 Remote debugging using :1234 0x0000000040000000 in ?? () (gdb) c Continuing. Breakpoint 1, start_kernel () at init/main.c:931 931 {
実行、ブレーク、ソースコードの表示もできています。良い感じですね!
目次: OpenOCD
HiFive1のJTAGを使う際はJ-Linkの設定(tcl/interface/jlink.cfg)を使えばOKです。しかしSEGGER J-LinkのJTAG箱が見当たらないのに、なぜこの設定で動くのか若干気になりました。調べたら納得だったのでメモしておきます。
回路図を見るとマイコンでUSB-JTAG変換を実現しています。USB端子はNXP MK22FN128VLH10(MK22FN128VLH10 Product Information - NXP)に接続されており、このICからJTAGの信号(TDIなど)が出ています。JTAGの信号線はSiFive FE310に接続されています。
なぜ突然NXPのマイコンICが出てくるのか?J-Linkはどこから来た??と思いきや、実はこれSEGGER J-LinkのオンチップJTAG、J-Link-OBというシリーズの1つで使われているマイコンです(参考: J-Link OB Debug Probe - SEGGER)。SEGGER J-Linkは専用のICがあるわけではなく、NXPやSTのマイコンで実現しているんですね、なるほど。
カタログ上はCortex-M/Cortex-A用となっていますが、これはSEGGER独自の機能が使えるか使えないかを表しているのでしょう。JTAGは4つの信号線(TMS, TCK, TDI, TDO)でJTAGのプロトコルを理解するデバイスが相手であれば良くて、CPUの種類は特に気にしないはず……。
目次: OpenOCD
SiFiveのHiFive1というボード(SiFiveのサイトへのリンク)をデバッグするときは、HiFive1のオンボードUSB-JTAGを使うことが多いと思います。
非常に便利ですがUSB接続ゆえに近くにPCが必要です。PCを作業机の横に置けば何の問題もないんですけど、我が家の場合は諸事情でちょっと困った配置になっています。
PCを作業机の横に持ってくる手も考えましたが、悪あがきとしてRaspberry Pi 3でOpenOCDを実行してサーバー代わりにしてみました。結果から言うと、思っていたよりうまく動いてくれました。嬉しい、Raspberry Pi偉い。
各機器の接続関係はこんな感じです。各ソフトに改造は不要です。GDBのTCP経由でデバッグできる機能と、OpenOCDのGDB serverとして振る舞う機能の合わせ技で実現できます。
(通常) PCのGDB <-(TCP local接続)-> PCのOpenOCD <-(USB)-> HiFive1 (今回) PCのGDB <-(TCP接続)-> Raspberry Pi 3のOpenOCD <-(USB)-> HiFive1
こんな変な使い方まで想定内とは驚きです。GDBもOpenOCDも良くできています。
Raspberry Pi 3ではOpenOCDを実行します。
$ ./src/openocd -c 'bindto 0.0.0.0' -f tcl/interface/jlink.cfg -f ./tcl/board/sifive-hifive1-revb.cfg Open On-Chip Debugger 0.11.0+dev-00551-gaad871805 (2022-01-16-22:30) Licensed under GNU GPL v2 For bug reports, read http://openocd.org/doc/doxygen/bugs.html Warn : Interface already configured, ignoring Info : J-Link OB-K22-SiFive compiled Nov 22 2019 12:57:38 Info : Hardware version: 1.00 Info : VTarget = 3.300 V Info : clock speed 4000 kHz Info : JTAG tap: riscv.cpu tap/device found: 0x20000913 (mfg: 0x489 (SiFive Inc), part: 0x0000, ver: 0x2) Info : datacount=1 progbufsize=16 Info : Disabling abstract command reads from CSRs. Info : Examined RISC-V core; found 1 harts Info : hart 0: XLEN=32, misa=0x40101105 Info : starting gdb server for riscv.cpu.0 on 3333 Info : Listening on port 3333 for gdb connections Info : Found flash device 'issi is25lp032' (ID 0x0016609d) Ready for Remote Connections Info : Listening on port 6666 for tcl connections Info : Listening on port 4444 for telnet connections Info : JTAG tap: riscv.cpu tap/device found: 0x20000913 (mfg: 0x489 (SiFive Inc), part: 0x0000, ver: 0x2) Warn : keep_alive() was not invoked in the 1000 ms timelimit. GDB alive packet not sent! (1606 ms). Workaround: increase "set remotetimeout" in GDB Info : JTAG tap: riscv.cpu tap/device found: 0x20000913 (mfg: 0x489 (SiFive Inc), part: 0x0000, ver: 0x2) Warn : keep_alive() was not invoked in the 1000 ms timelimit. GDB alive packet not sent! (1523 ms). Workaround: increase "set remotetimeout" in GDB Info : JTAG tap: riscv.cpu tap/device found: 0x20000913 (mfg: 0x489 (SiFive Inc), part: 0x0000, ver: 0x2) Warn : keep_alive() was not invoked in the 1000 ms timelimit. GDB alive packet not sent! (1599 ms). Workaround: increase "set remotetimeout" in GDB Info : JTAG tap: riscv.cpu tap/device found: 0x20000913 (mfg: 0x489 (SiFive Inc), part: 0x0000, ver: 0x2) Warn : keep_alive() was not invoked in the 1000 ms timelimit. GDB alive packet not sent! (1610 ms). Workaround: increase "set remotetimeout" in GDB Warn : Error writing to GDB socket. Dropping the connection. Info : dropped 'gdb' connection Info : accepting 'gdb' connection on tcp/3333 Info : JTAG tap: riscv.cpu tap/device found: 0x20000913 (mfg: 0x489 (SiFive Inc), part: 0x0000, ver: 0x2) Warn : keep_alive() was not invoked in the 1000 ms timelimit. GDB alive packet not sent! (1614 ms). Workaround: increase "set remotetimeout" in GDB
PC側からmonitor resetを実行すると「1,000ms以内に返事が来ない!タイムアウトしたぞ!」というWarningログが頻発します。HiFive1の反応が遅いのか、Raspberry Pi 3の判断が遅いのか、どちらかよくわかりません。両方かな……?
PCではGDBを実行します。例ではZephyrのバイナリを送っていますが、Zephyr以外でも手順は同じです。
$ riscv64-zephyr-elf-gdb build/zephyr/zephyr.elf GNU gdb (crosstool-NG 1.24.0.378_e011758) 9.2 Copyright (C) 2020 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "--host=x86_64-build_pc-linux-gnu --target=riscv64-zephyr-elf". Type "show configuration" for configuration details. For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>. Find the GDB manual and other documentation resources online at: <http://www.gnu.org/software/gdb/documentation/>. For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from build/zephyr/zephyr.elf... (gdb) target remote 192.168.1.106:3333 Remote debugging using 192.168.1.106:3333 0x00001004 in ?? () (gdb) monitor reset halt JTAG tap: riscv.cpu tap/device found: 0x20000913 (mfg: 0x489 (SiFive Inc), part: 0x0000, ver: 0x2) keep_alive() was not invoked in the 1000 ms timelimit. GDB alive packet not sent! (1615 ms). Workaround: increase "set remotetimeout" in GDB
GDBもタイムアウトがどうのこうのと怒っています。特に異常動作はしないので放っておいても良いですけど、邪魔であればメッセージのおススメ通りにset remotetimeoutの値を伸ばすと良いでしょう。
基本的には以上です動きました良かったね!で終わりなんですけど、Raspberry Pi 3のdmesgを見ていたら見慣れないエラーが出ていたのでメモしておきます。
[ 253.885123] usb 1-1.5: new full-speed USB device number 6 using dwc_otg [ 254.021413] usb 1-1.5: New USB device found, idVendor=1366, idProduct=1051, bcdDevice= 1.00 [ 254.021440] usb 1-1.5: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 254.021475] usb 1-1.5: Product: J-Link [ 254.021490] usb 1-1.5: Manufacturer: SEGGER [ 254.021505] usb 1-1.5: SerialNumber: 000979016829 [ 254.023795] cdc_acm 1-1.5:1.0: ttyACM0: USB ACM device [ 254.027758] cdc_acm 1-1.5:1.2: ttyACM1: USB ACM device [ 254.031278] usb-storage 1-1.5:1.5: USB Mass Storage device detected [ 254.032081] scsi host0: usb-storage 1-1.5:1.5 [ 254.875197] Under-voltage detected! (0x00050005) ★★★★これと★★★★ [ 255.037642] scsi 0:0:0:0: Direct-Access SEGGER MSD Volume 1.00 PQ: 0 ANSI: 4 [ 255.038948] sd 0:0:0:0: Attached scsi generic sg0 type 0 [ 255.043115] sd 0:0:0:0: [sda] 21829 512-byte logical blocks: (11.2 MB/10.7 MiB) [ 255.052887] sd 0:0:0:0: [sda] Write Protect is off [ 255.052914] sd 0:0:0:0: [sda] Mode Sense: 0b 00 00 08 [ 255.055179] sd 0:0:0:0: [sda] No Caching mode page found [ 255.055202] sd 0:0:0:0: [sda] Assuming drive cache: write through [ 255.148361] sda: [ 255.166356] sd 0:0:0:0: [sda] Attached SCSI removable disk [ 259.035120] Voltage normalised (0x00000000) ★★★★これ★★★★
このエラーはRaspberry Pi 3とHiFive1のUSB端子を接続したときに出現します(私の環境だと接続のたびに必ず発生)。電力供給ラインであるUSBのVBus端子電圧が下がっているという意味ですかねえ……?可能性としてはHiFive1が起動時だけ一気に大電力を消費することが考えられますが、深追いしておらず真相はわかりません。
正月、北海道から帰ってきて車の様子を見たら、完全にバッテリーが上がっていました。気づいたのはちょっと前(2022年1月10日の日記参照)くらいです。セルモーターは微塵も動かず、そもそもリモコンキーも効きません。ドアはカギで開けました。ドアを開けても室内灯すら点きませんね……。
今まで何度となくバッテリーをダメにしてきた悲しい経験から、これはバッテリー交換コースだと確信しました。またかよー。
JAFに来てもらう間、暇だったのでバッテリーの電圧を測りました。電圧は2.16Vでした。これは乾電池でしたっけ??正常な車のバッテリーは12V前後(セル電圧2V程度x6セル)であり、放電終止電圧は10V前後(セル電圧1.8V程度x6セル)です。2.16Vがいかに論外な状態であるか、おわかりいただけるかと思います。
バッテリーから流れる電流も測りました。電流はほぼ流れていないか、クランプメーターの検出限界以下と思われます。余談ですが、このクランプメーターはゼロ点が狂ってきたようで、何も繋がず、ゼロ点補正なしだと -0.31Aになってしまいます。直し方がわからない。
JAFさんにエンジンかけてもらった後に電流を測りました。やはり電流はほぼ流れておらず、充電されているように見えません。バッテリーが死んでいるのか、エンジン始動直後のせいか?どっちでしょうね?
バッテリーの液量インジケーターは元々どうなっていたのかわからなくて、正常か異常か判別できませんでした。
仮に液量が正常でも、過放電でサルフェーション現象が発生して電極が死んでいる(=充電ができない=次止めたらエンジンが掛からない)でしょうから、素直にバッテリー交換に行きますか。
近所のイエローハットまで20分くらい走って、エンジンを切ってみたところ、電圧は11.8Vとなっていました。ん?充電されている?もしかしてバッテリーは生きてたのかな?
このまま帰ってまたバッテリーが上がったり、旅先で立ち往生されるのは困るため、潔くバッテリーを交換しました。当たり前ですが交換後は12.6Vと元気な電圧になっていました。
バッテリーは今載っているものと全く同じものを買いました。特に変更する理由もないし。はー、こんなことで35,000円の出費は痛いな……。
メーターを見ると、エラーEr IUが出てました。なんじゃろ?これ??
Facebookで会社の皆さまに教えていただいたところ、統合ユニットの通信エラーが発生したときに記録されるエラーとのこと。ずっと出続けていて気になりますけど、普通に走れて実害もなさそうなので、しばし放っておこうと思います。
目次: RISC-V
昨年、秋月で買って放置していた、怪しい中華製のSPI接続ディスプレイ(MSP2807)がやっと動きました。制御用のホストとしてSiFive HiFive1を使いました。OSはZephyrというRTOSを使っています。
HiFive1ではLinuxが動かないのも理由の一つではありますが、SPIの制御だけならZephyrがちょうど良い規模感でしょう。大掛かりなアプリを動かしたければ、別のハード(HiFive1はRAMがたった16KBしかない!)とLinuxを持ってきた方が良いでしょう。
SiFive HiFive1(黒い方)とSPI接続ディスプレイMSP2807(赤い方)
写真のとおり、画面が点灯して書き換えもできた(青と緑の縞模様を描いている)ので、リセット、コマンドとデータは送れているようです。ホスト → ディスプレイの接続は合っていると思われます。
しかし、ディスプレイ側から何か読み出そうとするとALL 0になり何も読めません。ホスト ← ディスプレイの接続をどこかで間違えているのかな……??未だに理由がわからず直せないままです。
このディスプレイはILITEK ILI9341という液晶のドライバーICを使っています。ホストとの接続は何パターンか存在するのですが、
が全く書いていないため、どのモードで動いているのか良くわかりません。イケてねえなあ。おそらく4-wireモード(SPI + コマンドかデータか示すGPIO 1つ)だと思われますが、確かめようがないです……。
メモ: 技術系の話はFacebookから転記しておくことにした。加筆。
我が家の圧力鍋は圧力切り替え式でゲージ圧(大気圧 = 0kPaとする記法)で「低圧60kPa」「高圧100kPa」となっています。なぜこの数字なんでしょう?
正直に言って設定の意味を理解していなかったんですが、昨日の日記で飽和水蒸気圧曲線(添付の写真、Wagnerの式から導出)を見ていて、設定の意味に気付きました。
グラフの圧力軸はゲージ圧ではなく、絶対圧です。沸点は大気圧を100kPaとして、ゲージ圧+100kPaで概算しました。
これはもう見たままですね。10℃刻みです。とてもわかりやすいですね。ゲージ圧150〜160kPa(絶対圧250〜260kPa)の鍋もありますが、さらに上の約130℃設定(実際は127℃くらいか)を意味します。
調理器具ですから、温度は切り良く、覚えやすく、メーカーが作りやすい設定値を選んでいるはずです。当然と言えましょう。
こんなにわかりやすく考慮してくれているにも関わらず、当のユーザーたる俺ときたら……。全く設定の意味を理解せずに「常に高圧の一択」ですからね。メーカーの設計者は泣いてしまいますね。
メモ: 技術系の話はFacebookから転記しておくことにした。一部加筆。
ハチミツ入りの飴を食べていたら、パッケージに
「はちみつを使用していますので1歳未満の乳児には食べさせないでください。」
と警告があることに気づきました。ハチミツを乳児に与えてはいけないのは、比較的有名な話(ハチミツによる乳児のボツリヌス症 - 消費者庁)だと思います。飴の形に加工されていてもやはりダメなのでしょうか?
乳児ボツリヌス症の原因はハチミツに含まれるボツリヌス菌の芽胞です。ボツリヌス菌「食品衛生の窓」 - 東京都福祉保健局によると、ボツリヌス菌の芽胞は熱に強く、殺菌には120℃4分間の加熱処理が必要です。
ハチミツ入りの飴の話に戻ると、
なるほど、殺菌するタイミングがなさそうです……。
通常の鍋では、水の沸点(100℃)を超える加熱処理は不可能ですが、圧力鍋を使った場合はどうでしょう?我が家の圧力鍋、パール金属H-3551(メーカーサイトへのリンク)をみると、高圧側100kPa、低圧側60kPaとあります。
120℃ の飽和水蒸気圧は198.7kPaのため、大気圧+100kPa = 約200kPaとすると、沸点は120℃まで達します。したがって圧力鍋のロックピンが上がり、圧力が規定値に達したときから、4分間以上加熱することで「一般のご家庭でもボツリヌス菌の芽胞は倒せる」と思われます。やるじゃないか、圧力鍋さん。
とはいえ圧力が必ず200kPaまで達する保証はありませんし、そもそも圧力鍋は殺菌装置ではないので、過信は禁物です。加熱後はちゃんと冷蔵して早めに食べましょう。
圧力鍋が凄いことはわかりましたけど、飴を圧力鍋で煮込むわけにはいきませんから、やっぱりハチミツ入りの飴を乳児にあげてはいけません。
2020年10月の旭化成の半導体工場、火災事故調査報告書が出ていた(報告書へのリンク)ので読んでみました。人に犠牲がなかったのは良かったなと思いますが、報告内容はなかなか衝撃的でした。
通常の部屋と違い、クリーンルームは強力なダウンフローがあるし、天井と床下で繋がってる点は特殊です。クリーンルーム火災なんてレアな事例、積み上げもなさそうです。火災まで視野に入れると、設計めっちゃ難しそうですね……。
メモ: 技術系?の話はFacebookから転記しておくことにした。
デスクトップPCの部品のいくつかは昔のPCから引き継いで使っています。なかでもATX電源は交換を怠りがちですが、いざ壊れると起動しなくなるだけでなく、巻き添えでCPUやマザーボードまで故障する可能性もあって故障が怖い部品です。トラブルに遭う前に、予防的に交換します。
買ったのはCoolerMaster V650 GOLD V2(MPY-650V-AFBAG-JP, 650W)です。ヨドバシで14,000円くらいでした。ちらっと他店の値段を見たら11,000円くらいでした。ヨドバシはPCパーツがやや高いのかも?
今まではCoolerMaster SilentPro M600(RS-600-AMBA-D3, 600W)を使っていました。Core2 Quadマシンの時代(2009年〜)から使っていましたから、ほぼ付けっぱなしで13年使ったようです。CoolerMasterの電源は優秀ですね。これからも応援してます。
目次: 車
正月寒いなか放置しすぎたせいか車のバッテリーが死にました。テスターで電圧測ると2.3Vで室内灯すら点きません。またバッテリー交換コースかなー。
メモにあるだけでも2007年11月17日、2013年3月20日、2016年7月24日、2020年7月28日にバッテリー交換しています。次で5回目です。
車に乗る頻度が激減した理由は明確です。東京はあらゆる場所が「車で来るな!」とおっしゃるからです。それでも車で行くと
のどれかです。行く気がしませんのよ〜……。
結論から先に書いておくと、高速道路合流の速度問題が解決されていたので、そのメモです。
問題の説明の記事は、プロパイロット2.0の実現で浮かび上がった、高速道路の制限速度問題【岩貞るみこの人道車医】 - レスポンス(Response.jp)、などいろいろ出ているので、詳細はお任せするとして。
簡単に言うと、SAEレベル3以上、つまり機械が人の代わりに運転するタイプの自動運転では、法規上の最高速度に問題があります。普段の道路でも最高速度60km/hで走っている人はあまりいなくて、それも問題なんですけど、そこはさておき。当初、問題として取り上げられていたのが、高速道路への合流でした。
最高速度は道路交通法施行令という法律で定められていて、高速道路の加速車線の制限速度は一般道同様に60km/hでした。ご存じのとおり、高速道路の本線は100km/hなので、法律を守って運転すると、次のようになります。
追突の危険性があるのと、本線で急加速せざるを得ない、ギクシャクした運転になってしまいます。
これは昔から存在していた法律上のおかしな点なんですが、人間が運転する場合はあえて法律(=加速度車線の最高速度制限)を無視し、取り締まり側も厳密なことは言わず見逃す、というゆるい運用で問題を避けてきました。しかし自動運転車まで法律を無視する?それは本当に正しいのか??と問題が再燃したわけです。
引き続き運用でごまかすのも辛いでしょうし、この問題はどうやって直すのかな?と思っていたんですが、どうやら法律の方を直したみたいです。
第四章の二 高速自動車国道等における自動車の交通方法等の特例 (最高速度) 第二十七条 最高速度のうち、自動車が高速自動車国道の本線車道又はこれに接する加速車線若しくは減速車線を通行する場合の最高速度は、次の各号に掲げる自動車の区分に従い、それぞれ当該各号に定めるとおりとする。 一 次に掲げる自動車 百キロメートル毎時 ★★↑60km/hから100km/hに変わった★★ イ 大型自動車(三輪のもの並びに牽引するための構造及び装置を有し、かつ、牽引されるための構造及び装置を有する車両を牽引するものを除く。)のうち専ら人を運搬する構造のもの ロ 中型自動車(三輪のもの並びに牽引するための構造及び装置を有し、かつ、牽引されるための構造及び装置を有する車両を牽引するものを除く。)のうち、専ら人を運搬する構造のもの又は車両総重量が八千キログラム未満、最大積載重量が五千キログラム未満及び乗車定員が十人以下のもの ハ 準中型自動車(三輪のもの並びに牽引するための構造及び装置を有し、かつ、牽引されるための構造及び装置を有する車両を牽引するものを除く。) ニ 普通自動車(三輪のもの並びに牽引するための構造及び装置を有し、かつ、牽引されるための構造及び装置を有する車両を牽引するものを除く。) ホ 大型自動二輪車 ヘ 普通自動二輪車 二 前号イからヘまでに掲げる自動車以外の自動車 八十キロメートル毎時
自動運転の実現に向けて、継続して警察庁にて話し合いが持たれている(自動運転・自動走行 各種有識者会議等 - 警察庁)ので、今後も法律改正されていくことでしょう。
< | 2022 | > | ||||
<< | < | 02 | > | >> | ||
日 | 月 | 火 | 水 | 木 | 金 | 土 |
- | - | 1 | 2 | 3 | 4 | 5 |
6 | 7 | 8 | 9 | 10 | 11 | 12 |
13 | 14 | 15 | 16 | 17 | 18 | 19 |
20 | 21 | 22 | 23 | 24 | 25 | 26 |
27 | 28 | - | - | - | - | - |
合計:
本日: