あんパン

こしあん派

Raspberry Piに接続されたRaspberry Pi Pico / Pico2にuf2を効率的に書き込む補助ツールを作った

会社でBoard43というRP2350A互換ボードを作り、量産して配布するにあたってファームウェアを書き込む必要があった。

blog.smartbank.co.jp

今回、ファームウェアは2種類に分けていて、動作確認用のCで書いたものと、実際に動かすためのカスタムR2P2(PicoRuby)ビルドという構成。動作確認用でLED、ボタン、ブザーなどすべての構成要素を検証して、本番用のR2P2を書き込む流れにしたかった。1枚ずつちまちまコマンドを書いて焼いているといつまで経っても終わらないのは明白だったので、1ボタンで焼ける仕組みが欲しかった。ので作った。

github.com

BOOTSELモードで接続されたRaspberry Pi Pico / Pico 2 / RP2***ボードすべてに対して、GPIOのLOWをトリガーにファームウェアを書き込んでくれる。GP27がGNDと短絡したらdebug.uf2、GP17がGNDと短絡したらproduction.uf2を書き込む、みたいな感じ。

設定はtomlで書ける。

[general]
log_level = "info"           # debug, info, warn, error
poll_interval_ms = 500       # USB device polling interval (ms)

[[pin]]
gpio = 17
uf2_path = "/home/pi/firmware/production.uf2"
label = "Production firmware"

[[pin]]
gpio = 27
uf2_path = "/home/pi/firmware/debug.uf2"
label = "Debug firmware"

実際に使ってみると、とにかく高速に焼けるのでかなり便利だった。これがなければ発送の締切に間に合ってなかっただろう。。。

Raspberry Piに大量のボードを繋ぐと、おそらく電源がネックになって4台が限界だった。8台だと書き込んでる最中に落ちちゃってうまく書き込めないということが頻発した。バスパワーじゃなくてセルフパワーのUSBハブがあるといいかもしれない。また、ときおり書き込みに失敗するのでログを監視する画面はあると便利。

こういう調子で量産することがなければもう使うことはないような気がするけど、そんな機会は果たしてくるだろうか……?

macOSでUSB HIDのReportを監視するツールを作った

masawada.hatenablog.jp

Gotanda.rbで前述のこれを発表するときに、USB HIDのReportの中身みたいな内容の話をした。話すにあたってLinuxの usbhid-dump コマンド*1と同様のUSB HID Report観察ツールをmacOSで探したところ、意外とどこにもなかったので、こちらもClaude CodeにSwiftで書かせた。当日は時間がなかったのでReportを監視するだけのツールとして作ったけど、あらためてDevice DescriptorやReport Descriptorも出力できるコマンドとして作り直して公開した。SwiftでCLIツールを作ったのは初めてだったが、ArgumentParserがかなり使いやすいし、素朴にSwiftの書き味もいいので結構アリな気がする。

github.com

この手の解析ツールは公式に提供されていてもおかしくないツールだと思うものの、入力監視の権限が必要になるし実質的にキーロガーのような振舞いをするため、なるべくセキュアにやっていきたい都合上こういうのは公開できないのだろう。利用する上では注意してね、ということをrepoのREADMEにも書いている。

このツールを使うとMacBookに組込まれているおもしろセンサーの値も取れることが分かった。たとえば、画面のヒンジの角度がどれくらいか、というのもUSB HIDで取ることができる。何に使うのかって感じだけど、これをもとに画面の明るさや車両モーションキュー*2の動かし具合などを調節しているのかもしれない。

今後Raspberry Pi Picoでおもしろツールを生成するにあたって、かなり愛用するであろうツールが作れたので満足している。

*1:https://github.com/DIGImend/usbhid-dump

*2:酔い止め機能: https://support.apple.com/ja-jp/guide/mac-help/mchla3c4f1da/mac

Google Meetでボタンを押している間だけミュートを解除する物理デバイスを作った

Google MeetにはUSBデバイスでミュートスイッチを操作する機能が存在する。一般には会議用スピーカーのミュートスイッチに連動してMeetのミュートをON/OFFする機能と思われる。

workspaceupdates.googleblog.com

Call control will work with most USB telephony peripherals; however, the experience may differ from device to device.

書きぶりからして、USB HIDのReport DescriptorにTelephony Usageが含まれているデバイスを認識させればこの機能を利用できそう。これでPush to Talkを実現する物理デバイスができないか、ということを考えていた(というか2,3年くらい前に考えていたけど、気持ちが高まらず優先順としては低めだった)。

1月のGotanda.rbで急遽なにか話すことになり、ふと思い出して30分くらいでClaude Codeにガッと書かせたらできたので、これで発表した。当日のコードはごちゃついていたので、その後整理した結果できたのがこれ。

github.com

akizukidenshi.com

Raspberry Pi PicoまたはRaspberry Pi Pico 2を買ってきてPCに繋いで、認識されたディスクにファームウェアをドラッグアンドドロップすれば完成。Google Meetの設定から通話コントロールのデバイスを設定するだけで使える。Raspberry Pi Pico 2上では動作確認していて、Picoもどこかに実機があるけど発掘できていないので確認していない。たぶん動くはず。

通話コントロールの設定からデバイスを接続する

BOOTSELボタンを押している間だけLEDが光ってミュート解除されるようになる。

BOOTSELボタンを押すと喋れるようになる

とはいえリモートワークだとわざわざミュートを切り替えたいことがあんまりない。同じ会議室にいて音声統合しているケースだと他のPCに自分の声が拾われて聞きづらくなってしまうことがあるから、全員にこのボタンを持ってもらったら解決しそうだけど、それは現実的ではなかろう。

Claude CodeなりCodexなりにうまくコンテキストを渡せばRaspberry Pi Pico向けのファームウェアであっても十分に動くものを作ってもらえる、というのは収穫だったように思う。

Markdownを変換してブラウザで開くmdpというツールを作った

github.com

詳しい使い方はREADMEをみてください。

最近はClaude CodeなりCodexなりでSpec-Driven Developmentをしたり、調査結果をreport.mdに保存して読むということをよくやっている。ふだんVimを利用しているのでMarkdownもVimで読んでいたのだけど、読みづらいしMermaidはレンダリングされないしで限界が来ているなとおもったので、素朴に変換してブラウザで開くコマンドを作った。

作ったといっても実際にはClaude Codeが99%くらい作っていて、とりあえず動けばいいかとおもってあきらかにマズそうなところ以外は取り込みまくっているので実装が散らかっている。ここはあとでなんとかする……

推しポイントはテーマ機能で、テンプレートHTMLを作って置いておくと、変換したMarkdownをテンプレートと結合して開いてくれる。テンプレートに目次生成のJavaScriptだったりMermaidを解釈するJavaScriptだったりを仕込めば見た目を豪華にできる。細かいカスタムはそれぞれユーザに委ねられるので、好きな色味・表示でMarkdownを見られるのがいいとおもっている。これもClaude Codeに頼めばいい感じにしてもらえる。

mdpで変換したMarkdownでシンタックスハイライトされている表示mdpで変換したMarkdownでMermaidが解釈されている表示
実際にテーマを作って適用したもの

ちなみに作る前にyusukebeさんのGitHub CLI拡張も使ってみていて、実際これも便利だった。

github.com

ただ、複数ファイルをバシバシ開いていくときにいちいちサーバが立ち上がるのは自分の生活に合わないとおもって新しく作ったのだった。

ということでよければお使いください。

ChatGPTのWork with Appsを利用してXcodeでiOSアプリを作った雑感

ここ1年くらい睡眠用ASMR動画を流しながら寝ているのだが、つい先日、妻がロック画面に表示された動画の名前を音読する事件が発生したので、再発防止策として簡素なプレイヤーを自作して動画名を隠そうという気持ちになった。最近ChatGPTがXcode上で使えるようになったという情報を見たので実際に試してみた。

当該の記事はこれで、要はChatGPTのネイティブアプリを入れておくと、Work with Appsのショートカットを押したときになんかいい感じにアプリと連携してくれるよ、というもの。Xcodeだけじゃなく他のアプリケーション(iTerm2とかNotionとか)とも連携してくれるっぽい。

help.openai.com

以下雑感。

  • Xcodeと連携すると、Xcode上の最前面で表示している1ファイルだけをChatGPTに送信して、応答に含まれている差分を1ボタンで適用できるようだった
  • Clineみたいなものを想像しているとだいぶ期待外れだと思う
    • Plan/Actみたいなモードはないので「まず計画を示してください」みたいなプロンプトを無限に入力することになる
      • 無計画に実行するとだいたい気持ちとズレたものが出てきがちなので計画を洗練させる、みたいなのは一緒な気がする
    • 編集してほしいファイル以外を渡すと発狂する
      • VideoListView.swiftを渡すつもりがContentView.swiftを渡してしまうとContentViewの中にVideoListViewを作り始める、みたいなことが発生する
      • 適切なファイルを渡すためにも、どのファイルをどう編集するのか、お伺いをたてる必要がある
    • clinerulesみたいなものは存在しないので、新規に開く都度文脈を手書きすることになる
      • ペライチのドキュメントを用意して最初に手で読み込ませればよさそうではある
    • ファイルシステムを操作できない
      • 読み込みすらできないので、まず文脈を伝えるために1ファイルずつ送信してこれを覚えてくださいみたいなプロンプトを入力していた
      • 当然書き込みもできないので新規にファイルを作ってあげて、そのファイルを渡して…… みたいなことが発生する
    • 差分の適用が1ボタンでできるのは便利
      • Auto Approve的なやつもある
  • 簡単かつある程度定型的なものであれば意外とシュッとできる、気がする
    • とはいえプロンプトを結構な量入力しないとまともに動作しないので、熟達した人間が利用するものではないイメージ
      • マジの初心者が調べながら書くよりは速い、くらいだと思う
    • コード書くのだるいな、というときには有用かもしれない
  • つまるところ、裏側は普通のChatGPTであって、そこにソースコードを投げてやりとりできる、くらいの機能があるだけ
    • やりとりのログもChatGPT上に保存される
      • だらだらやっていると前のやつから消えていく? ような気がする
      • これって通常のChatGPTもこうなのかな、あんまり長くやりとりすることなかったので分かってない
    • 課金プランもChatGPT Plusで利用できるので、費用が定額なのは魅力的ではある
  • そうこうしているうちにWWDCでApple Intelligenceのいい感じグッズが発表されそうな予感はする