USB_LDDを使ってみる -- その3

USB_LDDをつかってBluetoothドングルのエニュメレーションまではできたので、いよいよBTstackを動かし始めます。入門編としては、SPPをつかうspp_counterというサンプルを動かしてみるというのがお約束のようなので、まずはこれを動かすことにします。

BluetoothのUSBトランスポートでは、コマンドの送信にコントロール転送、Bluetoothからのイベントの受信にインタラプト転送、ACLリンクのデータ送受にバルク転送、そしてSCOリンクの送受にアイソクロナス転送と、USBの各転送方式を全て利用しますが、SPPであればアイソクロナス転送は必要ありません。BTstackが動くとHCIでコマンドを送信して、それに対する応答がドングルからインタラプト転送で返ってきますので、まずはこの部分の動作を確認することにします。新たにインタラプト転送のパイプを開いてやり、そこからの読み出しを開始しておき、パイプ0にHCIコマンドを送ってやります。


ところが、最初の２つ、３つのコマンドに対してはちゃんと応答が返ってくるのですが、その先に進んでくれません。どうやらパイプ０にコマンドを送信した後の、送信完了コールバックが動いていないようです。

USBの動きとしては、1ms間隔でインタラプト転送によるイベントの読み出しがかかる中で、コントロール転送によるコマンド送信が発生するという動作になります。そこで試しに、コントロール転送でコマンドを送信する際には、進行中のインタラプト転送をUSB1_HostCancelTransfer()を使って　いったん止めてからコマンド送信をするようにしてみました。すると、


初期化に必要な一連のHCIコマンドが送信され、それに対する応答が返ってきてBTstackがちゃんと立ち上がるところまで進みました。

このようにコントロール転送とインタラプト転送を同時に動かさなければちゃんとBTstackが立ち上がるのですが、この先ではACLリンクの送受もしたいので、やはり複数の転送を同時に動かさなければSPPを動かすことができません。Processor Expertの生成したドライバコードをざっと見たところでは、複数のパイプを同時に使うことを意図して作られているようですので、何か使い方が悪いのか、生成されたコードにバグが潜んでいるかのいずれかだろうと思われます。そういうわけで、USBのコードを追いかけることになってしまいました。