« 2010年10月17日 - 2010年10月23日 | トップページ | 2010年11月7日 - 2010年11月13日 »

2010年10月31日 - 2010年11月6日の1件の記事

2010年11月 1日 (月)

フォトフレーム: SRAMを増設して15ビットカラーに

 雑誌(デジタルデザインテクノロジー誌2009年1号)の付録基板Lattice XP2を使ったFPGAフォトフレームは、遂にSDカードからのBMP画像ファイルを7インチWVGAデジタル液晶に表示することに成功した。細かい不具合を直すと、これが思っていた以上にきれいな画になったので、欲を出して、SRAMを増設し12ビットカラーから、もう少し本格的なデジタルフォトフレームにしようとがんばってみた。

SRAMへの書き出しを逆にして直った謎は解けた(10/20/2010)

 さんざん悩ませてきた縞模様の画像が解消されたのは、理屈に合わないがSPIから送られてきたデータの順序を逆にすることだった。12ビットのRGBの色信号はバイトをまたがって構成されており、本来この順番を逆にしたら、でたらめなデータになってしまうはずである。

 落ち着いて考え直して見てその原因がわかった。SPI,UARTはMSBファーストでデータを送るのだが、送られたデータをそのまま右端(LSB)から入れていくと、出来たバイトは逆のLSBファーストになるのだ。SPIで入れたupperバイトは15から8番目のデータで、送られるとMSBから8-15と並ぶ。lowerバイトは、これと同じ、0-7。

 この16ビットデータ(8-15と0-7)を並べてどちらから連続して12ビットとっても元にはもどらない。このupperとlowerをひっくり返すと、0-7、8-15と並び、これで16ビットデータは連続する。メモリからUARTに出す時は、これと全く同じようにMSBから送り出すので、元のオーダーに戻る。1バイト毎の処理ならばメモリにどういう形で入っているかは問題にならない。これが解決を遅らせた要因でもある。

 結果としては、リトルエンディアンとビッグエンディアンを間違えたということになる。ただ、何か少し違うような気もする。まあ、いずれにしてもUARTなどのシリアル系ではビット順は注意しないといけないことを身をもって学んだ。

Aa203325

デジタル色信号の配線の間違いがあった(10/24/2010)
 テスト画像のような単色画像はもう問題ないが、グラデーションのある写真画像はまだバグが残っていて鮮明な画像にならない。原因究明に、良い方法を思いついた。3原色のグラデーションの画像でテストすれば一発でどの色がおかしいかが分かる理屈だ。

 次女に作画を発注し、それをSDカードに移す。映し出された画像を見て、一目瞭然でおかしいところが判明した。赤と緑は問題ないが、青の暗いところが暴れている。うーむ、こいつはすごい。デジタル信号の間違いが一目で分かる。基板を調べると、画像のとおり青のビット3とビット4が逆に配線されていた。こういうトラブルシューティングは実に爽快である。配線間違いはFPGAのピンアサインでも修正できるが、あとのことを考えて半田ごてで修正する。

 よーし、写真がきれいに出るようになった。ただ、この液晶、輝度が高すぎて正面から見ると画像が白っぽく飛んでしまう。インバーターに半固定の抵抗をつけてブライトネスの調整をしてみたが、見やすい明るさまで落とすことは出来ない。液晶パネルは見る角度でずいぶん印象が違う。

液晶には最適な見る角度があるようだ。パネルを下からあおぎみるようにすると、黒がきれいに落ちて、画質が格段に向上することを発見した。逆に上からみるとパネルは白っぽくなって画像は薄く見にくくなる。フォトフレームは上から見ることが多い。早速、ディスプレイを天地逆にセットし、スキャン方向を今までのちょうど逆にして画像を出してみる。

Aa213328

 おおー、これは美しい。今まで輝度が大きすぎて白っぽい画が、色の良く出たまともな画像になった。これなら、フォトフレームとして十分実用になる画だ。ここではたと気が付いた。こちらが正位置なのだ。だから垂直方向の調整ビットが逆になっていたのである。

640×480のVGAは、7インチの液晶パネルの大きさで見ると非常にきめ細やかで、みごたえのある解像度になる。やはりQVGA(320×240)とは画質が格段に違う。試しに前のアナログ液晶のQVGAと一緒に映してみた。こうして直接比較して見るとQVGAとの差は歴然としている。今までの苦労が報われる美しさだ。

これはもう玩具の域を超えた立派なフォトフレームだ。実装が楽しみになってきた。 テスト画像を作ってくれた次女が感心してくれ、「欲しい。作って」とも言ってくれる(親孝行な奴だ)。

Aa253343

 しかし、12ビットカラーの明暗の段差はどうしようもない。単色では16階調しかないので、青空などははっきり等高線がついてしまいせっかくの解像度が台無しだ。微妙に色が変わるところは貼り絵的な段差になる。ここまできれいな画像が出るのなら、もう少し多ビットカラーに拡張したくなってきた。

JPEGデコードは現行のCQ-STARMでは無理とわかる(10/27/2010)
 フォトフレーム計画のロードマップによれば、次のステップ(第8ステップ)はJPEGファイルの描画である。実用的なフォトフレームにするには是非実現したい機能である。 FPGAの方が一段落したので、JPEGライブラリの方を本格的に調べ始めた。JPEGについては、以前から実現する方法をウェブで調べている。

 ウェブの検索では、いくつかのサイトがヒットしていたが、詳しく調べると、これらは、すべてオープンソースのfreeJPEG(IJG)がオリジナルであることがわかった。何と、このブログにもときどきコメントを寄せてくれる、ねむいさんや、そら。さんも、このJPEGライブラリを実装されて動かされているようだ。これは心強い。いざとなったら教えてもらえる。

 しかし、オリジナルのサイトのreadme.txtで確認したところ、現在の基板CQ-STARMではSRAMの容量不足で実装できないことがわかった。がっくり落ち込む。この付録基板のCPUは、STM32F103VBT6でフラッシュが128KB、フラッシュは何とか入りそうだが、SRAMは20KBしかない。

 IJGのJPEGルーチンは、デコード時、最小でもバッファーメモリは24KBを必要とするようで、ここに詳しい報告がある。この付録基板(CQ-STARM)は、ねむいさんが以前STM32F107VC6(フラッシュ256K、SRAM48K)に換装されておられ、私もこのあいだDigiKeyに発注してあるのだが、在庫切れでまだ到着していない(3ヶ月以上待たされている)。

 そういえばこれとは別に、STM32F103VET6を買ってあったのを思い出した。これはSTM32Primer2の石の予備に買ってあったものである。これは同じ型番の石なので問題なくピンコンパチでCQSTARM基板に換装できるはずだ。これなら今すぐにでもできる。 

 とはいえ、現在機嫌良く動いている基板のCPU換装は何となく気が進まない。¥3000も出せば、512KBフラッシュ、SRAMが64KBの同じ石のARM基板が買える。迷いどころである。

 ということで、方針が固まるまで、FPGAのSRAMを増設して15ビットカラー(3万2千色)にする方を先に着手することにする。

SRAMの増設も簡単には済まなかった(10/29/2010)
 液晶は18bitカラーだし、FPGAのピンも余っている。しかしメモリが512KBしかないので12ビットカラー(460KB)にした。SRAMを増設して1024KBにすれば、18ビット(690KB)まで出せるが、今度はコネクターを20ピンにしてしまっているので今のハードでは15ビットカラーが限度だ。転送時間のこともあるので、とりあえずの次の目標は、15ビットカラーにする。いずれにしても必要な、SRAMの増設にまずとりかかった。

Aa283374

 メモリ増設は色々なところで紹介されているように簡略なSRAMチップの2階建て(Piggy Back)方式で実装することにする。同じアドレス、データ線を使い、アドレス最高ビットでOE(OutPut Enable)を用いてバンク切り替え(OEの意味が始めて分かった)する。OEとWEを独立させて制御すれば、簡単に動くはずだ。

 SRAMの変換基板を重ねるため、最初ピンヘッダーで重ねようと、ローハイトのピンヘッダーを準備して、一方のピンが変換基板の穴に入るよう細く削りだした。しかし、全部の削りだしが終わる頃、SRAMがFPGA基板のソケットの下に半田付けしてあったことに気が付く。しまった。ピンヘッダー経由では高さがあってFPGA基板の下側にはいらない。

 仕方がないので、強引だが0.5ミリ錫メッキ線を一本づつピンポストに立てて半田付けし密着させることにする。始めてこずったが、写真のように一旦テープで線を揃え、基板の穴を通して一度に半田付けするとうまく行くことがわかった。

Aa283370

 2階建てが終わった。12ビットカラーでひとまずSRAM増設のテストをする。しかし、思ったようには動かない。

 トラブルの切り分けのため、まず2つめをdisableにして動かす。これは問題なく動いた。それではと増設したSRAMのテストをする。しかしこれは単独でも駄目だった。2つめのSRAMのハードが疑われる。ただ、読み込みはやっているようだ。

 ハードをチェックする。まずはピンアサインから。おやおや、WEのピンの場所を1つ間違えていた。何度も確かめてピンに印をつけてあったはずなのに、この印ごと間違えている。情けない。2段になったピンアサインは本当に間違いやすい。

 これを直して、2つ目もやっとデータが書き込まれた。しかし、何ラインかごとに画像が櫛のようにずれる。うーむ、これもハード臭いな。画像がずれるのは、データではなくアドレスがおかしい。2段重ねの導通をテスターで何度も測る。問題ない。ショート?それなら一つ目からおかしくなるはずだ。それはありえないと、独り言を言っているとき、変換基板のICチップのピンの半田付けがやけに薄いところを見つけた。

 ルーペで確認する。ついているようなついていないような微妙な半田付けだ。テスターでは導通している。問題なさそうだが、どうもここしか考えられない。だめもとで半田付けをやり直した。

 よーし、やっぱり半田付け不良だった。2枚目のSRAMも正常に画像を蓄積し表示ができるようになった。テスターでの導通は、プローブで押さえたためと思われる。

 2枚のSRAMの切り替えのテストも手間取った。最初、2つ目のSRAMの動作を止め、スタートアドレスをいくら1枚目の後半にしても画像が切れない。アドレスの最高位ビットを何度も計算しなおし(ワードアドレスなので混乱する)、19ビット目のビットが立てば、2枚目のSRAMをアクセスしに行き、データがないので真っ白になるはずなのだが、そうならない。

 今度はソフトだ。さんざん調べた結果、原因はこれも意外なところが犯人だった。追加したステートメントではなく、ソースリストの最後の書き込みと読み込みアドレスを区分するassign文のビットが拡張されていないという単純なミスだった(19ビット目が全く無視されていた)。

 これを直して、無事、SRAMをまたがって画像が蓄積された。これで1024Kのビデオバッファーが実現した。今度のミスは配線間違いとハンダ付け不良というハードミスが2つ、ソフトのうっかりミスが一つ、SRAM増設にともなうVerilogHDLのコードの方はすべて思ったように動いてくれた。HDLコーディングに大分自信がついてきた。

Aa313384

15ビットカラーが出た(10/31/2010)
 メモリが増設できたので、残るは15ビットカラー化である。STM32プロセッサーとFPGAのロジックを修正する。FPGAの方は12ビットカラーに比べると格段に楽になった。ステートマシンは不要で、メモリを取り出し、16ビットを5:6:5に配分するだけである。STM32の方は少し難しくなる。奇数回での送出になるので、バッファーの切れ目にどこで遭遇しても取り間違いが出ないよう、SDカード読み出しを関数にして何度も呼び出す必要がある(最初これに気がつかなくて、前と同じ縞模様が再現し、冷や汗をかいた)。

Aa253353

 内部処理を外部関数に切り出すのは、C言語では変数のスコープが大きく変わるので非常に気を遣うのだが、この際、泣き言は言っていられない。何しろここの世界は何十年のキャリアがある。弱みを見せるわけには行かないのだ。コンパイルする。何とかエラーは出さずに済んだようだ。これで動けば良いが。

 ハードの作業が残っていた。15ビット用の3本のデジタル色信号線を追加して、それぞれRGBに追加する。論理合成、ピンアサインも順調に済み、いよいよ通電である。STM32のUART端末で恐る恐るファイルを指定する。

 出た。STM32の修正も問題なく、15ビットカラーが出た。単色のグラデーションはまだ段差が目立つ(32階調)が、青空は何とか目だたない程度までなくなった。全体に画像がしっとりした感じになる。いやあ、これならフォトフレームとしても大威張りだ。

Aa263359

 次に何をするか迷っている。やっぱり今動いているCQ-STARM基板のCPU換装か。それとも別の基板を買ってくるか。

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

« 2010年10月17日 - 2010年10月23日 | トップページ | 2010年11月7日 - 2010年11月13日 »