AVRCP 1.3対応プレーヤを探して．．．

HFPとA2DPの動作確認はできたので、続いてAVRCPです。A2DPと同じくAVRCPの動作確認もiPadでできるのですが、ちょっともの足りないのです。iPadはiOS4.1でAVRCP 1.0に対応しているので、再生/停止したり、次の曲や前の曲へスキップといった操作は可能です。一方、WT32のコントローラ側ではAVRCP 1.3に対応しており曲名やアーティスト名の表示も可能となっているのですが、iOS 4.1がこれをサポートしていないので、これらの機能の動作確認実験をおこなうことができません。

そんなわけで、AVRCP 1.3あるいは1.4をサポートした安価なプレーヤを用意して実験してみしたいと思っていたのですが、どんな製品があるのか予備知識ゼロ。スマホの仕様をキチンと確認すれば適切な商品もあると思いますが、携帯の機種変更は今年後半まで待ちたいところ。SONYだったら何か手ごろな製品があるかと思いましたが、Bluetooth対応のWalkmanって新しい製品が無いような。。。Bluetoothって国内ではイマイチ普及が進んでいないということでしょうか。今後スマホがBTの市場を拡大していきそうな気はしますけど。手ごろなプレーヤが見つけられなかったので、Windows PCではどうかと思い、USBのドングルを購入してみました。



購入したのはBUFFALOのBSHSBD03です。商品仕様には対応プロファイルとしてA2DP/AVRCPが記載されていますが、AVRCPのバージョンまでは書かれていません。そもそもUSBドングルはハードウェア的にはHCIまでの層をカバーする製品ですから、上位のプロファイルをハードウエア的にサポートしているわけではなく、付属するCDに含まれるソフトウェアによって提供されるBluetoothのプロトコルスタックの機能仕様が対応するAVRCPのバージョンを決定することになります。細かい仕様は買って実際に使ってみないとわからなかったわけですが、価格は1000円台だし、ひとつあれば便利だろうということで買ってみました。

付属していたソフトは東芝のBluetoothスタックでした。実際にインストールしてみるとA2DP/AVRCPはWindows Media Playerと協調して動作するようになっているようです。設定のオプションを確認したところ、次のような画面に出会いました。



再生中の楽曲情報をデバイスに送るという項目があるではありませんか！ディフォルトではチェックされていなかったので、こいつをチェックしてMedia Playerを使ってみると以前購入したMW600に再生中の楽曲名が表示されました。バンザーイ。

というわけで、AVRCP 1.3対応のプレーヤが用意できたので、次回の記事ではWT32との接続実験について報告することにします。

基本は8000Hz

WT32とMMcodec01の接続では、HFPでの通話時とA2DPでの再生時ではサンプリング周波数を変更しなければならないことがわかりましたが、HFPやA2DPでの接続が無い場合でもWT32のPlayというコマンドを使えば音を出すことができることを思い出しました。このコマンドではサンプリング周波数はどうすればいいのか疑問を感じたので、簡単に実験してみました。



単音しかできないコマンドで、最初の6がオクターブの指定、カンマで音の長さ、a～gで音階を指定して、アンダースコアで休符を表現します。結果は、このコマンド実行時にもサンプリング周波数として8000Hzが必要でした。したがって、ディフォルトでは8000Hzを使いA2DPを流す時には44.1KHzを使えば良いようです。

I2Sを使う場合には、このようにサンプリング周波数の変更が必要になりますが、WT32のアナログ入出力を使用する場合にはこんな処理は必要はありません。WT32はヘッドフォンアンプを内蔵していますので、スピーカを直接つなげて鳴らすこともできます。簡単ですがスピーカをひとつだけつなげて試してみました。



もちろん音は鳴ったのですが、ヘッドフォンアンプですので、大きな出力は得られません。chiakiさんのTimpyのようにヘッドフォンの内部にマイコンとWT32を埋め込むことができれば、アナログ入出力を使うのが部品数も少なくていいのですが、とてもわたしにはそんな小型化はできそうもありません。やはり本体の箱にCODECを内蔵して、ステレオジャック経由でヘッドセットを接続して使う構成にするのが簡単そうです。

プロファイルとサンプリング周波数

MMcodec01で使用しているTLV320AIC23Bの初期化コードが用意できたので、さっそくHFPとA2DPでの接続試験をやってみました。

まずはWT32の設定をヘッドセットデバイス相当のものに変更しておきます。



そしてWT32のシリアルポートで、ATコマンドを叩いてやることで発信/通話ができます。



A2DPの動作確認にはiPadのiTuneで音楽を再生することで確認。こちらも問題なく動作したのですが、ちょっと不便なのはサンプリング周波数の切り替え。WT32とMMcodec01はI2Sでつないでいますが、MMcodec01側をマスターとしています。WT32側では SET CONTROL AUDIOコマンドによりスレーブ側動作としています。SET CONTROL CODECコマンドではサンプリング周波数を44.1KHzに設定していますが、この周波数はA2DPにおけるサンプリング周波数となります。HFPでの通話時には8KHzが固定的に使用されるようです。そのため、MMcodec01側の動作もA2DP使用時には44.1KHz, HFP使用時には8KHzに設定しなおしてクロックを供給してやらねばならないことがわかりました。

サンプリング周波数を変更するために、マイコン側では次↓のようにコマンドを叩いて、CODECの設定を変更しています。



WT32側をマスター、MMcodec01側をスレーブにすれば面倒な切替え無しですむかとも思ったでのですが、どういうわけかちゃんと音声の送受ができません。何やら声は聞こえるのですがノイズに埋もれた感じです。フレーム同期がちゃんと取れていないように思われます。原因は判明していないのですが、WT32をスレーブにすれば何の問題も無いので、この設定で実験を続けることにします。

現在の構成

とうめんの実験をはじめるのに必要な配線がほぼ終わりました。



現在の構成は下図のとおり。音声はI2SでWT32から直接MMcodec01へ流れるので、SAM7Sを経由していません。WT32の制御はUART, MMcodec01の制御はI2Cになります。



まずはWT32の動作確認からやりたいので、WT32の制御はマイコンを使わずに手動でおこなっていくこととします。そのため、実験時にはUSBシリアル変換器を次のようにつないでWT32を手動制御します。



黒い方のUSBケーブルは電源供給兼コンソールポートとなります。最終的には電源は電池にしますが、当面はUSB給電で実験を進めていきます。SAM7SからI2CでTLV320AIC23Bの初期化さえやってやれば、あとはWT32を操作するだけでHFPやA2DP/AVRCPの動作確認がおこなえるはずです。

ありあわせで始める

Bluetooth対応W-SIMジャケットの気になっていたバグも2つ取れて、残る大きな問題はW-SIMの初期化なのですが、こちらはどうもうまいこと解決できずにいます。ほとんどの場合W-SIMの抜き挿しで直りますので、電源投入時の動作に関連があるように思えます。W-SIMの電源部に100uFのOSコンを追加してみたりもしましたが、症状変わらずでした。SDカードのように、W-SIMも電源操作ようのFETを付けておけば良かったかもしれません。また、当初はインダクタも入れるつもりでいたのに、EAGLEで基板起こした段階で入れ忘れてしまったことも大きく後悔。いろいろとハードのバグも見つかったので、もう一度基板を作りなおしたい気もするのですが、どうせなら新たな要素も盛り込みたいので、もう少し時間をかけて考えていきたいと思います。

こんな調子なので、BT対応W-SIMジャケットの方は少しお休みすることにして、新たなプロジェクトを開始することにします。とは言ってもあまり変わり映えはしないのですが、Bluetoothのヘッドセット側の制御部を作ってみようかと思います。昨年末の記事で書いたように、HFPでは携帯の電波状況や電池の残りの表示も可能になるので、これを試してみようかと。また、AVRCPのContoroller側ではAVRCP 1.3の機能である曲のメタデータの取得も可能なので、再生中の曲名やアーティスト名の表示も可能となります。

制御にはSAM3Sを使いたいところですが、もう少し時間かかりそうなので、とりあえずは手持ちの部品を使って基本的な機能動作確認から始めることにします。いつものように秋月のA基板上にモジュールを並べて、配線を開始したところです。

• マイコン部分にはMMsam7sを使用。後でSAM3Sが使えるようになった際に、移行が簡単にできるので。
• BTには引き続きWT32を使用。BT対応W-SIMジャケットの実験ボードで使用したものを、再利用しています。
• フラットケーブルでつながっているのは、MMcodec01です。こちらも、以前MP3プレーヤで使ったものを再利用。

WT32にはADC/DACも載っているので、本来であればMMcodec01を使わずとも、直接マイクやスピーカをつなげることができます。しかしながら、WT32のアナログ音声出力信号は差動出力となっており、ヘッドフォンジャックを使いたい場合には、アンプを追加してシングルエンド出力に変換するようにとなっています。これは面倒なので、アナログ出力は使わずにMMcodec01をI2Sでつないで使うことにします。

基板上の空いている部分には、LCDと操作用のスイッチを載せるつもり。LCDは1.5インチ程度のものでいいかと思っていますが、問題は操作用のスイッチ。どんなののを、いくつ載せたらいいのか悩ましいです。いっそのこと、LCDを2.4"にして、タッチパネルを使った方が悩まずにすむかもしれません。

切れていなかった電源

Wakeup時のバグが直ったので、続いてSDカードの再初期化問題を追いかけてしばらくはまっていました。電源投入時はちゃんと初期化できるのですが、リセットをかけると失敗。再度リセットすると初期化成功します。成功と失敗をまるでトグルしているかのように繰り返します。

動作を追いかけてみると、CMD0でカードをリセット後CMD8で動作電圧を読み出すところまではちゃんと動いています。ところが、その後のACMD41がBUSYのままになってしまっていました。SDの資料を読んでみると、CMD8を入れずにACMD41を投入するとHCのカードはBUSYを返すことになっています。しかしながらちゃんとCMD8は投げており、その応答もちゃんと返ってきているのです。カードを替えてみても症状は変わらずです。

ACMD41でBUSYのままの時には、CMD8を入れ直してからACMD41を再試行してみてもやはりダメでした。CMD8の投入前にやっているのは、SDカードへの電源の入れ直しとCMD0の送信だけです。SDカードのVDD供給には、LPC2387のMCIのMCIPWR端子を使って電源制御を行っています。MCIPWRにFETのスイッチをつなげて、SDカードのVDDをオン/オフします。そこでSDカードのVDDを確認してみたところ、MCIのレジスタ操作によりMCIPWRをオフにしても、VDDの電圧が1.3V程度残っていることが判明。ちゃんとオフできていなかったようです。回路を確認してみると、FETのドレイン側にGNDに引っ張る抵抗を入れ忘れていたことが判明。回路図描いた段階から入れ忘れていたようです。パスコンだけは入っていたので、中途半端な電圧になってしまい、その影響でSDカードの状態がちゃんとリセットできていなかったと思われます。

抵抗を追加して、ようやくと問題解決しました。

LCD交換とWakeup時のバグ修正

年末に壊してしまったLCDのタッチパネル。交換用のボードは昨年中に届いていました。そのまま放置してあったのですが、まだ残っていたバグに取り組むことにしました。昨年末の時点で残っていた大きな問題は、

1. W-SIMカードの初期化に失敗する。W-SIMの抜き挿しを繰り返すと直る。
2. しばらく使っているとMP3再生の音が出なくなる。リセットすると直る。
3. リセットするとSDカードの初期化に失敗する。もう一度リセットすると、大丈夫。

1の問題は、ボーレートだかパリティが一致していないかのように、W-SIMからの応答メッセージが文字化けしているようです。試しにカードを交換してみても症状変わらず。ここで気付いたのですが、ユニバーサル基板で組んでいた時には、片方のW-SIMは3.3Vではどうしても正常に応答してくれませんでした。ところが、現在のプリント基板では、2枚とも動作可能になっています。いったい何が悪かったのだろう。

2の問題は、どうやらしばらく操作せずにいたためにスリープ状態になった後に問題が発生している様子。Wakeupの処理に問題がありそう。3の問題は、SDカードの初期化廻りでしょうか。

1の問題はハードに関連していそうなので、まずは2の問題を調査。ずいぶんと時間をつぶしてしまいましたが、Wakeup時のクロックの再初期化に間違いを発見して修正。ついでにWakeupのきっかけとしてBluetoothデバイスとのリンク確立を追加することにしました。WT32ではBluetoothでのリンクができるとGPIOの状態を変化させるように設定することができます。WT32のGPIOとLPC2387のGPIOをつなげてやり、これをWakeupのキッカケにすることにしました。これで、本体がスリープ中の時に、ヘッドセットの電源を入れると、本体のLCD表示が現れるようになります。

しかし、これだけではまだ対策は不十分でした。WT32はリンクが張られたことを通知するRINGメッセージを送信するのですが、その時点ではLPC2387はまだWakeupを完了していないので、最初のRINGメッセージを拾えないのです。このメッセージはどのリンクが上がったかの判別に用いており、対応するアイコンを表示させています。そのためヘッドセットの電源を入れると、A2DP/AVRCPのアイコンは表示できても、HFPのアイコンが表示されないという問題が発生してしまったのです。実はこの問題については、あらかじめ対応策を用意してあったのですが、それがうまく動いていませんでした。

対応策とはLPC2387がスリープに入る前にWT32のCTS信号をHレベルにしてやることで、WT32の出力を抑止してしまうことです。Wakeupした時点でCTSをLレベルにしてやれば、送信待ちをしていたメッセージが拾えるという仕組みです。ソフトではちゃんとCTS信号を操作したつもりだったのですが、実際にWT32へCTS信号として使っているP0.28の出力を調べてみるとLレベルのままで、Hレベルに変化していませんでした。回路図や結線を確認しても、ちゃんとP0.28とWT32のCTSはつながっています。しばらく、理由がわからずに悩んでいましたが、マニュアルを読み直してようやく原因がわかりました。P0.28はSCL0の機能が割り当てられている端子であり、そのためにこの端子はオープン・ドレイン出力となっていたのです。これに気付かづに、P0.28とWT32のCTSは直結してあったために、Hレベルにできなかったのでした。



4.7Kのプルアップを追加↑して、ようやくと問題解決です。そしてようやくと、期待したように動いている様子がコレ↓です。



指を触れずに画面が現れるのが結構気に入って、自己満足しています。

ちょっとおかしい

SAM3Uを少しは使ってみようということで、12bit ADC(ADC12B)の動作を確認することにしました。SAM3U-EKでは可変抵抗器がADC12Bにつながっており、入力電圧を0V～3.3Vに変化させながら、ADC12Bの出力する値を確認することができます。また、ADC12Bでは入力されたアナログ値をあらかじめPGAで増幅しておく機能があるので、あわせてそれも確認してみました。



最初のGain = 1の結果が増幅率が1のもっとも普通な変換結果です。電圧を7段階に変化させることで、出力値がだんだんと増えていることがわかります。4番目の値が 0x868となっており、ほぼ中央値(0x800)に近い値になっています。

2番目のGain = 2では増幅率を2にしたので、値は0から始まり4番目の値が0xfffになることを期待したのですが、どういうわけか最初から0x239などという値が出てしまっています。

3番目のOffset = 1, Gain = 2では、増幅率は2ですが、1/4 * VREF だけオフセット電圧を加えた場合です。

１画面に収まるように7段階の電圧変化しかみていないので、ちょっとわかりにくいのですが、Gainを指定した場合には期待したほどきれいに増幅されていない様子。増幅だけでなく、オフセットも加わってしまうように見えます。うーん、どこか使い方が悪いのかもしれませんが、ESチップのErattaを確認してみるとGainには12%程の誤差が生じるとの記述が。。便利に使えるかもしれないと思っていたのですが、これではかえって邪魔になるだけのようです。

けっこう違う

SAM3Sが入手できるまでSAM3U-EKを使って勉強しておこうと思い、改めてSAM3UとSAM3Sのマニュアルを読んでいます。同じSAM3のシリーズとは言え、いろいろと異なる箇所もあるようです。とりあえずPIOとADC/DAC廻りで気になった点を列挙しておくと。。

• SAM3UではSAM7シリーズと同じく、PIO端子に対してPeripheral AとPeripheral Bのふたつの機能が割り当てられる。SAM3Sでは、加えてPeripheral Cも割り当てられる。そのため、PIOの機能選択手順に違いが生じる。
• SAM3SではPIO端子のプル・ダウン制御ができるが、SAM3Uではできない。
• SAM3SではPIO入力端子のシュミットトリガの許可/禁止をすることができるが、SAM3Uではできない。
• SAM3SにはDACがあるけど、SAM3Uには無い。
• SAM3SのADCにはWater Mark機能があるが、SAM3Uには無い。

SAM7でもデバイスによって同じ機能でも若干の違いはあったのですが、それほど気にはなりませんでした。SAM3ではちょと、違いが大きすぎるような印象を受けます。特にPIO端子に割りあてる機能選択の違いが嫌らしい。全体的には、SAM3Uが最初に発表された後で、いろいろとSAM3Sで機能追加がなされた影響で違いが生じてしまったかのような雰囲気が感じられます。SAM3Nを見てみるとSAM3Sにより近いようで、SAM3Uだけがちょっと異質に感じられます。SAM3S/SAM3NにはQTouchのライブラリがサポートされているのに、SAM3Uではサポートされていないのも、そんな違いがあってのことでしょうか。

SAM3Uでは8/10ビットのADCと10/12ビットのADCの2種類があるため、前者をADC、後者をADC12Bと呼んで区別しています。SAM3Sは10/12ビットだけど名前はADC, そしてSAM3Nでは8/10ビットだけどADCという名称。なんだか、とっても嫌な感じ。今後登場するであろうSAM3X, SAM3Aが、混乱に拍車をかけるようなことが無いといいのですが。。

今年こそSAM3を

明けましておめでとうございます。昨年は初めてEagleでプリント基板を製作してみたり、MTM06に出展したりと、この何年かやってみたいと思い続けていたことにようやくと踏み出せたという点で、非常に有意義でまた勉強になった一年でした。本ブログでは当初より、AT91SAM7を中心としたARMマイコンを使ってきましたが、昨年はSTM32や mbed, LPCExpressoが普及したことで、すっかりARMマイコンというかCortex-M3を使うのが一般的になったように感じます。その一方で、自分はATMELのCortex-M3マイコンを待ち続けた結果、世間に取り残されてしまった感もあります。今年こそは、Cortex-M3を使った製作を行いたいと思います。

こんなにもATMELのSAM3を待ち続けているのにもかかわらず、なかなかいい話は聞こえてきません。DigikeyやMouserをチェックしてみても、SAM3S/SAM3Uともに「生産遅れ」という情報が掲載されています。一部のデバイスは2月くらいから入手できるようですが、ひととおりのデバイスが安定して供給されるのは5月くらいになるような気配です。いいかげん待ちくたびれたので、他のデバイスを使うことも考えた方がいいかもしれません。そんな事をツラツラと考えていたおり、年末にATMELからSAM3U-EKという評価ボード用の新しいデモコードがリリースされました。この評価ボードもTOPPERS/ASPをちょっと動かしてみただけでしまいこんでいましたので、この機会に新デモを動かしてみました。



タッチパネル付き、2.8"のLCDでデモが動きます。↓はそのメニュー画面。



音符のアイコンにタッチするとMP3プレーヤが動作します。SDカード上に置いたMP3ファイルあるいは、USBのマスストレージ経由でボード上のNANDフラッシュにコピーしたMP3ファイルを再生することができます。曲名表示とかはありませんが、今後もバージョンアップがあれば機能追加されるかも。



使われているMP3デコーダはMADでした。ボード上にCODECが載っており、I2Sでつながっています。せっかく購入したボードですので、もう少し使ってみてSAM3Uについて学習しておこうかと思います。