ＰＩＣＢＡＳＩＣコンパイラ
〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜
まるでインタプリタ。でもコンパイラです。超カンタン超シンプルです。
〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜

［第２２７回］



●ＰＩＣ１６Ｆ８４Ａ（５）ＣＰＬＤロジアナで確認

いったい何がおきているのか。
なぜ／ＰＩＣＲＤ１で００００が返ってきてしまうのか。
Ｗｉｎｄｏｗｓ側のプログラムもＰＩＣ　ＷＲＩＴＥＲのプログラムも繰り返し確認したのですがそんなおかしなことになる要素は全くみつかりません。
とにかく最初の起動時に異常が起きることが多いという点に何かわけがありそうです。
いったい何が起きるのかそれをロジアナで確認してみたところ異常な現象が確認できました。
下がその画像です。



ＣＰＬＤロジアナで記録した／ＰＩＣＲＤ１を実行したときの波形です。
ＰＲＯＢＥ０がＰＧＣ（クロック）です。
ＰＲＯＢＥ２がＰＧＤ（データ）です。
ＰＲＯＢＥ０（ＰＧＣ）の最初の立下りから記録が開始されます。
ＰＧＣの最初の１クロックの立下りが０μｓです。
最初はデータ部が全部０のＬｏａｄ　Ｃｏｎｆｉｇコマンドです。
ＰＧＣが連続して２２個出力されています（最初の１クロックは０μｓの前にありますから見えているのは２１クロックです）。
その間ＰＧＤはずっとＬになっています。
コマンド部（００００００）とデータ部（最初に１ビットの０、続いて下位８ビット００００００００、続いて上位６ビット００００００、最後に１ビットの０）です。
最後のクロックは８０μｓのところです。
その次から６回のＩｎｃｒｅｍｅｎｔ　Ａｄｄｒｅｓｓコマンド０６（ビット列は下位ビットから送出されるので０１１０００になる）が送出されるはずなのですが２ビット目（９０μｓのところ）で突然クロック出力がなくなっています。
ロジアナの画面はそこで終っているように見えますがこのあとずっと最後までＰＧＣもＰＧＤもＬのままです。
これだけを見るとＷｉｎｄｏｗｓプログラムかＰＩＣ　ＷＲＩＴＥＲプログラムに異常が発生してそこでハングアップしてしまったようにも思えますがＰＩＣ　ＷＲＩＴＥＲプログラムがハングアップしていない証拠にそのあと普通にデバイスＩＤとＣｏｎｆｉｇデータをＵＳＢ送出しています。
そのデータが全部０なのはおそらくＰＧＤラインがＬになりっぱなしだからです。
何らかの原因でＰＧＣとＰＧＤのラインがＬになってしまっているようにみえます。
おそらくそのことにＰＩＣ（ＰＩＣ１８Ｆ１３Ｋ５０）は気がつかないでＰＧＣを出しているつもりでＰＧＤを読み取っているのではないかと思います（なぜそんなことが？ありえないと思うのですが…）。

続いてもう一度／ＰＩＣＲＤ１を実行すると今度はまともな値が返ってきます。
ロジアナの記録を見ても異常はありません（下の画像）。



さきほどは９０μｓのところで信号が途切れてしまったのですが今回はまともです。
この後ろの波形も確認したのですがちゃんとＩｎｃｒｅｍｅｎｔ　Ａｄｄｒｅｓｓコマンドのコードがふつうに出力されています。

念のためにＰＩＣ１６Ｆ８４についてもテストをしてみました。
こちらは最初からまともな値が返ってきます（下の画像）。



ＰＩＣ１６Ｆ８４の場合デバイスＩＤは設定されていないようで３ＦＦＦが返ってきます。

さて。
異常は確認できましたが…。
これからどうしましょう。

ＰＩＣＢＡＳＩＣコンパイラ［第２２７回］
２０２５．３．７　ｕｐｌｏａｄ

前へ
次へ
ホームページトップへ戻る