USB Type-Cの充電器を3つほど購入しましたので、メモを残しておきます。
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のメール受信ポリシーが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(ルールに合致しなくても受信拒否しない)でも良いのかもしれません。
目次: 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回の処理に掛かる時間を計測します。
どういう訳かanalogRead(5)だけが異常に遅く、読み出し値も常に0で正常動作していないように見えます。とりあえずこの端子は使わないことにしましょうか……。
もうひとつのA/D変換対応端子の読み出しAPIであるanalogReadMilliVolts()の時間も計測しましょう。読みだした値をmV単位に換算する処理が必要なので、処理時間はanalogRead() < analogReadMilliVolts()になるはずです。
割り算が要るのでそこそこ重い処理だと思いますが、16us(160MHz換算で2560クロック)も掛かるんですね。迂闊に連打しない方が良さそうです。
目次: Arduino
M5Stackというボードが電子工作に便利らしいという話を聞き、M5 Core2とM5Stamp C3という小型のボードを買いました。Core2の方は機能豊富な分、お値段もそこそこ(8,000円くらい)します。M5Stampは安い(1,300円くらい)です。
M5Stackのサイト(M5Stack document PLATFORMのページ)を見ると、AIなど特定用途向けを外すと開発環境は4つあるようです。多いなあ。派閥争い中でしょうか。
1番目に表示されているUIFlowが一番おススメなのでしょうけど、残念ながらUIFlowはM5Stamp C3に対応していないようです。2番目に表示されていたArduino IDEにしました。Arduino IDEを使うなら素直にArduinoボードを買った方が良かったかな、まあいいか。
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シリーズを初めて使う人が買うべきボードではなかった??
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年能登半島地震災害義援金(日本赤十字社のサイト)、受付が始まってましたので寄付しました。何かの助けになると良いな……。
寄付したと言いふらすのは行儀が良くないと昔は思っていましたが、言いふらしても誰も不幸にならないし「みんなやってる」「みんなやろう」も広まるし、悪いことはないので積極的に言うようにしています。
メモ: 技術系?の話はFacebookから転記しておくことにした。追記あり。
目次: Linux
前回はLinuxマシン単独でGDBを使ってRISC-Vボードのデバッグを行うところまでを設定しました。
今回はその続きで、Visual Studio Code(以降VSCode)とSSH Remote Extensionを使ってGDBをOpenOCDに接続しRISC-Vボードをデバッグします。
C/C++デバッグ用のExtensionをSSH接続先にインストールします。C/C++ Extension Packをインストールしておくのが便利だと思います。
左側のActivity BarからRun and Debugを選択して(矢印1)、create a launch.json fileを押すと(矢印2)、デバッガを選べと言われるのでC++ (GDB/LLDB)を選択します(矢印3)。もしC++ (GDB/LLDB)が選択肢に現れない場合は、ソースコードウインドウを全部閉じてからもう一度やってください。
C言語ではないファイルを開いてRun and Debugやcreate a launch.json fileを押すと選択肢が変わるので注意してください。例えばCMakeLists.txtを開いてRun and Debugを押すと"CMake does not support automatic debugging for this file"とエラーが表示されるだけで何も起きません。
VSCodeは何もファイルを開いていなければ使用可能なデバッガを全て列挙し、開いているファイルがあればそのファイルに対して使用可能なデバッガだけを表示するようです。この仕様は初見だと分かりにくいですね……慣れたら便利なのかなあ?
詳細はその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ボタン(左端)を押すと、HiFive1ボードの実行が停止して実行中のプログラムのソースコードが表示され、コールスタックの表示なども動作するはずです。ブレークポイントの設定や再開、ステップ実行などもできます。
私はCUIでもあまり困らないタイプですが、デバッガだけはGUIの方が見やすくて捗りますね。VSCodeのコード閲覧性が良いというのもありそうです。
実質デバッガのアタッチしかできていません。ボードのリセット、実行ファイルのロードを端末から手動でやっている点が非常にイマイチです。
VSCodeのC/C++ Debugger Extensionは良く知らないので、VSCodeから実行する方法が判明したら追記しておきます。
< | 2024 | > | ||||
<< | < | 01 | > | >> | ||
日 | 月 | 火 | 水 | 木 | 金 | 土 |
- | 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 | 29 | 30 | 31 | - | - | - |
合計:
本日: