golangのgousbを使おうとしている。
EndpointはINもOUTも取れたので、実際にデバイスと送受信してみる。
それよりも前にinterfaceの使い方がよくわからずに悩んだのだが、別の機会に。
01: length, err := dev.outEndpoint.Write(data)
wiresharkで期待したデータをUSBで送信しているのは分かった。
分かったのだが、このWrite()から制御が戻ってこないのだ。
レスポンスが受信できないのであれば送信データが間違っているのかもしれないし、Write()がエラーでも返してくれればヒントになるかもしれない。
だが、制御自体戻ってこないのだ。
なぜだ・・・。
と思ったら、open時にgousb.Contextをdeferでcloseするようにしていたためだった。
失敗失敗。
gousb.Deviceのcloseと同じタイミングでcloseすればよいだろう。
Write()の結果は戻るようになったが、次のRead()が戻らない。
wiresharkを見ても受信データが流れているようには見えない。ただ、URB_BULK inにはなっているので受信しようとはしているのだろう。
念のため送信しているデータを以前作ったパケットデータと比較したが、間違えてはいない。
うまくいっていればACKが受信できると思うのだが、そうなっていない。
wiresharkで受信したままRC-S370を外して付けなおすと、たぶんkernelがアクセスしているログが取れた。
Resetコマンドもやりとりしているようで、こういう感じになっていた。
待ち時間が足りないのか、などとも思っていたのだが、これを見るとそうでもないようだ。
うーむ。
うちのやつと比較してみよう。
こちらがうちのログだ。
kernelの方は、out(CMD), in, in(ACK, in, out, in(RES)。
うちの方は、out(CMD), out, in, in。
関係あるかどうか分からないが、outが2回続いているな。
OutEndpoint.Write()を1回だけ呼んでみても、それだけでoutが2回発生してしまう。
・・・いや、これは関係なかった。
過去の自作ライブラリでもこうなった。
out(CMD), out, in, in(ACK), in, in(RESP)。
readをリトライしていけばなんとかなるかも、と思ったが、ダメだね。
わからぬ・・・。
0 件のコメント:
コメントを投稿
コメントありがとうございます。
スパムかもしれない、と私が思ったら、
申し訳ないですが勝手に削除することもあります。
注: コメントを投稿できるのは、このブログのメンバーだけです。