ID3タグ

ひさしぶりにLPC2388基板を引っ張り出しました。

まがりなりにもMP3とFM放送の再生ができるようになり、最低限必要な基本機能は用意できましたが、あまりにもそっけないので、少しは見栄えのする一般機能も順次付け加えていこうかと思います。まずは、MP3で再生中の曲の情報でも表示できるようにしようと決めて、調べてみました。ID3タグと言うんですか。白状してしまうと、これまでMP3プレーヤを作るどころか使ったことも無いので、こういう知識が全くありません。

ID3にはバージョンもいくつかあるようですが、ファイルの頭に入っているID3v2をデコードしてみることにしました。MP3ファイルの再生時にいつも先頭を読み飛ばしていたのは、この領域だったのですね。表示するタグは、とりあえずTIT2(曲名), TLEN(長さ), TPE1(演奏者)の3つとしてみました。(32文字で切ってます)



文字列はUTF-8対応できる形式になっているようですが、実験に使っているMP3データではUTF-8は使っていないようです。びっくりしたのは、同じCDに入っている曲のデータなのにもかかわらず、トラックによって文字列データがシフトJISや半角ASCIIで入っていたりとメチャクチャなこと。「自分で編集しなおして使うもの」というのが常識なんでしょうか？それとも、たまたま題材にしたアルバムのデータの出来が悪かっただけ？ いくつか半角に修正してみたものの、途中でメゲました。

最後に表示しているのは、演奏状態です。例では全20トラックの8トラック目を演奏中であり、およそ28%の位置ということです。コーデックのI²Sを12MHzのクロックで動かしている都合上、本来は44.1KHzのサンプリング・レートで再生すべきところを、実際には44.117KHzで再生しています。そのため、長い曲になると早めに再生が終わってしまうのがわかるかもしれません。

AT91SAM8G45とAT91SAM3U-EK

Linux4SAMで、その存在だけは暗示されていたAT91SAM9G45が発表になったようです。400MHz動作とUSB ホスト/デバイスのHigh Speed対応がウリという感じでしょうか。

AT91SAM9Gは自作で遊べる製品じゃないので、やはりわたしとしてはAT91SAM3Uあたりに興味が向くところです。AT91SAM3U-EKが発表になったのですが、お値段$199はタッチパネル付きのQVGA液晶が載った純正ボードにしてはリーゾナブルではないかと。メモリも載っているし。そろそろSAM3に手を出してみたいと思ってはいるのですが、そのうちにEtherあるいはUSB Host/OTGを持ったデバイスも出てくるのではないかとも想像しているので、いつまで様子見を続けるか悩ましいところです。

そんなことを考えながらAT91SAM3U-EKの回路図を見ていたら、気がついたことがひとつ。クリスタルが12MHzになっています。これまでAT91SAM7やAT91SAM9では、18.432MHzが標準的なクリスタルだったので秋月や千石じゃ置いてないし、売っている店があってもえらく高かったりしたのですが、12MHzなら秋月でも買えます。

スライド・ショーしてみる

JPEGの伸長、表示ができたので、次は当然の帰結として(?)スライド・ショーです。とは言っても、単純に順に表示していくだけで、何の芸当もないんですけど。でも、自作環境で、デジカメで撮った画を表示してみたかったんですよぉ。これまでは、SDカードに保存された画像を表示するにしても、BMPとかに変換していましたからね。JPEGファイルのままで表示できるだけで、単純に嬉しいです。



JPEGを伸長した結果を直接LCDに書き出してもいいのですが、そうすると伸長処理に時間がかかっているのが丸見えなので、いったんメモリ中に展開した後に一気にLCDにコピーすることで表示を切り替えています。

TWIを使うのをあきらめる

ATMEL用語ではI²CインタフェースのことをTWI (Two Wire Interface)と呼んでいます。MCKを100MHzにしつつCMOSカメラをI²Cで使いたいのですが、どうもAT91SAM9260のTWIを使ってI²C制御しているとうまく動いてくれません。検索をかけてみるといくつかのMLでも同様の問題が報告されているようです。

• LM-sensorsを使っている人なんかは、TWIを使わずにGPIOでBit-Bangして動かしているようです。
• AT91SAM9260のデータシートにはTWI関連のErrataは載っていないのですが、AT91SAM9261のデータシートにはErrattaがあります。AT91SAM9260のTWIはちゃんと動くの？
• AT91SAM9260のTWIはいかれていて、ドキュメントのとおりにはちっとも動かん と言い切っている人もいるようです。

思ったように動いてくれないという点では、わたしもまったく同感です。そこで、LM-Sensorな人たちと同じようにTWIを使うのをあきらめて、Bit-Bang、すなわちソフトウェアI²Cすることにしました。TWIの割り当てられているポートの設定を変更して、ドライバを書き直すだけですから、配線の変更は必要ありません。ソフトの修正だけで対応できます。



はい、きれいに動くようになりました。もちろん、MCKももとどおりです。これまではレジスタダンプを実行すると、少なくとも5回に1回はエラーが発生していたのですが、もうそんな問題は発生しません。CMOSカメラには何の問題もないことがわかってスッキリですが、TWIがどのように悪いのかはまだはっきりとわかっていません。

大事なことを忘れていた

JPEGの圧縮と伸長の両方が動くようになったものの、ちょと時間かかり過ぎているなぁと感じていたのですが、大事なことを忘れていたことに今頃になって気がつきました。

カメラをつなげた際に I²Cがうまく動いてくれずに悩んでいましたが、MCKを半分にしたところ動くようになったので、この設定で動かしていたのでした。MCKはほとんどのペリフェラルでのマスタークロックですので、これを半分にするということは、ほとんどのI/O処理時間が倍になることを意味します。JPEG圧縮/伸長はI/OではなくてCPU boundな処理だからということで、DTCの計算方式を確認してみたりしていたのですが、MCKはそのままSDRAMへのクロック供給信号であるSDRAMCになっていることに気付かずにいました。つまり、これまでメモリは100MHz近いクロックで動かせるところを半分の50MHzで動かしていたことになります。

さっそくMCKを元に戻して、JPEG伸長を確認してみました。



やっぱり!です。こんなに簡単に2倍近く速くなるとは。

しかしながら、MCKを速くするとカメラのI²C制御がうまくできなくなってしまう問題が発生してしまいます。そのため、画像の撮影ができません。まずはこのI²Cの問題をなんとかしないといかんようです。

JPEGの伸長、表示

CMOSカメラで撮影した画像をJPEG圧縮できたので、次の実験は当然ながらその伸長です。今回はファイルから読みだして、伸長しながら表示してみることにしました。libjpegはもともとstdioを使って開いたファイルから画像を読み出すためのモジュールとして jpeg_stdio_src()が用意されていますので、こいつをチョットいじってFatFsのAPI に変更してやればいいだけのことでした。

元画像は先週圧縮したものでVGA(640X480)サイズです。LCDのサイズはQVGAですので縦横を半分にしてやる必要があります。幸いなことにlibjpegでは伸長の際のパラメータとして縮小率を 1/1, 1/2, 1/4 または1/8のいずれかを指定できるようになっていますので、この機能を使って1/2に縮小し、スキャンライン毎にLCDに表示してやります。



例によってISLOWとIFASTの両方を試してみましたが、圧縮の時ほどの差異はみられません。処理時間は圧縮の時と比べて短いですが、縮小しているために画素数が少なくなっているのも影響しているのでしょう。

わたしはいつもブログで使う写真はVGAサイズで撮っていますので、これらのファイルも表示できるはずです。試しにこの画像ファイルで実験してみると。。



おやおや、ずいぶんと時間がかかるようになりました。デジカメで撮ったJPEGファイルとの大きな違いはファイルのサイズです。自分で撮影、圧縮する際にはqualityを85に設定していたので、PIC001.JPGのファイルサイズは44KBほどです。それに対してデジカメで撮影したPIC002.JPGでは200KB近い大きさになっています。当然、quality=100に相当するファイルになっているのでしょう。この違いが、処理時間の違いとして現われてきているようです。

と、ここまで書いてlibjpegがバージョンアップされていることに気が付きました。ショック! 現在の作業は5月にダウンロードした Version 6bに基づいています。98年にリリースされていらい更新されていないすっかり枯れたコードだと思っていたのですが、先月11年ぶりにVersion 7が出ているようです(驚き)。このバージョンでは N/8 (1<=N<=16)のスケーリングができるようですので、こっちの方が便利かも。

DevKit8000

エンヤさんのmini2440を見てちょっと羨ましく感じていたのですが、開発元のEmbestでは新製品としてDevKit8000を出したようです。お値段$149というのは BeagleBoardを強く意識してのことでしょうか？Embestのセットにはケーブルも付属しているのでお得感はあるし、LCDもオプションで用意されている点が便利そうではあります。

こんなに安いとマイコンとかの評価ボードを買う気がしなくなりますよね。困ったもんです。

タッチパネル

トランジスタ技術8月号のタッチパネル特集に目を通しました。あんなに種類がたくさんあるとは知りませんでしたが、やはり4線式抵抗皮膜型が基本で入手性も良いということなんでしょうか。

わたしは昨年のタッチパネルジャケットでタッチパネル付きLCDを使っていますが、じつはその前年にトラ技でも紹介されていたDMCのタッチパネルで遊んだことがあります。その時は、ヤフオクで落とした8.4インチTFT LCDと組み合わせてx86 Linuxにつなげたので、DMCのインタフェースをUSBでつなげました。当時のインタフェースチップはTSC-10だったのですが、今はTSC-30になっているのですね。もう少しちゃんとタッチパネルを使いこなせるようになりたいのですが、GUIを作るのも大変だし。。LinuxではWideStudioを使っていたのですが、マイコンで制限無しに使える、手軽なGUIが欲しいものです。

ちなみにこの時のタッチパネルはJW-systemから通販で買いました。個人でもひとつから買えるのは助かりますね。

JPEG画像の確認

MMnet1002ボード上でJPEG圧縮できるようになったので、それをSDカードに保存するとともに、圧縮時のIFAST/ISLOWによる違いを確認してみました。



上↑の画像がISLOWで圧縮したもので、下↓の画像がIFASTで圧縮したものです。



IFASTの方が画がクッキリと出ているのですが、なにしろ基板を片手で押えて、もう片方の手で制御PCからコマンドを叩くことで撮影操作をおこなっていますので、単に撮影時の手ブレの影響の方が大きいだけのことかもしれません。現状の操作性を考えれば、IFASTで充分に用が足りるでしょう。

さて、その操作性についてですが、何しろ実験用ボードなのでいろいろと問題がありまして。。

1. 電源が必要。ACアダプタのコードが邪魔で撮影しにくい。
2. 撮影操作にPCとのUSB接続が必要。USBでつないだPCからコマンド叩いていますので。
3. 撮影した画像の保存はできても、確認ができない。
4. SDカードの抜き挿しが不便。

SDカードにJPEGで画像が保存できるようになったのは進歩なのですが、まだその確認はボード単体ではできないので、SDカードをボードから抜いて、PCで確認している次第です。このカードの抜き挿しがまたやっかいでして、じつはSDカードを抜こうとするとちょうど液晶ボードにあたってしまうのです。よって、カードを抜く際には、いったん液晶ボードを先にはずしている始末。



うーん、やっぱボード作り直した方がいいなぁ。。

JPEG圧縮してみる -- その2

ARM9上でのJPEG圧縮の続きです。もう少し圧縮速度が速くならないかと思いlibjpegのドキュメントを読み直してみると、DTCの計算メソッドを指定できるようになっていました。しかも、libjpegを作りなおさなくても、圧縮を開始する前にcinfo構造体のメンバ(dct_method)で指定することができるようになっています。具体的には

cinfo.dct_method = JDCT_IFAST;
jpeg_start_compress(&cinfo, TRUE);

とするだけのことでした。これまではconfig時にディフォルトとして指定したJDCT_ISLOWを使っていました。計算精度を犠牲にして高速化が図られているということなので、試してみると。。



おぉ、2秒台達成です。かなり効果ありますね。これなら我慢できそうな気がします。しかし、ここまではVGA画像でのハナシです。SXGAではどうなるかも確認しておきましょう。まぁ、計算量は画素数に比例して増えるでしょうから、おおよその推測はつくのですが。。



予想してはいたものの、あまりの処理時間の長さにソフトがハングしたのではないかと疑い始めてしまいました。うーん、これは辛すぎます。JPEG出力できるカメラが欲しくなります。アセンブラで書き直せば我慢できる程度に早くなるんでしょうか？　いつか挑戦してみたい気もしますが、とりあえずはVGAでの撮像で我慢することにします。