転送速度向上

OPPでの電話帳データ転送が遅い原因を調べていましたが、やはりSPIフラッシュへの書き込み(プログラム)に問題がありました。SPIフラッシュでは、消去やプログラムに時間がかかりますが、これらの動作終了を通知する端子がAT25DFには用意されていません。しょうがないので、ソフトでステータスをポーリングしながら待つのですが、ずっとポーリングを続けるのももったいないので、10msの待ちを入れてポーリング間隔を10msにしていたのが原因でした。改めてデータシートを読み直してみると、ページあたりの平均書き込み時間は1ms。そこでポーリング間隔を1msに修正してみると。



3秒台になりました。ざっと倍。毎秒20KBも出ていませんが、頻繁に転送するわけでもないので、この程度で満足して、次の作業に進むことにします。

OPPでファイル転送

ここしばらく作業が停滞気味なんですが、ようやくと若干の進展があったので、記事にしておきます。

電話帳を転送すべくOPP受信の動作を確認しましたが、ようやくとその内容をデコードしてSPIフラッシュに書き込めるところまできました。



SPIフラッシュは初期状態では書き込みがプロテクトされているので、最初にコマンドを与えてアンプロテクトしておきます。そしてファイルをダウンロードするエリアをあらかじめ消去しておきます。あとは、OPPで使われているOBEXのフレームを検出し、それをデコード、受信したデータ部分をフラッシュへ書き込んでいきます。

OBEXでは最初にヘッダ情報が付いたフレーム形式を用いて転送が行われます。したがってヘッダ情報を正しく解釈して、その内容に応じた処理をする必要があるのですが、OBEXなんて扱うのは初めてなんでまだ良く理解していません。いくつか転送方式もあるようで、その全てに対応するのは大変そうですし、その必要があるのかも知りません。そこで、いつものように現物合わせで、とりあえず必要なものだけ実装しようという「いきあたりバッタリ方式」で作業してます。こういうことやってると、相手の端末が変わると、それだけですぐに破滅しちゃうわけですが、しょせん自分が使える端末なんて限られています。自分のPCで使えるTOSHIBAのBluetoothドングルに付属のファイル転送ツールと、時々借用できるXperia arcからの転送を受けられるようにしてみました。

WT32ではディフォルトのシリアルポート通信速度が115,200bpsなので、この設定がファイル転送時の速度にそのまま影響してしまいます。そこで、速度を230400bpsに上げてみましたが、それでも転送に6060msかかっています。調べてみるとどうやら受信時にフロー制御がかかっている様子。フラッシュへの書き込み処理の待ち時間が長すぎるようなので、調整の必要ありです。

OBEXでの受信はできるようにはなりましたが、WT32を使っての受信には、受信を許可/拒否する手順が用意されていないという問題もあることがわかりました。とにかく、OBEXのフレームが送られてきてしまうので、これを受信するか、無視するか、あるいは途中で無理やり切断するかで対応しなければなりません。できれば、通信相手と受信するファイル名とサイズを確認したうえで、受信を続行するかどうかを判断できることが望ましいのですが。

わからぬ仕様

最近の当ブログへのアクセス履歴を見ると、「AVRCP 1.3」というキーワードの検索で来る方が結構いらっしゃるようです。「MW600」というキーワードでの検索もあるので、やはりみなさんMW600で曲名表示できるプレーヤを探しているということなんでしょうか?

	SONY ソニーエリクソン Bluetoothワイヤレスヘッドセットマイク付き ブラック MW600/B
	ソニー
	ソニー

わたしも携帯を機種変更するならば、AVRCP 1.3対応の機種を選択したいのですが、それではどの機種が対応しているのか調べようと思っても、これがなかなかわかりません。

• DoCoMoでは機種ごとのBluetoothの対応状況をまとめたページが用意されています。しかし、ここではプロファイル名はわかっても、そのバージョンまではわかりません。
• 各機種のマニュアルをダウンロードしてみても、Bluetoothに関する記述は限定的。やはりプロファイルの名前が並んでいる程度の説明。
• 書店で何冊かのスマホ本をめくってみましたが、そもそもBluetoothに割いているページ数が少ないようで、やはり詳細まではわかりません。
• 各メーカの携帯関連サイトも参考にはなりますが、機種ごとに記述の有無が異なっているので、やはり詳細不明となること多し。

先日、近所のDoCoMoショップを訪れた際に、この疑問を店員さんに投げかけてみました。すると、「ドコモの相談窓口に問い合わせるか、kakaku.comのようなサイトの口コミを参照するのが良い」という返答。うーむ、店員も口コミ頼りということかぁ?! その店員氏は、いまはSH-12Cを盛んにお勧め中。「SH-12CがAVRCP 1.3対応しているかどうか確認してきます！」と言い残してバックヤードへ。どうやら相談窓口へでも問い合わせ/確認してくれるようです。

待つことしばし。くだんの店員さん戻ってきましたが。。「検索したら対応しているらしいという口コミやtweetがあったんで、たぶん対応しています。」という回答。やはり、社内では情報見つけられなかったようです。高機能になるのはいいのですが、もはや細かい技術仕様どころか使い方の説明すらどこにも書いてないので、仕方ないのでしょうかね。もっとも、そんなとこまで読む人は限られているのかもしれませんが。

Bluetoothの技術仕様に関しては、AVRCPのバージョン以外にもプロファイル名だけではわかりかねる点がいくつもあります。例えば、

• どのような操作をおこなった時に、どのプロファイルが使われるのか？ PBAPの時もそうでしたが、どこをどう操作すればどのプロファイルが使用できるのかが、明記されていないので手探りで使い方を習得せねばならない。
• サポートされるプロファイルのロールは？ Bluetoothのプロファイルの役割はデバイス間で、異なります。片方がクライアント的にふるまう役割を担当し、もう片方がサーバ的に振る舞う役割を担当して通信をおこないます。例えば、A2DPでは音源側がSourceと呼ばれ、受け側はSinkと呼ばれます。AVRCPではリモコン機能を提供する側がControllerと呼ばれ、それにより制御される機器側はTargetと呼ばれます。
• サポートされるオプションは? 標準化された通信プロトコルの世界では、必ずサポートしなければならない必須機能と、ベンダやデバイスの都合でサポートするかどうかを決められるオプション機能が定められています。ヘッドセット側が対応しているオプションでも、携帯側が対応していなければその機能は使えないことになります。普通、どんな製品でもこんな細かいところまでは説明されていませんね。

プロファイルをサポートする上でのロール(役割)は、とっても基本的な情報なのですが、意外と明記されていないようです。常識的に判断しろということなんでしょうか。OPPで電話帳や写真データを送受するには、送信の際にはクライアントとしての役割が求められ、受信の際にはサーバとしての役割が求められます。したがって、通常は両方のロールがサポートされているはずです。

スマホ端末にはHIDがサポートされる機種もあるようですが、どうやら外部キーボードのようなデバイスを接続するために用いられるようです。この場合、スマホ側はホストのロールを担当することになります。しかし、せっかくのスマホなんですから、タッチスクリーンや内蔵のセンサを利用したデバイス側の機能を提供できてもいいような気がします。そうすれば、スマホを使ってPCを操作したり、ゲーム機のコントローラ代わりに利用したりできると思うのですけど。自分でアプリ書けば、こういう使い方もできようになっているのでしょうか？

AVRCPでは携帯/スマホが音楽再生機能を提供するので、Target側となります。しかし、ヘッドセット(普通はController側)で音量調節機能を持っている機種では、プレーヤ側からのBluetooth経由での音量調節を可能とするために、Target側の機能をもっているものもあります。MW600はそのような例で、マニュアルにはAVRCPのController側とTarget側の双方に対応していることが明記されています。

最後に、WT32がサポートしているロールについてまとめておくことにします。マニュアルやアプリケーションノートを読めばわかることなのですが、情報が散逸している感じです。また満足な技術説明が無いプロファイルもあるので、実際に使ってみないとよくわからないこともあります。そのため、Bluetoothのプロファイル仕様を読みながら実験していたりします。

HFP	A2DP	AVRCP	PBAP	OPP	HID	SPP
HF	Sink	Controller	PCE	Client	Device	Device A
AGW	Source	Target	---	Server	---	Device B

このように多くのプロファイルで双方のロールに対応しています。しかし、A2DPとAVRCPでは両方のロールを同時に機能させることはできません。

スクロール表示

まだちょっと怪しい箇所があるのですが、音楽再生中の動画アップしました。



スペアナ表示部分は、SPIのドライバを見直したら以前のプロジェクトからコピペしていたために、CS信号の切り替えの度にディレイが生じていました。こいつを削除したところ50回/秒近い書き換えができるようになりました。そこで、曲名やアーティスト/アルバム名が長い時には横スクロールする機能もようやくと実装。曲名とアルバム名の両方をスクロールしても20回/秒くらいの画面書き換えができるようです。

スクロールはスペアナ表示の更新と同期して1ドットずつずらして表示し直しています。LCDは表示内容を読み出すこともできますが、書き込みに比べて時間かかるので、単純にすべて書き直す方法を採用。じつは、書き直す度にフォントもSPIフラッシュから読み出しています。表示速度が遅い場合には、フォントのビットマップ情報をキャッシュしなけりゃならないと思っていましたが、この程度の速度ならその必要もなさそうです。

すでにHFPでの着信や通話もできますが、それらの動画については電話帳機能ならびにそれと連動する発信機能を入れてから撮ろうかと考えています。ずいぶんと先になってしまうかもしれませんけど。

ちょっと気になる製品

きょうはBluetoothがらみでちょっと気になる製品について。

ひとつはBlueSAMと同じように携帯とペアリングして通話できるハンドセットBT-Phone01です。もう販売されているみたいなので、こんど秋葉にいったら探してみようかな。けっこう小さそうです。A2DP/AVRCPもできるので、機能的にはBlueSAMと良く似た仕様で参考になりそうです。電話帳はPBAPでの転送に限定されているようですが、ガラ携を無視してiPhoneとAndroidに限れば全く問題無しというところでしょうか。

そしてもうひとつがLiveView。 昨年話題になりましたが、いよいよ国内でも
LiveView MN800として販売されるみたいです。こちらは通話には使えないけど、腕時計スタイルであることと、Android上でプラグインアプリがいろいろとあるらしいのがおもしろそう。プラグインが単純にRFCOMMで通信しているだけだったら、コンパチ機能をBlueSAM上で実現できないだろうかとか想像しちゃいます。でも、アプリ側でデバイスアドレスをチェックするだけで、他社デバイスは簡単に排除できちゃうもんな。

昨今のスマホとかタブレットの普及にともない、こういう製品のニーズもそれなりに高まってきているのではないでしょうか。BlueSAMも、もう少し小さくできればいいのですが、その技量がないのがツライとこ。1.8インチ大画面を売りにするしかありません。

LPC1788

LPC1788の出荷が始まったというニュースはどこかで聞いた覚えがあるのですが、すでにEmbedded Artistから開発キットが出ていることをきょうになって知りました。機能満載を反映して、コネクタがたくさんついています。ちょっと遊んでみたい気もしますが、触り始めたら、そのまま1年くらい戻ってこれなくなりそうな予感がするので、しばらくは遠巻きにしてよう。

視野角

BlueSAMで使っているJD-T1800という液晶。安かったうえにSPIで簡単につなげられるのでけっこう気に入っているんですが、動画を撮ろうとして視野角によって発色が全然ことなることに気が付きました。

通常の向きだと。↓



レベルの高い部分はほんとはもう少し赤みがかっているのですが、写真だと発色が悪いようです。いままで、いつもこの向きでしか見ていなかったのですが、反対から見てみると。。



灰色で表示していたアーティスト名とアルバム名がほとんど見えなくなっています。また、やけに赤が強く出ています。バグが生じてアーティスト名とアルバム名が表示されなくなってしまったと思いこんで、しばらくプログラムを確認していたくらいです。

そもそも再生動作の動画を撮るつもりだったのですが、途中で見つけたバグが気になったので中断。また来週にでも再挑戦することにします。

OPPでの受信を試す

電話帳データをOPPで受信すべく、準備を進めています。まずは、WT32での受信動作確認作業を報告しておくことにします。

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フラッシュに書き込むという処理が必要になります。

SWDを試す

実験するつもりだったのに、ずっと忘れたままになっていた作業をようやく実施。それは、SWDを使ってみること。

これまではARM7/ARM9の延長でずっと普通のJTAGを使ってきましたが、Cortex-M3では信号数の少ないSWDを使うことができます。幸いにしてわたしが使っているSAM-ICEとCrossWorksは、ともにSWD対応となっています。

まずは、SAM-ICEとBlueSAMとの接続。SWDの信号は全てJTAG信号と兼用になっていますので、これまでのJTAGコネクタをそのまま流用できます。しかし、JTAGコネクタをそのままつないでしまったのでは、どの信号が実際に使われているのかはっきりとわからないので、ジャンプワイヤを使ってつないでみました。つないでいるのは、VCC, GND, SWCLK, SWDIO, NRSTの５本です。



CrossWorks側の設定は、次のようにSWDを選択するだけ。



フラッシュへの書き込みとブレークの設定動作を確認。問題なく動いているようです。SWDを使えば信号本数少なくてすみますから、今後はコネクタを小型化できます。20PinのJTAGコネクタについては標準的なコネクタ配列がありますが、SWDについては標準配列やコネクタの記述をみかけません。検索するとどうやら、1.27mmピッチで10ピンというのがあるようです。1.27はちょっと不便なので、2.54mmピッチ10ピンで使うことにしましょうか。でも、これではコネクタサイズが半分にしかならないので、自己流6ピンを決めて使えばいいかな。

電話帳のデータを転送するには

まだ不明点が残ってはいるものの、WT32のPBAP機能を使ってAndroid携帯の電話帳(Android用語では連絡先)にアクセスできることは確認できましたので、ここで電話帳の転送方式についてメモしておきます。

Android上で使用できるBluetoothによる電話帳データの転送方式には、次の２種類があります。

• PBAP 外部のデバイスが電話帳を閲覧したり、ダウンロードするための手段を提供する。Android側がサーバとして機能し、外部デバイスがクライアントとなる。
• OPP 選択した電話帳データあるは、電話帳データの全件を指定した外部デバイスに送信する。Android側がクライアントとなり、外部デバイス側がサーバとなる。

Androidの連絡先を開いた状態では、メニューを開くことでデータの送信が可能ですが、この時に使用されるのがOPPです。したがってユーザが意識して操作をおこなった結果として、データの送信が発生します。OPPでの接続は送信操作を実施するたびにリンクが接続され、データ送信が終わると切断されます。

それに対して、PBAPでの接続はいったん常時アクセスを認めてしまえば、クライアント・デバイス側はいつでも電話機側ユーザの介在なしに電話帳へのアクセスをすることが可能となります。PBAPではセッションのコネクションを張ったままにしておき、アクセスが必要になった度ごとにダウンロードしたり、閲覧することができます。PBAPが定義する機能としては、電話番号で検索して名前を取得することも可能なのですが、WT32のiWrapのドキュメントを読む限りでは、このような検索をおこなうための機能は実装されていないようです。うーむ、残念。

そんなわけで、OPPとPBAPのどちらを使うにせよ、電話帳の一部あるいは全部をBlueSAMの内部ストレージ(つまりはSPIフラッシュ)に転送しておき、BlueSAMは必要に応じてこれを検索するということになります。OPPとPBAPのどちらも電話帳データの転送にはOBEXを使い、電話帳データの表現形式としてはvCardを使っています。したがって、OBEXのフレームを受信する機能と、vCardをパースする機能をBlueSAM側で実装してやらなければならないことになります。

もちろん両方サポートするのが一番なのですが、まずはOPPとPBAPのどちらからサポートするかを決めなばなりません。上述したとおり、Androidは両方をサポートしていますが、iPhoneはPBAPしかサポートしていません。したがって、スマホを持っていれば迷うことなくPBAPを使うところです。しかしながら、わたしはまだどちらも持っていないばかりか、持っている携帯はOPPもサポートしていません。しょうがないので、電話帳データをいったんSDカードにvCard形式で保存し、そのファイルをPC上のToshiba Bluetoothスタックがサポートするファイル転送機能(OPP)を使ってBlueSAMに転送することにします。まずはこうして作業を開始し、その後他人の携帯を借りて動作確認しようと思います。