電話帳データをOPPで受信すべく、準備を進めています。まずは、WT32での受信動作確認作業を報告しておくことにします。
WT32ではOPPのクライアント側とサーバ側の両方の動作が可能ですが、受信動作のためにはサーバとしての設定が必要になります。具体的には
TOSHIBAのスタックにはOPPを使うファイル送信機能があるので、これを使ってみると。。
デバイスの検索にひっかかるようになりました。そして簡単なテキストファイルを送信してみると、WT32から次のような出力を得ることができました。
最初と途中で文字化けが生じている箇所がありますが、これは出力の中に8bitのデータが混在しているため。送信したファイルのデータは全て7ビットのASCIIコードなのですが、OPP送信の際に使用されるOBEXのフレームにはヘッダ情報が追加されています。どうやら、このヘッダ情報がそのまま出力されてきているようで、その部分で文字化けが生じているようです。ちゃんと受信をおこなうためには、OBEXのフレームを解釈してデータ部分だけを拾い、その結果をSPIフラッシュに書き込むという処理が必要になります。
WT32ではOPPのクライアント側とサーバ側の両方の動作が可能ですが、受信動作のためにはサーバとしての設定が必要になります。具体的には
SET BT CLASS 740428 SET BT NAME BlueSAM SET PROFILE OPP ONとして、一度resetをしておきます。これで、OPPサービスが利用できることをSDPで通知可能になります。3行目はOPPのプロファイルを利用可能にしていることが自明ですが、1行目はBluetoothについてある程度の知識が必要となるところです。Bluetoothではデバイス検索がおこなわれた際に、その応答の中にデバイスアドレスだけでなく、自分が提供する機能を表現する情報(Class of Device)も含めるようになっています。1行目は、このClass of Deviceの値を指定するための設定になっています。デバイスを検索する側では、Class of Deviceを見るだけでデバイスのおおよその役割が把握できますから、自分が求める機能を提供するかどうかの判断に役立てることができます。2行目は名前検索の際に応答する名前を設定しています。
TOSHIBAのスタックにはOPPを使うファイル送信機能があるので、これを使ってみると。。
デバイスの検索にひっかかるようになりました。そして簡単なテキストファイルを送信してみると、WT32から次のような出力を得ることができました。
最初と途中で文字化けが生じている箇所がありますが、これは出力の中に8bitのデータが混在しているため。送信したファイルのデータは全て7ビットのASCIIコードなのですが、OPP送信の際に使用されるOBEXのフレームにはヘッダ情報が追加されています。どうやら、このヘッダ情報がそのまま出力されてきているようで、その部分で文字化けが生じているようです。ちゃんと受信をおこなうためには、OBEXのフレームを解釈してデータ部分だけを拾い、その結果をSPIフラッシュに書き込むという処理が必要になります。