« 2010年9月5日 - 2010年9月11日 | トップページ | 2010年10月10日 - 2010年10月16日 »

2010年9月26日 - 2010年10月2日の1件の記事

2010年9月28日 (火)

フォトフレーム: デジタル液晶インターフェース実装

 完成を目の前にしてプロジェクトの進行が足踏み状態である。遅れの原因は今度は仕事ではなく、久しぶりの海外旅行のためである。海外と言っても、お隣の台湾で、それも台北近辺のみ。家族で3日間中華料理をいやというほど堪能してきた。お陰で体重が2キロも増えて、食事制限中である。

Photo

 家族と一緒だったのと、日本と大差がないと聞いた台北の電脳街には結局足を伸ばさなかった。ただ町を歩いていて気が付いたのは、LED電光掲示板がやたらに大きくて、どこにでもあることである。お寺のお札を売るところにも大きな電光表示板があるのには驚いた。

Photo_2

 それはともかくフォトフレームプロジェクトである。この間はもう完成だと浮かれていたが、調べてみると、まだまだやることが沢山あることがわかって頭を抱えていた。16ビットアクセスが出来るようになったが、液晶とFPGAをつなぐコネクター周りはまだ全く実装ができていない。今度はデジタルなので、20本以上の配線が必要である。この工作だけでも結構大変だ。

 それに、現在のSRAMでは(512KB)、VGAでは16ビットカラー(614KB)でなく、12ビットカラー(RGB444、4096色、460KB)しか出せない。SRAMからアクセスした2バイトのデータを4ビットづつRGBに展開していくロジックも必要である。QVGAデータをVGAに展開することも出来るが、ピクセルを合成するこちらのロジックはもっと大変である。

16ビットデータからRGB12ビットを取り出す(9/11/10)
 元のBMPの24ビットRGBファイルデータを、SPI8ビット、SRAM16ビットを経由して、ピクセルクロック単位に、4ビットづつのRGBデータ12ビットを切り出すロジックを少しまともに調べ始めた。

 24ビットBMPデータからSPIで送り出すところは各RGB8ビットから上位4ビットを取り出し、8ビットバッファーが埋まれば次々にSPIに送り出すだけで良い。受け取った側は何も知らずにただSRAMに書き出す。ここも問題ない。やっかいなところは、SRAMから読み出した16ビットデータを12ビットづつRGBに展開するところである。

 ピクセルクロックが早くなっているので、ここの余裕は全くない。うーむ、やっぱりマスタークロックを少なくとも2倍にしないと、このあたりの処理は無理なようだ。あれこれ考えた末、動くがどうかは自信がないが、出来たのは次のロジックである。

・SRAMからの16ビットデータを、一旦、バッファーに読み出し、このバッファーを2つ用意する。

・ステートマシンを4 段作り、ステート毎にRGB4ビット、12ビットを取り出し、残った
データを消さないよう、バッファーを換えて次のSRAMアドレスからデータを読み出す。

・4段終わると、最初のアライメントに戻るので(12×4=16×3)、最初のステートに戻る。

・以上の処理を行うサブモジュールを、描画プロセスとは独立して並行に走らせ、描画プロセスは、このサブモジュールが作った4ビットRGBを次々に液晶データラインに移すだけとする。

・サブモジュールの起動/終了は、画面1単位、つまり垂直同期のあとの最初の水平同期がトリガーとなる。終了は、SRAM最終アドレス。

FIFOが必要になった(9/13/10)
 ピクセルクロックとマスタークロックの差がなくなったので、新たな問題が発生した。プロセッサーからSPIでデータを受けるところにFIFOバッファーが必要になったのである。描画の最中はすべてSRAMのRead処理に占められ、Writeは出来ない。

 前は、1ピクセルクロックの間にマスタークロックは6回以上繰り返されるので、描画中も隙間を縫ってSRAM書き込み(2クロック)が入れたが、今度は空きがないのでSRAM書き込みは、水平ブランキングや垂直ブランキングの間に行わねばならない。

 640ピクセル描画するのに32ns×640ピクセル、20.5μsの間にSPIがデータを送ってきてもデータが書き潰されないようにするには、SPIが9Mhzで動いているので、1バイト0.88μsとして、24バイト以上のバッファーが計算上必要である。

 しかも、読み込みの間に万が一書き込みのリクエストが通ると、2クロック待たされ、ここで描画がおかしくなる。1ライン読み込みの途中では書き込みを止めるなどの措置をしないといけない。

 FIFOのコーディングはそう難しくないが、テストの方法が悩ましい。適当な画像ファイルを送っておいて、まず描画ルーチンを完成させ、そのあと描画中にファイルを送って様子をみるしかない。単独のテストは出来ない。

 ソースコードにかなり手を入れる必要がでてきた。旅行の準備も必要だ。集中して時間がとれない。とりあえずispLEVERの新しいプロジェクトを起こし、ソースをそっくりコピーして新しい機能を入れていく。まず、LatticeのIPexpressが提供するPLLモジュールでマスタークロック33Mhzを15/8倍の61.875Mhzにする(逓倍は奇数ができるが、分周ができないようだ)。これを半分にすれば、所定のピクセルクロック31Mhzに殆ど同じ(30.9375Mhz)になる勘定だ。

 このソースを作ったところで旅行の期日が迫ってきた。2匹の猫を預かってもらうブリーダーとの打ち合わせ、旅行用品の買い物、成田に前泊するホテルの確認など、電子工作どころでなくなった。

デジタル液晶のインターフェースを実装する(9/22/10)
 台湾から帰る前日に台風11号が台湾を直撃した。ホテルではNHKのBSが一部視聴できたので日本のニュースに不自由はしなかったが、台風は日本をはずれたのでニュースになっていない。台風情報は現地の放送を見るしかない。しかし言葉は全く分からないが漢字の字幕が出るし、台風の二ユースは似たようなものなので、これは面白かった。

 まず、嵐の中の中継が20年前の日本と同じ、新人アナウンサーが風に吹き飛ばされそうになりながら悲壮な顔でマイクに向かって叫んでいる。横ではオチョコになった傘を必死に支える通行人の背中のヤッケには○○新聞(TV局名)というロゴがすけて見えて、やらせであることが見え見え。家族で腹を抱えて笑っていた。

 帰りの飛行機が心配だったが、幸い半日遅れただけで台北の桃園飛行場を立つことが出来た。しかし離陸して5分もしない頃、乱気流に飛び込んで激しく降下し乗客が大きな悲鳴をあげる。台風が去ったといっても油断ができない。しかし、その後は平穏に成田に戻ることができた。いやあ怖かった。

 台湾も暑かったが、帰ってきた日本も相変わらずの暑さだ。旅行の後片付けも落ち着いて久しぶりにオーディオルームの電子工作机に戻った。液晶インターフェースの実装を開始した。

A9283246

 例の画像表示回路特集のトラ技(2009年11月号)の回路図を参考にする。クロストークや不要電波の放射を抑えるため、デジタル信号をなまらせるダンピング抵抗を入れるので思ったより複雑になる。それに液晶のフレキパネルの変換基板から直接FPGAにケーブルを出さず、ピン数を減らしたコネクターで中継したので、ハンダ付け箇所が2倍になり思ったより時間がかかった。

 やっとのことで配線が全て終わり、液晶パネルからフラットケーブルが出てFPGA基板につながった。アートワークのメモと一緒に記念撮影する。さて、ハードはこれで全部できあがった。次はSTM32プロセッサーのBMPファイルからのRGBデータ切り出しと、これまで擬似コードのレベルで止まっているVerilogHDLのコーディングである。何とか、個別テストを積み上げて開発ができないか頭を捻る。

想定されるテストの手順は、

・水平・垂直同期の確認(FPGAからの出力をオシロで確認)

・12ビットRGBデータの確認(描画を止めて、UARTのバイナリー端末で確認)

・SRAM読み出しの確認(ロジアナでSRAMアクセスをピックアップ)

・テスト用画像のBMP化(これは実際に画を出して確認)

・画像送出のテスト(同上)

でめでたくBMPファイルの画像が出るはずなのだが(第7ステップの完成)。

A9283241

木を見て森を見ずの諺どおりの勘違い(9/26/10)
 いよいよ、VerilogHDLソースを書き始めようというところで、重大な思い違いを見つけてすっかり落ち込んだ。旅行に出かける前に、SPIにはFIFOがいると書いていたが、もっと基本的なところに間違いがあった。あるとき(これまた風呂に入っているとき)、少しくらいのバッファーでは画像を表示し(読み)ながらデータを書くことができないことに気付き愕然とする。

 当初は、水平・垂直ブランキングの間にデータを書き込むつもりだったが、水平ブランキングと1ライン描画の時間の比は、WVGAで1ライン1000ドットとしてVGAの640ドットで2:1、垂直ブランクは9H(ライン)だが、縦は480本もあるのでFIFOバッファーは全体画像の半分近くなければ、SPIのデータはとりこぼしてしまう。

 やれやれ、以前のXbeeのUARTのバッファーのときと同じだ。ピクセルクロックの少なくとも2倍のSRAMアクセスのスピードがなければ、そもそも描画中にデータを書き込むことは不可能なことに早く気が付くべきだった。今はSRAMアクセスは2クロックを前提にしているのでピクセルクロックと同じだ。木を見て森を見ずという諺の通りである。

 画面を乱さずに画像を換えることは、この仕様では無理である。フォトフレームとして見栄えは落ちるが、一旦画像を止めて表示し直すという方法にするしかない。まあ画像がでたら、クロックを更に上げて、描画中にもSRAM書き込みが出来るような改修に挑戦してみよう(SRAMをもうひとつ付ける手もある)。画像を出すことが先だ。

| | コメント (2) | トラックバック (0)

« 2010年9月5日 - 2010年9月11日 | トップページ | 2010年10月10日 - 2010年10月16日 »