AACも追加しよう

MCIドライバのバグも見つかってひと安心したので、さらなる機能追加をしようと思います。現在のところのコードサイズはこんな↓もんです。



コードは全部ARMモードなんですけど、それでも200KBほどしか使っていません。まだフラッシュは300KBも残っています。そこで、コードサイズが増えそうな機能拡張としてAACデコーダを追加しようと思います。我が家でもカミサンのiTuneライブラリから曲データを拝借するには、MP3よりもAACの方が都合がいいですし。

デコーダとしてはMP3と同じく、HelixにあるAACデコーダが使えそうです。MP3と比べるとCPUを喰いそうなのですが、MP3再生には半分くらいしかCPUを使わないことが確認できたので、良く知りませんがSBRとかいうのを使わなければ、AACも楽勝でしょう。SBRはRAMも使うようなので、CPUが間に合ってもメモリでアウトになりそうですし。

ちょっと検索してみたら、やはりARMでMP3/AACの両方を載せている人がいました。しかも、AT91SAM7を使っているじゃないですか。がんばってるなぁ。おまけに、ChaNさんのFatFs使ってるし、この人も赤外線リモコン使えるようにしているようです。まぁ、だいたい皆さん同じような事を考えるということですね。もっとも、FatFsはATMELがAT91SAMシリーズ用のライブラリ(at91lib)の中に含めているくらいなので、ATMELユーザにとっては世界的にお馴染みであるとも言えます。

記事に目をとおしてみましたが、やはりAT91SAM7Sではかなり苦労して動かしているようで、CPUを喰うルーチンはSRAMに配置するようにしているようです。AT91SAM7は個人的には大変好みのデバイスなのですが、LPC2000シリーズと比べた時の最大の欠点はフラッシュからのコードの実行が遅いことです。AT91SAM7はデバイスにより最大55MHz～60MHzのクロックでの動作が可能なのですが、フラッシュのコードを実行する場合には、クロック30MHz以上ではウエイトの挿入が必要になってしまいます。ウエイト無しで動作できるのは、内蔵SRAMのコードを実行する時になるので、処理時間を短縮するためには、コードをSRAMに再配置する必要があるのです。それに比べてLPC2388は、MAMの機能により内蔵フラッシュのコードもARMモードであっても高速に実行できるので、大助かりです。AT91SAM7にもフラッシュのキャッシュ機能はあるのですが、バッファが小さいためにThumbモードでしかご利益がありません。

ともかく、この人のコードを見れば、AACデコーダの使い方が簡単にわかりそうなので、使わせていただくつもりです。

バグ修正

ビットレート320Kのファイルを再生した際に生じる問題は、やはりMCIのドライバに起因するものでした。複数のセクターを連続して読み出した場合には、DMAがセクター毎に発生し、そのたびにDMA終了割り込みが発生します。MCIのドライバをTOPPERS/JSP対応に変更した際に、DMAの終了待ちをセマファを使って wai_sem() したのはいいのでですが、その最大値が1 になっていました。そのため、wai_sem(）する前に連続してDMA終了割り込みが発生してしまうと、セマファの値が2以上になるべきところが、1にしかならないために、DMAの終了を検出し損ねていました。

たまたま320Kのファイルを再生する際に発生する頻度が高かっただけで、他のビットレートでも問題は時々発生していたようです。セマファの最大値をバッファのサイズに合わせて4に修正したところ、半日近く連続して繰り返し再生しても問題は発生しなくなりました。これで、そこそこ実用的になったと思います。

きょう〆切だったencafeの電子工作応募作品群を眺めていたら、chiakiさんのTimpy Rev8.0の動画を発見。前回のMTMで実物を見てはいるのですが、改めてその小ささと完成度の高さを痛感させられます。ユニバーサル基板でしかモノを作れない我が身が悲しい。それに、動画もやはり全体像がわかる、いい作品にしあがっていますよね。わたしも、もう少しマシな動画を用意したいと思います。そういえば、W-SIM電話機ジャケットはひとつも全体像が見える動画を上げていないことに気がつきました。これも、近いうちになんとかしたいと思います。

ビットレートを変更しての動作確認

クロックを72MHzに変更したので、改めてMP3のデコードにどの程度の時間がかかっているのかを調べてみることにしました。以前、おおざっぱに調べたことがありますが、その時はまだSDカードも使えない状態でしたので短時間のMP3データでしか調べられませんでした。そこで今回は、SDカードからの読み出しと伸長処理をおこなうだけで音声出力をおこなわないルーチンを作成して、どの程度の時間がかかるのかを調べてみました。ついでに、ビットレートも192Kに加えて、256Kと320Kの場合の3種類を調べることにしました。

実験の様子はこんな↓感じです。試験再生コマンド(mplay)を投入して、経過した時間を表示させています。実際には、並行してLCDに時計を表示するタスクが動いているのですが、その程度のオーバヘッドは無視することにします。結果は次のとおりです。



それぞれのファイルは、同一の曲をビットレートを変えて取り込んだものです。意外と、ビットレートによる時間差は少ないです。曲の長さは175.466秒ですので、

ビットレート	ファイル長	展開時間
192Kbit	4,208,952	83.370/175.466 = 47.51%
256Kbit	5,612,596	87.368/175.466 = 49.79%
320Kbit	7,017,028	88.580/175.466 = 50.48%

となり、SDの読み取り時間を含めてだいたい半分くらいの時間がかかっているようです。以前は60%くらいは費やしていましたから、ほぼ予想通りに性能が向上したということろでしょうか。

データがとれたのはいいのですが、じつは320Kbitのファイルを再生しようとすると、かなりの頻度で途中で試験再生が止まってしまうことが判明。普通に音を出せば問題なく動作するので、どうやらSDの読み取りが連続して発生した場合に問題が発生しているようです。週末にバグとりするつもりです。

クロック速度の変更

今頃になってなんですが、LPC2388のcclkを72MHzに変更してみました。これまでは57.6MHzだったのですが、それとて特別な理由があって選択した理由があったわけでもなく、Interface誌に掲載されていたどれかの記事のサンプルからクロック初期化部分を拝借した結果、そうなっていただけのことです。57.6MHzでも何不自由があるわけでもないのですが、どうせなら72MHzでの動作確認もとっておこうと思った次第です。

クロック初期化部分を変更しただけでビルドしてみると、シリアルポートの出力が文字化けしてしまいました。ボーレートの設定はPCLKから計算してあったのですが、UnFDRを使わずにUnDLM/UnDLLの設定だけで済ませていたのが原因でした。確認のために115200bpsを生成する場合を計算してみると

cclk	pclk	divisor	DL	DivAddVal	MulVal	Baud
57.6MHz	28.8MHz	15.625	15	0	0	120000
72.0MHz	18.0MHz	9.765	9	0	0	125000
72.0MHz	18.0MHz	9.765	8	2	9	115056

ここで、divisor = pclk/16/115200 です。divisorの値を四捨五入せずに切り捨ててDLの整数値を求めていたので、かなり誤差が大きくなっていました。切り上げてDLとして10を使っても動作したと思いますが、せっかくなので上記のDivAddValとMulValでUnFDRを設定しておきました。

DivAddValとMulValの算出はちょっと面倒ですね。わたしはNXPが提供しているExcelシートを使って求めてしまいました。AT91SAM7にも同様にFractional baud rateの機能があるのですが、こちらの方が設定は簡単だと感じました。

そろそろ出てくるのか？

NXPのホームページでマイコン製品を見たところ、製品種別として新たにCortex-M0が加わっています。先週の時点では無かったと思うのですが。。まだ実際のデバイスは登録されていませんが、とりあえず器だけは用意されたところを見ると、中身の実際のデバイスの方も近いうちに情報が載るということでしょうか？

ARMフォーラムでの出展

すでにARM愛好者さんからもお祝いのコメントをいただきましたが、ARM基板アプリケーションコンテストに出品したところ、なんと優勝してしまいました。最初は応募するつもりはなかったのですが、〆切が延長になったのを知って、〆切直前の連休でリモコンと音量調節機能を加えたところ、それなりに体裁が整ったので応募してみた次第です。昨日は、品川で開催されたARMフォーラムにおいて入賞作品の展示と表彰がありましたので、一日これに出向いておりました。



会議場前の通路に展示用机を用意していただき、各自の作品を展示。一番手前の作品は、いま研さんの作品です。説明用スタンドもお手製。

わたしのMP3プレーヤはこんな↓感じで展示。展示場所のFMの受かり具合が心配だったのと体裁を整えるために、前日に急遽ロッドアンテナをつけておきました。実際には写真のように窓際だったので、ちょっとアンテナ線をたらすだけでも充分だったでしょう。



皆さんの作品の写真は、すでにhamayanさんが掲示されているので、こちらをご覧ください(わたしの写真より、良く撮れていますので)。詳細については、別途Interfaceや出品者のページでも紹介されると思うのでここでは説明しませんが、みなさん力作ぞろいでした。

いま研さんはFreeRTOS+uIPのWebサーバを中心としたシステムなのですが、LPC2388に直接つなげたキャラクタ/グラフィックLCDだけでなく、XBee経由でArduino制御のLED掲示板に飛ばしたり、別の加速度センサーからデータを収集したりと、それぞれが単独でも見ごたえありの作品でした。

hkhacksのおふたりの作品は、実際にキーを打って画面を見ないと、この楽しさが伝わりません。キーを叩いた回数やキー種別統計が採れるのですが、なにより打鍵時にLCDに表示されるアニメーションの変化が楽しい作品です。SDカードに格納された画像をきれいに再生するための工夫がこらされています。基板も何度かの試作を経て出展用のものを作成されており、とてもきれいに組み上げられていました。

柳本さんは、これまでもV850基板を使って簡易オシロを組んでおられたということで、その経験も生かして画面の表示がとても良くできていました。持参されていた設計書が、とても丁寧に作成されていたのも印象的でした。

このようなコンテストに出品するのは初めてだったので、もちろん出展も初めて。いちおう説明用スライドを何枚か用意したクリアファイルを一緒に置いたのですが、いま研さんやhkhacksのおふたりのように配布用の一枚ものを用意した方が良かったと反省。出展の仕方の勉強になりました。以下に今回用意した資料を貼っておきます。













ふだん身近にはマイコン談義できる仲間がいないので、みなさんと楽しく話ができたのが、なによりも一番うれしかった一日でした。みなさん、どうもありがとうございました。

フォントの追加

これまでMP3の再生時の際の曲名や演奏者名の情報の表示には日本語表示に対応するためにIPA GUIフォントを使っていたのですが、英字/漢字に関わらずIPA GUIを使っていました。そのため、英文表示の際になんとなくノッペリとした印象を受け気に入らなかったので、英字部分には別のフォントを用いることとしてみました。

使用したフォントはGentium Book Basicです。IPAフォントと同じように次のような手順を経て、使用しています。

1. TTFファイルをダウンロード。
2. FreeTypeを使った自作ユーティリティで、必要なサイズのビットマップデータ(独自フォーマット)を生成。
3. Linux上で作成したフォントデータをSDカードにコピー。
4. LPC2388上で、SDカードのフォントデータをLCDモジュールに搭載されているNANDフラッシュにコピー
5. LCDの表示ルーチンは、NANDフラッシュからフォントデータを読み込み表示。

NANDフラッシュに関しては、単純なR/Wルーチンしか用意しておらず、ファイルシステムは載せていません。そのため、各フォントは単純に連続したページに配置して、その先頭ページを自分でメモして管理しているという手抜きで済ませています。そのため、NANDへのコピー作業の実態は次↓のようなものです。



copyコマンドで、フォント名とコピー先の先頭ページ番号を指定しています。結果として表示されるページ番号が次の領域のページ番号ですので、次のフォントのコピーはそのページから開始しています。そして、ソフト側ではフォントをオープンする際に、このページ番号を指定しているという仕掛けです。

Before	After

ついでに演奏者名の表示位置も若干修正。GUI作成ツールがあるわけじゃないんで、プログラム中でテキトーに座標指定することで位置修正しなけれりゃなりません。うーん、まぁ、こんなところで良しとしておきましょう。

特殊効果を試してみる

きょうは、とっても久しぶりにCMOSカメラ実験ボードを引っ張り出しました。ここのところずっとLPC2388漬けだったのに いきなりCMOSカメラになったのには、ちょっとしたキッカケがあったからです。

通販サイトをいくつか巡回していて、たまたま日昇テクノロジーを覗いてみました。Andoroid対応のARM11なんかもありましたが、わたしの関心は、CMOSカメラ・モジュールの方に。。同社が販売しているARM9ボード用のものですが、資料がそろっているので単体でも使えそうです。2.54mmピッチのヘッダであれば便利だなと思いましたが、残念ながら2mmピッチでした。データシートを確認してみると、なんとわたしが使っているのとおなじOV9650ではありませんか。しかも、その資料は、"Implementation Guide"という資料であり、TechToysには置かれていない資料です。レジスタの使い方についての補足的な説明が書かれており、CMOSカメラをちゃんと使うには欠かすことのできない資料のようです。こんなところで運良く入手できて、ラッキーです。

この Implementation Guide中にSpecial Image Effectsとして、簡単な色補正の例が、操作するレジスタ(TSLB, MANU, MANVの３つ)と、設定する値とともに紹介されていたので、さっそく試してみたくなったというわけです。

といわけで、実験してみました!! レジスタ設定を変更しながら、撮影した画像をJPEGに変換して、SDカードに保存するという作業を繰り返して、次のような画像を得ることができました。片手でカメラボードを支えながら、もう片手でPCからレジスタ設定やキャプチャのコマンドを投入するという作業だったので、けっこうシンドカッタです。

Mode	Picture
Normal Color
Black & White
Sepia
Blush
Reddish
Greenish
Negative

やっていることは単純で、出力の色差信号のU/V成分を固定値にしてしまうことで、特定の色調にして輝度成分(Y)だけを変えたり、出力を反転しているだけです。データシートのレジスタ説明を読むと「マニュアル設定用レジスタ」とあるので、全て自動設定に頼っているわたしのような者は最初から敬遠してしまうレジスタです。シロウトにはこういう出力画像が得られることまではなかなかイメージできないので、こうして具体例として説明してもらえるとわかりやすいですね。こういう特殊効果遊びやってみたかったんで、この結果にはとっても満足。ちゃんとカメラのレジスタの勉強すれば、もっといろいろな効果出せるのでしょうが、真面目に勉強に取り組むのって面倒なんですよね。今回みたいに、具体的な数字があると、すぐに試してみちゃうんですが。