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

［第１０３回］



●ＳＤカードＩＦ（２３）ＮＤ８０Ｚ３．５に接続（１６）解決編

やっと着地点まで来ました。
なぜ”ＦＦ”エラーになってしまうのか、その原因の解明です。
ここはなかなか説明が難しいです。
自分ではわかっています。
しかしそれを図に描いて示そうとしますといまひとつうまく説明ができません。
わかりにくいかもしれませんがそこはお許しを。

今までのところで書いてきましたように”ＦＦ”になってしまうのはどうやらＮＤ８０Ｚ３．５側のプログラムとＰＩＣ１８Ｆ２５５０のプログラムのタイミングが食い違ってしまうかららしいということがわかってきました。
本来ならば片方が「送信」ならばもう片方は「受信」であるはずです。
両者のプログラムはそのように設計してあります。
電話のように送信と受信が同時に行なわれることはありません。
こちらが送信のときは相手は受信でなければなりません。
こちらが送信のときに相手がそれを検知して受信に切り換えるというシステムでもありません。
ですからなんらかの理由でタイミングが合わなくなってしまうと双方が「送信モード」あるいは「受信モード」になってしまいます。
なぜそういうプログラムになっているかというとそれはひとえにソフトウェアの負担を軽くするためです。
コマンドによって双方がそれぞれ「送信モード」であるべきタイミングと「受信モード」であるべきタイミングはあらかじめプログラムで決定されていますから本来はそれが食い違うはずはない（はずでありました）。
万一それが食い違ってしまった場合にも正常なタイミングに復帰できるようにプログラムを修正しました（［第１０１回］）。
「対症療法的」な対策です。
ですからとりあえず”ＦＦ”問題はクリアできたのですが。

あれこれ思考を重ねていく中でなぜそうなるのかという原因がわかりました。
「わかったぞ！原因はそこだったんだ！」
謎解きの醍醐味であります。
というと格好いいのですが、要するに当初のプログラム設計にとんでもないアナがあったわけで別に自慢できることでもなんでもありません。
問題はＰＩＣ１８Ｆ２５５０のリセット直後の双方のプログラムのタイミングにありました。
ＮＤ８０Ｚ３．５と接続して動作テスト中のＰＩＣＳＤカードＩＦシステムは先にＮＤ８０Ｚ３．５側のプログラムを実行します。
ＮＤ８０Ｚ３．５のプログラムは実行を開始すると最初にＰＩＣＳＤカードＩＦボードのＰＩＣ１８Ｆ２５５０をリセットします。
そしてＰＩＣＳＤカードＩＦボードが接続されていてそれが正しく機能しているかどうかを確認し双方の送受信のタイミングを合わせます。
そこのところにアナがありました。
下は当初私が考えていた双方のプログラムの流れです。

ＮＤ８０Ｚ３．５の８２Ｃ５５のＰＣ２はＰＩＣ１８Ｆ２５５０のＲＥＳＥＴ端子（ＭＣＬＲ）につながっています（この部分の回路図は［第８５回］にあります）。
ＰＣ２〜ＰＣ０のポートの向きは「出力」に固定されています。
ＮＤ８０Ｚ３．５側のプログラムがスタートすると最初に十分な期間ＰＣ２をＬにしたあとＨにします。
ＰＣ１はＮＤ８０Ｚ３．５側が送出するクロックです。
送受信のためのクロックはＮＤ８０Ｚ３．５側からしか出力されません。
ＮＤ８０Ｚ３．５はＰＣ０から送信データを出力します。
このラインはＰＩＣ１８Ｆ２５５０のＲＣ０につながっていてＮＤ８０Ｚ３．５側からのデータを受信します。
ＰＣ７とＰＣ６のポートの向きは「入力」に固定されています。
ＰＣ７はＰＩＣ１８Ｆ２５５０からのＲＥＡＤＹ＿／ＢＵＳＹ信号を受信します。
ＰＣ６はＰＩＣ１８Ｆ２５５０からの送信データを受信します。
上記の４本のラインはプログラムの起動時には双方のタイミングを合わせるためと、ＰＩＣ１８Ｆ２５５０が存在していてそれが正しく動作するかどうかを確認するために使われます。

（１）リセット後にＰＩＣ１８Ｆ２５５０はＴＲＩＳＡ命令でＰＯＲＴＡの向きを「出力」に設定します。
ＰＩＣ１８Ｆ２５５０はリセット後はＰＯＡＴＡは「入力」になります。
８２Ｃ５５のラインはプルアップされているのでＰＣ７とＰＣ６はＨですがこれはＰＩＣ１８Ｆ２５５０からＨが出力されているからではなくてＲＡ３、ＲＡ２が「入力」でラインがハイインピーダンスだからです。
ＴＲＩＳＡの設定によってＲＡ３とＲＡ２はＬになります（と考えたところにアナがありました）。
わかっていたつもりだったのですが、ついうっかりしてＰＩＣ１８Ｆ２５５０も８２Ｃ５５と同じようにポートの向きを出力に設定するとポートの出力はＬになる、と考えてしまいました。
（２）ＰＯＲＴＡのＲＡ３出力とＲＡ２出力をＨにします。
ここでもうっかりしてまずいプログラムを書いてしまいました。
本来はＴＲＩＳＡの実行直後にＰＯＲＴＡのＲＡ３、ＲＡ２をＨにすべきでした。
そこにうっかりして他の命令をはさんでしまったためＲＡ３とＲＡ２がＨになるまでに少し時間がかかっていました。
後になってわかったことなのですが、それが”ＦＦ”問題の原因となったのでした。
下は修正前のプログラムです。

movlw 7f;8MHz movwf OSCCON clrf TRISA movlw 01;RB0=in movwf TRISB movlw 03 movwf TRISC movlw 0ff movwf PORTC movwf PORTA

ＣＬＲＦ　ＴＲＩＳＡからＭＯＶＷＦ　ＰＯＲＴＡまで７命令あります。
ＣＬＯＣＫは８ＭＨｚなので１命令の実行時間は４／８＝０．５μｓです。
リセット後にＲＡ７、ＲＡ６は３．５μｓの期間Ｌになります。
わずかな時間なのですが、これが「落とし穴」でした。

上のタイミング図に戻ります。
（３）ＰＩＣ１８Ｆ２５５０はその後ＲＣ１とＲＣ０（８２Ｃ５５のＰＣ１とＰＣ０）の状態を確認しそれが共にＬならば初期的な設定を実行します。
この間は約３００μｓです。
（４）それが済むとＰＩＣ１８Ｆ２５５０はＲＡ３をＬにします（ＲＡ２はＨのままです）。
（５）ＮＤ８０Ｚ３．５側はＰＣ７＝０、ＰＣ６＝１を確認するとＰＣ１とＰＣ０をＨにします。
（６）ＰＩＣ１８Ｆ２５５０はＲＣ１＝ＲＣ０＝１を確認するとＲＡ３をＨにします。
（７）ＮＤ８０Ｚ３．５側はＰＣ７＝ＰＣ６＝１を確認するとＰＣ１とＰＣ０をＬにします。
以後はＮＤ８０Ｚ３．５側のＰＣ１とＰＣ０がＬ出力になり、ＰＩＣ１８Ｆ２５５０のＲＡ３とＲＡ２がＨ出力になるはず、だったのですが。

ひょっとして。
もしもリセットしてもＰＩＣ１８Ｆ２５５０のポート出力はリセットされないとしたならば。
そしてもしもリセット前のＰＩＣ１８Ｆ２５５０のＲＡ３出力がＬ、ＲＡ２出力がＨになっていて、そこでリセットをかけたとしたならば。
その考えが頭に浮かんだ時点では、それは推測、ただの仮定に過ぎなかったのですが、いろいろ試していくうちにどうもそうに違いないという確信に変わってきました。
とりあえずは今は仮定としてそういうことだとすると、上記のタイミングは下のようになる可能性があります。

リセット直後からＮＤ８０Ｚ３．５側はＰＣ７＝０、ＰＣ６＝１をチェックし続けます。
ここにも対策すべきところはありました。
当初はＰＩＣ１８Ｆ２５５０はＰＯＲＴＡの向きを設定後にＲＡ３＝０、ＲＡ２＝１を出力するまではＲＡ３＝ＲＡ２＝１かＲＡ３＝ＲＡ２＝０のどちらかだと思い込んでいました。
以前にＰＩＣの動作については確認して理解していたはずなのですが、なんですかねえ、しっかりすっかり忘れてしまっておりました。
実に困ったことです。
上の仮定に従った場合（１）ＴＲＩＳＡの実行によってＲＡ３＝０、ＲＡ２＝１になります。
すると（５）ＮＤ８０Ｚ３．５がそれを認識してＰＣ７＝１、ＰＣ６＝１にします。
ＰＩＣ１８Ｆ２５５０はまだＴＲＩＳＡを実行しただけの段階ですから次に（２）ＲＡ３＝１、ＲＡ２＝１にします。
（１）の直後に（２）が実行されていればＲＡ３＝０の期間はほんの一瞬（０．５μｓ）ですから（５）が実行される可能性はかなり低くなるはずですが、上に書きましたようにその期間は３．５μｓですからＮＤ８０Ｚ３．５側のプログラムがその「穴」を検知して（５）を実行する可能性はかなり高くなります。
（７）そしてＮＤ８０Ｚ３．５は（２）の状態を確認するとＰＣ１＝０、ＰＣ０＝０にします。
（３）（４）ＰＩＣ１８Ｆ２５５０は（７）を確認すると初期設定を実行し約３００μｓ後にＲＡ３＝０にします。
この後はＰＩＣ１８Ｆ２５５０はずっと（６）ＲＣ１＝１、ＲＣ０＝１になるのを待ち続けることになります。

このように考えると確かにここで「食い違い」が発生することになります。
しかし本当にそうなのか。
実のところＰＩＣ１８Ｆ２５５０のＩ／Ｏポートはリセット後はどうなるのか。
そしてそもそも上図のようなことが本当に起こり得るのか。

今回は解決編のつもりだったのですがちょっと長くなってしまいましたので、今回はここまでにします。
次回に続きます。

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

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