AVR Camera TFT LCD Develope Board その後(2)

書込風景 タッチパネル付き?

回路図やプログラムを調べ、驚愕の事実を知る。カメラ→LCDのデータ転送にATmega32Lは介在していない。やっているのは、初期化とV-Sync毎にLCDにコマンドを書き込んでいるだけのようだ。カメラとLCDは8bitのデータバスで接続されている。カメラとLCDに共通のデータフォーマットがあったということなのだろう。

CPUの転送速度で、よく更新が間に合ってるな、最近のCPUは速いのねと思っていたのだが違っていたようだ。CPU経由なら、画像の反転とかすぐできると思っていたのに残念だ。将来、カメラとLCDの間にFPGAとか挟めれば面白いかもしれない。

あと、回路図+実物観察で気がついたのだが、LCDはタッチパネル付き!?

AVR Camera TFT LCD Develope Board その後

メールで送られてきたソースプログラムを見ると(たぶん)中国語のコメントだらけ。まず、このコメントを削らないといじる気にならないので、エディタで全部削除。WinAVRでコンパイルすると、目立つエラーも無くすんなりとhexファイルができた。

これをAVRSPで書き込むと、LCDに初期化中を示すメッセージを表示したところで進まない。ソースと一緒にあったhexファイルだとちゃんと起動する。でも、最初に書き込まれていたプログラムとは少し動作が違うようだ。起動時の画像は表示されないし、動作も若干もっさりしている。

自分でコンパイルしたhexファイルと動作するhexファイルを比較するとサイズが違う。コンパイルした環境が違うらしい。使えそうなコンパイル環境がないか探してみたがみつからない。

仕方がないので、ソースをいじってみることにする。とりあえず、delay.cにあった、如何にも最適化で消えそうなdelay_us関数

void delay_us(unsigned int time){     while (time--);} 

を、消えないように書き換えてみた。

void delay_us(unsigned int time){     while (time--) asm volatile("nop");} 

で、これでできたhexファイルを書き込んだら、あっさり動いた。ちゃんちゃん。

使っているのが WinAVRで、F_CPU値もちゃんと定義してあるのだから、<util/delay.h>の _delay_us()を使えばいいのにとか思う。
まだまだだな。中国人