Pi Picoのデバグが難しい [Pi Pico]
こないだからPi Picoのプログラムをしている。会社の工場で使う第1号にしようと思っている。Raspberry Piがたくさん増えてそれぞれがホストとWi-Fi経由で通信するせいで、貧弱なWi-Fi環境を圧迫するようになってきてしまった。Raspberry PiをPicoにしてネットワーク経由からUSB経由にすることでネットワークトラフィックを減らそう、という考えである。
その第1号機は、内蔵A/Dでアナログ信号を読み取ったり、GPIOでモータのOn/Offや状態監視をして、そのデータをmacOSで動くアプリにフィードバックするという簡単なもの。ホストから見るとvendor specific deviceとして見えて、ふたつのcoreのうち、core0でホストとやりとりをして、core1がA/DやらGPIOやらを制御するように書いている。前見た時はA/Dのデータが怪しかったのでPWMをローパスに通す回路を外付けして、その信号をA/Dで読んで自分自身で校正するようにした。これでどこまでINLが良くできるかはよくわからない。それはいいとして、そのPi Pico本体のデバグがなかなか進まない....
例えば、両方のコアではループが回っていてcore0では主にホストとの通信、core1では自分自身のハードウェアの制御をして、その間の通信にpico-sdkが提供してくれているqueueを使っている。ところが何かの拍子にそのコア間の通信がストールしたり、ホストとの通信が途切れたりする。
仮想記憶とマルチタスクを持ったOSだと実行がストールしてるかどうかは簡単に区別できるんだけど、Pi Picoのようなベアメタルではその区別が難しい、というかそもそもそんな区別はない。めんどくさいなと思ってやってなかった「Getting started with Raspberry Pi Pico(pdfファイル)」のAppendix Aにあるpicoprobeのセットアップをした。これはARMが持ってるデバグハードウェアにSWDという専用のシリアル通信でアクセスするためのもの。Pi PicoのボードのUSBとは反対側の端に出ている3本のピンがSWD用の端子。親切な人がいてmacOSでの使い方を教えてくれている。この通りにするとgdbがリモートで動いた。
左側のPi Picoがデバグされる方で、右側にpicoprobeをインストールしてある。両方がUSBを経由して1台のMacに繋がっている。すごい簡単。実際の作業はこういうふうにやってる。
右側下のターミナルウィンドウがOpenOCDのコンソールで、その上がリモートで繋がったgdb、左側がデバグ用のmacOSアプリのウィンドウでここからPi PicoへUSBを経由してコマンドを送ったりデータを受け取ったりしている。
VSCodeなんかの上でgui付きの便利なデバグができるらしいけど、VSCodeがディスプレイ全体を覆ってしまってmacOSのアプリウィンドウが隠れてしまうので、gdbのコマンドラインにしている。gdbコマンドをすぐ忘れてしまうけど慣れの問題だと考えて頑張ってる。
こういう環境整備はARMのデバグハードウェアやSWDやOpenOCDの技術の積み重ねがあってのことだけど、よくできている。僕がこれまで全然知らなかった世界で、こういうのほんとに感心してしまう。
でもなかなか使いこなすのが難しい。macOSのアプリをデバグするようなつもりでやってるとうまく行かないことがある。Pi Picoでは微妙なタイミングに依存するような場面が多くて、例えばループが空回りしているかどうかを見るのにタイマを組み込んだらそのレイテンシのせいで動作が変わったりして途方に暮れる。どうやら頭が仮想記憶とマルチタスクにスポイルされきっていて、どうやってデバグすればいいのかそもそもわかってないようである。
picoprobeのソースはたったこれだけ?と思うような簡単なものだけど、USB deviceとしてCDCとvendor specificなインターフェイスを持っている。OpenOCDからみたときにUSB経由のSWDトランシーバとして動作するようになっているらしい。ソースではPIOを使っていて肝心のところはよくわからない。OpenOCDにとってはハードウェアとしてはPi Picoでなくてもいいんだろうけど、結局Pi Picoをそれに使うのが一番安上がりだということみたい。例えば本家Raspberry PiではSWDの信号が作れるらしくて、OpenOCDをインストールしてネットワーク経由のリモートデバグとかができるようである。
今僕が書いてるのはマルチコアではあるけど、このpicoprobeに比べたらずっと簡単なことしかしてないのに、動作が不安定で、この1週間ほどほとんどデバグに進展がない。picoprobeだどなんの問題もないtud_vendor_write、_read関数が僕のでは書き残しや読み残しが起きて満足に動作しない。なんでだ?
ちょっと甘くみすぎていたようである。困った。
その第1号機は、内蔵A/Dでアナログ信号を読み取ったり、GPIOでモータのOn/Offや状態監視をして、そのデータをmacOSで動くアプリにフィードバックするという簡単なもの。ホストから見るとvendor specific deviceとして見えて、ふたつのcoreのうち、core0でホストとやりとりをして、core1がA/DやらGPIOやらを制御するように書いている。前見た時はA/Dのデータが怪しかったのでPWMをローパスに通す回路を外付けして、その信号をA/Dで読んで自分自身で校正するようにした。これでどこまでINLが良くできるかはよくわからない。それはいいとして、そのPi Pico本体のデバグがなかなか進まない....
例えば、両方のコアではループが回っていてcore0では主にホストとの通信、core1では自分自身のハードウェアの制御をして、その間の通信にpico-sdkが提供してくれているqueueを使っている。ところが何かの拍子にそのコア間の通信がストールしたり、ホストとの通信が途切れたりする。
仮想記憶とマルチタスクを持ったOSだと実行がストールしてるかどうかは簡単に区別できるんだけど、Pi Picoのようなベアメタルではその区別が難しい、というかそもそもそんな区別はない。めんどくさいなと思ってやってなかった「Getting started with Raspberry Pi Pico(pdfファイル)」のAppendix Aにあるpicoprobeのセットアップをした。これはARMが持ってるデバグハードウェアにSWDという専用のシリアル通信でアクセスするためのもの。Pi PicoのボードのUSBとは反対側の端に出ている3本のピンがSWD用の端子。親切な人がいてmacOSでの使い方を教えてくれている。この通りにするとgdbがリモートで動いた。
左側のPi Picoがデバグされる方で、右側にpicoprobeをインストールしてある。両方がUSBを経由して1台のMacに繋がっている。すごい簡単。実際の作業はこういうふうにやってる。
右側下のターミナルウィンドウがOpenOCDのコンソールで、その上がリモートで繋がったgdb、左側がデバグ用のmacOSアプリのウィンドウでここからPi PicoへUSBを経由してコマンドを送ったりデータを受け取ったりしている。
VSCodeなんかの上でgui付きの便利なデバグができるらしいけど、VSCodeがディスプレイ全体を覆ってしまってmacOSのアプリウィンドウが隠れてしまうので、gdbのコマンドラインにしている。gdbコマンドをすぐ忘れてしまうけど慣れの問題だと考えて頑張ってる。
こういう環境整備はARMのデバグハードウェアやSWDやOpenOCDの技術の積み重ねがあってのことだけど、よくできている。僕がこれまで全然知らなかった世界で、こういうのほんとに感心してしまう。
でもなかなか使いこなすのが難しい。macOSのアプリをデバグするようなつもりでやってるとうまく行かないことがある。Pi Picoでは微妙なタイミングに依存するような場面が多くて、例えばループが空回りしているかどうかを見るのにタイマを組み込んだらそのレイテンシのせいで動作が変わったりして途方に暮れる。どうやら頭が仮想記憶とマルチタスクにスポイルされきっていて、どうやってデバグすればいいのかそもそもわかってないようである。
picoprobeのソースはたったこれだけ?と思うような簡単なものだけど、USB deviceとしてCDCとvendor specificなインターフェイスを持っている。OpenOCDからみたときにUSB経由のSWDトランシーバとして動作するようになっているらしい。ソースではPIOを使っていて肝心のところはよくわからない。OpenOCDにとってはハードウェアとしてはPi Picoでなくてもいいんだろうけど、結局Pi Picoをそれに使うのが一番安上がりだということみたい。例えば本家Raspberry PiではSWDの信号が作れるらしくて、OpenOCDをインストールしてネットワーク経由のリモートデバグとかができるようである。
今僕が書いてるのはマルチコアではあるけど、このpicoprobeに比べたらずっと簡単なことしかしてないのに、動作が不安定で、この1週間ほどほとんどデバグに進展がない。picoprobeだどなんの問題もないtud_vendor_write、_read関数が僕のでは書き残しや読み残しが起きて満足に動作しない。なんでだ?
ちょっと甘くみすぎていたようである。困った。
2021-09-28 21:30
nice!(0)
コメント(0)
コメント 0