インバーターはENABLE用のTTL入力を要求するので、12Vと5Vが必要になる。抵抗分圧でも良いが、液晶のロジック部分の電源は3.3Vが必要である。迷った挙句、5Vと3.3Vのレギュレーターを2段使って12Vアダプターから供給することにした。インバーター用とロジック用の電源は分けた方が良いとされているが、パネルに2つも電源コードがつながるのはみっともない。このあたりは問題があればいつでも換えられる。エポキシの乾燥は時間をかけると強力になるので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というコネクター単位のピン番号と対応する。順番に並んでいるかと思うと思わぬところで飛び番があったりして、戸惑う。雑誌の表示は部品面で実際のハンダ付け面と違うので余計混乱する(書き直せばよいのだがさぼっている)。何とか配線が終わったので、VerilogHDLソースの変更にとりかかった。バスを広げるだけではなく、LowとHighバイトを互いに読んだり、書いたりする処理をつけ加える必要がある。SRAMアクセスは2回に一回になる。最後のデータの書き出しでつまづいた。データが奇数で終わるとSRAMに書き出されないまま終わってしまう。SPIの処理終了のところで何とか出来ないか、あれこれ考えていたが、簡単には出来そうにない。画像データなので最後の1バイトが読めなくても大勢には影響しないのだが気分が悪い。これが食事をしているときに突然閃いた。何も2回に一回アクセスする必要はない。毎回アクセスしてSRAMに書き、2回に一回だけアドレスを増やせば良いのだ。処理時間に影響は全くない。気が付けば何でもないことだが、コロンブスの卵だ。いう解決は気持ちが良い。機嫌良くコーディングを終えて、早速テストに入る。SRAM側のサブモジュールのバスを拡張するのを忘れていたり(VerilogHDLは型にうるさくないので見過ごし)、2ビット分の配線間違い(出てくるデータ化けを分析してピンポイントで発見。こいつも気分が良かった)があったりしたが、順調にSRAMの16ビット化は完了した。このあいだ9MHzに上げたSPIからの文字データが矢のように流れる。このあたりでブログに報告することにする。次はいよいよピクセルクロックの高速化である。パイプラインが動かなければ、マスタークロックそのものを上げる必要がある。(木)エラーのないFPGAのUARTコードを自作するFPGAのフォトフレームプロジェクトは、いよいよ第一期完成フェーズにあたる第7ステップに進んだ。SDカードにあるビットマップ画像データを液晶モニターに表示する段階である。フォトフレームを作ると決めてブログで宣言したのが今年の2月末。6ヶ月かけてここまできたことになる。このあいだには、XilinxのFPGAチップと液晶モニターをプローブの誤接触で壊したり、HDL言語(VerilogHDL)の習得にてこずったり、今回も多くのドラマ(?)が生まれた。電子工作を始めて2年半、自分でも感心するほど多種多様な工作をしてきたが、ひとつのプロジェクトにこんなに長く(半年)かけたことはない。FPGAはやはりてごわい。これまで何度も書いているように、当研究所では電子工作には必ず何らかの実用的(こじつけでも良い)な目的を決めてから、工作を始めることにしている。定年後の楽しみに始めたアマチュアの電子工作である。何をやろうと、どこでやめようと誰もとがめる人はいないのだが、これだけ目的にこだわるのは理由がある。自分は飽きっぽい性格で、めげやすい。何の規制もせずにやりたいことだけやっていたら、いつまでたっても技術の向上は望めない。電子工作は幸い、初心者からプロまで、どんなレベルであろうと、それなりに夢中になり楽しめる世界だが、悔しいことに技術レベルが上がれば上がるほど楽しめる範囲が広くなっていくことは否定できない。何でも良いから具体的な目標(仕様)を設定しておくと、何とかそれを実現しようと、一生懸命に工夫、努力をする。飽きっぽい割には、一旦こだわると意地になる習性がある。これによって技術レベルは確実に上がる。遊びとは言いながら少しでも技術レベルを上げて今まで出来なかったことを可能にし、世界を広げたい。当研究所の所長は、この40年間、ほぼコンピューターのシステム開発を仕事にしていた(後半は企画と管理ばっかりだったが)。この世界ではコンピューターのハードウエアというものはいわば神が創ったものであり、これに注文をつけることはとんでもないことで、仕様どおり有難く使わせていただくものだった。PCやマイクロコンピューターでも似たようなものである。FPGAはこういう今までの常識をくつがえすディバイスである。作ろうと思えば、自らが思いのままプロセッサーを自作できるのだ。何とかこのディバイスを自由自在に操れるようにしておきたい。フォトフレームプロジェクトは現物を作るだけでなくFPGAをマスターするということもプロジェクトの大きな目的にしている。そんなこともあってまた少し道草を食って、本来のフォトフレームとは関係ないFPGAのUARTにはまりこんでいた。雑誌のサンプルUARTソースがうまく動いていない(8/16)SPIのバグ取りに散々苦労して、わかって見ればその原因はUARTの方だったという話は前回にした。このFPGAのUARTのVerilogHDLソースコードは、雑誌のデザインウエーブマガジン(その後季刊のデジタルデザインテクノロジーに改称)2008年10月号P86のサンプルソースをそっくり利用させてもらっている。雑誌のサンプルソースにバグはないはずなのだが、SRAMからのUART出力には明らかにエラーが出ている。エラーの頻度はそう高くないので、これまで気が付かなかった。これとは別のfpga4fun.comのUARTに較べれば、はるかに安定していると思っていた。詳しく調べると、1KBに数文字の字化け(エラー)があるようだ。リセット直後の数文字はたいていおかしい。フォトフレームプロジェクトではそろそろデジタル液晶の準備にかからなければいけない(ケース工作はほぼ完成)のだが、ここはそれ、しつこい性格である。気になると、他の事に手が付かなくなる。この際、徹底的にデバッグすることにした。折りしも、SPIのトラブルのとき勧められた、「HDLによる高性能デジタル回路設計」という本を入手し、FPGAを本格的に勉強しはじめたこともある。ロジアナを使って、雑誌サンプルソースの不具合の原因解明を始めた。犯行現場の現場検証が重要だ。字化けの事実を検証する。テスト用にボーレートカウンターの動きをFPGA出力ピンに出すコードをソースに追加して、これをロジアナで拾い、少しづつデータを送ってはロジアナでタイミングチャートを分析する。その結果、どこで字化けが起きるかは、ほぼ確定できた。UARTのデータの送出順序はLSBファーストである。字化けは必ずMSBで起きている。データの最後の方を集中的に調べていくと、添付画像にあるように、8ビット目の最後がボーレートの半分で終わり、そのままストップビットになるところがいくつも見つかった。UART受信はボーレート期間中の多数決論理でHかLを決めているので、ボーレートが少しずれると半分の幅しかないMSBで0のデータが1になる可能性がある。これが前回の記事で1や2が半角のアやイになる理由である。スタートビットはこのあと正しく出ているので、エラーはここだけに止まる。字化けが起きる原因はつきとめられた。このUARTの最後のビットがボーレート通りの時間にならないかがわからない。ソースコードにはおかしなところはない。ボーレートの時間通りウェイトが入っている(はずである)。「HDLによる高性能デジタル回路設計」で勉強する。(8/18)すんさんの掲示板で勧められ、絶版だと聞いていたが、秋葉原の書泉で探してみたら最後の一冊らしいカバーが少し汚れたものが見つかり早速手に入れた。噂には聞いていたが、高度な内容である。非同期回路だけでなく、同期回路も安心ならないことを学ぶ。それ以外にも考慮しなければならないことが沢山ある。自分がいかに能天気にRTL設計をしていたかを思い知らされる。QuartusII)は、この本を読み進むうち、かなりな問題があることがわかってきた。送信要求のビットはキーボード押下で発生する非同期パルスだが、その配慮がなされていないこと、状態遷移のレジスターが多段(5ビット)で、単なるバイナリーコードであるうえに、これをインクリメントするステップと、状態遷移をするロジックが同一クロック時に動いており、これが正しく評価されない可能性があることなどである。本に拠れば、非同期はもちろんであるが、同期回路といえども、ハザード(出力が不定になるところ)は、常に起きる可能性があり、その対処が必要としている。それから言えば、この雑誌のサンプルソースはあやしいところが沢山ある。それにこのソースには不可解なところがある。UARTは非同期通信なので、同期シリアル(USART)と違ってデータはクロックのエッジではなく、HighかLowでデータを採取する。それなのにサンプリング周波数はボーレートの2倍にとってある。少なくとも送信の場合はオーバーサンプリングしても無意味である。受信側のモジュールとボーレートを共通にするためだと思うが、ソースコードを読めば読むほど、何かあやしくなってきた。具体的にどこでハザードが起き、それによってボーレートが最後だけ短くなるのかは、まだ経験が浅くてつきとめられない。現実に字化けが起きていることは事実である。なったら、自前でUARTのソースコードを書いてみたくなってきた。参考書で学んだテクニックを応用する絶好の機会だ。ここまで勉強したら自分で作ってみよう(8/21)擬似コーディングを念入りにやって、自前のUART送信コードを書き始めた。UARTは、クロックパルスを持たない非同期通信なので、スタートビットからの時間間隔(ボーレート)だけでデータをHかLに設定して送信する。雑誌の2倍サンプリングをやめて、ボーレートだけのステートマシンにする。自慢は、ステートレジスターのグレイコード化(1ビットづつ変化する遷移ビット)と、同時に多数のビットを変えないロジック、ボーレートカウンターのような多数のビットを変更するときは、ステートをあけて結果を利用するなどのテクニックだ。おお、前よりステートメント数も少なくなっている。これで動けばいうことなしだ。期待に胸をふくらませて論理合成する。祈る気持ちでUART端末を立ち上げる。ARMからデータを送り、FPGA側のUARTのスペースキー(出力指示)を押した。やった、やったぞ、最初の文字から全く誤りなくテキスト文書が表示される。