AVRCPによるリモコン機能

中途半端になったままだったBluegigaで久しぶりに作業です。AVRCPの動作確認まではしたものの、それをリモコン機能として生かす段階まで進んでいなかったので、その機能を追加しました。

ヘッドセット側の操作スイッチは、ジョグスイッチになっています。↓押すとPLAY/PAUSE, 廻すとFOW/REW です。



Bluegigaはシリアルでの操作が可能なのですが、これまでは「LPC2388側のUARTポートに空きが無い」と思い、LPC2388とはつないでいませんでした。これが、リモコン機能を追加できていなかった大きな理由です。ところが、良く確認してみるとわたしの思い違いで、未使用端子上にUART3が残っていました。いつも参照している付録基板回路図上では、CN2の1番ピンから8番ピンまでが、AD0_0～AD0_7と記載されています。わたしは、勝手にこれらのピンがADC専用に割り当てられていると思い込んでしまっていたのですが、実際にはTXD3とRXD3が、AD0_2とAD0_3と重なっているので、これらを使うことが可能でした。慣れ親しんだATMELのSAM7にはAD専用に割り当てられたピンがあるので、ついついLPC2388でも専用ピンだと思い込んでしまっていたのでした。

そんなわけで、BluegigaのTXOをLPC2388のRXD3に接続。これで、AVRCPのメッセージを拾えるようになりました。ソフトの方では、WT32からのAVRCPメッセージ出力を監視するタスク(wt32_listener)を追加。ここで、Q-STEERリモコンを使う時と同様のイベントを発生することにしました。これだけの簡単な機能追加で、一応の操作がヘッドフォンからできるようになりました。



動作の様子を説明すると次のようになります。

• ヘッドセットの電源を入れて、ジョグスイッチを押してしばらくすると、RINGを検出して再生音が流れ始めます。
• もう一度押すと、PLAYイベントを検出しますが、すでに再生中なので、このイベントは無視します。
• さらにもう一度押すと、PAUSEイベントが検出され、プレーヤは再生を停止します。
• 次にスイッチが押されると、PLAYイベントが検出され、再生を再開します。
• ジョグを廻すと前後の曲へスキップもできますが、ログは省略。

ちょっと気になるのは、始めの部分でジョグを押すと再生中にもかかわらず、PLAYイベントが検出されるところ。AVRCPで接続した時点で、ヘッドセット側とプレーヤ側の状態整合がおこなわれていないため、このような動作になってしまっていると推測されます。AVRCPには状態問い合わせのための手順が定義されていたと思うのですが。。。ヘッドセット側が状態取得要求を出していないのか、出しているけどWT32側がそれに応答できていないのか、このログだけからは判断できずにいます。

それでも、ヘッドセットだけで操作できるのはやはり快適です。ヘッドセットには音量調節のボタンもあるのですが、こちらはヘッドセット単体での制御になっており、AVRCPのメッセージは飛ばないようです。プレーヤ側の対応の有無を考慮すれば、ヘッドセット単体で制御してしまった方が無難な選択だというところでしょうか。実験して遊んでみたい側としては、ちょっともの足りませんが。。