原因はやはりハードらしい

いろいろとやってみましたが、やはりI2Sでストリームが流れている状態でI2Cで設定を変更しようとすると、NAKエラーが発生するようです。原因はソフトの問題ではなく、ハードがらみのようです。初期化ではいくつものレジスタを連続して設定しているので、設定の順番が影響しているのかもしれないと思っていましたが、ボリュームを変更するためにひとつレジスタを変更するだけでもエラーが発生する場合があることが確認できました。

改めてI2Sの信号とI2Cの信号の配線を離してみたりもしましたが、改善しません。こうなるとWT32とCODECの間の配線をやり直した方が良さそうです。現状ではCODECボードをフラットケーブルでつないでいることもあり、配線長が長くなってしまっています。ボードを直接基板上に載せてしまってケーブルを不要にするとともに、ダンピング抵抗でも入れてみようかと思います。

それでも、症状が改善しなければ、この際ですので、CODECもTLV320AIC3254に変更してしまおうかと思います。手配してあったSAM3S4Aも届いたので、マイコンも変更してしまいましょうか。ここまでやることになると、作り直しのようなもんですから時間かかりそうですが、いずれはやろうと思っていたことです。とりあえずは、データシート見ながら配線図でも描き始めしょうか。

I2CとI2S

A2DP, HFPとの組みわせだけでなく、W-SIMとの組み合わせでもCODECの動作を確認できて喜んでいたのですが、その喜びもつかの間、問題が見つかって悩んでいます。

CODECの設定はI2Cでおこなうので、動作のモードを切り替えるためには、I2Cでの設定し直しが必要となります。A2DPで音楽を聴いている最中にI2Cで初期化をし直そうとしてみたところ、これがうまく動きません。I2Cでコマンドを送信しても時々NAKを検出してしまうようです。どうやら、WT32にA2DPの接続が張られてI2Sのストリームが流れている状態だと、I2Cでの初期化が失敗するようです。A2DPの接続がなければ、何度でも繰り返し初期化できるのに。。。

配線を確認して、I2Sの信号とI2Cの信号を配線している線が重ならないようにしてみたりしたのですが、まだ解決できません。トホホ。。これはハードの問題ではなくて、ソフトの問題なのかもしれません。レジスタの設定の順番に注意が必要なのでしょうか。まだまだ試行錯誤で時間がかかりそうです。

TLV320AIC3253 と W-SIMの接続

W-SIMとつないだTLV320AIC3253を動作させるべく、しばらくPurePath Studioと戯れていましたが、なんとか期待する動作をさせることができました。

PurePath Studioの設定内容について記事として書き残しておきたいところですが、PurePath Studioのソフトならびにその説明書入手のためにはユーザ登録が必要であり、その具体的な内容については公開してはいけないようです。そこで、ここでは変更が必要であった箇所と、作成したprocess flowの概要についてのみ記しておくことにします。

まずは、FrameworkのSystemSettingsCodeプロパティの変更内容について。

• W-SIMからの音声信号はLong frame形式のPCM信号なので、AIC3253側のオーディオインタフェースをDSP形式16ビット長に設定変更。W-SIMからのPCM信号は8ビットしかありませんが、不要部分はminiDSPの処理で無視してもらいます。
• 内蔵LDOを使用するように設定
• 12MHzのMCKで動作するようにPLL設定を変更。
• Digital Micを使用するようにピンのコンフィグならびにADCへのルーティング

Process flowのダウンストリーム側の流れは、

• I2Sモノラル(Left)からの入力をu-Lawデコーダにつなぐ。
• デコード結果をsplitterにより2チャンネルのオーディオ信号に変換。
• それをinterpolaterにつなぐことでヘッドフォンから出力。

アップストリーム側は、

• Decimatorから得られるデジタルマイクからの信号を、mixerによりモノラル化。
• Biquadフィルタを使ったハイパスフィルタにより80Hz以下の信号成分を減衰。
• u-Lawエンコーダを通した結果をI2Sモノラル(Left)へ出力。

オーディオ・インタフェースで使用する信号の形式にかかわらず、PurePath Studio上ではI2Sというコンポーネントでデジタル・オーディオ・インタフェースを表現しています。

PurePath Studioを使ってみてわかったことのひとつに、TLV320AIC3253と3254の違いがあります。3253は3254からアナログ入力の端子を減らすことによりピン数を少なくしているだけかと思っていたのですが、miniDSPのあたりにも違いがあるようです。PurePath Studioで3254を使ってフローを作成する際には使える部品が、3253を選択すると使えなくなってしまいます。どちらのデバイスもサポートできる命令数の上限は同一だと理解していたのですが、miniDSPの命令の詳細についてはデータシートやAP Noteを読んでも一切説明されていないので全くわかりません。ユーザとしてはPurePath Studioを介してしかminiDSPを扱うことができません。そのため、PurePath Studioで見る両者の違いがデバイスの提供する機能/容量に起因するものなのか、それとも単にPurePath Studioの対応が不完全なのか判断する材料にも不足しています。ともかく、3254を使っていれば機能的な制約を受けずに済むようですので、折をみてCODECをTLV320AIC3254に変更することも考えてみた方が良さそうです。

PurePath Studioについては、がんばって作ってあるとは思うのですが、やはり説明資料不足という印象です。マニュアルがあるにはありますが、個々の機能部品(component)の説明が欠けているために、実際にはhelp機能に頼るしかありません。このあたりは、今後のバージョンアップによって改良されていくことを期待したいものです。

PurePath Stuidoではデバイスの設定ならびにminiDSPへダウンロードする一連のデータをI2C経由で落とす一連のデータとして生成することがでます。C言語のヘッダファイルの形式で生成することもできるので、アプリからはこれをインクルードして、使用することができます。生成されるデータはそれなりの量になるようで、今回の例では、およそ4500回のI2Cレジスタへの書き込みが必要となりました。

SAM3S発注

DigikeyにSAM3Sの48ピンと100ピンが入荷されていたので、とりあえずいくつか買っておくことにしました。自分としては64ピンが一番使いやすいかなと思っていたのですが、こちらはまだ時間がかかりそうです。

届いたら、現在実験中のセットを48ピンのSAM3Sに変更してみてSAM3Sの勉強を進めることにしようかとも考え中。ピン数が少ないとJTAGでピン数を消費してしまうのもつらいですから、SWDを使うことも覚えねば。このあたりの作業環境も準備しようとしているところです。

ちょっと寄り道を

今回はWT32とTLV320AIC3253をつなげるプロジェクトなんですが、ちょっと寄り道して、W-SIMとTLV320AIC3253をつなげることができるかどうかを実験してみたくなりました。

W-SIMからの音声信号はu-Lawで圧縮されているため、、これをリニアPCMに変換しないと通常のオーディオCODECとつなげることはできません。一方、ML7041のようなCODECは電話機用に設計されたものなので、u-LawとのEncode/Decode機能を内蔵しておりW-SIMと直接接続することができます。今回利用するTLV320AIC3253にはminiDSPが内蔵されていますので、このminiDSPをプログラムしてやることでu-LawのEncode/Decode機能を持たせることが可能なようです。

実験のために、ボード上にW-SIMのソケットを載せました。WT32とUARTでの制御信号ならびにI2S信号を共有するため、W-SIMとWT32は排他的にしか使用しないことにします。



ハード的にはこれだけでいいと思うので、後はソフトの準備です。TLV320AIC3253のminiDSPをプログラムするには、PurePath Studioというソフトが用意されているので、これを使ってminiDSPのコードを生成してやります。生成したコードは、I2Cを経由してTLV320AIC2353にダウンロードするという仕組みになっています。PurePath Studioの出力するコードは、基本的にはTIの評価ボードを使うことを想定しているようで、わたしの実験ボードで使用するにためには初期化コードを変更してやる必要がありそうです。現在、どのように変更すればいいのかを調査中です。

無理やりデジタルマイクを動かす

TLV320AIC3253と格闘中です。なんとかヘッドフォンとデジタルマイクの動作を確認することができたものの、まだ設定の調整が必要だと思われます。

TLV320AIC3253は電源とパスコンをつなげる程度の工作でデジタル・マイクとヘッドフォンをほぼ直結できてしまい、ハードウェア的にはとっても簡単に使えたのですが、使いこなすための設定/制御はなかなか大変そうです。設定はI2Cでレジスタを設定すればいいだけなのですが、そのレジスタ数がものすごい数あります。1ページ最大256ケの8ビットレジスタが、50ページ以上あるのですが、あまりにもたくさんあるので数える気にもなれません。もっとも、これら全てのレジスタを設定する必要があるわけもなく、ページ0とページ１のいくつかのレジスタさせ設定すれば基本的な機能の動作はできるようになっているようで、今のところこれらのレジスタしか使っていません。

基本的なI2Sストリームの再生やデジタルマイクの設定については、アプリケーションノートにその設定例が示されていたので、それを参考にすることで何とか動かすことができ、WT32からのA2DPストリーム(44.1KHz)とHFPの音声(8KHz)での動作を確認できました。アプリケーションノートの設定をなるべくそのまま使って確認したかったので、今回はWT32側をI2SマスターにしてCODEC側をスレーブにしています。

最初に8KHzでHFPでの通話を試した時には、ブチブチというノイズがDACから出力される再生音声に時折混じっていました。このノイズは44.1KのA2DPでは混入しないので、設定の違いを調べていったところHFPではマイクからの音を拾うためにデジタルマイクとADC部分を動作させているのに対し、A2DPでは再生しかしないのでデジタルマイク/ADC部分を動作させていないためであるということが判明。つまり、マイク入力関連のどこかでノイズが混入していることがわかりました。さらに切り分けを進めていったところ、マイク/ADC部分をモノラルで動作させればノイズは無く、ステレオで動作させた場合に発生することがわかりました。どうしてマイク入力の設定の違いが、ヘッドフォン出力に影響を与えるのか、その原因が理解できませんが、とりあえず対処療法だけは見いだせたという状態です。

デジタルマイクの接続も、本当は不安だらけでした。デジタルマイクは下図のようにつなぐのですが、実際にはモノラルしか必要ないのでマイクはひとつしかつながっていません。マイク出力のタイミングとCODECの期待するタイミングを下部に示してありますが、CODECがクロックの立ち上がり/立下りでデータをサンプリングするとすると、ちゃんとデータが拾えるかどうか不安なところでした。



実際に動作させてみるとちゃんと音声を拾えるのですが、マイクの設定を左右のチャンネルのどちらにしても、音が拾えてしまっています。どうしてなんでしょうか？

CODECの設定をモノラルに変更すると、CODECは右チャンネルのデータしか処理しないようなのですが、今度はマイクのチャネル設定に関係なく全く音声を拾えなくなってしまいました。音声データをI2SでWT32に送信する際にも、右チャンネルのデータしか送信しないために、左チャンネルは無音になっているものと思われます。そのため、WT32がHFPの場合には左チャンネルしか拾わないと想定すると、このような現象もつじつまが合います。幸いなことにWT32側のI2Sの設定を変更することで、ワードクロックと左右チャネルの関係を入れ替えることができましたので、これを変更することでCODECをモノラルにしてもちゃんと音声が通るようになりました。

こんな調子で現在のところ設定でごまかして無理やり音を通しているのですが、A2DPで音楽を再生する際にも左右が逆になってしまうのが問題です。

CODEC実験基板

製作中だったCODEC実験基板のひととおりの配線を終えました。部品数が少なくてすむので楽できました。



QFPの変換基板で場所をとってしまているので、プリント基板が用意できれば、ずいぶんと小型化できますね。左上方にあるのは1.8Vを生成するLDOです。後になって気が付いたのですが、TLV320AIC3254を使えば32ピンになるものの、1.8V LDOを内蔵していました。

左側の14ピンソケットは、MMcodec01と同じピン配置にしてあるので、MMcodec01の代わりにつなぎかえて使用します。I2Cで制御しますが、ソフト的にはTLV320AIC23Bとは互換性は無いので、ソフトは書き換えになります。また、TLV320AIC23Bでは水晶発振回路をもっていましたが、TLV320AIC3253にはその機能はありません。外部から適当な基本クロックをもらって、内蔵のPLLを使って必要なクロックを生成します。今回はMMsam7s(AT91SAM7S)の基本動作クロックである48MHzを4分周した12MHzを基本クロックとして使用することにします。

TLV320AIC3253

AVRCP 1.3関連記事の途中ではありますが、今回は新ネタの導入についてです。

現在の実験ボードではCODECとしてMMcodec01を使用していますが、このモジュールに搭載されているのはTLV320AIC23BというCODECです。このCODECはとてもポピューラなチップであるようで、各社の評価ボードにもこのチップあるいは機能的にほぼ互換のものが採用されているのをしばしばみかけます。MMcodec01を使っていたのでは、どうしてもサイズが大きくなってしまうので、今後プリント基板を作成する際に使用するCODECチップを探そうと思っていたところ、TIの比較的新しいCODECとしてTLV320AIC3253というのを見つけました。主な特徴としては、

• デジタルマイク入力
• ヘッドフォン出力
• miniDSP内蔵
• 1.8Vで動作可
• プログラマブルなPLL内蔵

といった項目が挙げられています。デジタルマイクとヘッドフォンはほぼ直結でつなげられるので、調整箇所も無くなりお手軽に製作できそうです。そこでTLV320AIC3253を試しに使ってみることにしました。QFN 24ピンなので、aitendoの48ピンQFP変換基板に載せてみました。aitendoからはQFN変換基板も発売されたようですが、それを知る直前にQFP変換基板を購入してしまいました。



デジタルマイクとして使用するのは、秋月で買ったSPM0405HD4Hです。先ごろモジュールが発売されたので、ちょっと値段は張りますが配線がラクになって助かるので、こちらを採用。



TLV320AIC3253はステレオCODECですので、デジタルマイクもLeft/Rightの2ch分つなげられるわけですが、マイクを使うのはHFPでの携帯電話通話だけなので1つだけしか使いません。というわけで、主たる部品はCODECとデジタルマイク、そしてCODEC用のデジタル電源1.8V生成用のLDOからなる実験基板を製作中です。

AVRCP 1.3を試す -- その1

USBドングルと東芝のBluetoothスタックの組み合わせでAVRCP 1.3が使えることがわかったので、WT32との接続実験をおこなってみました。以下は、全てWT32のシリアルポート上での表示、操作となります。

USBのBTドングルをPCに挿すと、東芝ツールが自動的に登録済みのWT32に対してA2DPで接続してきます。そこで、WT32側からAVRCPの接続を張ってやります。



AVRCP 1.3の機能を試してみるために、まずはAVRCP PDU 10 3を投入。これは、プレーヤ側が通知可能なイベントを列挙することを要求するためのコマンドです。PDU (Protocol Data Unit)という用語が示しているように、このコマンドではAVRCPプロトコル上で運ばれるデータをパラメータとして指定してやります。そのため操作の際には、コマンドの引数を調べるためにAVRCPの仕様を読みながらとなります。

このコマンドに応答があることを期待していたのですが、結果は↓のようにREJECTされてしまいました。これは対応する機能がサポートされていない場合の振る舞いです。そこで、続いてAVRCP PLAYという再生指示のコマンドを送ってみると、PC側ではWMP (Windows Meida Player)が自動的に立ち上がって、再生を開始してくれました。なかなか、洒落たことをしてくれます。



最初にAVRCP PDU 10 3を入力した時点ではWMPが動作していなかったので、もう一度同じコマンドを投入してやると、今度はちゃんと応答が返ってきました。どうやらAVRCP 1.3に関連する機能はWMPに対するプラグインとして用意されているらしく、そのためにWMPが起動されていることが必要なようです。

続いてAVRCP PDU 11を送り、アプリ側がサポートしている属性を調べてみると、再生モードとしてリピートとシャッフルの設定変更が可能であることがわかりました。



AVRCP PDU 12でそれぞれの属性に設定可能な値を調べ、AVRCP PDU 13で現在の設定値を調査。再生リストの曲目の再生が終了すると、最初に戻って再生するリピートモードになっており、シャッフルは禁止されていることがわかります。

試しにAVRCP PDU 14を使ってシャッフルの設定を変更、確認してみた様子が↓です。



再生モードの変更動作が確認できたので、次は一番試してみたかった曲目のメータデータの受信です。AVRCP PDU 20 0を送ると、再生中の曲について、プレーヤ側がサポートしている全データ項目を返してくれます。
日本語の部分はUTF8になっていました。



最後にAVRCP PDU 30で再生ステータス確認。00 04 a3 72の4バイトが曲の長さをms単位で表現しており、303.986秒に相当します。続く4バイトが現在の再生位置。そして最後のバイトは再生中は1, 停止中は２となります。

AVRCPの仕組みとその実際の動作を垣間見ることができ、なかなか楽しめます。