« FPGAを使ったフォトフレーム制作計画始動 | トップページ | FPGAの言語の習得で最初からつまづく »

2010年3月11日 (木)

FPGAフォトフレーム開発のロードマップ

 例年この時期は忙しい。所属している団体の全国集会(といっても大阪、名古屋だけだが)の幹事の仕事に、確定申告、それに新しいセミナーの講師資料の準備、以前から続けている老人ホームの慰問演奏会、恒例のスキー行などと、数えてみたら2月から3月にかけて7つ以上の行事が重なった。イベントというのは何故か平均的には起きてくれないものらしい。

 そんなことで電子工作にかけられるまとまった時間がとれない。リニアPCMプレーヤーのWindowsMediaPlayer生成WAVファイルの不具合の報告もつれない返事をしてしまった。ChaNさんのところは早速対応されたようなので、いずれはこちらも直さないといけないが(何しろChaNさんのFileSystemを使わせて貰っている)、必須フォーマットデータの間にオプションデータを突っ込んで来るWMPの横着な仕様に対応するのは、正直言ってどうも気が重い。

A3112747

 このブログのアップもほぼ20日ぶりである。このあいだはFPGAでビデオインターフェースを作ると勢い込んでいたが、現実に基板を揃え、実際のブロックダイヤグラムを細かく考え出すと、とてもじゃないが、そう簡単なことでないことが見えてきた。

 だいいち、FPGAに書き込むソース言語について全く経験がない(この前のLEDチカチカは丸写し)。Verilog HDLとVHDLという2つがあることくらいは知っているが、実際にコーディングしたことがない。これだけでも十分乱暴な話である。

 それに、ビデオインターフェースのブロックダイアグラムの各部の機能についておおよその理解はしているものの、これを統合してひとつのインターフェースにするのに何から手をつけていけば良いのか全く見当がつかない。

 BeagleBoardのときは、もともとソースをいじるつもりがなく、パッケージをネットから落としてそのままインストールし、それだけで満足だった。しかし、FPGAではこれをやりたくない。実は、LANによる商用電源の制御(Mega168インターネット開通3/17/08記事)も、最初はTCP/IPをソースレベルでハッキングと張り切っていたのだが、貰ったソースコードが余りにも簡単に動いてしまってそれきりになっている。

 FPGAくらいは徹底的にスクラッチから自分のやりたいことを作って行こう。苦労しないと技術は身につかない。そのためにはやはり簡単なアプリケーションを自分で作って動かしていくのが一番だ。

オペアンプ問題は動作電圧不足というオチ(2/22/10)
 俗事に時間をとられ、頭の中はFPGAに占領され、まとまった電子工作が出来ない日が続いているが、困ったことに何か手を動かしていないと気分が落ち着かない状態になっている。少しでも手が空けば、手は自然にブレッドボードに向かい、細々とした問題解決に励んでいた。

 直前の記事にあげたSDカードプレーヤーのオペアンプの問題は、ブログのアップ直後、またkugaさんのコメントで一気に解決した。何と、オペアンプには最小動作電圧というのがあるというのだ。

  データシートは穴があくまで見よといわれているが、オペアンプのデータシートはアナログの素人にとっては、殆ど理解不能である。最大定格と推奨動作条件くらいは見ていたが、最小動作電圧というのがあるとは知らなかった。慌ててデータシートを確かめる。

  これまでに買ったオペアンプは、LM358、NJM4580DD、NJM2114DD、それにNJM5532の4種類である。最小動作電圧はちゃんとデータシートに出ていた。LM358は単電源3V、4580は±2V。それに対して2114と5532は±3Vである。何、4580だって定格外ではないか。

 ブレッドボードにこのまえの秋月FGのテスト電源に使った±5V電源を組み込み、それぞれ動かしてみる。はいはい、今まで動かなかった2114も5532も全く問題なく良い音になった。オペアンプのみなさん大変失礼しました。

 PEN^2さんのコメントで、同相入力電圧範囲というのがあるのも知った。1倍の反転増幅回路なら正常に動くかもという助言で早速試してみたが(入力はDACなのでVccの1/2が中点)、残念ながら3.3Vの単電源では無理なようで、ちゃんとした音にはならなかった。

 それはともかく、オペアンプによる音の差は明確だ。値段の差がはっきりわかる。358はまずピリピリと小さなノイズが入ってちょっと問題外だが、残りの3つの差も何回か同じソースを聞いていると違いが見えてくる。4580の音に較べて、2114は弦がなめらかで、艶(つや)やかな音に変わる。5532は分厚い重厚な音になる。面白い。オーディオマニアがオペアンプにこだわるわけが分かるような気がする。

A3112743

 それにしても現用のNJM4580が定格外(±2Vのところを0~3V)だったことは意外だった。しかし定格外でも全く問題なく良い音を出してくれている。まあ、Mega328の定格外のクロックといい、今度のプレーヤーは針の穴を通すような実装だったというわけだ。危ない、危ない。

FPGAフォトフレーム計画のロードマップを作る(3/10/10)
 何を練習問題にするのかまだ思案中だが、本題のFPGAビデオインターフェースのアプローチは続けている。何事に付けても計画を立てておくのとそうでないのではあとの苦労が全然違う。今度のプロジェクトは沢山の要素で構成される。ひとつづつ検討して行く。

 まず、プロセッサーはこのあいだRTCを動かした雑誌付録基板、STM32F103(CQSTARM)を想定する。この石のフラッシュサイズは128KBなので、もし、JPEGデコードライブラリが入らなければ、さらにもうひとつの付録基板LPC2388がある。こいつはフラッシュが512KBあるので十分だろう。しかし、これはSDカードが実装されていないので追加する必要がある。

 画像データをプロセッサーからFPGAへ送るインターフェースは、静止画ならSPIで十分だと思う。ユーザーインタフェースは最初はUARTにし、その後はLCDとタクトスイッチで良いだろう。最終アプリケーションはフォトフレームなので複雑な操作はいらない。

 問題は、ビデオバッファーである。現在持っているFPGA(Xlinx XC3ES250)のブロックRAMはおよそ200Kビットだが、今あるTFT液晶の320×240の解像度(QVGA)の1画面のピクセルサイズ(76.8Kビット)で割ると、3ビットすらとれない。これでは16色も出せない。フォトフレームにするには最低でも256色、欲を言えば6万色(16ビット)は欲しい。

 ということで、必然的に外部RAMをつけることになる。外付けRAMは当初から、しかけの難しい(というより素人には無理な)DRAMではなく、SRAMを考えている。我々アマチュアの心強い味方、秋月電子には、SRAMをいつも何種類か揃えてくれている。

 おや、狙っていたアクセス速度10nsの高速SRAMは売り切れだ。55nsのものしかない。55nsでも、8ビットパラレルでアクセスすれば、QVGA(320×240)の16ビットカラーがNTSC程度の動画(フレームレート30fps)で楽に描画できるが、もうちょっと上のVGA(640×480)となると破綻する(55nsのフレーム単位の転送速度606KB、16ビットカラーVGAのフ レームデータ量614KB)。

4mbitsram_2

 もちろん、VGAも動画も今やるわけではない。しかし、折角ビデオインターフェースを作るなら、このあたりまで視野に入れておきたい。秋月のサイトによれば、高速SRAMの次の入荷は4月上旬とある。それまで待つことにする。

 動画ということになると、当研究所には昔々買ったQCAMという目玉小僧の形をしたVGAカメラがある。30万画素でパラレルポートにつないでいた。これが動かせなくても、最近はCCDカメラも安価だ。まあ、まだ相当先の話になるが、カメラをつけて録画というところまで考えると、余裕を持たせたVRAMにしておきたいところだ。このあたりはそうそう簡単には作れない。

 今のPCならUSBを使った安価なカメラを使って録画するところまで何の苦労もせず出来ると思うが、マイコンではまだ結構難しい。アマチュアの電子工作でも最高レベルに属する。段々気持ちが高ぶってやる気が出てきた。

 例によって、逐次開発方式で開発ステップを考える。

1.    FPGAの言語の習得
VerilogHDLか、VHDLかを早く決めないといけないが、とりあえず7セグLEDあたりをUARTからコントロールするテストアプリケーションを作る。

2.    FPGAとSRAMの接続、非同期アクセステスト

SRAMをFPGA基板に外付けし、FPGAでSRAMをアクセスする。UARTからメモリアクセスが目標(同一データ多量書き込み、読み出しがテストターゲット)

3.    FPGAのビデオインターフェースの出力、カラーバーなど
FPGA内のPLLモジュールでクロックを作りVSYNC、HSYNC信号を生成する。カラーバーを画面に出すことがゴール。

4.    FPGA基板へのDAC制作、またはDACチップの接続

ラダー抵抗式DACで、最初16色程度のカラーを出し、最終的には秋月で売っているビデオDAC、BU3616を使ってVRAMデータをアナログRGBデータに変換する。

5.    FPGAとARMとのインターフェース設計

SPIモジュールの開発。ARMからデータの転送。

6.    ARMのSDカードアクセス
ファイルシステムの導入。UARTによる制御。ChaNさんのFATFSを使わせて貰おう。

7.    SDカード内のBMPデータの描画
これがまず最初のゴール。とりあえずのフォトフレームが完成。

8.    JPEGデコードライブラリの導入

9.    フォトフレームの実装
液晶ケースに基板固定。スタンド、外枠など。

10.    将来構想として、動画再生、カメラの導入、録画など

 初期のステップは独立して作業可能。2と4 が難しそう。3は多数の参考情報あり。6はFPGAでなくARMの開発。7がとりあえずの完成形。9を最終ゴールとする。

 ロードマップが出来た。久しぶりにXlinxの開発環境を立ち上げて動くことを確かめる。雑誌のLEDチカチカのテストコードはVHDLだった。自分の好みから言えば、ステートメントが少なくて済むVerilogHDLにしたいのだが、手本にしようと思うUARTのコードもVHDLだし、どうしたものか迷う。

  このあたりは、電子工作でも一番心楽しい時である。ちょうど旅行の前にどこに行くかあれこれプランを立てて夢を膨らませるのに似ている。

|

« FPGAを使ったフォトフレーム制作計画始動 | トップページ | FPGAの言語の習得で最初からつまづく »

電子工作」カテゴリの記事

FPGA」カテゴリの記事

コメント

shuji009@愛読者さん、お久しぶりです。
>申し訳無かったです。
いえ、とんでもない。忙しいのはこちらの事情で、あやまられることは何もありません。WMPなどのMS製品はなるべく使わないようにしているもので、つい邪険にしてしまいました。申し訳ありません。

>ところで、http://ameblo.jp/etsuo-okuda/entry-10477341542.html

おお、このサイトは専門家のページでレベルが高いですね。1ビットDACの理論は難しすぎて私も理解できません。いずれにしても原波形のオーバーサンプリングが前提なのでリニアPCMの1サンプリングデータからPWMでアナログ化することではないと思います。オーバーサンプリングはDSPなどの世界ですから、マイコンには無理かと。

投稿: がた老 | 2010年3月13日 (土) 11時57分

ロードマップ・・・良いですね。
私ももう少し技術力がアップしたら、大きな目標を
決めてスクラッチ&ビルドで行きたいものです。

>リニアPCMプレーヤーのWindowsMediaPlayer生成WAVファイルの不具合の報告もつれない返事

事情も知らず、私こそずけずけと書いてしまい、申し訳無かったです。

実は、がた老さんのプレーヤの大改造を行っている時に、
ChaNさんの新プレーヤが出ました。私がやりたかった
事をパワーアップしたような感じでやられおられたので
今月上旬は、浮気をしていました(汗;)。
お陰で、元のデータが固定フォントなものをプロポーシ
ョナルにすることがTFTでもできました。

ところで、
http://ameblo.jp/etsuo-okuda/entry-10477341542.html
の前後で、DACについて書かれています。1ビット
ストリームで、44.1k×2^16Hzが必要ないことを。

投稿: shuji009@愛読者 | 2010年3月13日 (土) 00時16分

コメントを書く



(ウェブ上には掲載しません)


コメントは記事投稿者が公開するまで表示されません。



トラックバック


この記事へのトラックバック一覧です: FPGAフォトフレーム開発のロードマップ:

« FPGAを使ったフォトフレーム制作計画始動 | トップページ | FPGAの言語の習得で最初からつまづく »