ＰＩＣＢＡＳＩＣコンパイラ
～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～
まるでインタプリタ。でもコンパイラです。超カンタン超シンプルです。
～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～
［第２２８回］
●ＰＩＣ１６Ｆ８４Ａ（５）Ｖｐｐをオシロで確認
前回のＣＰＬＤロジアナを使ったＰＧＣとＰＧＤの観測によってＬｏａｄ Ｃｏｎｆｉｇコマンドが終った直後あたりでＰＧＣとＰＧＤのパルス出力が突然Ｌになってしまうことがわかりました。
ＰＩＣ１８Ｆ１３Ｋ５０のＰＩＣ ＷＲＩＴＥＲプログラムが突然暴走してそこでハングアップしたかのような状態に見えますが、実はその後もＷｉｎｄｏｗｓ側のＣ＋＋プログラムとＰＩＣ１８Ｆ１３Ｋ５０との間のＵＳＢ通信は続いていてＰＩＣ１８Ｆ１３Ｋ５０からは「読み取ったはずの」ＰＩＣ１６Ｆ８４ＡのデバイスＩＤとＣｏｎｆｉｇのデータがＵＳＢ送信されてきています。
ということから考えると。
余りに奇妙でありえないことのように思えるのですが。
ＰＩＣ１６Ｆ８４ＡがＰＧＣとＰＧＤの端子を突然出力モードにしてしまってＬを出力してしまうのではないか。
早い話がＰＩＣ１６Ｆ８４Ａの暴走です。
そんなことがありか？
それしかほかに考えられることはありません。
ＰＩＣ１６Ｆ６２７もＰＩＣ１６Ｆ８４もそんなことはありませんでした。
またＰＩＣＫＩＴⅡではＰＩＣ１６Ｆ８４Ａもまともに書き込みも読み出しもできています。
だとすると。
ＰＩＣ１６Ｆ６２７やＰＩＣ１６Ｆ８４ならよいけれどＰＩＣ１６Ｆ８４Ａに対してはＰＩＣ ＷＲＩＴＥＲプログラムが正しく対応できていない、ということになります。
実際にそれまでＰＩＣ１６Ｆ８４Ａの書き込みや読み出しがまったくできなかったのが／ＰＩＣＲＤ１と／ＰＩＣＲＤを２本立てにしてテストをしてみたところとりあえずはまともに動作するようになりました（［第２２５回］）。
それでもなおおかしなところが残っているのはそのあたりのプログラムにもう一工夫が必要ということではあるまいか。
それは。
ひょっとすると、あのあたりではないか？
突然ひらめいた考えがだんだんと確信に変わってきました。
まま。
その前に。
まずはＰＩＣＫＩＴⅡのＶｐｐの出力をオシロスコープで確かめてからにいたしましょう。
どう考えてもやっぱりそこが怪しい。
そこしかない。
そういうことで。
下がオシロスコープで観測したＰＩＣＫＩＴⅡのＶｐｐとＰＧＣの波形です。
上側（ＣＨ１）がＶｐｐの波形です。
Ｖｐｐ電圧は＋１３Ｖほどもありますから垂直のスケールは５００ｍＶ／ｄｉｖにしてあります（１：１０プローブですから入力信号は１／１０になります）。
下側（ＣＨ２）はＰＧＣです。
ＰＩＣＫＩＴⅡにＰＩＣ１６Ｆ８４ＡをセットしてＲＥＡＤを実行したときの波形です。
Ｖｐｐの波形を観測することが目的ですから時間軸はこのくらいにしないと観測できません。
それではＰＧＣは速すぎるので上の画像のようにしか捉えられません。
問題はＰＧＣではなくてＶｐｐです。
どうやら狙いが当たったようです。
Ｖｐｐは何回かＬになっています。
ＶｐｐはＭＣＬＲ端子に入力されているのでそこがＬの期間はＰＩＣ１６Ｆ８４Ａにリセットがかかっていることになります。
データシートから推測していたよりも随分長いリセット期間で１００ｍｓから２００ｍｓもあります。
うむむむ。
この波形だけではどうしてこんなに何回もリセットが必要なのかはよくわからないのですが、とにかくリセットに１００ｍｓぐらいはかけなければならない（もしくはかけたほうがよい）のは確かなようです。
どうやらそこが決め手のように思われたので／ＰＩＣＲＤ１の先頭部分でＶｄｄとＶｐｐをほぼ同時にＯＮにしていたところを最初にまずＶｄｄをＯＮにして（このときＭＣＬＲ＝Ｖｄｄ＝０Ｖ）それから２００ｍｓウェイトしてからＶｐｐ＝＋１３Ｖにしました（これもあとで確認したのですがどうもＶｐｐ＝９Ｖではだめで＋１３Ｖぐらいにする必要があるようです）。
そのようにＰＩＣ ＷＲＩＴＥＲプログラムを変更してトライしてみたところ。
できました！