音声PCMの接続 -- 再生時

メッセージの録音ができたら、再生も必要ですので、その場合の処理を考えます。再生時には、MCUが録音記録媒体から読みだしたPCM信号をCODECに送ることになります。W-SIMは通話状態の時しかPCMCLK/PCMSYNC信号を生成してくれませんから、これらの信号もMCUが自分で生成する必要があります。

RDとPCMOUTがつないであるのは、ガイダンスメッセージをCODECのマイクから録音できるようにするためです。このように再生時にはW-SIMはまったく関与しないので、切り離すためにセレクタが必要となります。

切り替えが必要な信号とそれぞれの接続先を整理すると次のようになります。

緑色と橙色の時で切り替えが必要な信号のグループと水色とピンクの場合で切り替えが必要な信号があることがわかりましたので、これらを独立して切り替えられるように74257をふたつ使っています。また、切り替え制御はCODECのGPIO機能をI²C経由で行うことにしました。

音声PCMの接続 -- 録音時

今回は音声を録音するための接続についてです。受信した音声を録音するためには、いったんMCUでPCM音声データを受けて、それを録音媒体に書き出すという処理が必要となります。AT91SAM7SEではSSCという同期シリアルコントローラを適切に設定することにより、W-SIMからのPCMデータを直接受信することが可能です。



W-SIMとAT91SAM7SEとの配線は上図のようになります。録音に先立ち、ガイダンス音声を流したい場合には、MCU側からPCMデータをW-SIMに送信してやる必要が生じます。点線で示した部分です。しかしながら、W-SIMのPCMOUTにはすでにCODECからの配線があるので、これとぶつかってしまいます。この問題を回避するには、セレクターを設けてやることにします。

AT91SAM7SEのTKとTFは、それぞれ送信用のクロックとフレーム同期信号ですが、ガイダンス音声の送信にはこれらの信号は未配線でもかまいません。SSCでは、受信側のクロックとフレーム同期信号を送信時にも使用するように設定することが可能なためです。

配線図からも明らかなように録音機能と通話機能は共存できますので、普通の通話時にも音声を録音することは可能です。ただし、録音できるのは通話相手の音声だけで、自分側からの音声は録音されないのが難点ですが。

音声PCMの接続 -- 通話時

今回の製作では、音声PCMの処理として、通話だけでなくメッセージの録音や再生機能もサポートする計画ですので、それぞれの場合の音声PCMの接続の仕方について整理しておくことにします。まずは普通に通話する場合です。

通話時にはCODECとW-SIMのPCM信号が互いに接続されます。今回の製作でもCODECは以前と同じくOKIのML7041を使っています。両者のつなぎ方をPCM関連信号だけに着目して図示すると次のようになります。

PCMINとPCMOUT同志を接続する点に注意です。W-SIMの信号名はホスト側からみた名称になっており、PCMINが出力端子、PCMOUTが入力端子になっているからです。

通話状態になるとW-SIMからPCMCLKとPCMSYNC信号が出力されるようになり、それにともないPCMIN/PCMOUTが入出力されます。CODECが適切に設定できていれば、音が出るはずです。CODECは初期状態ではu-Law圧縮/ロングフレーム同期になっており、W-SIMの出力形式と合致していますが、出力先としてディフォルトで選択されているスピーカはパワーダウン状態になってしまっています。そのため、スピーカ・アンプをパワーオン状態にするか、出力先をイヤホンに変更してやる必要があります。

このように普通に通話する時の音声入出力にはMCUは全く介在していません。少しはMCUにも仕事させようというわけで、録音機能を持たせることにした次第です。

ハードを追加した基板

予定の追加ハードもだいたい配線できたので、現状を記録しておくことにします。まずは1枚目の上部基板です。外見上は、以前の様子とさほど変わりありませんが、写真左下にRTCが追加されています。



ピンソケットで接続されているLCDボードをとりはずすと、その下に配置されているW-SIMが見えます。W-SIMの右側にあるのは、ATMELのDataFlashで32Mbitの容量があります。タッチパネルと同じくSPIで接続する都合上、この場所に配置しています。



新たに用意した2枚目の下部基板は、3つのピンヘッダ/ソケットで上部基板と接続しています。基板の右端部分はリチウムポリマ電池と、その充電回路で、ミニUSBコネクタからの給電により充電します。このコネクタは上部基板とはつながっていないので、充電目的専用です。

3つのピンヘッダで囲まれた部分には、CODECとCODECへの信号を選択するセレクタが配置されています。



下部基板を裏返すとML7401 CODECとセレクタとして使っている74HC257が見えます。写真右下の電解コンデンサの下にある、灰色の四角状の石は、2.048MHzの発振器です。CODECへのマスタクロックとして使います。74HC257は買い置きのSOPを使ったのですが、ピッチ変換基板使うくらいなら、DIP品を買い直した方が安いし面積も小さくできたような気もします。



DataFlashの動作確認も始めています。とりあえず、Device Idの読み取りは正しくできたので、一安心です。

ダイアルパッドを用意した

CODECチップも最低限の配線はしたので、ダイアル用のキーパッドを用意して発呼ができるところまで作ってみました。いちおうiPhoneを意識して(?!)ブラックを基調としてみましたが、ざっと文字を並べてみただけのキーパッドなんで見栄えはいまひとつさえません。数字のフォントは大きさ的には悪くないとは思うのですが、実際に表示してみるといまひとつ線が細い感じがします。FreeTypeの機能を使って太字にしてみた方がいいかもしれません。後ほど、FreeTypeをもう少し勉強してフォントを作り直してみようかと思います。



いちおう電話番号をタッチパネルで入力して、Callボタンを押すことで発信して実際に接続するところまで動いています。もっとも、まだマイクを接続していないので、実際には通話先からの音声を再生できるだけで、こちらからの音声は伝えられないのですが。。。

各ボタンは、きれいにデザインしたビットマップを用意できればいいのですが、そんな技量も根性もないので、単純にプログラムでフォントと描画位置を指定して文字を描画しているだけです。恥ずかしいですが、Callの文字がはみでているのは位置指定を間違えているせいです。機能的にもまだまだ足りないところを追加せねばなりませんし、見栄えももう少しマシになったら動画も用意してみようかと思います。

日本語の表示

ようやくと大きなサイズのフォントを用意して、表示するところまでこぎつけました。



TrueTypeのIPAフォントからFreeTypeを使って作成したビットマップデータには、文字グリフの占める領域部分のデータだけが含まれています。最初に白抜きで表示している「みなさん、こんにちは」の各文字はその様子を示しています。文字に応じて必要最小限のデータ量で済むという利点もありますが、正しい位置に表示をおこなうためのメトリック情報も必要となります。漢字のようにほとんどが全角サイズであれば、かえってデータ量が増えてしまうかもしれません。

青色表示した時刻表示用文字は、ひらがなと比べて少しサイズを小さくしてあります。必要な文字だけを必要なサイズで準備して使うことができるようになりました。

次のステップは、いよいよダイアル用のキーパッドを作成し、タッチパネル操作による発呼です。

フォントを準備するには -- その２

結局、FreeTypeのライブラリを使って、自分でTrueTypeフォントからビットマップ形式でのフォントデータを作成することにしました。用意されているチュートリアルをざっと読んでみると、単純なテキスト描画は簡単にできそうなことがわかったからです。

チュートリアルで紹介されているプログラム(example1.c)に手を加えて、C言語の配列データとして、ビットマップデータを出力するように変更してみました。example1.cではグレースケールを使う形式でのビットマップを生成するようになっているので、モノクロのビットマップを生成するように変更して、あとは出力形式を自分の都合のいいように整える程度の作業でした。

Microchipのフォント変換ツールのように、filterファイルを用意し、そこで使われている文字列内のグリフのビットマップだけを抽出して出力する機能も加えてみました。日本語については、filterファイルではUTF-8で記述し、変換プログラム内ではUTF-16で扱います。FreeTypeではFT_Load_Char()関数により、グリフの読み込みならびにビットマップの生成が行えますが、読み込むグリフの文字コードをUTF-16で指定してやれば、IPAフォントから対応する文字データを取得できることを確認しました。

ビットマップの準備はできたので、これに合わせたLCDへの表示ルーチンの作成を開始することとします。日本語表示の画面を出すまでもう一歩です。

ハードの方は、追加部品の配置とおおまかな配線を終了したところです。こちらについても順次動作確認を進めていくことにします。

フォントを準備するには

以前にも書いたようにサイズの大きなビットマップフォントを用意しようと思っています。フリーのビットマップを探そうかとも思ったのですが、ふとMicrochipのグラフィック・ライブラリではどうしているんだろうと思い調べてみました。

するとライブラリとともに提供されるツールとして、"Bitmap and font converter"というプログラムが用意されていることがわかりました。このツール、TrueTypeのフォントを読み込んで、指定したサイズのビットマップを出力するラスタライザなのですが、画面に表示する代わりに、バイナリファイルやCプログラムの形式に変換して出力してくれるようになっています。プログラムに組み込むための方法については、AN1182としてまとめられており、わかりやすいです。日本語のフォントも扱えるようになっており、メッセージ表示で使用される文字のグリフだけを抜き出したフォントデータを作成することもできるので、組み込み目的にはうってつけです。

フォントとしてはIPA GUIフォントを使えばいいと考えているのですが、問題はこのコンバータです。Microchipのライブラリは、Microchipの製品に組み込むことが使用条件となっていますので、わたしは使ってはいけないことになります。同じような機能のフリーのソフトとかあっても良さそうな気がするのですが、見つけられずにいます。FreeTypeのライブラリを使って、自分でツールを作るしかないのでしょうか。。

消えないビット

2週間くらい前から悩まされている問題があります。ATSAM7SE256のフラッシュに書き込むファームが大きくなってきたら、書き込みエラーが発生するようになってしまったのです。書き込んだ後にべリファイすると正しく書き込めていない箇所があります。



どういうべリファイをしているのか詳しい動作がわからないのですが、なぜかいつもエラーが報告されるのは1ヶ所だけです。1ヶ所見つかった時点でべリファイ動作を中止しているのか、はたまたホントに１ヶ所しか間違いがないのかわかりません。いつもアドレスは0x0011XXXXなのですが、特定の１ページだけというわけではなさそうです。上記のエラーはB2であるべき個所がB6になっていることを示していますが、どうやらいつもこの例のように0になるべきビットが立ったままになってしまっているようです。

再書き込みをしてみても、同じ位置で同じエラーになります。一度、全ページを消去してから書き込むとたまに正しく書けることもありますが、ほとんどの場合やはりエラーとなるようです。現時点ではエラーの発生する箇所は、初期化データが配置される領域に相当しています。そのため、どの部分が化けるかによって、問題無く動作を開始しても、しばらくしてから突然例外が発生するというように動作が不安定になるという症状が発生してしまいます。

ATMELのデータシートでは10,000回の消去が可能となっていますが、まだ1000回も書き込んでないハズです。消えにくい石に当たってしまったということでしょうか。いちおう予備のSE256は買ってあるので、ピッチ変換基板ごと交換することは可能ですが、高価なピンヘッダへの出費が痛いです。いまんとこ、0xffで初期化したダミーの配列を定義して、エラーの発生しそうな領域を食いつぶしてなんとかしのいでいます。しかしながら、問題領域がプログラム・テキスト領域内に侵入するのは時間の問題です。そうしたら、しばらくはダミーのコード追加で逃げることになるかも。

Static Maps APIへの移行

以前からそのうちにやろうと思っていたGoogle Static Maps APIへの対応作業をおこないました。これまでの使っていたmapprintというAPIは非公式なものでしたが、staticmapはGoogleが公式に公開しているAPIです。使い方のあらましは、どちらも同じようなものですが、細かい点はビミョーに異なっていました。

• 緯度/経度の指定順序が逆になった。以前は小数点を省略したが、今度は必要。
• Zoomレベルの指定が逆になった。以前はゼロが最大ズーム。今度は17で最大。
• 画像サイズの指定はwidth,heightの形式からwidthxheightの形式になった。
• APIを利用するに際しては、GoogleからAPI Keyを取得する必要あり。

APIキーの取得はWebページで即時にできますし、APIの変更も微々たるものですので、対応作業にはさして時間はかかりませんでした。APIを使って取得できるのは、指定した緯度経度を中心とする、指定したサイズの画像である点も同じです。公式サービスであることを強く印象付けてくれるのは、やはり地図画像の中にシッカリとGoogleロゴが入るようになったということでしょうか。



APIの変更と同時に操作用の簡単なUIも用意してみました。画面の最下部にはズームレベルを指定/表示するスケールを用意しました。ここでの1～8の指定がstaticmap APIでのズームレベルの10～17に対応します。表示される領域の移動は画面上でのグラブ操作のようにタッチパネル上でペン先を移動することでおこないます。スムーズスクロールできるわけではないので、ペン先を離した時点で移動方向を判断してから新たな地図画像を要求してダウンロードするので、新たな画面が表示されるには数秒かかってしまいます。動画で示せば文章で説明するまでもないのですが、画像情報の要求のためにHTTPでconnectする際や、地図画像をダウンロードしている途中でしばしばタイムアウトエラーが発生してしまう問題が発生しており、原因をつかみかねています。単純に、PHS電波の入りが悪くてパケット通信が滞っているだけかもしれませんが。