で、確認したら2台ともnaomiには認識されて、個別にアドレスは振られた模様。でもなぜかSEGA I/Oはアドレス持って認識されてはいるもののIDも空だし入力も送信できてない。なんか動作してないっぽい感じ。下流にいるionaはきっちり動作してるので電気的な問題じゃなさそう。となるとSEGA I/Oがなんらかの自粛モードに入ってるのか、ionaが通信を邪魔しちゃってるのか。これを調べるとなるとプロトコルアナライザーが必要だなー、と。
そこで作ることにしたのがJVS I/O Monitor。基本、D+に流れる信号をモニタしてやれば良いので難しくはありません。
 |
| こいつの出番 |
去年作った基板を使えばSTM32を使ってお手軽にUSBデバイスが作れますので、D+をモニタして解析した通信内容をログとしてUSBシリアルとしてホストに流してやるデバイスを検討。一晩もあれば作れるだろう……と思っていたのですが。
トラブルいっぱい。
USB側は慣れてたけど、USARTの扱いが色々といけてない。ログ解析をしながらUSBでデータを流しだし、USARTを取りこぼしなく処理する、というのはどうやら無理っぽいです。
マイコンの数だけ落とし穴があると言ったがアレは嘘だ、ペリフェラルの数だけある、というかレジスタの数だけある事すらあるかもしれない— とよしま (@toyoshim) August 11, 2019
（言ってないけど）
stm32f042について新たに得られた知見1)USBとUART1を同時に使うとUSB通信時にUARTが死ぬパタンあり。UART2で回避可能。2)UARTはHAL的には3系統APIあるけどDMA+リングバッファ以外実用的じゃない。3)リングとUSB通信用のバッファを、間でフォーマット変換するのに必要十分なだけ取るとメモリが溢れる。— とよしま (@toyoshim) August 12, 2019
という事で悲鳴の声。どうにも処理が安定しないので、デバイス側はログ収集に専念させ、ホスト側で解析をするよう方針を変えました。で、どうせホストでやるならWireshark使うよね？って事でざっくり調べてできそうな事を確認、方針を固めました。
取り敢えず、ほぼ生のログを転送するだけにして、ホスト上でpcapフォーマットに変換、リダイレクトでwiresharkに食わせて、作ったplugin経由でログ解析して眺めるって形に落ち着きそう。まぁ、これはこれで正しい。作るのも使うのも面倒臭いけど。— とよしま (@toyoshim) August 12, 2019
しかしまた、いっきに遠回りに……。ホスト側の処理は正確にはシリアルから読んだ物をpcap形式にして名前付きパイプに書き込むって物でした。Wiresharkはデバイスだけじゃなくパイプを開いてログとる事もできるんですね。Linuxのシリアルも罠いっぱいで初めての人は色々とハマる（主にmodem周りのdaemonさんがATコマンド勝手に投げつけたり、ttyをrawにしなきゃいけなかったり）んだけど、それはまた別の話。慣れないLuaとドキュメント足りてないWiresharkのAPIと戦う事数日、なんとか動くようになるも、なんかまだ取りこぼしがある。リクエストの後にUSBにデータ送り出すと常にレスポンスのデータ間に合わずに見逃してる感じ。
WiresharkでそれっぽくJVSIOのログをリアルタイムで見られるようになってきた。 pic.twitter.com/U6Rhlue7Mz— とよしま (@toyoshim) August 13, 2019
って事でファームウェアをもう少し頑張るわけだけど……なんで取りこぼしなくデータ読むためだけに「俺SUGEEEE」みたいなバッファ回すコードかかなきゃならんのか。
そうこうしてるうちにLuaも少しはわかって来たので全体を少し手直し。綺麗になったのか良くわからないけど、まぁいっか。って事でようやくテスト環境が整ったのでした。
例によって色々とこちらに。
0 件のコメント:
コメントを投稿