コグノスケ

USB Type-C充電器の置き換え

USB Type-Cの充電器を3つほど購入しましたので、メモを残しておきます。

• Anker A2663113（Nano II 65W、USBポート: Cx1）
• Anker A2667N11（PowerPort III 3-Port 65W、USBポート: Cx2 + Ax1）
• ELECOM MPA-ACCP4465BK（USB Power Delivery 65W キューブAC充電器、USBポート: Cx2 + Ax1）

Anker Nano IIはLenovo ThinkPad E480のACアダプターを置き換えるために買いました。ThinkPad E480付属のACアダプタはやや大きいため、Nano IIのようなコンパクトな充電器はありがたいです。

Anker PowerPort IIIはスマホやタブレットの充電に長らく使ってきたAUKEY PA-Y12（72W Charging Station、USBポート: Cx1 + Ax2）の置き換えです。出力は負けますがコンパクトでありがたい限りです。時代の進化を感じます。

AUKEY Charging Stationに比べると、Anker PowerPort IIIはType-Aポートが-1でType-Cポートが+1です。以前ならType-Aポートが多い方が嬉しかったのですが、最近は我が家もType-Cでの充電に対応した機器が多くなって、AでもCでもどっちでも問題なくなりました。

ELECOMキューブ充電器は旅行で持っていく用に買いました。3ポートあるのにコンパクトでとても良いです。

ただ1点気になるのは、Type-CポートとType-Aポートの抜き差しを繰り返すとまれに充電制御がおかしくなる？現象です。Type-CポートのUSB-PD出力が5Vに張り付いてしまい、他のポートを空けても戻らなくなることがありました。コンセントから外して再度電源を投入すると直ります。何か条件があるのかな？

自分のドメインとGmailとDNSのSPFレコード

目次: 自宅サーバー

Gmailのメール受信ポリシーが2024年の2月で変更されるというニュース（Gmailユーザへメールが届かなくなる？Googleが発表した「新しいメール送信者のガイドライン」とDMARC対応を解説！ - NRIセキュア ブログ）を思い出しました。

自分のドメインからGmailにメールを送ることはほとんどないですが、全く送れないのも困りそうです。試しにGmailに自分のドメインのメールアドレスからメールを送ったところエラーが返ってきました。もうポリシーが変更されているのでしょうか？

とりあえずDNSの設定を変更してSPF（RFC 7208, Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1）レコードを追加します。送信元がメールサーバーのIPと一致しなければ、全部受信拒否してOKという強気の設定にしました（バリュードメインの設定パネル用の書式で書いています）。

txt @ v=spf1 ip4:219.94.129.142 -all

設定後しばらく待って（少なくともDNSのTTLに指定した秒数以上）からGmailにメールを送ったところ正しく届いていました。良かった良かった。

設定の意味がわからないときは

SPFレコードの設定を解説してくれているブログ（送信ドメインを認証するためのSPFレコードに詳しくなろう - SendGridブログ）が参考になりました。

活きた設定例を見たいときはプロバイダ各社のSPFレコードを見ると良いと思います。SPFはTXTレコードの一種なので、TXTレコードをDNSに問い合わせます。

$ dig wakwak.com TXT
（略）

;; QUESTION SECTION:
;wakwak.com.                    IN      TXT

;; ANSWER SECTION:
wakwak.com.             86400   IN      TXT     "v=spf1 ip4:211.9.226.0/25 ip4:211.9.226.128/26 ip4:211.9.227.0/25 ip4:211.9.227.160/27 ip4:211.9.230.0/23 ip4:211.132.128.0/23 ip4:211.132.130.160/28 ip4:211.132.130.132/31 ip4:211.132.130.208/31 ip4:219.103.130.0/24 ip4:219.103.131.128/26 ~all"

;; AUTHORITY SECTION:
wakwak.com.             73658   IN      NS      ns2.wakwak.com.
wakwak.com.             73658   IN      NS      ns1.wakwak.com.

;; ADDITIONAL SECTION:
ns1.wakwak.com.         37518   IN      A       211.9.226.37
ns2.wakwak.com.         37518   IN      A       211.9.226.101

理由はわからないですが、プロバイダのSPFレコードを見るとディレクティブ（レコードの最後の部分）に~allを使っていることが多いです。

今回はkatsuster.netのSPFレコードのディレクティブを-all（ルールに合致しなければ全部受信拒否）にしましたが、世の中のプロバイダ同様に~all（ルールに合致しなくても受信拒否しない）でも良いのかもしれません。

M5Stamp C3のAD端子

目次: Arduino

M5Stamp C3で遊んでいるとプログラムが妙に遅くなることがあって気になります。AD端子が関わっているようです。原因を調べてメモしておきます。

まず全力を見るためdigitalWrite()でGPIO出力のHIGH <-> LOWを往復させるだけのスケッチ（Arduinoはボードで動かすプログラムのことをスケッチと呼ぶ）を作成し、出力がHIGH区間の幅（＝ループ1回の処理に掛かる時間）をオシロスコープで計測したところ約7.6usでした。

M5Stamp C3のピン配置図（M5Stack社のサイトから転載）

M5Stamp C3のピン配置図を見るとA/D変換に対応した端子は0, 1, 4, 5の4つです。先ほどのスケッチにA/D変換対応端子の読み出し（＝処理が遅くなる容疑者）を順に追加して、同様にループ1回の処理に掛かる時間を計測します。

• digitalWrite()のみ: 7.6us
• analogRead(0): 64.0us
• analogRead(0), (1): 118.0us
• analogRead(0), (1), (4): 176.0us
• analogRead(0), (1), (4), (5): 20.8"ms"

どういう訳かanalogRead(5)だけが異常に遅く、読み出し値も常に0で正常動作していないように見えます。とりあえずこの端子は使わないことにしましょうか……。

もうひとつのA/D変換対応端子の読み出しAPIであるanalogReadMilliVolts()の時間も計測しましょう。読みだした値をmV単位に換算する処理が必要なので、処理時間はanalogRead() < analogReadMilliVolts()になるはずです。

• analogRead(0): 64.0us
• analogReadMilliVolts(0): 80.0us

割り算が要るのでそこそこ重い処理だと思いますが、16us（160MHz換算で2560クロック）も掛かるんですね。迂闊に連打しない方が良さそうです。

M5Stackとesp32とArduino

目次: Arduino

M5Stackというボードが電子工作に便利らしいという話を聞き、M5 Core2とM5Stamp C3という小型のボードを買いました。Core2の方は機能豊富な分、お値段もそこそこ（8,000円くらい）します。M5Stampは安い（1,300円くらい）です。

開発環境

M5Stackのサイト（M5Stack document PLATFORMのページ）を見ると、AIなど特定用途向けを外すと開発環境は4つあるようです。多いなあ。派閥争い中でしょうか。

• UIFlow
• Arduino IDE
• Micropython
• .NET nanoFramework

1番目に表示されているUIFlowが一番おススメなのでしょうけど、残念ながらUIFlowはM5Stamp C3に対応していないようです。2番目に表示されていたArduino IDEにしました。Arduino IDEを使うなら素直にArduinoボードを買った方が良かったかな、まあいいか。

M5Stamp C3はデバッグできない

M5StackシリーズはいずれもEspressifのESP32ファミリーのSoC（IoT向けの小規模SoC）を採用しています。CPUとSRAM、一通りの低速系I/O I2C, SPI, I2Sなどの他に、Wi-FiやBluetoothに対応していて素晴らしいSoCです。無線技術に強いEspressifならではですね。

私が購入したM5Stamp C3はESP32-C3というSoCを採用しています。ESP32シリーズの中でC3は割と後発らしく、CPUが従来のXtensaではなくRISC-Vに変更されています。

新しいせいかCPUアーキを変更したせいか知りませんが、Arduino IDEでデバッグしようとしてもOpenOCDが繋がらないとエラーが出てデバッグできないです。ログを全部載せると長いので別ファイル（ ログ全部）にします。

Debug: 215 114 command.c:155 script_debug(): command - init
Debug: 216 115 command.c:155 script_debug(): command - target init
Debug: 217 115 command.c:155 script_debug(): command - target names
Debug: 218 115 command.c:155 script_debug(): command - esp32c3 cget -event gdb-flash-erase-start
Debug: 219 115 command.c:155 script_debug(): command - esp32c3 configure -event gdb-flash-erase-start reset init
Debug: 220 115 command.c:155 script_debug(): command - esp32c3 cget -event gdb-flash-write-end
Debug: 221 115 command.c:155 script_debug(): command - esp32c3 configure -event gdb-flash-write-end reset halt
Debug: 222 115 command.c:155 script_debug(): command - esp32c3 cget -event gdb-attach
Debug: 223 116 target.c:1659 handle_target_init_command(): Initializing targets...
Debug: 224 116 riscv.c:444 riscv_init_target(): riscv_init_target()
Debug: 225 116 semihosting_common.c:107 semihosting_common_init():  
Error: 226 131 esp_usb_jtag.c:642 esp_usb_jtag_init(): esp_usb_jtag: could not find or open device!    ★JTAGが見つからない？？
Debug: 227 131 command.c:545 run_command(): Command 'init' failed with error code -4
User : 228 131 command.c:608 command_run_line(): 
Error: 229 131 riscv.c:1755 riscv_get_gdb_arch(): Unsupported xlen: -1
Error: 230 131 esp_semihosting.c:67 target_to_esp_semihost_data(): Unknown target arch!
Debug: 231 131 riscv.c:490 riscv_deinit_target(): riscv_deinit_target()
Debug: 232 132 target.c:2225 target_free_all_working_areas_restore(): freeing all working areas

エラーの前後だけ切り出すとこんな感じです。JTAGデバイスが見つからんと言っているように見えますが、どうしたら良いか全くわかりません。しばらくはprintfデバッグするしかないようです。M5Stamp C3はM5Stackシリーズを初めて使う人が買うべきボードではなかった？？

ArduinoとESP32ライブラリ

M5Stackについて書かれたブログやコードを見ていると、外部ライブラリ（AdaFruit, Lovyan GFXとか）を使う場合と、Arduino-ESP32ライブラリを使う場合があるようです。

Arduino-ESP32ライブラリのドキュメントはEspressifが公開しています（Arduino-ESP32 2.0.14 documentation）。このライブラリはOSSでGitHubにてソースコードが公開されています（Arduino core for the ESP32 - GitHub）。

どうやってライブラリを入れ替えるのかわかりませんけど、Arduinoライブラリの中を見ることはできそうです。ありがたいですね。

Arduino-ESP32ライブラリはESP32 IDF（IoT Development Framework）というEspressif独自APIのライブラリを使用して実装されているようです。ドキュメントはやはりEspressifが公開しています（ESP-IDF Programming Guide）。GitHubにてソースコードも公開されています（Espressif IoT Development Framework - GitHub）。

このライブラリはちゃんと見てないですが、バイナリ（*.a）しかない部分もあって若干意味不明に見えます……。まあライブラリの表面だけだとしてもソースコードがあってありがたいです。きっと。

令和6年能登半島地震災害への寄付

正月も元日から日本を揺るがした能登半島の震災ですが、令和6年能登半島地震災害義援金（日本赤十字社のサイト）、受付が始まってましたので寄付しました。何かの助けになると良いな……。

寄付したと言いふらすのは行儀が良くないと昔は思っていましたが、言いふらしても誰も不幸にならないし「みんなやってる」「みんなやろう」も広まるし、悪いことはないので積極的に言うようにしています。

メモ: 技術系？の話はFacebookから転記しておくことにした。追記あり。

VSCodeでRISC-Vボードをデバッグその4 - SSH Remote ExtensionでGDBをボードにアタッチ

目次: Linux

前回はLinuxマシン単独でGDBを使ってRISC-Vボードのデバッグを行うところまでを設定しました。

今回はその続きで、Visual Studio Code（以降VSCode）とSSH Remote Extensionを使ってGDBをOpenOCDに接続しRISC-Vボードをデバッグします。

C/C++ Extension Packをインストール

C/C++デバッグ用のExtensionをSSH接続先にインストールします。C/C++ Extension Packをインストールしておくのが便利だと思います。

launch.json fileの作成

左側のActivity BarからRun and Debugを選択して（矢印1）、create a launch.json fileを押すと（矢印2）、デバッガを選べと言われるのでC++ (GDB/LLDB)を選択します（矢印3）。もしC++ (GDB/LLDB)が選択肢に現れない場合は、ソースコードウインドウを全部閉じてからもう一度やってください。

CMakeLists.txtを選択していた時に出るエラー

C言語ではないファイルを開いてRun and Debugやcreate a launch.json fileを押すと選択肢が変わるので注意してください。例えばCMakeLists.txtを開いてRun and Debugを押すと"CMake does not support automatic debugging for this file"とエラーが表示されるだけで何も起きません。

VSCodeは何もファイルを開いていなければ使用可能なデバッガを全て列挙し、開いているファイルがあればそのファイルに対して使用可能なデバッガだけを表示するようです。この仕様は初見だと分かりにくいですね……慣れたら便利なのかなあ？

Linuxマシン側の準備

詳細はその2（2023年12月30日の日記参照）にて紹介していますので、ダイジェストでお送りします。

ボードとSSH接続先のLinuxマシンを接続します。メニューの[Terminal] - [New Terminal]で1つ目の端末を開いてOpenOCDを起動します。

$ sudo openocd -c 'bindto 0.0.0.0' -f tcl/interface/jlink.cfg -f tcl/board/sifive-hifive1-revb.cfg

メニューの[Terminal] - [New Terminal]で2つ目の端末を開いてGDBを起動し、実行ファイルをロードします。launch.jsonの"program"で指定した実行ファイルをロードしてください。

$ riscv64-zephyr-elf-gdb build/zephyr/zephyr.elf

(gdb) target remote localhost:3333
(gdb) monitor reset halt
(gdb) load
(gdb) continue

UARTを見てRISC-Vボードが正常に動作していることを確認します。

$ pyserial-miniterm /dev/ttyACM0 115200 --raw

ここまで確認出来たらいよいよVSCodeからGDBを起動できます。長かったですね。

デバッガの設定

先ほど紹介したcreate a launch.jsonを選択するとGDBを起動する設定が生成されます。

{
    // Use IntelliSense to learn about possible attributes.
    // Hover to view descriptions of existing attributes.
    // For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
    "version": "0.2.0",
    "configurations": []
}

が、バグっているのか何なのか、ほぼ何も書かれていないlaunch.jsonが生成されます。なぜ……？無いものは仕方ないので、

{
    "version": "0.2.0",
    "configurations": [        
        {
            "name": "(gdb) Attach",
            "type": "cppdbg",
            "request": "launch",
            "program": "${workspaceFolder}/build/zephyr/zephyr.elf",
            "cwd": "${workspaceFolder}",
            "MIMode": "gdb",
            "miDebuggerPath": "/home/katsuhiro/work/zephyr-sdk/riscv64-zephyr-elf/bin/riscv64-zephyr-elf-gdb",
            "miDebuggerServerAddress": "localhost:3333",
            "setupCommands": [
                {
                    "description": "Enable pretty-printing for gdb",
                    "text": "-enable-pretty-printing",
                    "ignoreFailures": true,
                },
            ],
        },
    ]
}

上記のように変えます。デバッガのパス（miDebgguerPath）は適宜環境に合わせてください。

デバッガ起動

VSCodeのRun and Debugから先ほど作成した設定でデバッガを起動します。

デバッグ用のツールバー

デバッガが起動してOpenOCDに接続できるとVSCodeの上部に小さなツールバーが出てきます。出ない場合は下部にエラーメッセージが表示されるはず。

Pause後の画面の例

ツールバーのPauseボタン（左端）を押すと、HiFive1ボードの実行が停止して実行中のプログラムのソースコードが表示され、コールスタックの表示なども動作するはずです。ブレークポイントの設定や再開、ステップ実行などもできます。

私はCUIでもあまり困らないタイプですが、デバッガだけはGUIの方が見やすくて捗りますね。VSCodeのコード閲覧性が良いというのもありそうです。

できていない点

実質デバッガのアタッチしかできていません。ボードのリセット、実行ファイルのロードを端末から手動でやっている点が非常にイマイチです。

VSCodeのC/C++ Debugger Extensionは良く知らないので、VSCodeから実行する方法が判明したら追記しておきます。

羽田空港で大事故

早朝の便で東京に帰ってきました。

Twitterで羽田空港がどうこうと騒いでいる人がたくさんいて、何かあったのか？とニュースを見たら、羽田空港で日本航空機のエアバスA350と海上保安庁機のボンバルディアDHC8が滑走路上で衝突し、日航機が爆発炎上しているLive映像が流れていました。さっきまで居た羽田空港……だよな？炎上してる……。

A350は炎上してほぼ灰になったにも関わらず、400人もの乗客が全員脱出に成功して死者が一人も出なかったのは奇跡です。日本航空が日頃から安全を重視して取り組んでいる賜物だと思います。

それにしても2024年は1月1日から大災害、大事故が連続しており、何とも不安になるスタートですね……。