公開日：2020/12/26

14th Season

#14-2　いちたすいちは？に～(OV7670)

　カメラモジュール(OV7670)をDUEで制御して、TFTシールドに画像を表示しようとしています。前回のハードウェア設計に引き続き、ソフトウェアの設計を続けて行きます。

ソフトウェアの設計

　完成したプログラムを見ていただくと、結構な物量が有ります。カメラ(OV7670)とTFTシールド(ILI9328)に加えてSDカードまで制御しているので、そりゃあ、大きくなります。本節では、ポイントとなる技術のみ、さらっと解説しておこうと思います。全体像は完成版プログラム(qvga_cam.ino)でご確認ください。

※新規に制御を追加するOV7670以外のモジュール(TFTシールドやSDカード)に関しては、過去記事で解説済みです。逆引き索引などから過去記事を当たってみてください。

入力クロック(XCLK)の生成

　「#13-2　MMLで三和音を演奏する」で使ったDUE(SAM3X8E)のPWMユニットを使って14MHzデューティ50%のPWMを作り、OV7670への入力クロックXCLKとします。
　前回示した接続表より、XCLKに割り当てたDUEの端子はPWML2(D43)なので、使用するのはPWMチャンネル2となります。

　　// PORT setting
　　digitalWrite (pin_XCLK, HIGH);
　　pinMode (pin_XCLK, OUTPUT);

　　// output clock XCLK=14MHz, D43(PA20/MCCDA/PWML2)
　　// PMC setting (PWM peripheral id=36)
　　REG_PMC_PCER1=PMC_PCER1_PID36;
　　// PWM setting
　　REG_PWM_CPRD2=F_CPU/14000000;
　　REG_PWM_CDTY2=F_CPU/14000000/2;
　　REG_PWM_CMR2=PWM_CMR_CPRE_MCK;
　　REG_PWM_ENA=PWM_ENA_CHID2;
　　// PWML2 (PA20) output
　　REG_PIOA_PDR=PIO_PDR_P20;
　　REG_PIOA_ABSR |= PIO_ABSR_P20;

　上のコードがPWMチャンネル2の初期設定該当箇所抜粋です。
　PWM_CPRD2レジスタがPWM周期、PWM_CDTY2レジスタがデューティです。デューティ50%のPWMにするためには、PWM_CPRD2＝F_CPU/14000000が偶数です。例えば、12MHzのPWMを出力しようとすると、

　　PWM_CPRD2＝F_CPU/12000000＝7　(周期レジスタ)
　　PWM_CDTY2＝F_CPU/12000000/2＝3.5　(デューティレジスタ)

と、PWM_CDTY2レジスタ値(デューティ)が割り切れず、整数に切り下げるとデューティ＝3/7≒42.9%になってしまうのです。14MHzなら、デューティレジスタ値が割り切れて綺麗にデューティ50%のPWMが出力できます。14MHz以外では、前回示した他の周波数でもOKです。
　ここで生成するクロックXCLKがOV7670制御の基本クロックとなるため、後でPCLKの周波数調整などを行う時のCLKRCレジスタ設定値などすべてがXCLKを基準に変化することになります。

※OV7670のデータシートには、XCLKのデューティ＝45(MIN)～55(MAX)[%](TYP 50%)が規定されているので、12MHzの時のデューティ＝42.9%だと、定格外使用となります。

OV7670からの出力データ取り込み手順

　データバスD7～D0や、ストローブ信号(VSYNC，HREF，PCLK)など、同時に参照する必要のある信号が有りますので、I/Oポート1本づつしか参照できないdigitalRead()関数などは使用しません。直接、DUE搭載MCU、SAM3X8Eのレジスタを叩いて制御します。
　直接レジスタを叩いてI/Oポートを制御する方法については、「#12-1　DUE＋TFTシールド」で解説済みなので、そちらを参照してください。
　また、こちらの接続表で、同時に参照する必要のあるデータバスD7～D0がPORT-Cの連続するビットに固まっていること、ストローブ信号(VSYNC，HREF，PCLK)もPORT-Cに固まっていることを確認しておいてください。さすがに同じポートに割り当てておかないと同時参照できないので、最初の基本設計段階で考慮しておくことが必要です。

　以下に、OV7670データシートからデータ出力タイミング図を引用して、データの取り込み手順を記します。

※OV7670データシートから引用

１）VSYNC＝1までポーリング。

この時点で、フレームの転送がスタートする。

２）VSYNC＝0までポーリング。
３）HREF＝1までポーリング。

この時点で、ラインの転送がスタートする。

４）データを取り込みながら、PCLK＝1となったら、直前に取り込んでいたデータが有効。

上図(Figure 5)の様に、PCLKの立ち上がりエッジのタイミングで、データが有効なため。
「PCLK＝1を確認後にデータを取り込む」では、間に合わないので注意。

∵上図(Figure 5)における、tHD＝8ns(MIN)なため(OV7670データシートより)。
※「スペック上は」。……上図(Figure 5)を見る限り、PCLKの立ち下がりエッジでデータが変化するので、ホールド規定tHDがこんなに厳しいハズがないのだけど……。

同様な理由で、少なくとも、このポーリング中は割り込みを禁止して取り込み処理に集中しておく。

５）PCLK＝0までポーリング。
６）HREF＝1の間、４）へ戻って繰り返し。
７）この時点でデータカウント≠WSIZ×2の場合はエラー。

∵1ライン分のデータWSIZ＝320ドット分を取り込んだはず。
実際のプログラムでは、多少、ロバストに処理してある(OV7670のバグを回避するため)。

８）1ライン分のデータをTFTシールドへ描画。

QVGAでは、VGA 1ライン分の休止期間(歯抜け)があるので、この間に描画。

９）ラインカウント＝HSIZになるまで３）へ戻って繰り返し。

ライン数HSIZ＝240ラインのデータを受信したら、QVGAデータの取り込み終了。
ラインカウント＜HSIZの間にVSYNC＝1となってしまったら、いくつかのラインを取りこぼしているので、エラー。

　OV7670は上図のタイミングで常にデータを垂れ流しているので、取り込む側がVSYNCなどでタイミングを取ってデータを取り込む必要があります。従って、ちょうどVSYNC＝1→0になった瞬間に取り込みを開始した時が、待ち時間最大となり、ほぼ1フレーム分の時間待ちが発生します。

　また、要となるのは一番高速に変化するストローブ信号PCLKの周波数です。DUE @84MHzがI/Oポートの状態を確認しながら、PCLKのエッジを取りこぼさないように掴む必要があるので、PCLKが速すぎると失敗します。
　PCLKの周波数fPCLKから周期tPCLK(＝1/fPCLK)が決まり、tP＝2×tPCLK ⇒ tLINE＝(640＋144)×tP ⇒ tFRAME＝(480＋30)×tLINEと、次々に決定して行って、最終的なフレームレートtFRAMEが求まるので、PCLKの周波数をどこまで上げられるか？がカギとなります。

※OV7670に「待った」をかけるプロトコルが無いので、OV7670が垂れ流してくるデータをひたすら取り込み続けるしか有りません。一度取りこぼしたら最後、「あっ、今のデータもう一回……」と言っても聞いてはくれません。

画像の保存

　折角カメラで撮影した画像を、TFTシールドに表示して終わりでは味気ないので、SDカードI/Fを使って、画像データを保存する手段を持たせておこうと思います。
　カメラから取り込んだ画像は自然画像なので、一般的にはJPEG等の非可逆圧縮アルゴリズムでセーブするのが正解ですが、ArduinoでチマチマとJPEG保存プログラムを組む気にはならないので、WindowsのBMP形式でセーブしようと思います。
　WindowsのBMPファイル形式については、「#13-1　TFTシールドにBMPを表示する」にて解説してありますが、あの時はロード側だったので、以下表にBMPセーブ時の対応として改めてまとめます。

BMPファイル			サイズ	内容	セーブ時対応
	BITMAPFILEHEADER
		bfType	2	BMPヘッダ識別子'BM'	0x4d42('BM')
		bfSize	4	ファイルサイズ	0x00025836 (320×240×2＋bfOffBits)
		bfReserved1	2	リザーブ１	0x0000
		bfReserved2	2	リザーブ２	0x0000
		bfOffBits	4	画像データの先頭ファイルポジション	0x00000036(54)
	BITMAPINFOHEADER
		biSize	4	sizeof(BITMAPINFOHEADER)	0x00000028(40)
		biWidth	4	画像横サイズ	0x00000140(320)
		biHeight	4	画像縦サイズ	0x000000f0(240)
		biPlanes	2	プレーン数	0x0001(1)
		biBitCount	2	ピクセルのビット数	0x0010(16)
		biCompression	4	圧縮形式	0x00000000(0)
		biSizeImage	4	画像データサイズ	0x00000000(0)
		biXPelsPerMeter	4	横方向解像度	0x00000000(0)
		biYPelsPerMeter	4	縦方向解像度	0x00000000(0)
		biClrUsed	4	カラーテーブルの数	0x00000000(0)
		biClrImportant	4	重要なカラーテーブルの数	0x00000000(0)
	uncompressed bit map data
		16 bit/pixel	2	[MSB]I(1)，R(5)，G(5)，B(5)[LSB]	320×240[ドット]繰り返し

　以上の様に、BMPヘッダの全項目が決め打ちの定数になったし、肝心なビットマップデータも非圧縮で丸ごと書き出したら終了なので、簡単に実装できそうです。以下、コード抜粋。あら、簡単。

　　// bmp file header
　　const　uint8　bmp_head[ ]=
　　{
　　　　// BITMAPFILEHEADER
　　　　0x42,0x4d,　　// 0x4d42('BM')
　　　　0x36,0x58,0x02,0x00,　　// 0x00025836(320*240*2＋bfOffBits)
　　　　0x00,0x00,　　// 0x0000
　　　　0x00,0x00,　　// 0x0000
　　　　0x36,0x00,0x00,0x00,　　// 0x00000036(54)
　　　　// BITMAPINFOHEADER
　　　　0x28,0x00,0x00,0x00,　　// 0x00000028(40)
　　　　0x40,0x01,0x00,0x00,　　// 0x00000140(320)
　　　　0xf0,0x00,0x00,0x00,　　// 0x000000f0(240)
　　　　0x01,0x00,　　// 0x0001(1)
　　　　0x10,0x00,　　// 0x0010(16)
　　　　0x00,0x00,0x00,0x00,　　// 0x00000000(0)
　　　　0x00,0x00,0x00,0x00,　　// 0x00000000(0)
　　　　0x00,0x00,0x00,0x00,　　// 0x00000000(0)
　　　　0x00,0x00,0x00,0x00,　　// 0x00000000(0)
　　　　0x00,0x00,0x00,0x00,　　// 0x00000000(0)
　　　　0x00,0x00,0x00,0x00　　// 0x00000000(0)
　　};

　　// header
　　for (ix=0; ix<int (sizeof (bmp_head)/sizeof (uint8)); ix++)
　　　　fout.write (bmp_head[ix]);

　　// bitmap
　　for (iy=0; iy<tft_SIZH; iy++)
　　{
　　　　for (ix=0; ix<tft_SIZV; ix++)
　　　　{
　　　　　　// BGR565:　bbbb bggg gggr rrrr
　　　　　　pix=tft_getpix (ix,iy);
　　　　　　// IRGB1555:　irrr rrgg gggb bbbb
　　　　　　pix=((pix<<10)&0x7c00) | ((pix>>1)&0x03e0) | ((pix>>11)&0x001f);
　　　　　　fout.write (pix&0xff);
　　　　　　fout.write ((pix>>8)&0xff);
　　　　}
　　}

　唯一、TFTシールドから読み出したBGR565フォーマットのピクセルデータから、BMPファイルの16ビットピクセル値、IRGB1555に変換が必要となります。
　BMPファイルは一番下のラインから順にデータを書き出すボトムアップなこともお忘れなく。

※BGR565からIRGB1555への変換で、Gデータを1ビット失っています。24ビットBMPにして、この1ビットもちゃんとセーブしたい方は、各自対応ください。

シリアルモニタコマンド

　いつもの様にシリアルモニタで受け付けるコマンドを用意して、デバッグと評価を実施したいと思います。
　シリアルモニタを使わずに、TFTシールドのタッチパネルなどでGUIを形成すれば、所謂「デジカメ」が完成します。ただ、酷くバグバグのOV7670をこれ以上いじりたいと思わないので、「デバッグおよび試行用」と割り切りたいと思います。

　デバッグ中には、「このレジスタにこの値を設定したらどうなる(どう変わる)のだろう？」と、いう試行錯誤が発生します。その度にプログラムを変更していては、都度、コンパイル＆書き込みが必要となります。DUEへのプログラム書き込みはUNOに比べて時間がかかるので、最小限に抑えないとデバッグが面倒です。
　そこで、TFTシールドやカメラモジュールのレジスタを直接触ることができる様に、アクセスコマンドを用意しておきます。
　OV7670の一部レジスタには、1つの設定項目が複数のレジスタに分散して配置されていて、レジスタを個別に書き込む方法だけだと設定し難い値が存在します。例えば以下の項目がそうです。

ゲインの手動設定
露出の手動設定
変換行列の設定

　デバッグを容易にするため、これらの項目を設定するためのコマンドも準備したいと思います。以下に目標仕様を記します。

　　シリアルモニタコマンドの目標仕様：

rdtft,<adr_hex>

TFTシールド(ILI9328)の内部レジスタ<adr_hex>からデータを読み出して表示します。
<adr_hex>は8ビット16進数で指定します。
【rdt】と短縮可能です。

wrtft,<adr_hex>,<dat_hex>

TFTシールド(ILI9328)の内部レジスタ<adr_hex>にデータ<dat_hex>を書き込みます。
<adr_hex>は8ビット16進数、<dat_hex>は16ビット16進数で指定します。
【wrt】と短縮可能です。

dmptft[,<adr_hex>[,<siz>]]

TFTシールド(ILI9328)の内部レジスタ<adr_hex>から<siz>個のレジスタを読み出して表示します。
<adr_hex>は8ビット16進数、<siz>は10進数で指定します。
<adr_hex>は、表示する際に16の倍数に切り下げます。
<siz>を省略すると、<siz>＝16が指定されたものと解釈します。
<adr_hex>以降が省略されると、全レジスタを表示します。
【dmpt】と短縮可能です。

rdcam,<adr_hex>

OV7670の内部レジスタ<adr_hex>からデータを読み出して表示します。
<adr_hex>は8ビット16進数で指定します。
【rdc】と短縮可能です。

wrcam,<adr_hex>,<dat_hex>

OV7670の内部レジスタ<adr_hex>にデータ<dat_hex>を書き込みます。
<adr_hex>は8ビット16進数、<dat_hex>は8ビット16進数で指定します。
【wrc】と短縮可能です。

dmpcam[,<adr_hex>[,<siz>]]

OV7670の内部レジスタ<adr_hex>から<siz>個のレジスタを読み出して表示します。
<adr_hex>は8ビット16進数、<siz>は10進数で指定します。
<adr_hex>は、表示する際に16の倍数に切り下げます。
<siz>を省略すると、<siz>＝16が指定されたものと解釈します。
<adr_hex>以降が省略されると、全レジスタを表示します。
【dmpc】と短縮可能です。
デバッグ中、色々なレジスタを設定した後で良い感じの出力が得られた時、このコマンドで全レジスタのダンプを取って保存しておくと、後でどのレジスタが利いていたのか調べることが可能です。

試行錯誤で色々なレジスタを設定していると、結局どの設定が利いていて、どの設定を変更したのか、明確に認識しきれない場合があるので、重宝します。

take

OV7670から1フレーム分のデータを取り込んでTFTシールドへ表示します。
【take】コマンドを実行すると、【itvl】コマンドの自動実行が無効になります(自動実行していても停止します)。

itvl,<interval_ms>

【take】コマンド相当の処理を<interval_ms>ミリ秒毎に自動的に実行します。
<interval_ms>は符号無整数です。<interval_ms>に0を指定すると、自動実行を停止します。
使い方としては：

【itvl,1】等として連続表示
カメラを動かして画角やピント等を調整
【mec】、【mgc】コマンドなどで画像を調整
「ここ」って言うところで【take】コマンドを実行
【save】コマンドでSDカードにBMPセーブ

mec,<mec_uint16>

自動露出制御(AEC；Automatic Exposure Control)を停止して、手動(Manual)で露出を設定します。
<mec_uint16>は、16ビットの符号無整数(10進数)です。
通常の照明下では30～60前後の値でした。

撮影条件によって大きく異なるので、この範囲に限らず、広く丁度良い画像になる値を探ってみてください。

自動ゲイン制御も同時に停止します。再び有効にするには【auto】コマンドを使います。

mgc,<mgc_uint10>

自動ゲイン制御(AGC；Automatic Gain Control)を停止して、手動でゲインを設定します。
<mgc_uint10>は、10ビットの符号無整数(10進数)です。
【mec】コマンドの設定値との関係になるので一概には言えませんが、800～1,000程度の数値になります。

撮影条件によって大きく異なるので、この範囲に限らず、広く丁度良い画像になる値を探ってみてください。

自動露出制御も同時に停止します。再び有効にするには【auto】コマンドを使います。

auto,<enable1_disable0>

自動露出・自動ゲイン制御を有効／無効化します。
デフォルトは、<enable1_disable0>＝1(有効)です。
【mec】／【mgc】コマンドを使い、手動である程度調整した後で自動制御を再び有効にすると、うまく自動調整できる場合があります。

mtx,<mtx1>,<mtx2>,<mtx3>,<mtx4>,<mtx5>,<mtx6>

RGB → Y/C分離信号への変換行列を設定します。
<mtx1>～<mtx6>には、9ビット符号付固定小数を3桁の16進数で指定します。

例）mtx,1D6,049,1E2,045,1EC,1CF

変換行列の仕様については、次回解説します。

dir[,<dir_name>]
ls[,<dir_name>]

SDカード内のファイルリストを表示します。

save,<file_name>

現在TFTシールドに表示されている画像をSDカード上のファイル名<file_name>にBMP形式でセーブします。
<file_name>が既に存在しているとエラーになります。

who
help

初期実験

　OV7670の設定レジスタ数が多くて、設定すべき値を絞り切れないので、まだ完成前ですが初期実験を実施して感触をつかんでおきたいと思います。

　こちら(前回)に従って外部回路を構築した後、プログラムをDUEにコンパイル＆書き込んで実験しました。プログラムは未完成なので、今回はリンクせず、次回完成版をリンクします。以下、実験中の様子です。

　　実験サンプル：【】内はシリアルモニタからの送信データ
　　INFO: OV7673.7fa2
　　INFO: ILI9328
　　RDY

　　【take】
　　OK: took a picture

　OV7670モジュールからデータを取り込んで表示させてみました(以下図)。

※モデルさんは筆者宅にお越しいただいたドロッセルお嬢様。サングラスが赤で、上画像見たままの方向で左下に映り込んだ万能基板が緑色です。

　まず、映像が表示されたので、VSYNC，HREF，PCLKなどのストローブ信号に従ってデータを取り込む方法に誤りが無いことが判りました。→OK
　しかし、色合い🎨が変です。どうも、赤色の被写体が緑になって、緑色の被写体が紫っぽくなっている模様。

　前回の検討でOV7670とTFTシールドのピクセル値の合わせ込み(RGB565で統一)を検討して、その通りに実装したつもりだったのですが、間違っているのでしょうか？

　　実験サンプル：【】内はシリアルモニタからの送信データ
　　【wrc,71,b5】
　　OK: camera write [0x71]=0xb5

　　【take】
　　OK: took a picture

　OV7670のテスト機能で、カラーバーを表示するビットに1を立てました。元に戻す時は【wrc,71,35】としてください。読み出したカラーバーが以下図です。

　期待値の正確なところはわからないのですが、R，G，B各原色ON／OFFの組み合わせで表示可能な8色：黒(0)、青(1)、赤(2)、マゼンタ(3)、緑(4)、シアン(5)、黄(6)、白(7)が順番通りに並んでいるので、恐らく、期待値通り、正しいと思われます。→OK
　と、言う事は、やはりOV7670とTFTシールド間のピクセルフォーマットは正しく合わせ込めているのでしょう。先ほどのカメラ映像で、色合いがおかしかったのは何か他の問題ですね。設定が足りていないのか、間違えているのか？

　OV7670の制御には、ここから更に長い道のりが待っていました。この先のドタバタは、また次回お話いたします。