これまでUARTで動いていた順序を逆にしたわけだから、おかしくなるはずなのだが、現実には綺麗に画像が出ている。理屈はわからないがうまく行ったことだけは確実だ。嬉しくて記念撮影をする。ここ一週間ばかり頭を悩ませていた問題が遂に解決した。ガッツポーズをしながら部屋の中を歩き回る。これまでの暗い気分がうそのように晴れて、体中に充実感がみなぎる。この成功した時の気分がたまらない。今度は本当に大変だった。この計画を断念するところまで追い込まれていた。諦めずに粘った甲斐があった。興奮が納まって改めて冷静に原因を考える。以前のUARTでは問題にならなかったのだろう。UARTは8ビット単位だったのでSRAMに入ったものをそのまま返すだけで問題にならなかったのだ。今度は、バイトをまたがってデータを作り直している。SPIはMSBファーストだが、SRAMに入るときは丁度逆になるようだ。その証拠に、テスト画面でなく、昔のデジカメの写真(640×480)を出してみると見事にネガ写真になった。これはFPGAのピンアサインを逆に設定し直して、無事、写真もそれらしく出た。どこか不具合が残っていて少し色がおかしいが、これまでの化け化けの写真と違ってだいぶましな画像になった。フォトフレームプロジェクトはこれで一段落した。教訓は、言い古された表現だけれど、「デバッグは外へ、外へ」「大丈夫と思ったところが危ない」「デバッグに疲れたら別のことをやって気分転換」だ。最後に今まで疑っていたFPGAやSRAM、STM32などハードのみなさん、この場を借りてお詫び申し上げます。疑って申し訳ありませんでした。画像らしいものが出てあともう一息デジタル液晶も画面が真っ暗(9/30/2010)どうも何かに呪われている。フォトフレームのHDLソースのロジック追加は、擬似コードレベルからのコーディングは特に問題なく完成し、論理合成やコンフィギュレーションも順調に終わったので、通電したのだが、画面には何の反応もない。オシロで見る限り同期周波数も、色信号も規定どおりに出ている。画面はアナログ液晶のときと同じように真っ暗なままである。手探りで作ったPLLは見事に33Mhzのクロックを逓倍して62Mhz(正確には61.875Mhz)のマスタークロックを作っている。デジタル液晶のピクセルクロック31Mhzも正確に出ている(実際は30.938Mhzだが)。同期信号も所定どおりの間隔で出ていることをオシロで確認した。今度の液晶はピクセルクロックと、色信号の出る間のDATAイネーブル信号を要求しているが、これも想定どおりちゃんと入っている。それなのに、どうして画面に何もでてこないのか。SRAMにデータを書き込まないで描画すると、メモリのランダムな値でちょうど砂をまいたような画面になるはずなのだが、全く暗いままだ。このままでは何の手がかりがない。何処から手をつけてよいのかわからない。カラーバーから確かめていくしかないか。カラーバーも真っ暗(10/2/2010)SRAMからの描画をあきらめて、わかりやすいカラーバーを出してみることにする。急いでコーディングし、試してみた。ところが、電源を切ろうとして一瞬カラーバーが出た。ありゃあ、前と同じだ。過渡的なときには色が出るが、一旦電源を入れてしまうと出ない。前のアナログ液晶と同じである。画面を見てみるとカラーバーがうっすらと出ているのが見えている。そのうちもっと暗くなって、画面は視認できなくなる。デジタル液晶なので色信号の電圧はLVTTLだ。オシロにもきれいな3.3Vパルスが出ている。DATAイネーブルを疑ったが、ここは正論理で間違いなく正しいピンに所定の描画サイクルで出ている。このデジタル液晶はピクセルドット周波数を要求する。この立ち上がりと立下りのどちらでRGBデータを拾うのかはデータシートに明記されていない。思うが両方やってみる。電源を切ったときとか、入れた瞬間に鮮やかな色が出て、定常になると色が消えるというのが不可解だ。何かの条件が色を出すのを止めている感じだが、この条件が見えない。前のアナログのときと同じような状態というのが気にかかる。鮮やかなカラーバーが出た。原因は意外なところ(10/3/2010)ここ数日は暗い日々だった。苦労して作ったデジタル液晶が、このあいだのアナログ液晶と同じように、まともな明るさにならない。ピクセルクロックもデータイネーブルも規定どおり、水平・垂直同期も正確に出ている。色信号もオシロで見る限り正常。画面は暗いままである。前と同じように電源投入直後は少し明るいが次第に暗くなる。この次第に暗くなるというのが何ともおかしい。液晶パネルのドット描画のロジックが良く見えていないので対策のしようがない。ピクセルクロックの立下りでデータを拾う仕様で、データが逆に出ていたら真っ暗になるのかとか妄想してみるがピクセルデータは期間中、同じ値(のはず)であり、そんなわけはない。そんなことあるわけない。アナログの場合は、色信号の電位差で明るさが決まるが、デジタルは各ビットが1であれば問題なく何らかの色は出るはずである。電源を疑ってケースを開け、それぞれの接続を確かめ、パネルに近いところで波形や電圧を見る。電源は少しパルスが乗っているが、3.05Vと正常範囲内だ。レギュレーターが、触った時火傷しそうに熱いのに気が付いた。一段目のレギュレーターは液晶パネルのバックライト用の12Vから5Vにするため7V分を熱にしているからだが、ちょっと熱すぎる。熱抵抗を計算してみると最初のTA48M05(500mA)では125°C/Wでヒートシンクなしでは少し苦しい。大きめのレギュレーターTA4805S(1A、62.5°C/W)に換えてみることにする。換装して電源を入れる。お、ほんの少し画面が明るくなったように見える。解決策をもとめてウェブを探していたら他社の液晶パネルのデータシートが見つかった。そこにはロジック部の消費電流が出ている。いえば、この液晶のデータシートには、ロジック部の消費電流が記号でTBDとあるだけで実数値が出ていない。ウェブの消費電流の方を見て驚いた。5Vで120mA、3.3Vでは160mAも流れると書いてある。ロジック部の消費電流がこんなに大きいとは思っていなかった(100mA以下とみていた)。3.3Vのレギュレーターは例のLPCMプレーヤーに入れてビートが出たため使っていないXC6202である(8ヶも余っている)。150mAとれるので余裕と思っていたが足りない可能性がある。この液晶パネルの実際の消費電流を測ってみた。結果は125mAで、XC6202の定格内だ。こちらのレギュレーターは熱もそうない。電圧もちゃんと3.05Vでている。これまでの状況から、どうも電源が臭い。調べるところがなくなって、だめもとで別の3.3V電源アダプターでロジック部を供給することにしてみた。何と、何と、これで液晶モニターに鮮やかな色が戻ったのである。ええー、オシロで測った今までの電源電圧は一体なんだったのか。きれいな3原色が表示される。夢にまで見た鮮やかさである。XC6202が悪者になってしまった。こいつが力不足で120mAを消費するロジック部を正常に駆動できなかったのだ。定格内なのにおかしいが、これが原因であることは間違いない。急いで、500mAとれるTA48M33にしてみる。いう単純な原因が画面が明るくならない原因だった(あとでデータシートを良く見たら電源の最小電圧は3.135Vだった。0.085Vの差で真っ暗になるとは)。わかってしまえば何でもないが、ここにたどり着くまでえらい時間がかかった。SRAMを読んだ画面が出た!(10/6/2010)液晶に色が戻ったので、ロジックを更にいじって、カラーバーを上段に、コメントアウトしてあったSRAMの内容を表示するルーチンを生き返らせて、下段に出すレイアウトにする。SPIが動いていないのでデータは更新できないが、SRAMのランダムなデータを拾って、ちょうど大理石模様のようなこまかい画像が表示された。今までは、縦縞ばかりだった(1ライン中のデータが同じままのとき)が、これはSRAMを順調にラインを越えてアクセスしていることを意味する。これまでの暗い気持ちがいっぺんに吹き飛ぶ。これで画像表示まで大きく近づいた。それにしても長い道のりだった。この爽快感はいつ経験してもこたえられない。ランナーがマラソンにはまるのと同じである。苦しみが大きければ大きいほど、喜びが倍増する。次は実際の画像の確認である。SPIから送られた画像データが表示出来れば、フォトフレームの第7ステップ(一期完成ステージ)は完了する。STM32プロセッサーのBMPデータの抽出コードはまだ出来ていないので、とりあえずSPIの動作を確認するため、UARTでSRAMを確認できるようにする。データ読み込み中は画面を止めることにしたので、SPIの動作を優先しSPIデータが入る(チップセレクト)とただちに読み出しを停止するように変更する。UARTは別のSRAMアドレスを用意し、画面の垂直ブランクの時だけSRAMをアクセス出来るよう、assign文で読み込みアドレスの切り替えを2段にする。VerilogHDLの変更が終わった。データを送れば画面はかわるものの一色でぬりつぶされ、UARTからはデタラメな文字しか出てこない。退歩してしまった(最初はSRAMを読んでいる証拠の砂模様画像だった)。これからが勝負である。ひとつづつつぶしていこう。ことで画像らしいものが出た。あと一息(10/8/10)FPGAのソースコード開発をひとまず横に置き、画像ファイルを送るSTM32側の開発を再開した。BMPファイルを読み、ヘッダー情報からRGBデータだけを抽出して、FPGAにSPIで送るロジックの開発だ。24ビットのRGBデータを12ビットRGBに抜き出すロジックは、はじめSDカードからの読み込みの単位で処理を考え、読み込みブロックをまたがるRGBの分離に頭を捻っていたが(RGBは3バイトで1ピクセルを構成するので、端数が出る可能性がある)、これは発想の転換でいっぺんに解決した。プログラムはRGBをとりだす処理の方をメインループにし、ブロックサイズを越える時点で、次のSDカードを読む処理を入れてデータブロックを更新すればよい。今まであれこれ悩んでいた継ぎ目でのロジックはこの方法では考える必要がない。このあたりがソフトウエア開発の醍醐味だろう。幾何でいう補助線一本で証明が出来たときの快感と同じである。機嫌よくコーディングを終えて、BMPファイルを用意する。ペイントプログラムはどうもピクセル単位にキャンバスを作れないようなので、一旦ペイントで適当に画像を作り、デジカメについていたおまけソフトで640×480のピクセル24ビットBMPファイルに切り出す。さあ、これで画像ファイルも出来た。PCでSDカードに移し、STM32のSDカードスロットに入れて、FPGAに送り込む。さあどうだ、FPGAは、その後UARTを止めたりして前の状態に戻しSRAMが読める状態になっているはずだ。あれえ、全く変わらない。SPIは読んでいるようだが(LEDが点滅)、SRAMにちゃんと書いていないようだ。なってくると、もうオシロは役に立たない。ロジックアナライザーの出番である。FPGA基板のコネクターに例のスタブ(0.5mm銅線)をたて下位のSRAMアドレスやいくつかの制御線にプローブをあて慎重に解析を開始した。今度のソースはこれまでになく複雑になっている。画像を出すロジックは、同期信号を作成するモジュール、色信号を所定のドットに乗せるロジック、12ビット色信号を16ビットSRAMデータを読みながら作るロジックの3段が並行し、これにSRAMを読むモジュールと計4つのプロセスが同時に走る。ロジアナの威力はやはりすごい。次から次に不具合が見つかっていく。現在のロジアナの限界が見えてきて解析が順調に進まなくなった。今使っているロジアナは、2年前に買ったオプティマイズの100Mhz、32CHの安いけれどなかなかの性能で、これまで重宝してきた。今のFPGAのマスタークロックは、62Mhzでピクセルクロックは31Mhzである。ピクセルクロックくらいまでは見えるが、60Mhz台のSRAMアクセスのタイミングを正確にとることは難しい。実際に、このタイミングをはずしているのかロジアナが捕まえられなかったのかがわからないのでは解析しようがない。うーむ、「すん」さんがこのあいだ買ったという200Mhz台のロジアナが欲しいな。高いけど(¥38,800)。それはともかく、とりあえずは先に進まなければならない。コードを少し修正しては、ロジアナでタイミングを調べ、さらにおかしそうなところを修正してタイミングチャートを調べる。RGBをぬきだすところと、画面に出すところのタイミングが少しづつ合ってきてSRAMのアクセスが順調になってきた。ドット単位にアドレスが増えていく。SPIで入れたデータがどうしても順調にSRAMに書き込まれない。出来る時と出来ない時がある。調べた結果、原因は、やっぱりFPGAのコードではなく外であることがわかった。STM32のCS(チップセレクト)が間違っていたのである。データを送る以前に正しくCSがセットされていなかった。これを直すと画面のSRAM初期画面と明らかに異なる画面が出た。水平同期が乱れた時の横線である。SRAMに新しくデータが送られた証拠である。画像のサイズが狂っているので横流れになっているが、これを補正していけば画像になるはずである。今度のデジタル液晶は、800×480のWVGAなので汎用性を持たせるため、両側の80ドットを黒くして画面を640×480にしている。したらSRAMアクセスは黒いところも動き、画像を縦の長さを無視して展開しているのではないか。ソースコードをいじって640ドットだけSRAMを読むようにする。元の画に較べれば、色は殆ど出ていないし、表示が斜めに傾き、画像がちょうど裏になっている(スキャン方向を間違えている)が、明らかにBMPファイルの画像の絵である。フォトフレームを志して半年、はじめて出た記念すべき画像だ。いやいやそれにしても普段何気なく使っている映像機器の画面表示の裏にはとんでもなく複雑なロジックが動いていることを実感する。スクラッチから静止画をひとつ出すのにこんなに苦労するとは正直言って始める前には想像もしていなかった。ここまでくればもうあと一息である。ハードや画面描画には問題なくなったので、あとは中のRGBデータのハンドリングを正しくしてやれば、ちゃんとした映像になる見通しがついた。デジタルフォトフレームのプロジェクトもそろそろ大詰めが近い。完成を目の前にしてプロジェクトの進行が足踏み状態である。遅れの原因は今度は仕事ではなく、久しぶりの海外旅行のためである。海外と言っても、お隣の台湾で、それも台北近辺のみ。家族で3日間中華料理をいやというほど堪能してきた。お陰で体重が2キロも増えて、食事制限中である。家族と一緒だったのと、日本と大差がないと聞いた台北の電脳街には結局足を伸ばさなかった。町を歩いていて気が付いたのは、LED電光掲示板がやたらに大きくて、どこにでもあることである。お寺のお札を売るところにも大きな電光表示板があるのには驚いた。それはともかくフォトフレームプロジェクトである。この間はもう完成だと浮かれていたが、調べてみると、まだまだやることが沢山あることがわかって頭を抱えていた。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つ用意する。段作り、ステート毎に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分もしない頃、乱気流に飛び込んで激しく降下し乗客が大きな悲鳴をあげる。台風が去ったといっても油断ができない。その後は平穏に成田に戻ることができた。台湾も暑かったが、帰ってきた日本も相変わらずの暑さだ。旅行の後片付けも落ち着いて久しぶりにオーディオルームの電子工作机に戻った。液晶インターフェースの実装を開始した。例の画像表示回路特集のトラ技(2009年11月号)の回路図を参考にする。クロストークや不要電波の放射を抑えるため、デジタル信号をなまらせるダンピング抵抗を入れるので思ったより複雑になる。それに液晶のフレキパネルの変換基板から直接FPGAにケーブルを出さず、ピン数を減らしたコネクターで中継したので、ハンダ付け箇所が2倍になり思ったより時間がかかった。ことで配線が全て終わり、液晶パネルからフラットケーブルが出てFPGA基板につながった。アートワークのメモと一緒に記念撮影する。ハードはこれで全部できあがった。次はSTM32プロセッサーのBMPファイルからのRGBデータ切り出しと、これまで擬似コードのレベルで止まっているVerilogHDLのコーディングである。何とか、個別テストを積み上げて開発ができないか頭を捻る。確認(FPGAからの出力をオシロで確認)・12ビットRGBデータの確認(描画を止めて、UARTのバイナリー端末で確認)・SRAM読み出しの確認(ロジアナでSRAMアクセスをピックアップ)・テスト用画像のBMP化(これは実際に画を出して確認)・画像送出のテスト(同上)でめでたくBMPファイルの画像が出るはずなのだが(第7ステップの完成)。木を見て森を見ずの諺どおりの勘違い(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週間以上日が空いてしまった。珍しく連続して仕事があり電子工作に時間がとれなかったこともあるが、何かひとつ大きな懸案が解決すると暫く気が抜けてやる気がなくなるという、いつもの癖でもある。いうときは、細かい手仕事か全然別の工作のことを考えて気を紛らし、意欲が復活するのを待つ。いうことなら、リニアPCMプレーヤーを作ったお陰で、最近音を出す機会が急に増えたオーディオ装置に手を加えたいものがある。この装置は昔々、オーディオに凝っていたときに揃えたQUADのセット(405、44、CD67)と、タンノイのスピーカー、Berkeleyである(憧れのAutographまでは手が出なかった)。音域は広くないが落ち着いたクラシック向けの音で30年近く愛聴している。スピーカーは、さすがに最近、音に艶がなくなった(近々修理に出す予定)が、アンプは一度電源コンデンサーを交換したくらいで元気に音をだしてくれている。リモコンに慣れた体には音量調整にいちいち装置まで腰を浮かすのがつらい。電子ボリュームというICがあるのは知っていて、いずれはリモコンを自作してやろうと思っていた。それがウェブをさまよっていて、TI(BurrBrown)のPGA2311というICを見つけた。こいつは他の電子ボリュームICに較べると、値段は3倍以上するが、歪み率が2桁近く低いことがわかった。高級オーディオ用のICのようだ。3倍以上といってもDigikeyで一個¥1000近辺で買える。したオーディオセットにはこれくらい奢(おご)ってやりたい。急にリモコンが作りたくなってきた。ロジアナにつなぎ、リモコンを当てると、さまざまな波形が即座に見える。フォトフレームそっちのけで、ウェブを見ながら家中のリモコンを片っ端から試して面白がっていた。そのうち、いつもこのブログにコメントを寄せてくれるshuji009さんが、電子ボリュームを使った工作を計画していることを、すんさんの電子掲示板で知った。うーむ、どちらも示し合わせて始めたわけではない。何か同期しているようだ。そんなこんなでフォトフレームプロジェクトの方は進捗が遅い。デジタル液晶の準備(8/31/2010)半かけで放置してあったデジタル液晶のケースの工作を再開した。この液晶は、アナログ液晶と一緒にAitendoの決算バーゲンで買った7インチのWVGA(800×480)のワイド液晶パネルである。韓国製(DMMT-7000WVGA)の新品で、シャープのLQ070Y3DG01のコンパチをうたっており、店には元の液晶もあったが中古だったので新品のこちらの方を選んだ。18ビットRGBで26万色出るデジタル液晶である。クロックはこれまでの6Mhz台ではなく、一気に30Mhz台に上がる。素人がいじる限界の周波数だ。液晶を2台買う時に、アナログと同じ仕様というのも芸がないと思って、少し背伸びしたのだが、30Mhzというと今のFPGAのマスタークロックとほぼ同じだ。SRAMのアクセスが心配である。インバータは別付けで既に用意がしてある。インバーターを裸で使うのはちょっと怖いので、この前に壊した最初のカシオのアナログ液晶のプラスチックケースにインバータ基板を入れる工作にとりかかる。インバーターと、フレキケーブル変換基板を、液晶パネルの裏面に5ミリのスペーサーをエポキシ系接着剤で固定して、そこへネジ止めする。スペーサーは接触面積が少ないので瞬間接着剤(シアノクレート系)では、ちょっと力をかけるとすぐはずれるので使えない。ケースと液晶パネルの固定は、ケース表面の4隅にパネルが固定されるよう寸法を正確に測った小さなアクリル小片を接着し、パネルが中で動き出さないようにしてから、ケースの裏面に固定用のアクリル板をあててケースのネジ止めで全体が動かないようにする。このあたりは瞬間接着剤でも十分だ。