フォトフレーム機能の改善

これまでJPEG画像のフォトフレーム表示機能は、単純なスライドショー表示だけだったのですが、ちょっと手を加えてマニュアルでの画像送りと、スライドショー表示を切り替えられるようにしてみました。



操作のために画像表示の下に操作アイコンをもつバーを表示しています。右側の矢印をタッチすることで、次の画像を表示します。左側のプレーボタンを押すと、スライドショー表示に切り替わりボタン表示が一時停止(Pause)に変化します。



バーを常時表示しているのも邪魔なので、画像表示をタッチすることで、バーの表示をオン/オフできるようにしてみました。



動画ではわかりにくいのですが、再生している3種類のアルバムは、それぞれコーデックが異なっています。最初のStart WarsがMP3で、その次は M4A (AAC), そして最後の陽水はWAV非圧縮となっています。画面には映っていませんが、再生音はLPC2388につなげたUSBスピーカから出しています。

SAM3シリーズ

いつの間にかATMELのARMマイコンのページが新しくなって、SAM3シリーズの簡単な紹介が出ています。どうやらSAM3U, SAM3Sに加えて、これからSAM3N、SAM3X, SAM3Aの3つのシリーズが加わるようです。

SAM3X, SAM3AではハイスピードのUSB OTGがサポートされているようですから、おもしろそうです。是非とも挑戦してみたいものですが、このクラスになると自作でちゃんと安定して動くものが作れるのか不安ですね。一度、評価ボードを買ってみるのもいいかもしれないという気がしてきました。

MMlpc1768

いつものPropoxがついにLPC1768のヘッダボードを出してくれました。先週末からページが用意されていたのですが、内容はほとんどMMlpc2368のままで、コピペでとりあえずエントリだけ作ったというのがミエミエだったのですが、次第に内容がLPC1768対応になってきました。まだ写真がLPC2368のままなんで、「ほんとに製品用意できているのか？」という心配はあります。マニュアルは用意されたけど、回路図はLPC2368のままだったりと、ポーランドも大陸的なおおらかさで製品準備を進めているご様子です。

それでもついにショップにも商品が載り、値段がつきました。64Mbのデータフラッシュがついて50USDしないので値段としてはリーゾナブルではないかと。実際には、税金と送料でプラス20～25USDくらいかかるでしょう。embedやLPCXpressoを見送った身としてはかなり興味あります。しかし、白状してしまうと、実は昨年MMlpc2368を買ってしまっていたりします。ここでMMlpc1768に手を出してしまったらMMlpc2368はお蔵入り決定ですので、グッと我慢して少しはMMlpc2368を動かしてみようかとも思います。基本部分はLPC2388のコードが使えるでしょうから、ethernetのドライバを追加して何か簡単なプロジェクトを始めようかなという気になってきました。とりあえずは、ネタを考えねば。でも、そんなことしているとSTM-32は先送りになってしまうなぁ。

Propoxさんには、是非ともSAM3Sのボードもお願いしたいです。ここで、日本語でお願いしても何の効果もありませんが、Propoxならきっと出してくれるだろうと信じています。

アルバム画像JPEG対応

そもそもアルバム画像を表示するためにJPEG伸長の再調査を始めたのですが、ついつい簡易フォトフレーム機能の追加に走ってしまいました。はい、ようやくとMP3の方のアルバム画像もJPEGファイルをもとに表示するように変更しました。見た目では何も変わっていないように見えるわけですが、↓の例ではJPEGを展開して75x72ドットの画像を表示しています。



WMPを使ってアルバム画像を取得すると、JPEGファイルが複数作成されます。実際には大小2種類の画像なのですが、なぜか違う名前でも用意されています。LCDに表示するには、小さい方のAlbumArtSmall.jpg を使えばいいのですが、この名前11文字には収まりません。



LFNを使えばファイル名で区別するのに何も問題が無いのですが、FatFsでLFNを使うとコード変換表のためにコードサイズが大きくなるので、これを避けるためにLFNを使わずに済ますことにしました。解決法は単純で、JPGファイルのうち、ファイルサイズの小さいものを使うというだけです。

さて、JPEG入れたらフラッシュの使用サイズが400KB超えてしまいました。libjpegはv7になってn/8 のスケール機能が使えるようになったのはいいのですが、その処理のためのコードがサイズ喰っているようです。



LPC2388はフラッシュ512KBありますからまだまだ残りはあるのですが、書き込みに時間かかるのがつらくなってきました。

フォトフレーム機能の追加

JPEG展開ルーチンはすんなり移植できたのですが、時計表示モードにフォトフレーム機能を追加するにはいくつか作業が必要だっとので、ちょっと時間を要しました。

まず考えなくてはいけないのは、画像の伸長/表示をどのタスクで処理させるかです。現在 main_taskで時計表示をおこなっていますが、このタスクに画像の伸長/表示処理を追加したのでは、その処理時間が問題となります。VGAサイズでも500msとかかかるので、その間　時計表示の更新ができないと時計の秒表示の進み方が不自然になってしまいます。そこで、伸長/表示はplayer_taskで処理させることにし、main_taskはplayer_taskに対して定期的に次の画像を表示する指示を発行することとしました。

次の問題は、表示の排他処理です。画像の展開/表示に時間がかかるので、その途中に時計表示の更新の要求が入ります。main_taskとplayer_taskの２つのタスクがLCDに対しての書き込みをおこなうことになりますが、表示処理の途中でタスク切替えが発生したのでは、表示がおかしくなってしまいます。そこでLCDへの描画処理の入り口と出口にセマフォの獲得/解放を追加することで、描画の途中で別のタスクがLCDにアクセスすることのないように排他処理をおこなうことにしました。JPEG画像の展開/表示は1ラスタ単位で処理されるので、この単位でLCDに対してのアクセスを占有しています。

他にもスタックサイズを調整したり、不要なルーチンをけずったりしてなんとか動くようになりました。



ポートレートの画像は、↓のように表示します。



動画で示した方がいいのですが、アルバム画像の表示までJPEG対応してから動画を撮影してみようかと思います。

消えゆくAT91

ATMELから新しいARM9のデバイスSAM9M10が発表されました。こいつは、H.264, MPEG-4, MPEG-2といったビデオコーデックのデコードができるVDECという機能を搭載しているようです。どうやらソフトで動画ストリームのヘッダ情報を解析して、必要な画像パラメータを抽出、レジスタを設定したら、デコーダにビデオデータを流し込んでやれば、再生してくれるらしい。レジスタがたくさんあるので、各コーデックをそれなりに勉強しなければ使いこなせそうもないが、ちょっと挑戦してみたい気もしてくる。でも、さすがにこのクラスだと評価ボードが$500くらいするんだろうなぁとは思う。

さて近頃ATMELから発表されるARMデバイスは、みんなSAMxxと呼ばれるようになったようです。以前はAT91SAM7SのようにAT91がお約束のプレフィクスだったのですが。SAM3Sは"non-stocked"ながらもMouserの検索にひっかかることに気付く。まだ、バラ売りじゃないので手が出せませんけど。

一方、NXPのCortex-M0であるLPC111xはすでにバラ売りされているようです。LPC1114のLPCXpressoも売られていますし。

JPEG伸長とフォトフレーム機能のイメージ

Linux上での動作確認でJPEG伸長に要するメモリ量は把握できたので、今度は実際にLPC2388上にコードを移植してみました。昨年、AT91SAM9260にCMOSカメラをつなげた際に同様の作業をしていますので、その時のインタフェース用コードを流用すればいいだけなので比較的スムーズに作業は終了。もともとlibjpegは移植性を重視した作りになっていますので、移植作業はわりと簡単です。主な作業としては、

• jconfig.txtをjconfig.hにrenameして、編集。以下の行を追加。

  #define NO_GETENV
  #define MAX_ALLOC_CHUNK 20000
  #define ALLIGN_TYPE long

• 浮動小数演算を使わないようにjmorecfg.hを編集して、DCT_FLOAT_SUPPORTEDの定義をコメント・アウトする。
• stdio用のインタフェースであるjdatasrc.cを参考にして、FatFs用のI/Oインタフェースを作成する。
• vmunix用のメモリ管理インタフェースであるjmemnobs.cを参考にして、メモリプールからの割り当てルーチンを用意する。
• jerror.cを編集し、エラー出力をTOPPERSのsyslogに変更する。

といったところでしょうか。適宜、必要に応じてヘッダファイル部分を変更したりして、コンパイル、リンクを通します。まずは、デバックコンソールからの操作で展開処理が動くことを確認し、処理時間を測定してみました。まだ、画面への表示はおこなっていません。



アルバム画像のサイズであれば50msかかっていませんから、ほとんど処理時間は気になりません。VGAサイズだとちょっと待つ感じ。最後の1600x1200だと、ハングしたのかと心配になるくらいに長く感じられます。どうやら、フォトフレーム機能での表示にはVGAくらいの大きさが適していそうです。しかし、いずれの場合も画面サイズに合わせてスケーリングした結果、メモリは30KBも使わないことが確認できました。これなら、問題なさそうです。

表示サイズのスケーリングですが、上の処理例からもわかるように表示サイズを240x180に制限することにしました。実際のLCDの画面サイズは 320x240ですが、すでに画面を縦置き(portrait)で使うことにしてしまっているので、landscapeのVGAデジカメ画像を1/2にスケールしたのでは、表示が90度回転してしまうことになります。90度回転して表示させる処理は、LCDの表示モードを設定することで簡単に実現できるのですが、やはり見にくくていけません。そこで、画像幅を240ピクセルとすることで、縦置き状態で正常に画像を表示させることにします。当然、縦方向が余ってしまうわけですが、時計表示のモードにフォトフレーム機能を持たせることにすれば、余りの部分に時計表示を入れることができ、ちょうど良いと思われます。目標とする表示イメージはこんな↓感じです。

JPEG再考

年末に3つのデコーダの記事を書いて、3つのデコーダを担当するタスクは同時に走ることはないので、スタックを含むRAM空間を共有できることを説明しました。この記事を書いて、自分でももう一度確認してみようと思い立った事があります。それが、アルバム画像の表示についてです。MP3再生では、WMPがダウンロードしてくれた画像データを表示していますが、昨年の実装の際にはJPEG画像の表示にはメモリが必要となりそうなので、これを断念していったんBMPに変換したものを表示する仕様としていました。しかし、良く考えてみれば楽曲の再生中に画像表示が必要なわけではなく、アルバム画像を表示してから再生を開始しているので、デコーダが使うメモリ領域は画像表示に利用できます。つまり、JPEG展開に要するメモリ量がMP3再生に要するメモリ量と大差なければ実装可能なわけです。

さっそくJPEG展開に必要なメモリ量を確認してみました。今回は、libjpegの最新版であるrelease 7を使うことにします。まずはドキュメントの確認です。libjpeg.txtにはMemory usageという節があり、それによるとまずは静的におよそ24Kバイトを必要とし、それに加えて画像の幅に比例したバッファ領域を必要とするようです。おぉ、24KBというサイズは、ほぼMP3のデコーダが必要とするメモリ領域と同等です。あとは画像の幅に比例したバッファ領域ですが、アルバム画像は幅80ピクセル程度ですからこれも大して喰わないはずです。これならなんとかなりそうじゃないですか。

libjpeg.txtのメモリ必要量の記述はv6bの頃の数字のようですし、画像幅に応じたメモリ量を確認するためにも、実際に使ってみて消費されるメモリ量を確認してみました。まずはLinux上での確認です。djpegのソースとメモリ管理するjmemnobs.cにちょっとprintf追加してみました。



矢印の左側の数字が追加獲得したメモリ量、右側は合計量です。jpeg_start_decompressで、画像幅に応じた領域まで割り当てられているようですが、アルバム画像ファイル程度の大きさなら30KBもあれば充分なようです。それじゃ、ちょっと画像ファイルを大きくしてみましょう。



今度↑はVGA(640x480)のファイルですが、確かにメモリ使用量増えてます。さすがに64KBのうちの半分以上を使われるのはツライ。せめて半分の32KB以下に抑えたいところです。そこで....



LCDはQVGAですのでVGAの画像はそのままでは表示できません。そこで、展開時にスケーリングして半分にしています。縮小することでメモリ消費量も抑えられるのですが、アルバム画像の時と同量のメモリしか割り当てられていません。この理由については調べていませんが、元のJPEG画像のカラーモデルに違いがあったりするのかもしれません。それじゃ、さらに大きい元画像を試してみましょう。



djpegで指定できるスケーリングはn/8となっていますので、この大きさになると1/8にしないとLCDに収まりません。結果、表示画像サイズは200x150となり、QVGAを下回ります。その影響もあってか、メモリ使用量も減ってます。

大雑把に見て30KB～32KBのメモリ・プールを用意しておけば、アルバム画像だけでなく、デジカメ画像の表示もできそうです。こうなったら、簡易フォトフレーム機能も追加するしかないですね。

メモリ増設

明けましておめでとうございます。

今年も引き続きARMマイコン中心でやっていくつもりです。年末購入したSTM-32ボードは、せめて通電くらいしなければと思いつつもまだ手つかずの状態です。開発環境も整えなければならないのですが、まずはPC環境からなんとかしたいと以前から思っていました。

わが愛機はLet's note CF-T5　1GBメモリなのですが、いつもはFedora 5(これまた古い!!)のVMを走らせてMakeする環境としています。しかし同時にブラウザとPDFでデータシートを開いたいたりしていると、かなりスワップ頻度が高くなって操作感が低下することしばしば。近頃のネットブックはディスク容量も豊富だし、WLANも11n対応していたりとなかなかに魅力的なので試してみようかとも思いましたが、やはり画面が狭いのは不自由だし、結局10万円くらいのノートが必要な印象です。もちろんLet'sの軽さに慣れてしまっているので、重量は1.2kg程度の必要あり。新型Let'sに更新するだけの予算(というより収入か?)はないし。。。



やはり、またしばらく様子見かと思っていたのですが、エレコムの1GB増設メモリが3,000円しないで買えることを知り、さっそく購入。本体の512MBと合わせて 1.5GBメモリ搭載となりました。メーカの動作保証は最大1GBメモリなのですが、いちおう問題なく動いているようです。一度だけ、なぜかSDカードが認識できなくなりましたが、Windows XPを再起動したら問題消えました。スワップも明らかに少なくなったので、かなり操作性が向上した印象を受けます。これで、少なくともあと半年から1年は "しのぐ" ことにしましょう。