● 実験テーマ93
「PIC16F_心電計の、QVGA化実験」
（モノクロ液晶を、カラーQVGA液晶に置換えてみました。PIC16F1983（8bit
CPU／16MHz）で、QVGAに心電波形を表示する実験です。）
以下、この実験の顛末記です。
■ 2017.6.21～ 2017.6.22
・前テーマ92の末尾にも書いたが、液晶をもう少し、X方向の分解能の高い（今128dotだが、256dotのモノクロがあればよいのだが・・）
ものにと、探していたが、どうもモノクロで、x=
256dotは特殊らしく、流通に難がありそうなので断念した。
モノクロ＋バックライト無しで動作させているのは、バッテリー駆動前提に考えていたためだが、
今回は、多少消費電流が増えても良しとした。（主にACアダプターでの使用）
カラーQVGAなら、x= 320dotあるので、サンプル周期も、現在の半分でOKである。
つまり、Tsamp=20mS→ １000mS/Dが、Tsamp=10mS→ 500mS/Dになり、
Tsamp=10mS→ 500mS/Dが、Tsamp=5mS→ 250mS/Dに、波形再現性も向上する。
・将来、P板化する際も、ざっと見では、2.4inchQVGAにしても、100
x 80mmサイズの、P板に、全て部品は収まりそうである。
QVGAと、P板間が、11mmあるので、その下の空スペースに十分部品を乗せられる。
とりあえず、PIC16F1983で、カラーQVGA液晶の表示テストをやってみる。（このPICでは初）
実験には、モノクロのECGの実験時に作った、ユニバーサル基板を流用することにした。
前に作った、モノクロ→ QVGA接続変換基板を使えば、そのまま差し替えでスマートに実験出来る。
・PIC16F_QVGA_TESTプロ作成済み。
コンパイルで、Error= 0, Waming= 8件ほど出た。
どうも、XC8では、ストリング出力関数で、例えば、lcd_str("123");と書くと、ワーニングになるようである。
これを回避するには、冒頭で、str123[]= "123";
と宣言してから、lcd_str("123");とやるか、
sprintf(str123, "123");
lcd_str("123");
とやればよいようであるが、ワーニングなので、実際に動かして動いたら、そのままにすることに。
（直接的でなく、面倒なので・・）
・余り深く考えず、進めて行った結果か、最初の動作チェックは、上手く行かなかった。
P_ONで、バックライトがONするだけで、ダンマリ。
最初に気が付いたのは、QVGAのロジック電源は、3.3Vということ。（気付くのが遅かった・・・）
モノクロは、5Vだが。
なので、まずQVGAへの、5Vを、3.3V供給に修正した。
むろん、3.3Vレギュレータが必要になる。
手持ちが無かったので、前作で使わなくなった、実験テーマ21の、PIC24F
MP3（I2C LCD）の基板からの
部品取り（TA78033）で何とかした。
これでやってみたが未だ駄目。
冷静に考えてみると。今、PICは、5V動作なので、QVGAとのロジック・インターフェースのレベルが合わない。
5Vに対して、3.3Vロジック。これでは駄目なのも当然である。（これも気付くのが遅かった・・・）
QVGAを装着しない時は、3.3V供給ピンの、2pinに、3.3Vが出ているが、装着して測ると、4.98V位に
上がってしまう。
I/Fの電位差で、5V電流が、3.3V I/Fに流れ込むからだと思われる。
これの対策だが、PIC16F1983は、3.3Vでも動くので、まずは、PICを、5V→
3.3V電源に変更する。
アンプ系の電源も、3.3Vにしないといけない。
ヘッドアンプ部は、±5Vで動かしているが、出力は、約1Vp-pなので、レベル的に問題ない。
ユニバーサル実験基板の方の電源は、Vcc=
3.3Vと、5Vを選択出来るように、ピンを立てた。
これで、モノクロ／QVGAともに切替えて実験出来る。
■ 2017.6.23
・昨日の修正を行った。
液晶コネクタの、2pinは、QVGAを装着した状態でも、3.3Vを確認。
だが症状は変わらず。ソフトがおかしい？
＜試行・調査＞
① ここで、液晶をモノクロに戻し、PICを3.3V電源にして、PIC16F_GLCD_TEST.hexを書込み
動くか確認。（大型のSG12864Aは、スペック上は、5V電源だが、3.3Vでも動く。）
これは動いた。
なので、PIC16F1983の、3.3V動作は問題なし。（デバイス認識もOK）
② 一箇所誤り発見
QVGAライブラリ・ソースの出力関数で、16bitデータを上位、下位8bitに振分け処理している
ところが、LATBのまま。
データポートは、PORT Aにしたので、LATAに修正。しかしこれでも駄目。
③ プログラムが、RUNしているか確認。
LCD初期化・画面クリア後に、LED ONして止めてみた。
これは、OK。RUNしている。
④ XC8の場合、ポート出力は、LATと書かないで、PORTを使う。（実際には、ラッチ出力をアクセス）
ヘッダーで定義されている、LCD_DB PORTA
を使えばよい。
LATA→ LCD_DEBに修正。これでも未だ駄目。
⑤ XC8のポートレジスタ（R**）は、8bitしか無い。
なので、今元にしている、C30で書かれているライブラリソースの、LCD_DB
& 0X00FF
というマスク処理をしても意味がない。
LCD_DB = (index & 0xFF00) | (LCD_DB & 0x00FF);→ LCD_DB = (unsigned char)((index & 0xFF00)>>8);
に修正。これでも未だ駄目。
⑥ 判らなくなったので、ここで液晶のコントロール信号（RCポート）の単体チェックをしてみた。（現在Fcy=32MHz動作）
RC1： RESET/→ × Hiぱなし。
RC3： CS/ → 〇
RC6： RS → × Hiぱなし。
RC7： WR/ → 〇
何故か、CCP機能とのマルチ機能ピンになっている、RC1/CCP2と、RC6/CCP3がおかしい？
■ 2017.6.24
・どうも、32M動作だと、RCポート出力の一部が正しく動作しないようである？（PICを壊したか？差替えチェックはしてない）
パタパタ変化せず、レベル固定になる。
PLL未使用の、8M, 16M動作は、OKを確認。
そこで、16M動作に修正することにした。（消費電流的には有利）
これで表示テストは大方OKになったが、表示テストの最初で、VRAMのゴミが残ってそれが、Lcd
Clearする間、見えて
しまうのが気になった。
これは、PIC24Hの40M動作では気にならなかったが、現在は16Mと遅い。そのせいと思われる。
また液晶をUL024TFにすると、これは殆ど気にならなかった。今は、S95417である。
いろいろ調べている内に、問題は解決した。
lcd_Init関数の最後、いきなり、lcd_out(0x0007, 0x0133); // 262K color and display ON
とやっているが、その前に、メインでやっていた、lcd_Clear(BLACK);を追加。
つまり、FFFFでVRAMを埋めてから、DISPLAY ON。（メインのlcd_Clear(BLACK);は削除）
これで良くなる。
■ 2017.6.25
・本番ソフトの検討を始めた。
モノクロの時と異なるのは、主に以下の、5点
① Fcy= 8M→ 16Mになったので、T2設定（PR2設定）変更
PR2= 124→ 249に変更
② sample_cnt= 16;→ sample_cnt= 8;
// 250mS/D時：0.625*8=5mS周期：波形BUFへの格納処理
sample_cnt=
32;→ sample_cnt= 16; // 500mS/D時：0.625*16=10mS周期：波形BUFへの格納処理
③ 遅延関数の為の、クロック定義の変更
#define _XTAL_FREQ 8000000→ #define _XTAL_FREQ 16000000
④ QVGAの全画面クリアは時間が掛かるので、そのチラツキ対策が必要
⑤ HOLDタイミングの変更
これ位が変更点と思って、ソフトを作成した。
ところが、コンパイルすると、WAVbufferサイズの、512ワード（1024バイト）は確保出来ない旨のエラー発生。
最初に気が付くべきだったが、 PIC16F1938の、SRAMエリアは、最大1024バイトなので、当然である。
QVGAは、x方向分解能= 320dotなので、トリガ点からの表示用に、321ワード＋トリガ検知トライ回数190回の、
比較用のデータ数：190ワードで、511ワードなので、切りの良いところで、WAVbufferサイズを、512としていると解釈している。（オリジナルは後閑さん作）
SRAM容量の多い、PIC24H等に変えるのが良いのだろうが、せっかく、8bitのPIC16F1983で、QVGAを動かせたので、
トリガの掛かり具合が、サンプル周期の遅いレンジで多少悪くなるのは妥協して、トリガ検知トライ回数190回を
96回までに減らし、WAVbufferサイズを、512ワード（1024バイト）から、416ワード（832バイト）に減らした。
これでコンパイルしたら、エラーは無くなった。
しかし、SRAMの使用量を見ると、約98%でギリギリOKである。（もうこれ以上機能追加は出来ない）
これで動かしたら、シングル・トリガ・モード以外は、OKになる。
■ 2017.6.26
・シングル・トリガ・モードでの症状例であるが、以下である。
① まず、AUTOで、1Hz入力する。
② SINGLEに切替えて、READY SWをON→ LED ONで、トリガ待ち
③ トリガすると、1Hzの波形表示で止まる。
④ ここで、F.Gを、2Hz出力にする。
⑤ READY SWをON→ LED ONで、トリガ待ち
⑥ トリガすると、前に、ホールドした波形がクリアされず残ったまま、2Hz波形が多重に表示。
これは、なんということなかった。
シングル・トリガ・モードでは、冒頭に全画面クリアが必要だが、それが抜けていただけである。
ただ、Fcy= 16MHzでは、全画面クリアに数秒（約3～4秒位）かかるが、これは妥協した。
これで大方OKになる。
ちょっと気になることと言えば、500mS/Dの時、観測出来る、R波が、5波に増えるが、そのピークレベルの
バラツキがやや目立つ。これも妥協した。
WEB検索で、他の工作例を見ても、完全に、レベルは一致してなく変動するようだ。
また、変動の度合いも、電極が皮膚に馴染んでくると少なくなってくる。
＜回路図＞
・こちらから、どうぞ→ 「心電計制御部実験（QVGA液晶版）」
＜最終ソース及びヘッダファイル＞
・こちらから、どうぞ→ 「PIC16F_ECG_Scope_V3.c」
/// GLCDライブラリ
colorlcd_libPIC16FVH.c
colorlcd_libPIC16FVH.h
///
アスキーフォント
ASCII12dot.h
