目次: 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 {
実行、ブレーク、ソースコードの表示もできています。良い感じですね!
目次: 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を扱う方法をご紹介したいと思います。
目次: 電池
今までニッケル水素電池(以降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出力も充電もできない、どうしようもない状態の電池がどんどん増えてしまいます。
うちの電池そんなにダメなの?困ったね。
目次: 射的
以前、ガスブローバックタイプのエアガンを買ったのですが、家だとうるさいし狭いです。往来の人に危険が及ぶので公の場所(公園、河川敷など)で撃つのも厳禁!!です。というわけで単なる飾りと化していました。
さすがに置物にするのは勿体ないので、どこか撃てる場所はないだろうか?と思って探すと、秋葉原に7mのシューティングレンジのあるカフェ(バー?)がありました。末広町にあるトリガーハッピーというお店(お店のサイトへのリンク)です。
やってみた感想は「当たるけど当たらない」ですね。
エアガンの出来はとても良く、狙った方向に飛ぶので正しく狙えば当たります。けど、狙っている私が明後日の方向に狙いを付けているのでぜーんぜん当たりません。7m先と思われる9個の的を倒すのに16秒くらいでした。たぶん早い人は半分くらいのタイムでクリアできるんじゃないかな……。
結果はさておき、普段できない遊びでなかなか面白かったです。また行ってみるかー。
目次: 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に逃がして、コードはテストしたい内容のみを記述することで設定もコードもすっきりする、ってわけです。
目次: 射的
ガスガンが増殖して6個になりました。有名どころ&異なる国を狙って買ってみました。有名どころは他もありますけど、さすがにもう要らないですね。射的で遊ぶにしても、同時にいくつも使わんし……。
いずれも東京マルイというメーカーのガスガンです。
実銃は性能が違い(そもそも使用できる弾丸が違う、M1911は .45 ACP、Five-seveNは5.7x28mmマシンガンの弾、他は9x19mmパラベラム弾)ます。しかしおもちゃであるガスガンは、見た目が違うだけで性能がほぼ全部同じです。趣味で選べばOKです。
デザインはベレッタ92とM1911が好きですね。機能美&シンプル。レールが付いているデザインはあんまり好きじゃないです。銃口側がシュッと細めのタイプが好きなんですね。たぶん。
持ちやすさはUSP Compactが良かったです。他も特に不満はないです。ああ、でもM1911とFive-seveNはグリップがでかすぎて若干持ちにくいかも?
あと説明書読んでいて驚いたんですが、操作方法が全然違います。特にセーフティー、デコックはモノによって全然違います。似た形なのに全く統一感がありません。使っている人たちは文句言わんのでしょうか?銃は不思議な世界ですね……。
メモ: 技術系?の話はFacebookから転記しておくことにした。追記。
新しくSeagate ST8000VN004(SATA, 8TB)を買いました。最近のHDDにしては珍しく音がかなりうるさいです……印刷時のプリンターみたいな音がしています。音も気になるんですけど、さらに気になることがあってSMARTでステータスを見てみると、
SMART Attributes Data Structure revision number: 10 Vendor Specific SMART Attributes with Thresholds: ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 1 Raw_Read_Error_Rate 0x000f 081 068 044 Pre-fail Always - 129582469 ★★★★!? 3 Spin_Up_Time 0x0003 096 096 000 Pre-fail Always - 0 4 Start_Stop_Count 0x0032 100 100 020 Old_age Always - 2 5 Reallocated_Sector_Ct 0x0033 100 100 010 Pre-fail Always - 0 7 Seek_Error_Rate 0x000f 100 253 045 Pre-fail Always - 131692 ★★★★!? 9 Power_On_Hours 0x0032 100 100 000 Old_age Always - 0 10 Spin_Retry_Count 0x0013 100 100 097 Pre-fail Always - 0 12 Power_Cycle_Count 0x0032 100 100 020 Old_age Always - 2 18 Head_Health 0x000b 100 100 050 Pre-fail Always - 0 187 Reported_Uncorrect 0x0032 100 100 000 Old_age Always - 0 188 Command_Timeout 0x0032 100 100 000 Old_age Always - 0 190 Airflow_Temperature_Cel 0x0022 056 056 040 Old_age Always - 44 (Min/Max 34/44) 192 Power-Off_Retract_Count 0x0032 100 100 000 Old_age Always - 2 193 Load_Cycle_Count 0x0032 100 100 000 Old_age Always - 2 194 Temperature_Celsius 0x0022 044 044 000 Old_age Always - 44 (0 20 0 0 0) 195 Hardware_ECC_Recovered 0x001a 081 068 000 Old_age Always - 129582469 197 Current_Pending_Sector 0x0012 100 100 000 Old_age Always - 0 198 Offline_Uncorrectable 0x0010 100 100 000 Old_age Offline - 0 199 UDMA_CRC_Error_Count 0x003e 200 200 000 Old_age Always - 0 240 Head_Flying_Hours 0x0000 100 253 000 Old_age Offline - 0 (243 14 0) 241 Total_LBAs_Written 0x0000 100 253 000 Old_age Offline - 129529342 242 Total_LBAs_Read 0x0000 100 253 000 Old_age Offline - 53127
Raw_Read_Error_RateやSeek_Error_Rateが凄まじい値をたたき出しています。比較対象としてWestern Digital WD40EFRX(SATA, 4TB)を見るといずれも0です。
SMART Attributes Data Structure revision number: 16 Vendor Specific SMART Attributes with Thresholds: ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 1 Raw_Read_Error_Rate 0x002f 200 200 051 Pre-fail Always - 0 ★★★★0です 3 Spin_Up_Time 0x0027 162 162 021 Pre-fail Always - 6900 4 Start_Stop_Count 0x0032 100 100 000 Old_age Always - 18 5 Reallocated_Sector_Ct 0x0033 200 200 140 Pre-fail Always - 0 7 Seek_Error_Rate 0x002e 200 200 000 Old_age Always - 0 ★★★★0です 9 Power_On_Hours 0x0032 080 080 000 Old_age Always - 14956 10 Spin_Retry_Count 0x0032 100 253 000 Old_age Always - 0 11 Calibration_Retry_Count 0x0032 100 253 000 Old_age Always - 0 12 Power_Cycle_Count 0x0032 100 100 000 Old_age Always - 16 192 Power-Off_Retract_Count 0x0032 200 200 000 Old_age Always - 2 193 Load_Cycle_Count 0x0032 170 170 000 Old_age Always - 92796 194 Temperature_Celsius 0x0022 112 100 000 Old_age Always - 38 196 Reallocated_Event_Count 0x0032 200 200 000 Old_age Always - 0 197 Current_Pending_Sector 0x0032 200 200 000 Old_age Always - 0 198 Offline_Uncorrectable 0x0030 100 253 000 Old_age Offline - 0 199 UDMA_CRC_Error_Count 0x0032 200 200 000 Old_age Always - 20 200 Multi_Zone_Error_Rate 0x0008 100 253 000 Old_age Offline - 0
何だこりゃ、やられた!故障か?
しかしSMARTで異常を検知できるほどなのに普通に読み書きできていて不思議だったので、もう少し調べてみると解説しているサイト(リンク: Seagate's Seek Error Rate, Raw Read Error Rate, and Hardware ECC Recovered SMART attributes)が見つかりました。
どうも気にしなくて良いみたいですね。試しに今まで使っていたSeagate ST4000VN008(SATA, 4TB)のステータスを見ると、Raw_Read_Error_Rateが凄い値になっています。
SMART Attributes Data Structure revision number: 10 Vendor Specific SMART Attributes with Thresholds: ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 1 Raw_Read_Error_Rate 0x000f 082 065 044 Pre-fail Always - 156528383 ★★★★ 3 Spin_Up_Time 0x0003 094 094 000 Pre-fail Always - 0 4 Start_Stop_Count 0x0032 100 100 020 Old_age Always - 36 5 Reallocated_Sector_Ct 0x0033 100 100 010 Pre-fail Always - 0 7 Seek_Error_Rate 0x000f 069 060 045 Pre-fail Always - 8577083 ★★★★ 9 Power_On_Hours 0x0032 100 100 000 Old_age Always - 153 (72 27 0) 10 Spin_Retry_Count 0x0013 100 100 097 Pre-fail Always - 0 12 Power_Cycle_Count 0x0032 100 100 020 Old_age Always - 13 184 End-to-End_Error 0x0032 100 100 099 Old_age Always - 0 187 Reported_Uncorrect 0x0032 100 100 000 Old_age Always - 0 188 Command_Timeout 0x0032 100 100 000 Old_age Always - 0 189 High_Fly_Writes 0x003a 100 100 000 Old_age Always - 0 190 Airflow_Temperature_Cel 0x0022 071 052 040 Old_age Always - 29 (Min/Max 21/33) 191 G-Sense_Error_Rate 0x0032 100 100 000 Old_age Always - 0 192 Power-Off_Retract_Count 0x0032 100 100 000 Old_age Always - 29 193 Load_Cycle_Count 0x0032 100 100 000 Old_age Always - 59 194 Temperature_Celsius 0x0022 029 048 000 Old_age Always - 29 (0 20 0 0 0) 197 Current_Pending_Sector 0x0012 100 100 000 Old_age Always - 0 198 Offline_Uncorrectable 0x0010 100 100 000 Old_age Offline - 0 199 UDMA_CRC_Error_Count 0x003e 200 200 000 Old_age Always - 0 240 Head_Flying_Hours 0x0000 100 253 000 Old_age Offline - 44 (25 151 0) 241 Total_LBAs_Written 0x0000 100 253 000 Old_age Offline - 10828710302 242 Total_LBAs_Read 0x0000 100 253 000 Old_age Offline - 112993489
故障かと思って勢いでSeagateに返品依頼をしてしまいました。故障ではないとわかったのでキャンセルしたいですが、キャンセルする方法がわかりません。頑張って探しましたが、Seagateのサイトの作りは本当にひどくて操作する気が起きなくなりました。まあ、送り返さなければそのうち消されるでしょう。もう放っておきましょう……。
先日(2022年2月12日の日記参照)購入したHDDにデータをコピーしていると、印刷中のプリンターのような「ガー、ガー」という音が発生していました。
一体何事か?故障なのか?とも思ったのですが原因がわかりました。ext4ファイルシステムのlazyinitが原因でした。
本来ext4はmkfsが非常に遅く、TB級の巨大な領域をフォーマットすると10分以上時間が掛かります。lazyinitはこの苦痛を和らげるためにmkfsで行うはずだった初期化(inodeテーブルの0クリア)を後回しにする方式だそうです(参考: Ext4 Filesystem - Thomas-Krenn-Wiki)。
遅いmkfsを劇的に高速化する素敵なlazyinitではありますが、mkfsのすぐ後に大量のデータを書き込む用途には不向きです。lazyinitが有効な領域をマウントするとext4lazyinitというカーネルスレッドが定期的に書き込みに来ます。これによりシークが発生してデカい音がしますし、writeの速度もかなり落ちます。
下記のようにmkfs.ext4のオプションでlazyinitを無効化できます。
# mkfs.ext4 -E lazy_itable_init=0,lazy_journal_init=0 /dev/sdc1
無効化することでwriteの速度も高速化し、異音も解決しました。
Seagateのサポートサイト(リンク)は日本語に対応していてありがたいのですが、アカウントを作成する際は日本語を一切使わない方が良いです。
アカウントを「登録」する際は日本語を使っても文句を言わないのに、アカウントの「登録内容を変更」する場合は日本語を使うと文句を言われます。この時点で既におかしな挙動ではありますが、さらにおかしなことにアカウントの登録内容に日本語が含まれていると住所変更ができなくなるなどのおかしな挙動を示します。バグってる感満載です……。
もしアカウントの登録内容に日本語を含めてしまった場合、下記の手順で回避することができました。
氏名に日本語を使ってアカウント登録すると「配送先住所」のところに日本語が出てきてしまいます(注: 画像は既に修正した後なので英語になっています)。困ったことに、このままだと交換の申請も住所変更も何もできなくなります。この状態を解消するには、
とすると回避できます。ダミー住所の追加方法はわかりづらいので画像で説明します。
新たに英語のみのダミー住所を追加(中身は適当で良い、後で消すから)
自分の住所を修正する方法は、ダミー住所を追加したときと同様です。
最近は多言語対応に失敗したサイトはあまり見かけないため、Seagateのサイトの悲惨さはかなり目立ちますね。日本でのSeagateのHDDの人気を考えると、Seagateには文句が大量に来ているんじゃないでしょうか?このヘンテコなバグもいずれ修正されるでしょう。
目次: 射的
秋葉原のトリガーハッピーでシューティングレンジに再チャレンジしました。初心者向けの的9個を順不同に全て撃つモードをやっています。距離は7mくらいですかね?測ったわけじゃないので知らんですが。
あと、的の名前を初めて知りました。G&GのM.E.T. というターゲットで、繋げる個数も可変でゲームも色々なモードがある多機能の製品みたいです。その割にはボタン1個しか制御装置がない不思議インタフェースです。よくわからずボタンをバシバシ押していたら、モードが変わってしまって焦りました。
前回はアベレージ20秒、ベスト16秒ってところでしたが、今回はアベレージ15秒、ベスト12秒くらいでした。最近は毎日遊んでいたせい?か多少早くなったようです。楽しい。
今回は持ちにくいFN Five-seveNに代えて、ベレッタ92(東京マルイU.S. M9ピストル)で挑みました。そこそこ好調でしたがかなり重い(※)のと、一発目をかなり外しました。ダブルアクションの影響でしょうかね?横方向がブレブレで全然当たりません。難しいなー……。
次にまたやるとしたら、ブレにくいM1911(シングルアクション)かグロック19(トリガーセーフティー)がいいのかなあ?特にタイムを競う訳ではないですが、外すよりは当てる方が楽しいですし。
(※)U.S. M9ピストルは「実銃と同じ重さ」がウリの製品で1kg近くあります。通常のガスガンは700gくらいが多いかな?
目次: RISC-V
HiFive1に接続していたSPI接続の液晶ディスプレイ(MSP2807)の調子がおかしいです。Raspberry PiのUSBポートに繋ぐとHiFive1ごと電源が落ちてしまいます。バックライトも付かず動作していないように見えます。
電力がギリギリなのか?と思ってACアダプタから直で電力を供給してみたところ、液晶ディスプレイのボードから煙と異臭が!!ボードが壊れてしまいました!
基板を見ると裏面にあるレギュレータU1のパッケージがコゲて穴が開いてます。回路的には5Vの供給ラインかな。他の部分は液晶で隠れていて見えませんが、壊れた可能性があります。
前は元気に動いていたのに急にどうしたんでしょうか?実はどっか短絡していておかしいまま動いていたのかなあ??
不幸中の幸いと言いますか、ACアダプタやHiFive1が道連れで壊れなかったのはラッキーでした。今のところそう見えるだけで壊れているかもしれないので、次回以降使うときは注意してみておかないと……。
メモ: 技術系の話はFacebookから転記しておくことにした。加筆修正。
目次: RISC-V
昨日(2022年2月27日の日記参照)燃えたSPI接続液晶ボード上のレギュレータXC6206ですが、燃えた原因が分かりました。GNDとVCCの配線を逆に繋ぐ単純なミスでした。
HiFive1側はGNDを黒、VCCを赤にしました。しかし液晶ボード側を間違えてGNDを赤、VCCを黒(=逆に接続)にしていました。
本来5Vかけるべきところに -5Vを印加した訳です。TorexのXC6206のスペックシート(仕様書へのリンク)によれば入力定格 -0.3〜7Vですので -5Vは定格10倍以上。そりゃあ壊れますよ。あーあー……やっちまいました。