最果て

あめりなです。
週末は天気が崩れまくりますね。
SPYZはインタフェースディスクリプタが2つある割にはコンフィギュレーションディスクリプタで示すインタフェース数は1と意味不明状態なのですが、実際、ディスクリプタをプリントしているコードを読むとコンフィギュレーションディスクリプタを取得した際のデータ長分だけグリグリしながら、インタフェースとエンドポイントをプリントしているので、コンフィギュレーションディスクリプタのインタフェース数でループしている訳じゃないのは確かでした。因みにエンドポイントはインタフェースディスクリプタのエンドポイント数を参照してループしていますけどね。
そういう訳で、インタフェース数をシカトしているように見えたのですが、実際にエンドポイントへのパイプを作成するロジックはどうなっているかとドライバコードを読むと、

USBD_CreateConfigurationRequest()

でインタフェースリストを取得してエンドちゅう。因みに、この関数はホストコントローラへのリクエスト関数で、複数インタフェースがあっても先頭のインタフェースしか返さないと関数仕様書はおっしゃってます。意味が分かりません。んな訳ないだろ。2ndパラメタは"インタフェースリスト"なんですよ。どちらにしろ、やはり1stインタフェースしか採取していないのでパイプが開かれていない状態ちゅうのはよく分かりました。
で。
やはり、これはドライバを作らないといよいよダメだぞ状態になってきました。
unix用ライブラリのlibusbでプリントした奴も同じディスクリプタを返しているので(デバイスクエリなんだから当たり前ですが)、その先のパイプ制御ロジックがポイントちゅうことになります。unix上ではlibusbでSPYZと直結出来ますからね。
あー、あとデータシートをまた読み直してみたのですが、シングルバルクが仕様だそうで、2ndインタフェースのエンドポイント数が1なのは正常ちゅうことでした。
なんとなくですけど、rwbulkをリライトして2ndインタフェースアクセスしーの、パイプ開きーのは出来そうな予感です。んふふ。
結局、今までの弊害は下記2点に集約。
・インタフェースが2つあるのに1つとかほざくコンフプリタ
・複数インタフェースの先頭を採用する上記関数を使ったドライバ
まぁ、週末はスノボなんでボチボチと。