その結果、先ほどのログでは”３Ｄ”が表示されましたが今回は”７Ｄ”が表示されています。
ＩＮ ８２を実行したときに”７Ｄ”が表示されていると次にＪＰ Ａ０００を実行し、続いてＩコマンドを実行すると”ＦＦ”エラーが発生し、”３Ｄ”が表示されたときはエラーは発生しません。
もっと正確に言うとＩＮ ８２で表示される値がビット表現で０１ＸＸ ＸＸＸＸのときにエラーになり００ＸＸ ＸＸＸＸのときにはエラーになりません。
ＩＮ ８２は８２Ｃ５５のＣポートの入力値を読む命令です。
Ｃポートのビット７（ＰＣ７）にはＰＩＣ１８Ｆ２５５０のＲＡ３の出力が接続されていてビット６（ＰＣ６）にはＲＡ２が接続されています。
Ｅコマンドでプログラムを終了したときにＰＩＣ１８Ｆ２５５０のＲＡ３の出力が”０”でＲＡ２の出力が”１”のときにエラーが発生し、ＲＡ３の出力が”０”でＲＡ２の出力も”０”のときにはエラーになりません。
ＲＡ３はＲＥＡＤＹ＿／ＢＵＳＹ出力で通常はＰＩＣ１８Ｆ２５５０は受信待ちになりますからＲＡ３＝０でスタンバイしています。
ＲＡ２はデータ出力で次に何かを出力するまで最後に出力したときのままになっています。
そこが”１”だとエラーが発生するということがわかりました。
前回の検証でＰＩＣ１８Ｆ２５５０がＲＥＳＥＴから開放されてプログラムが起動されてＴＲＩＳＡ命令が実行されたときにＲＡ３＝０、ＲＡ２＝１だとそれ以後ＮＤ８０Ｚ３．５とＰＩＣ１８Ｆ２５５０との交信のタイミングが食い違ってしまう可能性があることがわかりました（前回参照）。
確かに先ほどのログと上のログを見るとＩＮ ８２の実行結果とその次にＪＰ Ａ０００を実行してＩコマンドを実行したときにエラーが発生するかしないかいうことがぴったり符合しています。
そこまではわかりました。
すると次にはどういうときにＩＮ ８２の値が”３Ｄ”になり、またどういうときにその値が”７Ｄ”になるのかを解明しなければなりません。
それは言い換えると、上に書きましたように通常はプログラムの終了時にはＲＡ３＝０になっていると考えられますから、プログラムの終了時にＲＡ２が”０”になっているのはどういうときで、”１”で終っているのはどういうときなのかを明らかにすることだと言えます。
ＲＡ２はＰＩＣ１８Ｆ２５５０のシリアルデータ出力ラインです。
ＰＩＣ１８Ｆ２５５０が８ビットのデータを出力（送信）するときにはそれをシリアルデータに変換してＲＡ２から送出します。
ＲＡ２から出力されるシリアルデータはビット０から始まってビット７で終ります（［第９９回］参照）。
ビット７まで送出したあとＲＡ２の出力は次にデータを送出するまでの間最後に送出したビット７の値を維持しています。
つまりプログラムを終了したときにＰＩＣ１８Ｆ２５５０から最後に送出したデータのビット７が”１”のときにＲＡ２＝１になります。
送出したデータのビット７が”０”のときにＲＡ２＝０になります。
先ほどのログでＥコマンドで終了したときの直前のＰＩＣ１８Ｆ２５５０からのデータはＲＢコマンドの実行によって送出された”００”（００００ ００００）でしたからビット７は”０”です。
このときはエラーにはなりません。
後のログでは”９０”（１００１ ００００）が送出されて終りましたからビット７は”１”です。
このとき次にＪＰ Ａ０００を実行したあとでＩコマンドを実行すると”ＦＦ”エラーが発生します。
ＪＰ Ａ０００を実行すると最初にＰＩＣ１８Ｆ２５５０をリセットします。
私はＰＩＣ１８Ｆ２５５０はリセットするとＩ／Ｏポートの出力ラッチはクリアされて０になると思い込んでしまっていました。
ＰＩＣ１８Ｆ２５５０は（それに限らずおそらく多くのＰＩＣは）リセットによってＩ／Ｏポートの向きが入力になります。
それだけではなくてアナログと兼用しているポートはアナログモードになります。
そしてアナログモードになっている端子をデジタル的に読むとその値は”０”になります。
ということから「なんとなく」リセットによってＩ／Ｏポートの出力は０クリアされると思い込んでしまったようです。
思い込みは危険であります。
やっぱり何でもしっかり確認すべきでありました。
ということで前回Ｄａｔａ Ｓｈｅｅｔを確認した結果ＰＩＣ１８Ｆ２５５０の出力ラッチ（ＬＡＴＡ）はリセット（ＭＣＬＲ ＲＥＳＥＴ）によっては変化しないということが確認できました。
そこまでわかってしまえばエラー回避のための対策はおのずから明らかになります。
ＰＩＣ１８Ｆ２５５０についてはみっともないプログラムになっていましたのでＴＲＩＳＡよりも前にＬＡＴＡの値をＦＦにするように変更しました。
ＴＲＩＳで向きを出力にしても８２Ｃ５５のように出力ラッチがクリアされたりしませんから、そのようにするとリセット後からずっとＲＡ３、ＲＡ２のラインはＨになります。
おそらくはそのようにプログラムを変更しただけでエラーは回避されると思いますがさらに念のためにＮＤ８０Ｚ３．５側のプログラムはＰＩＣ１８Ｆ２５５０のリセットを終了したあと十分な時間を置いてからＰＣ７（ＲＡ３）＝０、ＰＣ６（ＲＡ２）＝１を確認するように修正をしました。
ところで。
何回か書きましたように電源をＯＮしたあとの最初のＩコマンドの実行では”ＦＦ”エラーが発生していないということについてなのですが（Ｅ：９２のエラーのことではありません）。
ＰＩＣ１８Ｆ２５５０のＤａｔａ ＳｈｅｅｔによるとＬＡＴＡの値はＰｏｗｅｒ－ｏｎ Ｒｅｓｅｔでは「わからない」となっています（前回参照）。
文字通りに解釈すれば２５％の確率でＲＡ３＝０、ＲＡ２＝１になる可能性があります。
繰り返しテストをしていたらあるいは電源ＯＮ後の最初のＩコマンドの実行でも”ＦＦ”エラーになったかもしれません。
しかし。
上記のプログラム修正を行ないましたから今となってはそれはもうどちらでもよいことだと思います。
あえてそのことを確かめる必要はもうありませんでしょう。
最後に。
せっかくプログラムを修正したことですから念のために、もうエラーが発生しないということを確かめておきましょう。
ＲＯコマンドでＴＥＳＴ２４．ＢＩＮをファイルオープンしてＲＢコマンドでデータを読みました。
２バイト目のデータは”９０”です。
ここでＥコマンドでプログラムを終了しました。
ＩＮ ８２を実行すると”７Ｄ”が表示されました。
今までならこの状態でＪＰ Ａ０００を再実行しそこでＩコマンドを実行するとエラーが発生して”ＦＦ”が表示されました。
しかしプログラムを修正しましたからＩコマンドは正しく実行されエラーは発生しなくなりました。
もうひとつ。
念のためにリセット後の信号をＣＰＬＤロジアナで観測しました。
［第１０４回］でお見せしたＣＰＬＤロジアナの波形ではリセット後４０μｓあたりでＲＡ３（ＰＲＯＢＥ２）がＬになっています。
それはその直前にＩＮ ８２で”７Ｄ”が表示されたときの波形ですが、同じ条件でもプログラムを修正した結果リセット後はＲＡ３もＲＡ２（ＰＲＯＢＥ３）もずっとＨのままです。
リセット後４９０μｓのところでＲＡ３（ＰＲＯＢＥ２）がＬになりました。
ここでＰＩＣ１８Ｆ２５５０が初期設定を完了したことを示しています。
ここは今までと変わりません。
しかし今までならばＲＡ３（ＰＲＯＢＥ２）＝Ｌ、ＲＡ２（ＰＲＯＢＥ３）＝Ｈを受けてＮＤ８０Ｚ３．５側はＰＣ１（ＰＲＯＢＥ０）＝Ｈ、ＰＣ０（ＰＲＯＢＥ１）＝Ｈにするところですが変化がありません。
ＮＤ８０Ｚ３．５側のプログラムはＰＩＣ１８Ｆ２５５０のリセット解除後に約９ｍｓのＷＡＩＴルーチンを実行するようにプログラムを修正しました。
そんなに長く待たなくても２～３ｍｓでも十分かと思ったのですがたまたま他のところで使うために９ｍｓのｗａｉｔサブルーチンがあったのでそれをＣＡＬＬするようにしました。
ちょうど９ｍｓ後にＰＣ１（ＰＲＯＢＥ０）とＰＣ０（ＰＲＯＢＥ１）がＨになりました。
ＰＩＣ１８Ｆ２５５０はそれを受けてＲＡ３（ＰＲＯＢＥ２）をＨにし、さらにＮＤ８０Ｚ３．５側がそれを見てＰＣ１（ＰＲＯＢＥ０）＝Ｌ、ＰＣ０（ＰＲＯＢＥ１）＝Ｌにしたことが確認できます。
やっと。
これにて一件落着です。
いつもでしたら金麦で乾杯！というところですけれど。
ええ。
それはもちろんそうしますけれど。
結局のところしっかりＤａｔａ Ｓｈｅｅｔを確認しないで思い込みでプログラムを書いてしまったことがエラーの原因だったことがわかったわけで。
なんとも苦い乾杯であります。
そういえば。
金麦も増税で値上がりしてしまいましたですね。
値上がり前に買い込んだ分も残り少なくなってきました。
まことにお代官様はワルでいらっしゃいます。
ＰＩＣＢＡＳＩＣコンパイラ［第１０６回］
２０２３．１１．２７ｕｐｌｏａｄ
前へ
次へ
ホームページトップへ戻る