ＰＩＣ−ＵＳＢＩＯ ｕｓｉｎｇ ＢＡＳＩＣ
〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜
ＵＳＢインターフェースを内蔵したＰＩＣを使ってＷｉｎｄｏｗｓパソコンで外部回路を制御するための各種Ｉ／Ｏ基板の製作記事です。
〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜
［第１４０回］
●ＰＩＣＵＳＢＩＯ−０３（８９）Ｉ２Ｃモード（１１）マスターモード（１０）ＤＳ１３０７受信プログラム（４）
前回からの続きです。
ＤＳ１３０７のＤａｔａ ＳｈｅｅｔにはＤＳ１３０７からデータを受信する場合には最後のデータを受信したときにはＡＣＫではなくてＮＡＣＫを返すことと書いてありました。
それで受信プログラムをそのように直したところなるほどプログラムを繰り返し実行しても正しく受信できるようになりました。
しかしなんとなくすっきりしないものが残ります。
確かにＤＳ１３０７のＤａｔａ Ｓｈｅｅｔにはそのように書いてあります。
しかしＰＩＣ１８Ｆ１３Ｋ５０のＤａｔａ Ｓｈｅｅｔにはそんなことは書かれていないようです。
ちょいと納得がいかない気持ちです。
実際に受信するときの波形を見てみれば何かがわかるかもしれません。
そこでプログラムを変更したあとのプログラムと変更する前のプログラムを実行してその両方の波形をＣＰＬＤロジアナで観測してみました。
すると最後のＳＴＯＰコンディションのところの波形に異変がおきていました。
こちらはプログラム変更後の最後のデータ受信部分の波形です。
見えている部分ではクロック数は８クロックで最後の９クロック目がありません。
ＰＩＣＵＳＢＩＯ用のＢＡＳＩＣインタプリタのＰＩＣＯＵＴ、ＰＩＣＩＮは実行するのに時間がかかります（［第１２９回］参照）。
ＮＡＣＫは８ビットの受信データをＰＩＣＩＮ関数で読んだあとでＰＩＣＯＵＴ命令でＳＳＰＣＯＮ２に値をセットすることで送信されますからＰＩＣＩＮ＋ＰＩＣＯＵＴの時間がかかります。
約９ｍｓｅｃ後に９番目のクロックが出力されています。
ＰＲＯＢＥ０がＳＣＬ（クロック）でＰＲＯＢＥ１がＳＤＡ（データ）です。
ＮＡＣＫは’１’ですから９番目のクロックの前後で’Ｈ’になっています。
そしてこちらが’ＳＴＯＰ’です。
ＰＩＣ１８Ｆ１３Ｋ５０のＤａｔａ Ｓｈｅｅｔの説明の通りクロックが立ち上がる少し前にＳＤＡが一旦’Ｌ’になったあとクロックが立ち上がったあとで’Ｈ’になっています。
間違いなくこれはＳＴＯＰコンディションです。
さてそれでは変更前のプログラムの波形を見てみます。
最後の受信データのところはさきほどの波形と同じです。
変更前のプログラムではデータの受信後は全てＡＣＫを送出しています。
最後のデータの受信後もＡＣＫです。
ＡＣＫは’０’です。
９番目のクロックのところで’０’（Ｌ）を出力しています。
ここで「あれ？」と思いました。
なんだかＳＤＬがずっと’Ｌ’のままのように見えます。
うむむむ？
ＡＣＫ、ＮＡＣＫの送出後はラインは開放されるのじゃなかったか？
ラインを開放するとハイインピーダンスになってプルアップ抵抗のせいで’Ｈ’になるはず…。
なんだか「出力」が’Ｌ’のままになっているみたいです。
ちょいといやな予感です。
ＳＴＯＰコンディションのはずなのですが。
やっぱり。
ＳＤＡはずっと’Ｌ’のままでした。
これではＳＴＯＰコンディションにはなりません。
これがその後に受信プログラムが正しく実行できなくなってしまう原因のようです。
しかしなぜこんなことがおきてしまうのか？
これはＩ２Ｃのルールなのか？
きっとそうに違いない…。
しかししかし。
それならばなぜこのこと（最後のデータの受信後はＮＡＣＫを送る）がＤＳ１３０７のＤａｔａ Ｓｈｅｅｔに明記されているのに
もっとおかしなことにはこの現象から抜け出すには一旦ＰＩＣＵＳＢＩＯ−０３とＤＳ１３０７の電源を切って（具体的にはＵＳＢケーブルを外して）ＢＡＳＩＣも終了したのち再度ＢＡＳＩＣを起動してＵＳＢ接続をしなければならないという点です。
Ｉ２Ｃに関係するレジスタをクリアしてもだめ、割込みフラグをクリアしてもだめ、一度 Ｉ２Ｃモードを無効にしてから再度送信プログラムからやり直しても一旦前回のような状態になってしまうともう正常な通信はできません。
そんなおかしなことってあるのか？
謎はかえって深まるばかりでありました。
このあと私は思い違いをしていたことにやっと気がつくことになります。
しっかり「先入観」に支配されていたのでありました。
次回に続きます。
ＰＩＣ−ＵＳＢＩＯ ｕｓｉｎｇ ＢＡＳＩＣ［第１４０回］
２０２２．１２．２８ｕｐｌｏａｄ
前へ
次へ
ホームページトップへ戻る