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


PIC−USBIO using BASIC

〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜
USBインターフェースを内蔵したPICを使ってWindowsパソコンで外部回路を制御するための各種I/O基板の製作記事です。
〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜

[第129回]



●PICUSBIO−03(78)SPIモード(10)picout、picinの実行時間

PICUSBIO用のBASICインタプリタについては今まで毎回サンプルプログラムを書いてきましたし、またそれを書き直したりするところなどもお見せしてきましたので、扱いにくいことで定評がありますPICがPICUSBIO用BASICインタプリタを使えばいとも簡単に扱えるようになることは十分ご理解いただけたことと思います。
唯一の欠点は実行速度が遅いことです。
インタプリタですからコンパイラに比べればどうしても実行速度は遅くなってしまいます。
それに加えてPICと通信するところはUSB(HID方式)ですからここでうんと時間がかかってしまいます。
それもこれも実行速度が遅くなる欠点を帳消しにしてもさらに有り余るだけの利点(使いやすさ)があると判断してそのような形のソフトウエアとして作ってきています。
それで。
そのPICとの通信部分で時間がかかるということについては当然認識していたつもりだったのですが。

やっぱりトシのせいなのでしょうかねえ。
ついそのことを忘れてしまいます。
お話は[第125回]に戻ります。
MCP4911にSPIモードでコマンドを送ってその信号波形をCPLDロジアナで観測しました。
この時点で「PICとの通信には時間がかかる」ということについてしっかり確認しておくべきでした。
そこのところをうっかりスルーしてしまったために後になってから「なぜこんなところでこんなに時間がかかるのだ」なんて見当違いの穴ぼこにはまってしまって年末の貴重な時間を思い切り空費してしまいました。

下は[第125回]でお見せしたCPLDロジアナの観測波形です。

MCP4911に送ったコマンド(第1バイト)です。
そしてこちらは下位8ビットの出力波形です。

連続して2バイトを送った(つもりの)ところ第1バイトと第2バイトの送信時間を確認してみますと、前者が9000μsから始まっているのに対して後者は18000μsから始まっています。
第1バイトの送出を開始してから第2バイトの送出を開始するのに9msecもかかっています。
なぜこんなに時間がかかるのか?
この時点でそのことに気がつくべきでした。
結論から先に言いますとこれは異常でもなんでもなくて当たり前、仕方がないことだったのでした。
しかし上の方に書きましたようにこのことはしっかり認識しておくべきでした。
どういうことかと言いますと。

こちらがそのときのプログラムです。

50行が第1バイトの送信で、60行が第2バイトの送信です。
間に55行があります。
これが送信に時間がかかっている原因です。
BFビットのチェックをしているところです。
picin()はUSB経由でPICからデータを読む命令(関数)なのですがその仕組みはちょっと込み入っています。
最初にPICにレジスタを指定するための情報を送り、そのあとPICからそのレジスタのデータを受け取ります。
その間にPICとの間でUSBの送受信が複数回行なわれます。
USB(HID)通信は1回あたり1msecかかります。
PICUSBIO用のBASICインタプリタは独自の通信プロトコルのためにその複数倍の時間を要します。
picout(送信)よりもpicin(受信)のほうがさらに時間がかかります。
ここで9msecもかかっていたのはpicout+picinのためだったのです。

この点についてさらに深く考えてみます。
このときのSPI通信のクロックは1.47KHzです([第125回]参照)。
1クロックあたりの時間は0.68msecです。
送信完了まで(つまりBFビットが立つまで)には0.68x8=5.44msecかかります。
実はpicoutとpicin()の実行時間については大体のところはわかっていてpicoutが約2msec、picin()は約6〜8msecかかります。
すると50行のあと55行がなくていきなり60行を実行すると第1バイトがSSPBUFに書き込まれた2msec後に第2バイトがSSPBUFに書き込まれることになりますから第2バイトはおそらく無視されてしまうことになります。
結論としてはこのプログラムの場合にはpicout、picin()には時間がかかるけれどもそれは必要で、仕方がないことということになります。
しかしもしクロックがもっと高い周波数である場合には55行を外すということも考えられると思います(後日そのケースに出会うことになりました)。

さて。
[第127回]ではスレーブ側のプログラムで当初は80行でSSPBUFに’STX’を書いたところ正しく送信されなかった(実は無視されてしまった)ので65行を追加した、と書きました。
下の画面です。

この70行は本来は不要なものなので(前回参照)、ここは削除してしまえば済むことなのですが、それはともかくとしてこのプログラムではなぜ80行ではだめなのかの考察です。
そこにおそらくpicin()の実行速度が関係しています。
マスター(左側)は70行でRC6を0にするためにpicoutを実行したあとすぐに’STX’を送出するために80行のpicoutを実行します。
おそらくRC6が0になった2msec後にはSDOから’STX’が送信されることになります。
同時にクロック(SCK)も送信開始されます。
スレーブ側はそのときまでにSSPBUFに送信データをセットしておかなければなりません。
スレーブ側のプログラムに70行があったのではRC6を確認するだけで最低でも6〜8msecはかかってしまいますからこれではとても間に合いません。
このときはそこまで深くは考えなかったのですが、70行よりも前に送信データをSSPBUFにセットしておく必要があるらしいと考えてそのようにしたのは結果として正解だったのでした。

PIC−USBIO using BASIC[第129回]
2022.12.14upload

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