フォトフレーム：最後まで難航したが遂に成功

　久しぶりに晴れ晴れとした気分でブログを書いている。そう、悪戦苦闘していたLattice XP2基板のFPGAデジタルフォトフレームが、やっとのことで想定どおりの640×480ドット12ビットカラーの画像をBMPファイルから描画するようになったのだ。

　フォトフレーム計画（プロジェクト）を立ち上げて、ほぼ7ヶ月。今年のがた老AVR研究所はほとんどの時間をこれにあてていた。毎日のように一喜一憂していたが、遂に第7ステップのBMPファイルの描画に成功した。当面のゴールである。嬉しいというより背負っていた重い荷をおろしたときのような解放感が強い。

　綺麗な画がでるまでは、本当に暗かった。何度もプロジェクトを投げ出しそうになった。その度に気持ちを奮い立たせて元へ戻った。たかが趣味で何でこんな苦しい思いをするのか時々馬鹿馬鹿しくなるが、うまく行ったときの快感が忘れられない。前にも書いたが、相当中毒が進んでいる。

　思い通りにならない時は、世の中すべてが自分に反対しているように見え、今までの生き方そのものが否定されているような暗澹たる気分になるのだが、一旦解決したとなるともう有頂天、まるで天下をとったような気分になる。これだから電子工作はやめられない。

ピクセルのずれが直らない(10/10/2010)
　前記事にあるとおり、XP2のフォトフレーム基板に何とか画像らしいものが出て、あとはもう一息、微調整で上手く行くという考えは甘かった。どうやっても、まともな画像になってくれないのである。

　左右の逆表示は、液晶モニターのスキャン方向ビットの調整（この液晶のデータシートの垂直方向指示ビットは間違っている。0->上から　1->下からが正しい）で直ったが、ピクセルドットの食い違いによる不具合はどうやってもうまくいかない。

　12ビットカラーは6バイトで4ピクセルを表現するので、1ピクセルでもずれると、とんでもない色になってしまう。連続しているところはちゃんと12ビットをとりだしているのだが、1ライン(640ドット）描いた次のラインで、SRAM読み込みがスタートせず、1ドットずれてデータが入り、48ラインごとに元の状態に戻り、結果として縞模様の斜めにずれた画像になる。

　状況は、画面の状態から良く分かるのだが、これをどう解決するかの方策が見つからない。１ライン中の連続表示ではうまく行っているので、ラインのスタートのときにSRAMアクセスのトリガーをかけてやれば、良いように思えるのだが、どんなあわせ方をしても斜めの縞模様は解消できない。

　描画範囲と、画像の幅は1ピクセルでも違うと、大きく左右にずれる。しかしこの傾きは微妙だ。ドットで言えば、40ピクセルくらいしか傾いていない。縦の行は480行あるので、12行について1ドットの勘定だ。

　ピクセルドットの計算違いや、SRAMのアドレスインクリメントの狂いで、こんな微妙な違いは起こらないことに大分経ってから気づいた。FPGAの中のビットハンドリングがどこかで変調をきたしている。

　非同期アクセスか、ハザードの問題だろうか。ステートマシンのグレイコードをいじってみたり、非同期だったSPIのCS信号を同期させてみたり、SRAMアドレスハンドリングを調べてみたりするが、状況は全く変わらない。

　いくつかBMPファイルを入れてテストしてみるが、みな同じ現象。画像データそのものを疑ってペイントソフトが作ったファイルをバイナリエディターで確認するが問題なし。現象ははっきりしているが、原因がわからないので解決できない。

やっぱりバグは外にあった(10/13/2010)
　ひとつめの不具合、画像が斜めに傾く現象は、意外なところが犯人だった。最初、FPGAのビットハンドリングをしつこく調べていたが、どうしても不具合を発見できない。少し冷静になって「デバッグは外へ、外へ」の鉄則どおり、データを送り出すところから調べてみることにした。

　SPIからのデータは、BMPファイルのヘッダーを取り除いた色信号そのもののデータが果てしなく続くデータストリームである。ここで1バイトでもずれたら画像は間違いなく斜めになる。しかしコードはSDカードの読み込みブロックサイズを意識せず、ブロックをまたがってもちゃんとデコードできるようになっている。ずれるわけはない、うっ、待てよ。このブロックの終了条件、おかしくないかい。

　うはあ、大小比較は等しいときはFalseだ。これだ。1バイト、ブロックサイズを行き過ぎている。2KBごとに1バイト、1ライン960バイトなので3ラインごとに1ドット（12ビット）ずれる理屈だ。これだこれだ。あせる手でSTM32のコードをコンパイルしなおし、テストする。

　良いぞ、画像の傾きは直った。しかし、3原色の背景は少し色が出てきたが、まだ縞模様のままで本来の色ではない。次の不具合、色を正しくするトラブルシューティングだ。

「デバッグは外へ」にならって、送られてくるSPIの画像データをロジアナでさらにくわしく調べる。うーむ、でだしのところから既におかしいぞ。今のロジアナはプロトコルアナライザー機能がないので、8ビット波形を手でデコードしてみるが、明らかにBMPファイルの通りになっていない。

　どうも、8ビットデータの処理を間違えているのではないか。データのシフトがおかしい、おや、この<<（ビットシフト）が式全体にかかっているように見える。ああー、C言語の文法を間違えている？　参考書を確認する。　そうだ、＋（プラス）の方が<<より優先順位が高い。今のコーディングでは4ビットシフトしてデータをつけたすのでなく、全体に足してからシフトしてしまう。括弧が必要だ。

　よーし、縞模様になる原因はわかったぞ。これで問題は解決だ。意気込んでコンパイルし、テストする。画が出るのをわくわくして待つ。あれえ、縞模様は消えない。前より少し色が出たようにも見えるが、本来の赤は緑がかった青に、青は黄色になり黒い細い縦線が残ったままだ。期待していただけに、反動ですっかり落ち込む。

高性能のロジアナを注文してしまう(10/14/2010)
　負けず嫌いの当研究所の所長は、こういう状況ではたいてい意地になる。こうなったら徹底的に原因究明をしてやる。ちょうど良い機会だ。これまで欲しくても我慢していた、200Mhzのロジアナ(ZeroPlus　LAP-C16128、￥38,800 )を勢いで注文してしまった。深夜にネットで注文し、振込みもネットですませる。

　2日で到着した。おお、これは便利だ。ソフトが充実している。しかしプロトコルアナライザーでつまづく。標準で付いているSPIが設定できない。ラインが足らないと文句を言われる。BUSにはちゃんと3本定義した。思いあぐねて夜中の1時半、販売元のストロベリーリナックスに到着の報告も兼ねて問い合わせのメールをした。

　何と30分後に回答が帰ってきた。その日はもう気力がなかったので、次の日テスト。何だと、CTRキーを押しながらadd channelしないと同じバスに入っていかないという。マニュアルにあるのかもしれないが、読みきれない。早い回答があるというのは、FAQなのだろう。

　CTRキーを使わなくてもバスに最初に設定したラインを右クリックしても同じことができることがわかった。知ってしまえばなんと言うこともない設定だが、概念を理解していないと難しい。

　しかし、やっぱり道具や測定器には金をかけるものである。次々に新事実が明らかになってきた。プローブがまともなので測定が手軽に出来るのが良い。それにこのクラスのロジアナには、まだ使っていないけれど0.5ミリピッチICにもつけられる極小のプローブ16本がサービスでついている。お買い得だ。

　SRAMアドレス、制御線、カラー信号などつけられるだけのプローブをつけてタイミングチャートを出し、何度も測定した結果、明らかになったのは、

　・色信号が安定して出されていない。データによるものか、FPGAのコードによるものか、FPGAの出力ピンのハードの影響か今のところわからないが、単純な単色の色コードが周期的に描画されている（画像の通りだけれど）。

・個別の色はでたらめだが、全体としては想定どおり（カラーバー）の色信号が出ている。つまり4ビットカラーの送出シーケンスに誤りがなく、中のデータだけが問題である。

・SRAMアクセスは完全にうまく行っている。

何のことはない原因はやっぱり単純なミスだった(10/17/2010)
　ロジアナの測定で原因がだいぶ絞られてきた。FPGAの描画プロセス、SRAMの読み込みには、ほぼ問題がない。不具合はやはり、送られてくるデータと、それをデコードするプロセスのところにある。

順番としては、SRAMに本来の12ビットデータが入っているか確認するのが先だ。UARTを復活させて16進表示でSRAMの中味を別の手段で確認しようとしたが失敗する。画像データをスキャンさせながらUARTを動かしてSRAMの中味を誤りなく表示させることは難しい。垂直同期期間だけUARTを動かそうとするが、どうもエラーが出るようで表示するたびに内容が違う。

　万策が尽きた。少し開発の手を休めて家族と買い物に行ったりする。こういう気分転換がデバッグに効果があるようだ。いずれにしてもSRAMは間違いなく読んでいる。STM32は、画像データをデータブロックなしに果てしなく500KB近くをSRAMに送り込んでいる。それで狂いもなく一画面分が表示されるのだから、FPGAのハザードやノイズで色が変わるならもっとランダムに色が変わらないとおかしい。現在の画はきれいに縦線が揃っている。

　16ビットのSRAMへの送り込み、取り出しはUARTの時に2バイトコードで正しく処理されていることを確認しているのであまり深く調べてこなかったが、どう考えてもここで何かが間違っているとしか考えられない。しかし、何度見返してみても16ビットデータは最初の24ビットBMPファイルから4ビットを3つづつ取り出し、それをSRAMに貯めこんでいる。SRAMから取り出す順序も間違っていない。

　ところが、ロジアナで見たRGBデータの組み合わせ（赤一色が青と黒のまだらになる。画面もそうなっている）は、SRAMデータのMSBとLSBを逆にすると赤一色からその色の組み合わせになることが紙の上でわかった。うーむ、もしかするとこれかもしれない。

　半信半疑だけれど、もうやることがない。おかしいとは思うが、これを逆に（SPIで受ける時upperバイトとlowerバイトを逆にする）して見る事にした。おおー、何ということだ。逆にすると、カラーバーを入れたテストファイルの画面が見事に原画と同じように表示されたではないか。

　ばんざい。ばんざい。これまでUARTで動いていた順序を逆にしたわけだから、おかしくなるはずなのだが、現実には綺麗に画像が出ている。理屈はわからないがうまく行ったことだけは確実だ。嬉しくて記念撮影をする。ここ一週間ばかり頭を悩ませていた問題が遂に解決した。　

　とにかく嬉しい。ガッツポーズをしながら部屋の中を歩き回る。これまでの暗い気分がうそのように晴れて、体中に充実感がみなぎる。この成功した時の気分がたまらない。しかし、今度は本当に大変だった。もう少しでこの計画を断念するところまで追い込まれていた。諦めずに粘った甲斐があった。

　興奮が納まって改めて冷静に原因を考える。何故以前のUARTでは問題にならなかったのだろう。そうか、UARTは8ビット単位だったのでSRAMに入ったものをそのまま返すだけで問題にならなかったのだ。今度は、バイトをまたがってデータを作り直している。SPIはMSBファーストだが、SRAMに入るときは丁度逆になるようだ。

　その証拠に、テスト画面でなく、昔のデジカメの写真(640×480)を出してみると見事にネガ写真になった。そう、色信号まで逆なのだ。これはFPGAのピンアサインを逆に設定し直して、無事、写真もそれらしく出た。まだ、どこか不具合が残っていて少し色がおかしいが、これまでの化け化けの写真と違ってだいぶましな画像になった。

　とにかく、フォトフレームプロジェクトはこれで一段落した。教訓は、言い古された表現だけれど、「デバッグは外へ、外へ」「大丈夫と思ったところが危ない」「デバッグに疲れたら別のことをやって気分転換」だ。最後に今まで疑っていたFPGAやSRAM、STM32などハードのみなさん、この場を借りてお詫び申し上げます。疑って申し訳ありませんでした。