ソフトが充実している。プロトコルアナライザーでつまづく。標準で付いているSPIが設定できない。ラインが足らないと文句を言われる。BUSにはちゃんと3本定義した。思いあぐねて夜中の1時半、販売元のストロベリーリナックスに到着の報告も兼ねて問い合わせのメールをした。何と30分後に回答が帰ってきた。その日はもう気力がなかったので、次の日テスト。channelしないと同じバスに入っていかないという。マニュアルにあるのかもしれないが、読みきれない。早い回答があるというのは、FAQなのだろう。CTRキーを使わなくてもバスに最初に設定したラインを右クリックしても同じことができることがわかった。知ってしまえばなんと言うこともない設定だが、概念を理解していないと難しい。道具や測定器には金をかけるものである。新事実が明らかになってきた。プローブがまともなので測定が手軽に出来るのが良い。それにこのクラスのロジアナには、まだ使っていないけれど0.5ミリピッチICにもつけられる極小のプローブ16本がサービスでついている。・色信号が安定して出されていない。データによるものか、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バイトを逆にする)して見る事にした。おおー、何ということだ。逆にすると、カラーバーを入れたテストファイルの画面が見事に原画と同じように表示されたではないか。