ここしばらく作業が停滞気味なんですが、ようやくと若干の進展があったので、記事にしておきます。
電話帳を転送すべくOPP受信の動作を確認しましたが、ようやくとその内容をデコードしてSPIフラッシュに書き込めるところまできました。
SPIフラッシュは初期状態では書き込みがプロテクトされているので、最初にコマンドを与えてアンプロテクトしておきます。そしてファイルをダウンロードするエリアをあらかじめ消去しておきます。あとは、OPPで使われているOBEXのフレームを検出し、それをデコード、受信したデータ部分をフラッシュへ書き込んでいきます。
OBEXでは最初にヘッダ情報が付いたフレーム形式を用いて転送が行われます。したがってヘッダ情報を正しく解釈して、その内容に応じた処理をする必要があるのですが、OBEXなんて扱うのは初めてなんでまだ良く理解していません。いくつか転送方式もあるようで、その全てに対応するのは大変そうですし、その必要があるのかも知りません。そこで、いつものように現物合わせで、とりあえず必要なものだけ実装しようという「いきあたりバッタリ方式」で作業してます。こういうことやってると、相手の端末が変わると、それだけですぐに破滅しちゃうわけですが、しょせん自分が使える端末なんて限られています。自分のPCで使えるTOSHIBAのBluetoothドングルに付属のファイル転送ツールと、時々借用できるXperia arcからの転送を受けられるようにしてみました。
WT32ではディフォルトのシリアルポート通信速度が115,200bpsなので、この設定がファイル転送時の速度にそのまま影響してしまいます。そこで、速度を230400bpsに上げてみましたが、それでも転送に6060msかかっています。調べてみるとどうやら受信時にフロー制御がかかっている様子。フラッシュへの書き込み処理の待ち時間が長すぎるようなので、調整の必要ありです。
OBEXでの受信はできるようにはなりましたが、WT32を使っての受信には、受信を許可/拒否する手順が用意されていないという問題もあることがわかりました。とにかく、OBEXのフレームが送られてきてしまうので、これを受信するか、無視するか、あるいは途中で無理やり切断するかで対応しなければなりません。できれば、通信相手と受信するファイル名とサイズを確認したうえで、受信を続行するかどうかを判断できることが望ましいのですが。
電話帳を転送すべくOPP受信の動作を確認しましたが、ようやくとその内容をデコードしてSPIフラッシュに書き込めるところまできました。
SPIフラッシュは初期状態では書き込みがプロテクトされているので、最初にコマンドを与えてアンプロテクトしておきます。そしてファイルをダウンロードするエリアをあらかじめ消去しておきます。あとは、OPPで使われているOBEXのフレームを検出し、それをデコード、受信したデータ部分をフラッシュへ書き込んでいきます。
OBEXでは最初にヘッダ情報が付いたフレーム形式を用いて転送が行われます。したがってヘッダ情報を正しく解釈して、その内容に応じた処理をする必要があるのですが、OBEXなんて扱うのは初めてなんでまだ良く理解していません。いくつか転送方式もあるようで、その全てに対応するのは大変そうですし、その必要があるのかも知りません。そこで、いつものように現物合わせで、とりあえず必要なものだけ実装しようという「いきあたりバッタリ方式」で作業してます。こういうことやってると、相手の端末が変わると、それだけですぐに破滅しちゃうわけですが、しょせん自分が使える端末なんて限られています。自分のPCで使えるTOSHIBAのBluetoothドングルに付属のファイル転送ツールと、時々借用できるXperia arcからの転送を受けられるようにしてみました。
WT32ではディフォルトのシリアルポート通信速度が115,200bpsなので、この設定がファイル転送時の速度にそのまま影響してしまいます。そこで、速度を230400bpsに上げてみましたが、それでも転送に6060msかかっています。調べてみるとどうやら受信時にフロー制御がかかっている様子。フラッシュへの書き込み処理の待ち時間が長すぎるようなので、調整の必要ありです。
OBEXでの受信はできるようにはなりましたが、WT32を使っての受信には、受信を許可/拒否する手順が用意されていないという問題もあることがわかりました。とにかく、OBEXのフレームが送られてきてしまうので、これを受信するか、無視するか、あるいは途中で無理やり切断するかで対応しなければなりません。できれば、通信相手と受信するファイル名とサイズを確認したうえで、受信を続行するかどうかを判断できることが望ましいのですが。