電源を投入したときに最初にＩコマンドを実行すると１回だけこのエラーが表示されます。
Ｅ：９２はＳＤカードの情報が正しく読み取られなかったときに表示されるエラーコードです。
このエラーの回避方法についても後ほど考えてみるつもりです。
ということで今回の問題についてです。
ログの終わりに近いところでＩコマンドの入力に対するエコーがＦＦと表示されたあとＥ：８２と表示されています。
ここは今までのログではＥ：ＦＦになっていました。
今まではそこのところは何の対策もとっていませんでした。
何も対策をしないままだと同じエラーが繰り返されます。
そこでプログラムを修正してＥ：ＦＦの代わりにＥ：８２を表示するようにしました。
Ｅ：８２は「コマンドコードではない」というエラーです。
これは新しく作ったエラーコードです。
そしてプログラムが不正な流れにはまってしまっていると判断してその流れから抜け出して通常のコマンド入力処理に戻るようにしました。
ちなみにその上のところで
ＩＮ ８２
を実行して
７Ｄ
という値を得ています。
エラーが発生するメカニズムにちょいと気がついたところです（問題解決への伏線です）。
このことについては後で説明することになると思います。
この”８２”は８２Ｃ５５のアドレス（ＰＯＲＴＣ）のことでＥ：８２の表記とは関係ありません。
動作の確認のため送受信の波形をＣＰＬＤロジアナでモニタしました。
ＣＰＬＤロジアナの画面です。
ＣＰＬＤロジアナについてはこちらを参照願います。
確かに。
ロジアナは強力な助っ人でありました。
ＰＲＯＢＥ０は８２Ｃ５５のＰＣ１からのクロック出力です。
ＰＲＯＢＥ１は８２Ｃ５５のＰＣ０からのデータ出力です。
Ｉコマンドのコマンドコード１３（１１００１０００）が出力されています。
ＰＲＯＢＥ２はＰＩＣ１８Ｆ２５５０からのＲＥＡＤＹ／ＢＵＳＹ出力です。
受信または送信時にはＬ（ＲＥＡＤＹ）を出力します。
ＰＲＯＢＥ３はＰＩＣ１８Ｆ２５５０からのデータ出力です。
このときはＨになっています。
このあと通常なら出力したコマンドコードのエコーがＰＩＣ１８Ｆ２５５０から返されます。
下は問題の”ＦＦ”が返っているところです。
この応答があるまでに５ｍｓ以上かかっています。
この間ＰＩＣ１８Ｆ２５５０は何をやっているのか？
それについても今はそういうことだったかと合点しています。
ＰＲＯＢＥ３はずっとＨになっているのでデータとしては”ＦＦ”になります。
全てがわかった今では理解できることなのですが、実はこのときＰＩＣ１８Ｆ２５５０は「受信モード」になっていてコマンドコードの受信待ちになっています（食い違いが起きています）。
ＰＩＣ１８Ｆ２５５０は「受信モード」なので”ＦＦ”を出力しているのではなくて何も出力していなくて出力ラインがずっとＨになっているのですがそれが結果としてコマンドエコー”ＦＦ”としてＮＤ８０Ｚ３．５に読み取られます。
［第９９回］の説明では「受信なのでラインがハイインピーダンスになるが８２Ｃ５５の入力ラインはプルアップされているのでその結果として”ＦＦ”が入力される」と書きましたがそれは誤りでした。
ＰＩＣ１８Ｆ２５５０が受信モードのときでもＰＩＣ１８Ｆ２５５０のデータ出力がハイインピーダンスになることはありません。
ＰＩＣ１８Ｆ２５５０のデータ出力ラインは最後に出力したデータのビット７の状態によってＨかＬを継続します。
しかしこのときは別の理由によってＰＩＣ１８Ｆ２５５０のデータ出力ライン（ＰＲＯＢＥ３）はＨになっていたのでした。
一方でＮＤ８０Ｚ３．５の側は「受信モード」のときはデータ出力ラインは常にＨ出力になります。
こちらも出力がハイインピーダンスになっているのではありません。
（こういうことが手間がかかっても当ブログ風記事を書いているからこそ気が付く大きなメリットです。自分のためにノートに製作メモを書いているだけでは気が付かずに思い違いをしたまま過ぎてしまいます）
コマンドのエコーを受信した次の受信です（上で書きましたように食い違いがおきているために実際はエコーではないのですが）。
正常ならばここは正常に処理が行なわれたというしるしとして”００”がＰＩＣ１８Ｆ２５５０から送られます。
今回のプログラム修正をする前は食い違いのためＰＩＣ１８Ｆ２５５０からは「エコー」として”ＦＦ”が出力されていたのですが、ＮＤ８０Ｚ３．５の側はそれをエラーコードとして受信しＥ：ＦＦと表示しました。
今回の修正によってＰＩＣ１８Ｆ２５５０はエラーコード”８２”を出力しています。
ここで「食い違い」が起きたときのその後のＮＤ８０Ｚ３．５とＰＩＣ１８Ｆ２５５０の動作について整理しておきます（「食い違い」の原因についてはまた後での説明になります）。
上記の後、ＮＤ８０Ｚ３．５は次のコマンドを出力します。
ＰＩＣ１８Ｆ２５５０は”ＦＦ”をコマンドコードとして受信したのでここでエラーコードを出力します。
両方とも出力ですが双方の出力ラインは別になっているのでデータの衝突は起きません。
どちらも出力モードのときはデータの入力は行ないませんからこのときは両方とも正しく出力が行なわれたと判断して次のステップに進みます。
その次のステップではＮＤ８０Ｚ３．５は「受信」モードとなって「エコー」の受信待ちになります。
ＰＩＣ１８Ｆ２５５０も「受信モード」となってコマンドの受信待ちになります。
ということで食い違いが起きたままエラーの発生が繰り返されます。
それはプログラム修正をする前のプログラムの動作です。
今回のプログラム修正によってそのような繰り返しが起こらないように改めました。
上は食い違いが起きたときのプログラム修正後の送受信波形でしたが、参考までに食い違いが起きなくてＩコマンドが正しく処理されたときの送受信波形を下に示します。
最初にＮＤ８０Ｚ３．５（の８２Ｃ５５）からコマンドコード１３（１１００１０００）が送信されその直後に今度はＰＩＣ１８Ｆ２５５０からエコーとして同じコード１３が出力されています。
先ほどはＰＩＣ１８Ｆ２５５０から応答があるまで５ｍｓ以上かかっていましたが今回は即答しています。
続いてＩコマンドの処理が正常に完了したことを示すコード００がＰＩＣ１８Ｆ２５５０から出力されました。
出力されるまでに約１８ｍｓかかっています。
ＳＤカードの初期設定にはそのくらいの時間が必要なようです。
ＰＩＣ１８Ｆ２５５０のデータ出力ラインはずっとＬのままで”００”が出力されていることを示しています。
こちらも参考までに、上のほうで書きましたＥ：９２が表示されたときの波形です。
コード”１３”を出力してエコーで同じコードが返ってくるところまでは上と同じです。
その後ＰＩＣ１８Ｆ２５５０からエラーコード”９２”が出力されました。
エラーコードが返ってくるまでに７２ｍｓもかかっています。
正しくアクセスできたときは１８ｍｓでしたからそれに比べるとちょっと長いようです。
上のほうに書きましたようにこのエラーは電源投入後の最初のＩコマンドのときだけ表示されます。
なぜそうなるのか、またどうすればそれを回避できるのか、時間ができたときに考えてみることにします。
ＰＩＣＢＡＳＩＣコンパイラ［第１０１回］
２０２３．１１．１６ｕｐｌｏａｄ
前へ
次へ
ホームページトップへ戻る