HFP状態表示

LCDへのスペアナ表示に続いて、HFPでの接続状態表示をしてみることにしました。まずはHFPで接続した際にWT32から出力される情報のおさらいから。



ほとんど自明ですが、bttchgが電池の充電状態、signalが電波状況です。どちらの値も状況が変化した際にも出力されます。これらの情報をそれぞれ電池アイコンとアンテナアイコンで表示するようにしてみました。↓



NETWORKから事業者名もわかるので、DoCoMoと表示してみましたが、これは自分の端末の出力に合わせて表示してみただけです。他のDoCoMo端末や他の事業者の端末ではどのように出力されるのかを確認してみる必要がありますが、自分でいくつも端末を買うわけにもいきません。機会をみて、知人に協力を仰いで情報収集しようと思います。

今回追加した表示情報は、HFP接続した携帯端末の情報ですが、もちろんW-SIMについてもアンテナ表示をすることができます。まだDISP信号を配線していないので、近いうちに未使用ピンを使って情報を取得するようにするつもりです。

PCM信号選択

ドッチーモ・ジャケットを目指すべく、HFPとW-SIMの選択をおこなうためのセレクタを実験基板に追加しました。いつものように74HC157です。




下図のように74HC157で、W-SIMとWT32のどちらの音声信号をCODEC AIC3253につなぐかを選択してやります。また、W-SIMとWT32には独立したUARTを使って制御するように配線変更。


WT32のPCM設定も変更したので、W-SIMとHFPのどちらを使った場合でも音声信号は8ビットu-LawのPCM信号としてCODECに入ります。そのため、CODEC側は同一の設定で動作可能。音楽再生の時には、WT32からはI2Sフォーマットで、サンプリングも44.1Kになるので設定を変更する必要があります。すなわち、音楽再生時と音声通話時を切り替える際に、動的にCODECで走らせるminiDSPのコードをダウンロードしなおしてやるという処理が必要になります。

きょうのところは、ハードの準備ができたところまで。ソフトの方はチビチビとやっていくことにします。

ドッチーモ・ジャケットを夢想する

スペアナ機能までの動作実験ができたので、自分としてはAIC3253でやってみたかった事のほとんどは動作確認がとれたと感じています。これまでの主な動作確認事項を整理すると、次のようになります。

1. A2DPによる音楽の再生と3D効果(miniDSPを使わない)
2. HFPによる携帯通話(miniDSPを使わない)
3. W-SIMとのPCM接続(miniDSPを使用)
4. A2DPによる再生とスペアナ表示(miniDSPを使用)

1と4はどちらもA2DPでの音楽再生なので、4の方に3D機能を盛り込めれば一石２鳥なので、PurePath Studioで設定してみたところ盛り込めそうです。

2の方はI2SでHFPの音声を流して実験してみましたが、これはWT32の設定を変更することで、PCM信号で流すこともできます。おまけにu-Lawで流すことも可能です。このようにWT32の設定を変更してしまえば、CODEC側から見れば、HFPでの接続とW-SIMとの接続は通話音声に関しては同じように扱えます。

現在の実験ボードではW-SIMとWT32を同一のUARTで制御しているために両者は排他使用としていますが、これをちゃんと分けて、さらにPCM信号についてもセレクタを使って選択するようにすれば、W-SIMによる通話機能とBluetoothのHFPを介しての携帯通話機能の両方をサポートできる「ドッチーモ・ジャケット」が作れそうです。次のW-SIMジャケットではCODEC使わずにマイコンだけで済まそうかと考えていたのですが、このCODEC使ってもおもしろいんじゃないかと思えてきました。

でも自由に発信できるようにするためには、キーパッドが必要になってしまうので、単にヘッドセット側のユニットを作ろうと考えていた当初の構想から大きく方針が変わってしまうことになってしまいます。うーん、どうしようかなぁ。キーパッドやタッチパネルを使えるようにすると、サイズも大きくなってしまいますし。まだ決めかねるので、しばらくは準備のための実験を続けようかと思います。

スペアナに挑戦する -- LCD表示編

今回は、AIC3253を用いたスペアナ表示の後半。いよいよLCDへの表示です。PurePath Studioで生成したminiDSPのコードを AIC3253の初期化時にダウンロードしてやります。その後、I2S経由で楽曲のデータが与えられれば、miniDSPが随時その解析をおこなって、設定したバンド毎のレベルを対応する係数バッファに格納してくれます。



係数バッファはデュアルバンク構成になっており、ホスト側のマイコンが内容を読み出している間にも、miniDSPはもう片方のバンク側のバッファに次の解析結果を格納することができます。バッファの切り替えもI2Cのレジスタを設定することで行えますので、ホスト側マイコンの処理の流れは次のようになります。

1. バッファの切り替えをおこなう。前回の解析結果が読み出し可能になる。
2. 解析結果である係数バッファの内容を全て読み出す。
3. 解析結果をスケーリングして、LCDに棒グラフ表示する。
4. 1に戻る。

このように、ひたすら読み出しと表示を繰り返すだけです。解析結果は左右独立に16バンドずつ、合計32の係数レジスタを読み出すことで得られます。ひとつの係数レジスタは24ビット幅の値をもっているため、8ビット幅でアクセスするI2Cを使ってのアクセスでは、32 x 3 = 96回の読み出し処理が必要となります。しかしながら、良く考えてみると24ビットの情報をもらったところで、LCDにはそんなに細かい精度で表示できるわけはありません。今回は32段階で表示することにしましたので、頭の8ビットだけ読み出せば充分に用が足りるということに後から気が付きました。

と、まぁこのような経緯を経てようやくと表示できるようになりました。そして各種改良を加えた現在の状況がコレ↓です。



残念ながら動画ではわかりにくいのですが、32段階のレベル表示には色の変化もつけています。連続してデータの読み出しとグラフ表示を繰り返しているわけですが、毎秒18回ほどの書き換えができています。1回毎に10msのディレイを挿入しているので、まだ早くできる可能性が残されていますが、これだけ速ければ充分でしょう。ヘッドフォン出力の音量ももちろん、I2Cレジスタで調節することができます。出力を大きくしてやれば小さなスピーカなら鳴らせるので、100円ショップで買った簡易ステレオスピーカをつないで動画を撮影しました。

各モジュールのつながり方は下図のようになっています。マイコンは各モジュールの制御をおこなってはいますが、音の再生や音声信号処理には関わっていません。上述したようにCODEC(AIC3253)が処理してくれた結果をI2Cで読み出して、それをSPI経由でLCDに表示しているだけです。

スペアナに挑戦する -- PurePath Studio編

テレビを見ていると、繰り返し同じ映像やニュースを見聞きしていても、そのまま釘付けになってしまいそうです。半ば思考停止になるんじゃないでしょうか。自分がやりたいことを、自分で考えて行動することにしましょう。計画停電に伴い行動時間も制約されるので、逆に自宅で作業できる時間は増えてきています。そんなこともあり、工作実験作業を継続することにします。

SPI LCDがつながったので、いよいよこれを使ってやりたかったことに取り組んでいます。もちろん、A2DPで再生する曲名をAVRCPで取得/表示したりといったことにも挑戦したいのですが、CODECがらみでより興味を引かれたことがあります。それは、次のようなスペアナの表示です。




これまた、TLV320AIC3253の評価ボード用のデモソフトの画面です。こちらはminiDSPのデモになっており、再生される音のスペクトラムを左右独立に表示することができます。このデモと同じことを、SPI LCDに表示してみようというわけです。やっぱ、音に合わせて動きのある画面って魅力的じゃあないですか。PurePath Studio(PPS)を使って、miniDSPをプログラムすれば良いわけですが、このデモソフトにはPPSのソースに対応するフローファイルが含まれていません。そのため、自分でPPSを使って同じ機能を提供するフロー定義を作成し、それをビルドすることでダウンロードすべきminiDSPへの命令と係数を生成する必要があります。

以前にも書きましたが、PurePath Studioについては詳細を公開することができないので、以下概要だけを書いておきます。

PurePath Studio(PPS)には、もともと最大8バンドのスペクトラムアナライザが部品として用意されていますので、これを使えば実現できることは容易に察しがつきました。その部品のヘルプを参照することで、バンドパスフィルタを各チャンネルの前に配置することで、設定した範囲の周波数成分のエネルギーを求められることもわかりました。「これは簡単じゃん」というわけでデモ画面と同じように左右それぞれ20バンド分のフィルタと、スペアナ部品を3つ使うことで 8 + 8 + 4 = 20バンドの周波数成分を求めるフローを作成してみました。ところが、実際にこれをビルドしようとするとエラーになってしまいます。どうやらバンドパスフィルタを合計40個も定義するために、DAC miniDSPの係数バッファの資源が足りなくなってしまうようです。

デモでは20バンド処理できているようなので、これを実現する方法があるはずなのですが、どうすればいいのかわかりません。フローの構成をちょっと変更してみたりしましたが、どうしても資源不足になってしまい20バンドを処理するフローが組めません。結局、左右16バンドならなんとか組めたので、それで我慢することにします。

このようにしてminiDSPを使うことで、各周波数帯域のエネルギーを求めることができます。こうして求めた値は、AIC3253の係数レジスタに保持されます。ホスト側のマイコンはI2Cでアクセスすることで、これらの係数レジスタの値を読み出して、それをグラフ表示してやればいいのです。

ちょっと窮屈

SPI接続のTFT LCD JD-T1800を実験ボードの上に載せました。CODECの基板と場所が重なってしまうので、LCD基板で使用するソケットには背の低いものを使うことでなんとかしのいでいます。



LCDの資料としてはコントローラ(ST7735)と、サンプルのプログラムが付いていましたので、それらを参考にまずは単純な文字表示ドライバを作成。文字表示することで動作確認まで完了。ドット抜けもないようですし、10ドルであったことを思えば悪くない買い物でした。

東京に戻ってきた

金曜の地震。わたしは、京都にでかけていて大地震を知りました。もともと土曜に戻る予定でしたが、金曜は新幹線も上りは運休したこともあり土曜に帰れるのか不安もあったのですが、朝から平常通りの運転がなされたことには安堵するとともに、運転再開の早さに驚きもしました。

昼間、京都にいる間は繰り返し流れるTVの報道で地震の恐怖は頭で充分に理解できるものの、実際に体感したわけではない者にとっては、やはり遠くのできごととです。なにしろ、日常の生活はまったく普通に流れています。土曜の繁華街には人や車が行きかい、バスも地下鉄も平常どおりに運行されているのです。

そして予定どおりの新幹線に乗車して、予定どおりの時刻に新横浜着。横浜線に乗り換える段になって、運行本数が少なくなっており発着に遅れが出ているのを見て、ようやくと地震の影響を我が身で感じることになったのでした。横浜線に乗車中は、多くの人が携帯の画面を眺めています。その人たちの携帯が一斉に、めいめいの音色で鳴りだしました。緊急地震速報ですが、みんなそれほど驚くわけでもないようです。繰り返される余震に速報にも慣れてしまっているのでしょうか。すぐに横浜線が運転速度を落とすのがわかりました。1分ほど待って、速度を戻したようです。まだしばらくは、余震も続くでしょう。

いろいろな意味でこの地震は人々の、そして日本の生活を変える機会になる/なったことは間違いないでしょう。そして、その影響は日本だけにとどまることもないでしょう。何しろ全ての出来事は、そして判明する事実はアッというまに全世界に通達される時代です。地震の後、わたしは都内に住む母親に連絡をとろうとしましたが、ドコモもNTTも関東向けの回線はなかなか通じませんでした。呼び出しても、親の方が移動に苦労しており応答できなかったり。夕方6時過ぎになってようやく互いの安全が確認できました。その後、留学のためにイギリスに在住している姪とも連絡。彼女はリビア情勢を確認しようとしてアルジャジーラを点けたところ、津波の映像が飛び込んできて驚いたそうです。そんな姪の連絡基本手段はもちろん、Facebookでのwallやmessageです。

SPI接続LCD

CODEC実験の次の段階では表示装置を使いたいので、LCDをつなげることにします。マイコンのピン数の制約もありSPIでつなげられる手ごろなLCDを探していました。まだOLEDを使ったことがないので、aitendoで販売されているものにも興味はあるのですが、ちょっと画面が小さいです。1.5インチで128x128程度は欲しいと思っていたところ、ねむいさんが128x160のSPI接続専用のLCDを使っているのを見つけました。まさしくわたしが望んでいた仕様なので、同じものを探してみたところ、eBayでJD-T1800という型番のTFT LCDを販売しているショップを見つけました。

なんと送料サービスで$9.99でした。今のレートだと、わたしの家から秋葉往復する電車賃より安いことになります。初めてのeBayでの買い物でしたし、何しろ送料サービスの商品ですのでシンセンからの郵送途中で割れたりしないか不安でしたが、無事郵便で到着。緩衝材でグルグル巻きにされたうえに、プチプチの封筒に入っていたので、まったく無傷でした。



フレキの端子は0.8mmピッチだったので、手持ちのSOP用変換基板を割って使ってみました。実験ボード上に載せるとCODECの基板とあたってしまいショートしそうなので、カプトン・テープを張ってあります。

3D効果を試してみる

ようやくとI2Cの通信不具合が解消できたので、CODEC(TLV320AIC3253)が売り文句にしている機能のひとつを試してみました。

その機能とは3D効果音です。TIはTLV320AIC3253のデモ用に評価ボードを販売しており、そのボードで動作するデモソフトも用意しています。デモソフトを実際に動作させるためには、評価ボードが必要なわけですが、試しにインストールしてみたところボード無しでも立ち上げることだけはできました。



機能デモのひとつにある3D効果を選択するとスライダーが表示され、これを操作することで3D効果の調節が可能になっています。



曲の再生中にCODECのレジスタを操作することで、3D効果の度合いを動的に変更することが可能です。GUIを用意するのは無理にしても、効果の度合いを段階的に変更する程度なら簡単にできるだろうと考えてやってみました。概要は次のとおりです。

• まずDACの動作モードとしてPRB_P23を選択。DACの動作モードとしては、あらかじめ構成が決められたPRB_P1～PRB_P25の25種類とminiDSPのプログラムを使用するモードの合計26種類が選択可能です。どのモードを選択するかによって、実現される機能と消費電力が変化します。今回は3D効果をサポートしているモードからPRB_P23を選択。
• 3D効果の度合いは、DACの係数レジスタC32の値を変更することで制御できます。設定可能な値の範囲は0x800000～0x7FFFFFとなっていますが、デモの画面内容から推察する限りでは、有効なのは0x0～0x7FFFFFのように見受けられます。

実際にコマンドでレジスタを段階的に変更してみた様子がコレ↓です。CODECの初期化時にPRB_P23を選択して初期化をおこない、3deffectコマンドで係数を7秒間隔で変化させています。



曲にもよりますが、確かに音に広がりが出てきます。最後に効果無しの初期状態に戻ると、急に音が萎えてしまったような印象を受けてしまうくらいです。

I2Cトラブル解消!!

I2SでA2DPのストリームが流れていると、I2Cでの制御ができなくなってしまう問題で困っていましたが、ようやくと解決できました。

まず最初に22Ωのダンピング抵抗をSAM7SのI2C端子に追加してみたのですが、効果なし。かねての計画どおり、次の対策としてフラットケーブルでの接続をやめヘッダソケットで接続できるようにCODEC基板を改修。ケーブルの長さが災いしていたのでしょうか、効果テキメンです。音楽再生中にCODECの初期化をやり直しても、I2CのNAKエラーは全く発生しないようになりました。



ようやくと、次のステップに進めそうです。一方、W-SIMのloader modeについては進展なし。問題なく使える方のカードでやりくりしようと思います。