Repo
kjana00@gmail.com
2013-05-08 00:53:55
今朝は晴れ。朝ごはんはパンとサラダとソーセージ。連休前にまあ大丈夫だろうと買っておいたレタスはやっぱりだいぶ味が落ちるな……暑くなるかと思ったけどそうでもない。気温の乱高下が激しいのはちょっと困る。
資料の直しだのメールの返事書きだのをして作業場へ。それで、全然解決してない問題をどうしようかという。さくっとあきらめて何か駄目ですっていう報告しようかと思ったけど、ちょっと思い付いてしまったことがあるんでやってみようかという方向……ということでソフトウェアベースの USB アナライザを探してきて、DLL 使って動いてる Windows のアプリケーションが何やってるんだか眺めてみた。
ちょっとキャプチャ出来たり出来なかったりの法則が読めなかったりしたけどまあ何とかなってしばらく悩んでみる。ブロックデータ転送にバルク転送使ってるなと真似してみるっていうのは駄目だった。どう駄目なのかは良くわからないけど。とにかく状況が改善されてるように見えない。HID クラスのレポートに分割して載せるわけじゃないから転送自体は一見、ちゃんと動いてるように見えなくもないわけだけど。でも、ブロック閉じて別のブロック開くところでエラーになるからね……エラーはなくて警告かもしれないという話もあるとはいえ。
こっちのプログラムでは投げてないコマンド投げてるんだよなっていうのを真似してみても駄目。まあこのコマンド、パラメータ読み出しのはずだから影響あるわけないんだけど。それから分割したコマンドを見てて、何かペイロード長は最大 26 bytes じゃなくて 28 bytes だよなというのが見えたんで試してみる。……あれ、止まる場所変わったな。今まで通ってたコマンドが通らなくなった。でも、これってさっき見た通りだと non fatal な警告なんだよね……無視してみようか。
してみたら、分割したコマンドの最後の部分がエラーになるっていう症状が消えて、ちゃんと最後まで動くようになった。そのままブロックのクローズ、別のブロックのオープン - データ転送 - クローズ、セッションクローズ、フラッシュと素直に全部通ってるように見える。……これかな? つまり、プロトコル仕様書に嘘が書いてあった? 最大長 32 bytes でヘッダに 4 bytes だから、書いてあるペイロード長の最大 26 bytes だと謎の隙間が気になってたところではあるんだけど、何せ今、使われてるコードを引っ張ってきたもんだから、動いてる分には気にするべきじゃないのか、って思ってたところだったんだけど。同じように分割して送ってるはずの別のコマンドは 26 bytes 制限のままで通ってたっていうのもあり。でも 28 bytes にしてもそっちはそのまま通り続けてて、今まで通らなかったのも通るようになったんだから、こっちの方が正しいんだろうか。
とりあえずこんなことがありましたという報告をまとめてメーカーとの窓口をしてくれている人にメール。休み前に片付かなかった問題がすっきり片付いたということで、週報をまとめていい時間になったところですっきり帰ることに。呼び出されるコマンド書いたのはいいけど呼び出し側のテストどうしようねっていう話があるわけなんだけど、まあ、明日だ、明日。明日以降。
そういうことで帰って晩ごはんに冷奴と豚汁うどん。食べる前どころか着替える前に無駄に時間を潰すのはやめましょうなんていう話があったりしつつ。何で自分の部屋で立ち読みするのか。乾燥きんぴらを使うとちょっと酒臭さが強調されるんだろうか。うーん。
後は WWW 見たりゲームしたりと。地道に回ってレベル 36 になったぐらいな。もう一段階潜るのとクエスト行くのとどっちがいいかな…… 34 階でもたまにまずい敵が出て来てえらい目にあったりしてるわけで、あんまりほいほい動けない感じ。