ＰＩＣ−ＵＳＢＩＯ　ｕｓｉｎｇ　ＢＡＳＩＣ
〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜
ＵＳＢインターフェースを内蔵したＰＩＣを使ってＷｉｎｄｏｗｓパソコンで外部回路を制御するための各種Ｉ／Ｏ基板の製作記事です。
〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜

［第１２９回］



●ＰＩＣＵＳＢＩＯ−０３（７８）ＳＰＩモード（１０）ｐｉｃｏｕｔ、ｐｉｃｉｎの実行時間

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

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

下は［第１２５回］でお見せしたＣＰＬＤロジアナの観測波形です。

ＭＣＰ４９１１に送ったコマンド（第１バイト）です。
そしてこちらは下位８ビットの出力波形です。

連続して２バイトを送った（つもりの）ところ第１バイトと第２バイトの送信時間を確認してみますと、前者が９０００μｓから始まっているのに対して後者は１８０００μｓから始まっています。
第１バイトの送出を開始してから第２バイトの送出を開始するのに９ｍｓｅｃもかかっています。
なぜこんなに時間がかかるのか？
この時点でそのことに気がつくべきでした。
結論から先に言いますとこれは異常でもなんでもなくて当たり前、仕方がないことだったのでした。
しかし上の方に書きましたようにこのことはしっかり認識しておくべきでした。
どういうことかと言いますと。

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

５０行が第１バイトの送信で、６０行が第２バイトの送信です。
間に５５行があります。
これが送信に時間がかかっている原因です。
ＢＦビットのチェックをしているところです。
ｐｉｃｉｎ（）はＵＳＢ経由でＰＩＣからデータを読む命令（関数）なのですがその仕組みはちょっと込み入っています。
最初にＰＩＣにレジスタを指定するための情報を送り、そのあとＰＩＣからそのレジスタのデータを受け取ります。
その間にＰＩＣとの間でＵＳＢの送受信が複数回行なわれます。
ＵＳＢ（ＨＩＤ）通信は１回あたり１ｍｓｅｃかかります。
ＰＩＣＵＳＢＩＯ用のＢＡＳＩＣインタプリタは独自の通信プロトコルのためにその複数倍の時間を要します。
ｐｉｃｏｕｔ（送信）よりもｐｉｃｉｎ（受信）のほうがさらに時間がかかります。
ここで９ｍｓｅｃもかかっていたのはｐｉｃｏｕｔ＋ｐｉｃｉｎのためだったのです。

この点についてさらに深く考えてみます。
このときのＳＰＩ通信のクロックは１．４７ＫＨｚです（［第１２５回］参照）。
１クロックあたりの時間は０．６８ｍｓｅｃです。
送信完了まで（つまりＢＦビットが立つまで）には０．６８ｘ８＝５．４４ｍｓｅｃかかります。
実はｐｉｃｏｕｔとｐｉｃｉｎ（）の実行時間については大体のところはわかっていてｐｉｃｏｕｔが約２ｍｓｅｃ、ｐｉｃｉｎ（）は約６〜８ｍｓｅｃかかります。
すると５０行のあと５５行がなくていきなり６０行を実行すると第１バイトがＳＳＰＢＵＦに書き込まれた２ｍｓｅｃ後に第２バイトがＳＳＰＢＵＦに書き込まれることになりますから第２バイトはおそらく無視されてしまうことになります。
結論としてはこのプログラムの場合にはｐｉｃｏｕｔ、ｐｉｃｉｎ（）には時間がかかるけれどもそれは必要で、仕方がないことということになります。
しかしもしクロックがもっと高い周波数である場合には５５行を外すということも考えられると思います（後日そのケースに出会うことになりました）。

さて。
［第１２７回］ではスレーブ側のプログラムで当初は８０行でＳＳＰＢＵＦに’ＳＴＸ’を書いたところ正しく送信されなかった（実は無視されてしまった）ので６５行を追加した、と書きました。
下の画面です。

この７０行は本来は不要なものなので（前回参照）、ここは削除してしまえば済むことなのですが、それはともかくとしてこのプログラムではなぜ８０行ではだめなのかの考察です。
そこにおそらくｐｉｃｉｎ（）の実行速度が関係しています。
マスター（左側）は７０行でＲＣ６を０にするためにｐｉｃｏｕｔを実行したあとすぐに’ＳＴＸ’を送出するために８０行のｐｉｃｏｕｔを実行します。
おそらくＲＣ６が０になった２ｍｓｅｃ後にはＳＤＯから’ＳＴＸ’が送信されることになります。
同時にクロック（ＳＣＫ）も送信開始されます。
スレーブ側はそのときまでにＳＳＰＢＵＦに送信データをセットしておかなければなりません。
スレーブ側のプログラムに７０行があったのではＲＣ６を確認するだけで最低でも６〜８ｍｓｅｃはかかってしまいますからこれではとても間に合いません。
このときはそこまで深くは考えなかったのですが、７０行よりも前に送信データをＳＳＰＢＵＦにセットしておく必要があるらしいと考えてそのようにしたのは結果として正解だったのでした。

ＰＩＣ−ＵＳＢＩＯ　ｕｓｉｎｇ　ＢＡＳＩＣ［第１２９回］
２０２２．１２．１４ｕｐｌｏａｄ

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