フォトフレーム： 画像らしいものが出てあともう一息

デジタル液晶も画面が真っ暗(9/30/2010)
　どうも何かに呪われている。フォトフレームのHDLソースのロジック追加は、擬似コードレベルからのコーディングは特に問題なく完成し、論理合成やコンフィギュレーションも順調に終わったので、通電したのだが、画面には何の反応もない。オシロで見る限り同期周波数も、色信号も規定どおりに出ている。しかし画面はアナログ液晶のときと同じように真っ暗なままである。

　いったい何が悪いのだ。手探りで作ったPLLは見事に33Mhzのクロックを逓倍して62Mhz（正確には61.875Mhz)のマスタークロックを作っている。デジタル液晶のピクセルクロック31Mhzも正確に出ている(実際は30.938Mhzだが）。同期信号も所定どおりの間隔で出ていることをオシロで確認した。

　今度の液晶はピクセルクロックと、色信号の出る間のDATAイネーブル信号を要求しているが、これも想定どおりちゃんと入っている。それなのに、どうして画面に何もでてこないのか。SRAMにデータを書き込まないで描画すると、メモリのランダムな値でちょうど砂をまいたような画面になるはずなのだが、全く暗いままだ。このままでは何の手がかりがない。何処から手をつけてよいのかわからない。やっぱりカラーバーから確かめていくしかないか。

カラーバーも真っ暗(10/2/2010)
　SRAMからの描画をあきらめて、わかりやすいカラーバーを出してみることにする。急いでコーディングし、試してみた。しかし、こいつも駄目である。ところが、電源を切ろうとして一瞬カラーバーが出た。ありゃあ、前と同じだ。過渡的なときには色が出るが、一旦電源を入れてしまうと出ない。前のアナログ液晶と同じである。良く画面を見てみるとカラーバーがうっすらと出ているのが見えている。しかし、そのうちもっと暗くなって、画面は視認できなくなる。

　何が原因なのだろう。デジタル液晶なので色信号の電圧はLVTTLだ。オシロにもきれいな3.3Vパルスが出ている。DATAイネーブルを疑ったが、ここは正論理で間違いなく正しいピンに所定の描画サイクルで出ている。このデジタル液晶はピクセルドット周波数を要求する。この立ち上がりと立下りのどちらでRGBデータを拾うのかはデータシートに明記されていない。まさかと思うが両方やってみる。もちろん状態に変化はない。

　電源を切ったときとか、入れた瞬間に鮮やかな色が出て、定常になると色が消えるというのが不可解だ。何かの条件が色を出すのを止めている感じだが、この条件が見えない。
前のアナログのときと同じような状態というのが気にかかる。

遂に鮮やかなカラーバーが出た。原因は意外なところ(10/3/2010)
　ここ数日は暗い日々だった。苦労して作ったデジタル液晶が、このあいだのアナログ液晶と同じように、まともな明るさにならない。ピクセルクロックもデータイネーブルも規定どおり、水平・垂直同期も正確に出ている。色信号もオシロで見る限り正常。しかし、画面は暗いままである。前と同じように電源投入直後は少し明るいが次第に暗くなる。この次第に暗くなるというのが何ともおかしい。

　原因がわからない。液晶パネルのドット描画のロジックが良く見えていないので対策のしようがない。ピクセルクロックの立下りでデータを拾う仕様で、データが逆に出ていたら真っ暗になるのかとか妄想してみるがピクセルデータは期間中、同じ値（のはず）であり、そんなわけはない。同期の裏側で描画しているから？　そんなことあるわけない。

　アナログの場合は、色信号の電位差で明るさが決まるが、デジタルは各ビットが1であれば問題なく何らかの色は出るはずである。電源を疑ってケースを開け、それぞれの接続を確かめ、パネルに近いところで波形や電圧を見る。電源は少しパルスが乗っているが、3.05Vと正常範囲内だ。しかし、レギュレーターが、触った時火傷しそうに熱いのに気が付いた。

　一段目のレギュレーターは液晶パネルのバックライト用の12Vから5Vにするため7V分を熱にしているからだが、ちょっと熱すぎる。熱抵抗を計算してみると最初のTA48M05(500mA)では125°C/Wでヒートシンクなしでは少し苦しい。大きめのレギュレーターTA4805S(1A、62.5°C/W)に換えてみることにする。

　換装して電源を入れる。お、ほんの少し画面が明るくなったように見える。しかし大勢に影響はない。解決策をもとめてウェブを探していたら他社の液晶パネルのデータシートが見つかった。そこにはロジック部の消費電流が出ている。そういえば、この液晶のデータシートには、ロジック部の消費電流が記号でTBDとあるだけで実数値が出ていない。ウェブの消費電流の方を見て驚いた。5Vで120mA、3.3Vでは160mAも流れると書いてある。

　ロジック部の消費電流がこんなに大きいとは思っていなかった（100mA以下とみていた）。3.3Vのレギュレーターは例のLPCMプレーヤーに入れてビートが出たため使っていないXC6202である（8ヶも余っている）。　150mAとれるので余裕と思っていたが足りない可能性がある。これはいけない。この液晶パネルの実際の消費電流を測ってみた。

　結果は125mAで、XC6202の定格内だ。こちらのレギュレーターは熱もそうない。電圧もちゃんと3.05Vでている。しかし、これまでの状況から、どうも電源が臭い。調べるところがなくなって、だめもとで別の3.3V電源アダプターでロジック部を供給することにしてみた。

　何と、何と、これで液晶モニターに鮮やかな色が戻ったのである。ええー、オシロで測った今までの電源電圧は一体なんだったのか。きれいな3原色が表示される。夢にまで見た鮮やかさである。

　また、XC6202が悪者になってしまった。こいつが力不足で120mAを消費するロジック部を正常に駆動できなかったのだ。定格内なのにおかしいが、これが原因であることは間違いない。急いで、500mAとれるTA48M33にしてみる。鮮やかな色が出た。結局、電源容量不足という単純な原因が画面が明るくならない原因だった（あとでデータシートを良く見たら電源の最小電圧は3.135Vだった。たった0.085Vの差で真っ暗になるとは）。わかってしまえば何でもないが、ここにたどり着くまでえらい時間がかかった。

SRAMを読んだ画面が出た！(10/6/2010)
　液晶に色が戻ったので、ロジックを更にいじって、カラーバーを上段に、コメントアウトしてあったSRAMの内容を表示するルーチンを生き返らせて、下段に出すレイアウトにする。出ました、出ました。まだSPIが動いていないのでデータは更新できないが、SRAMのランダムなデータを拾って、ちょうど大理石模様のようなこまかい画像が表示された。

　今までは、縦縞ばかりだった（1ライン中のデータが同じままのとき）が、これはSRAMを順調にラインを越えてアクセスしていることを意味する。いやあ、嬉しい。これまでの暗い気持ちがいっぺんに吹き飛ぶ。これで画像表示まで大きく近づいた。しかしそれにしても長い道のりだった。この爽快感はいつ経験してもこたえられない。ランナーがマラソンにはまるのと同じである。苦しみが大きければ大きいほど、喜びが倍増する。

　いよいよ次は実際の画像の確認である。SPIから送られた画像データが表示出来れば、フォトフレームの第7ステップ（一期完成ステージ）は完了する。STM32プロセッサーのBMPデータの抽出コードはまだ出来ていないので、とりあえずSPIの動作を確認するため、UARTでSRAMを確認できるようにする。

　データ読み込み中は画面を止めることにしたので、SPIの動作を優先しSPIデータが入る(チップセレクト）とただちに読み出しを停止するように変更する。UARTは別のSRAMアドレスを用意し、画面の垂直ブランクの時だけSRAMをアクセス出来るよう、assign文で読み込みアドレスの切り替えを2段にする。

　VerilogHDLの変更が終わった。わくわくしながら電源ON。しかし、データを送れば画面はかわるものの一色でぬりつぶされ、UARTからはデタラメな文字しか出てこない。かえって退歩してしまった（最初はSRAMを読んでいる証拠の砂模様画像だった）。まあ、これからが勝負である。ひとつづつつぶしていこう。

やっとのことで画像らしいものが出た。あと一息(10/8/10)
　FPGAのソースコード開発をひとまず横に置き、画像ファイルを送るSTM32側の開発を再開した。BMPファイルを読み、ヘッダー情報からRGBデータだけを抽出して、FPGAにSPIで送るロジックの開発だ。

　24ビットのRGBデータを12ビットRGBに抜き出すロジックは、はじめSDカードからの読み込みの単位で処理を考え、読み込みブロックをまたがるRGBの分離に頭を捻っていたが（RGBは3バイトで1ピクセルを構成するので、端数が出る可能性がある）、これは発想の転換でいっぺんに解決した。いや気分が良い。

　つまりプログラムはRGBをとりだす処理の方をメインループにし、ブロックサイズを越える時点で、次のSDカードを読む処理を入れてデータブロックを更新すればよい。今まであれこれ悩んでいた継ぎ目でのロジックはこの方法では考える必要がない。一気に解決した。このあたりがソフトウエア開発の醍醐味だろう。幾何でいう補助線一本で証明が出来たときの快感と同じである。

　機嫌よくコーディングを終えて、BMPファイルを用意する。ペイントプログラムはどうもピクセル単位にキャンバスを作れないようなので、一旦ペイントで適当に画像を作り、デジカメについていたおまけソフトで640×480のピクセル24ビットBMPファイルに切り出す。

　さあ、これで画像ファイルも出来た。PCでSDカードに移し、STM32のSDカードスロットに入れて、FPGAに送り込む。さあどうだ、FPGAは、その後UARTを止めたりして前の状態に戻しSRAMが読める状態になっているはずだ。あれえ、全く変わらない。

　SPIは読んでいるようだが（LEDが点滅）、SRAMにちゃんと書いていないようだ。こうなってくると、もうオシロは役に立たない。ロジックアナライザーの出番である。FPGA基板のコネクターに例のスタブ（0.5mm銅線）をたて下位のSRAMアドレスやいくつかの制御線にプローブをあて慎重に解析を開始した。

　今度のソースはこれまでになく複雑になっている。画像を出すロジックは、同期信号を作成するモジュール、色信号を所定のドットに乗せるロジック、12ビット色信号を16ビットSRAMデータを読みながら作るロジックの3段が並行し、これにSRAMを読むモジュールと計4つのプロセスが同時に走る。

　ロジアナの威力はやはりすごい。次から次に不具合が見つかっていく。しかし現在のロジアナの限界が見えてきて解析が順調に進まなくなった。今使っているロジアナは、2年前に買ったオプティマイズの100Mhz、32CHの安いけれどなかなかの性能で、これまで重宝してきた。

　しかし、今のFPGAのマスタークロックは、62Mhzでピクセルクロックは31Mhzである。ピクセルクロックくらいまでは見えるが、60Mhz台のSRAMアクセスのタイミングを正確にとることは難しい。実際に、このタイミングをはずしているのかロジアナが捕まえられなかったのかがわからないのでは解析しようがない。うーむ、「すん」さんがこのあいだ買ったという200Mhz台のロジアナが欲しいな。少し高いけど(￥38,800)。

　それはともかく、とりあえずは先に進まなければならない。コードを少し修正しては、ロジアナでタイミングを調べ、さらにおかしそうなところを修正してタイミングチャートを調べる。RGBをぬきだすところと、画面に出すところのタイミングが少しづつ合ってきてSRAMのアクセスが順調になってきた。ドット単位にアドレスが増えていく。

しかし、SPIで入れたデータがどうしても順調にSRAMに書き込まれない。出来る時と出来ない時がある。散々調べた結果、原因は、やっぱりFPGAのコードではなく外であることがわかった。やれやれ。

　STM32のCS（チップセレクト）が間違っていたのである。データを送る以前に正しくCSがセットされていなかった。これを直すと画面のSRAM初期画面と明らかに異なる画面が出た。ちょうど水平同期が乱れた時の横線である。これだ。SRAMに新しくデータが送られた証拠である。画像のサイズが狂っているので横流れになっているが、これを補正していけば画像になるはずである。

　今度のデジタル液晶は、800×480のWVGAなので汎用性を持たせるため、両側の80ドットを黒くして画面を640×480にしている。もしかしたらSRAMアクセスは黒いところも動き、画像を縦の長さを無視して展開しているのではないか。ソースコードをいじって640ドットだけSRAMを読むようにする。

　出た。元の画に較べれば、色は殆ど出ていないし、表示が斜めに傾き、画像がちょうど裏になっている（スキャン方向を間違えている）が、明らかにBMPファイルの画像の絵である。フォトフレームを志して半年、はじめて出た記念すべき画像だ。

　いやいやそれにしても普段何気なく使っている映像機器の画面表示の裏にはとんでもなく複雑なロジックが動いていることを実感する。スクラッチから静止画をひとつ出すのにこんなに苦労するとは正直言って始める前には想像もしていなかった。

　ここまでくればもうあと一息である。ハードや画面描画には問題なくなったので、あとは中のRGBデータのハンドリングを正しくしてやれば、ちゃんとした映像になる見通しがついた。デジタルフォトフレームのプロジェクトもそろそろ大詰めが近い。