« 2010年8月 | トップページ | 2010年10月 »

2010年9月の2件の記事

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月11日 (土)

フォトフレーム: デジタル液晶を動かす準備

 前回のブログから2週間以上日が空いてしまった。珍しく連続して仕事があり電子工作に時間がとれなかったこともあるが、何かひとつ大きな懸案が解決すると暫く気が抜けてやる気がなくなるという、いつもの癖でもある。

 こういうときは、細かい手仕事か全然別の工作のことを考えて気を紛らし、意欲が復活するのを待つ。そういうことなら、リニアPCMプレーヤーを作ったお陰で、最近音を出す機会が急に増えたオーディオ装置に手を加えたいものがある。この装置は昔々、オーディオに凝っていたときに揃えたQUADのセット(405、44、CD67)と、タンノイのスピーカー、Berkeleyである(憧れのAutographまでは手が出なかった)。

A9103077

 音域は広くないが落ち着いたクラシック向けの音で30年近く愛聴している。スピーカーは、さすがに最近、音に艶がなくなった(近々修理に出す予定)が、アンプは一度電源コンデンサーを交換したくらいで元気に音をだしてくれている。

 しかし、リモコンに慣れた体には音量調整にいちいち装置まで腰を浮かすのがつらい。電子ボリュームというICがあるのは知っていて、いずれはリモコンを自作してやろうと思っていた。それがウェブをさまよっていて、TI(BurrBrown)のPGA2311というICを見つけた。こいつは他の電子ボリュームICに較べると、値段は3倍以上するが、歪み率が2桁近く低いことがわかった。どうも高級オーディオ用のICのようだ。3倍以上といってもDigikeyで一個¥1000近辺で買える。

 ちゃんとしたオーディオセットにはこれくらい奢(おご)ってやりたい。急にリモコンが作りたくなってきた。仕事の帰りに久しぶりに秋月に寄り、沢山ある赤外線受信モジュールのひとつ(シールド付き、PL-IRM0101-3 ¥110 )を買ってきた。ロジアナにつなぎ、リモコンを当てると、さまざまな波形が即座に見える。フォトフレームそっちのけで、ウェブを見ながら家中のリモコンを片っ端から試して面白がっていた。

I00622

 そのうち、いつもこのブログにコメントを寄せてくれるshuji009さんが、電子ボリュームを使った工作を計画していることを、すんさんの電子掲示板で知った。うーむ、どちらも示し合わせて始めたわけではない。何か同期しているようだ。そんなこんなでフォトフレームプロジェクトの方は進捗が遅い。でも、少しづつ作業は進めている。

デジタル液晶の準備(8/31/2010)
 半かけで放置してあったデジタル液晶のケースの工作を再開した。この液晶は、アナログ液晶と一緒にAitendoの決算バーゲンで買った7インチのWVGA(800×480)のワイド液晶パネルである。韓国製(DMMT-7000WVGA)の新品で、シャープのLQ070Y3DG01のコンパチをうたっており、店には元の液晶もあったが中古だったので新品のこちらの方を選んだ。

S_a9093056

S_a9093074

 18ビットRGBで26万色出るデジタル液晶である。クロックはこれまでの6Mhz台ではなく、一気に30Mhz台に上がる。素人がいじる限界の周波数だ。液晶を2台買う時に、アナログと同じ仕様というのも芸がないと思って、少し背伸びしたのだが、30Mhzというと今のFPGAのマスタークロックとほぼ同じだ。SRAMのアクセスが心配である。S_a9093061

 インバータは別付けで既に用意がしてある。インバーターを裸で使うのはちょっと怖いので、この前に壊した最初のカシオのアナログ液晶のプラスチックケースにインバータ基板を入れる工作にとりかかる。インバーターと、フレキケーブル変換基板を、液晶パネルの裏面に5ミリのスペーサーをエポキシ系接着剤で固定して、そこへネジ止めする。スペーサーは接触面積が少ないので瞬間接着剤(シアノクレート系)では、ちょっと力をかけるとすぐはずれるので使えない。S_a9093055

 ケースと液晶パネルの固定は、ケース表面の4隅にパネルが固定されるよう寸法を正確に測った小さなアクリル小片を接着し、パネルが中で動き出さないようにしてから、ケースの裏面に固定用のアクリル板をあててケースのネジ止めで全体が動かないようにする。このあたりは瞬間接着剤でも十分だ。うむ、うまく行った。

S_a9093064_2

 電源は迷った。インバーターはENABLE用のTTL入力を要求するので、12Vと5Vが必要になる。抵抗分圧でも良いが、液晶のロジック部分の電源は3.3Vが必要である。迷った挙句、5Vと3.3Vのレギュレーターを2段使って12Vアダプターから供給することにした。インバーター用とロジック用の電源は分けた方が良いとされているが、パネルに2つも電源コードがつながるのはみっともない。まあ、このあたりは問題があればいつでも換えられる。

S_a9093068

 エポキシの乾燥は時間をかけると強力になるので1日置いてから組み立てにとりかかる。電源アダプターは、最初のとき開けた穴を流用する。フレキケーブルが長すぎたがそう問題ではない。変換基板からはフラットケーブルでFPGAにつなぐ予定だ。 インバータ部の配線が終わったので、とりあえず12V電源を入れて確認する。よーし、ちゃんとラスターが出た。

BMP画像ファイルのフォーマットを勉強する(9/4/2010)
 そろそろ画像ファイルのフォーマットを検討する段階である。最終的にはJPEGファイルを入力にすることにしているが、早く画像が見たい。とりあえず最初はBMPファイルから画像を出すことにする。ARM上のJPEGデコードライブラリは、ネット上にいくつかフリーのものがあることは大分前に確認している。フラッシュも30KB程度ですみそうだが、簡単に動かすことはできない。

 BMPファイルについては概念的なことは知っているが詳細は全く知らない。あらためてウェブで調べる。WAVファイルと同様BMPファイルフォーマットもすぐ見つかった。有難い時代になったものである。ここのサイトの説明が簡明でわかりやすい。

 それによると、24ビットBMPが一番簡単そうである。驚いたことに16ビットBMPというフォーマットはないのだそうだ。8ビット以下は、カラーパレットという別のテーブルを用意し、これをインデックスにして色を表す。こちらの方も面倒だ。

 PC上の定番ソフト、ペイントを調べ、JPEGから24ビットBMPに変換できることを確認する。よし、このフォーマットをJPEGのターゲットファイルとしよう。24ビットBMPはピクセルごとにRGB順に8ビットづつ色信号が並び、表示行の一行が4の倍数(不足分はパッドする)で、これがライン分並ぶという至極、簡明なフォーマットである。ヘッダーを削って、これを2バイトづづ(5+5+5、1ビットパッド)、FPGAへ送れば、3万色の画像が出る理屈だ。

 悩ましいのは、BMPのストリームの方向である。標準は一番下右からデータが始まり、上へ上がっていくという通常のビデオスキャンとは逆の方向である。最初戸惑ったが、フレームメモリ(SRAM)の最高アドレスから逆に書いていくとか、モニターにスキャンを逆にするモードなどで対応できることがわかり胸をなでおろした。

 BMPファイルからのデコードに見通しがついた。いやいや、遂にフォトフレームプロジェクトも画像フォーマットを具体的に検討するところまで来たかと感慨にふける。

デジタル液晶のソフト改修の検討(9/8/10)

 デジタル液晶はワイド仕様のWVGAである。画面の中央部に640×480を表示するにしても、ピクセルクロックは31MHzもある。FPGAのマスタークロックは33Mhzで、このままでも動きそうな気もするが、5%を越える誤差は少し厳しい。これはPLLで微調整が出来そうだが、それよりSRAMのアクセスが問題だ。現在のソースではうまくいかない。

 現在は、2クロックでデータを読む仕掛けになっている。ピクセルクロックにクロックを合わせた場合、倍のクロックにしないと上手く動かない。PLLでマスタークロックを2倍にして現行のソースを使うか、マスタークロックをそのままにして、SRAMのアクセスをパイプライン(アクセスリクエストとデータフェッチを同一クロックで行う)にして描画は前のクロックのデータを使う方式にするか迷った。

チャートを引いて検討する。確信は持てないが、後者のパイプライン方式でもうまく行きそうな気がする。最初の1ピクセルの表示はできないが、SRAMのデータシートには、最も簡単なアクセス方式としてCEもOEもアクティブにしたままアドレスだけをかえるチャートが例として出ている。つまり、アドレスの変更だけで10ns後には自然にデータラインにデータが出てくる。ピクセルクロックとマスタークロックを同一にすれば問題ないように思われる。

データバスを16ビットにする(9/10/2010)
 今度の液晶パネルがWVGAとえらく昇格してしまったので、メモリが足らなくなった。この4メガビットSRAMは、1アドレスあたり16ビットをアクセスできるが、配線とソフトが面倒なので、これまでは上半分の8ビットしか使っていなかった。半分の256KBではVGAでは8ビットカラーも無理だ(308KB要る)。

ワイド画面にしないで中央に640×480を出すにしても、残りの8ビットを使わないとVGAの16ビットカラーは出せない。実は16ビットカラーだと614KBも必要で、512KBならRGB4ビットづつの12ビットカラー(4096色、460KB)が限度である。

変更がおおがかりになってきたので、少しづつ動作確認しながら作業していくことにする。まずは、この16ビットアクセスの変更だ。これはクロックが今のままでもテストが可能だ。 FPGA基板のSRAMの配線を追加する。こんどのXP2は144ピンなのでまだ余裕だが、アドレス18、SRAMデータ16、RGBデータ15、これにSPIやUART、SRAM制御線を入れていくと60本近い。相当混んできた。これだけ本数が増えるとピンアサインに気を遣う。

 FPGAのピンアサインは沢山読み替えが必要で一筋縄ではいかない。まず論理合成ツールの入力となるのはピンナンバーであるが、ピンナンバー以外にIO[nn]といったピン名があり、これが雑誌基板の外出しのコネクターのAnnとかBnnというコネクター単位のピン番号と対応する。順番に並んでいるかと思うと思わぬところで飛び番があったりして、戸惑う。しかも雑誌の表示は部品面で実際のハンダ付け面と違うので余計混乱する(書き直せばよいのだがさぼっている)。

A9113094

 何とか配線が終わったので、VerilogHDLソースの変更にとりかかった。単にバスを広げるだけではなく、LowとHighバイトを互いに読んだり、書いたりする処理をつけ加える必要がある。SRAMアクセスは2回に一回になる。

 最後のデータの書き出しでつまづいた。データが奇数で終わるとSRAMに書き出されないまま終わってしまう。SPIの処理終了のところで何とか出来ないか、あれこれ考えていたが、簡単には出来そうにない。まあ画像データなので最後の1バイトが読めなくても大勢には影響しないのだが気分が悪い。

 これが食事をしているときに突然閃いた。何も2回に一回アクセスする必要はない。毎回アクセスしてSRAMに書き、2回に一回だけアドレスを増やせば良いのだ。処理時間に影響は全くない。気が付けば何でもないことだが、コロンブスの卵だ。しかし、こういう解決は気持ちが良い。

 機嫌良くコーディングを終えて、早速テストに入る。SRAM側のサブモジュールのバスを拡張するのを忘れていたり(VerilogHDLは型にうるさくないので見過ごし)、2ビット分の配線間違い(出てくるデータ化けを分析してピンポイントで発見。こいつも気分が良かった)があったりしたが、順調にSRAMの16ビット化は完了した。このあいだ9MHzに上げたSPIからの文字データが矢のように流れる。

このあたりでブログに報告することにする。次はいよいよピクセルクロックの高速化である。もしパイプラインが動かなければ、マスタークロックそのものを上げる必要がある。

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

« 2010年8月 | トップページ | 2010年10月 »