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

［第９３回］



●ＰＩＣＵＳＢＩＯ−０３（４２）Ｔｉｍｅｒ１（２４）ＣＯＭＰＡＲＥモード（５）テストプログラム（４）

前回はＣＯＭＰＡＲＥモードの最後のテスト（ＣＣＰ１ＣＯＮのｂｉｔ３−ｂｉｔ０＝１０１１）で割り込み条件が成立したときにＴｉｍｅｒ１がリセットされるはずなのにそれよりも１カウント多くカウントしてしまうらしいという現象がおきました。
それは本来そういう仕組みになっているのかそれとも何かほかの理由でそういう現象がおきるのか、そこのところを確認してみたいと思います。
まずは事実を確認するためにプログラムを実行しているときのＴｉｍｅｒ１の値を読み込んでそれをＰＲＩＮＴしてみることにしました。

６６行を追加しました。
これでＴＭＲ１Ｌの値が画面に表示されます。

プログラムを実行しました。

ＴＭＲ１Ｌの値が連続して表示されるようになりました。
カウントアップされるまでの表示回数を数えてみました。
最初の０の期間は入力パルスの途中からカウントすることになりますから少ない回数でカウントアップしていますがそのほかのカウント値では４６回か４７回でカウントアップしています。
今回のテストの目的とは関係ありませんが試しに計算をしてみました。
入力パルスの周期は約７００ｍｓｅｃですから７００／４６≒１５（ｍｓｅｃ）です。
今回のプログラムで６０行から９０行までのループが１回実行されるのに約１５ｍｓｅｃかかっています。
その間にＵＳＢ（ＨＩＤ形式）で何回かＰＩＣと通信していますからそのくらいの時間はかかってしまいます。
それはそれとして、上の結果を見ますとやっぱりＴｉｍｅｒ１は１０までしっかりカウントしています。
Ｔｉｍｅｒ１が１０までカウントして、そのあと（Ｓｐｅｃｉａｌ　Ｅｖｅｎｔ　Ｔｒｉｇｇｅｒによって）リセットされて０に戻るまでの表示回数もほかのカウント値のときと同じ４６回です。
あれっ？
カウント１０ですぐにリセットされていませんね。
表示回数から見て前回のオシロでの観測結果が正しいことがわかります。
ドキュメントではＣＣＰＲ１の値とＴｉｍｅｒ１の値が一致するとＳｐｅｃｉａｌ　Ｅｖｅｎｔ　Ｔｒｉｇｇｅｒによって「そのときに」Ｔｉｍｅｒ１がリセットされる、と読めるのですが、前回と今回のテストではＴｉｍｅｒ１の値はその次の１カウントをしたタイミングでリセットされるように見えます。
どういうことなのでしょう。
そこのところをもう少し追求してみました。

Ｓｐｅｃｉａｌ　Ｅｖｅｎｔ　Ｔｒｉｇｇｅｒがどのタイミングで実行されるのかを確かめることはできませんが、その「引き金」になるはずのＣＣＰ１割り込みはＣＣＰ１ＩＦが１になることで確認することができるはずです。
そこでプログラムを下のように変更してみました。

７５行を追加しました。
ＣＣＰ１ＩＦ（ＰＩＲ１のｂｉｔ２）が１になったらそこで”ｂｒｅａｋ”と表示してＴＭＲ１ＬとＰＩＲ１の値を表示したあとｓｔｏｐコマンドでプログラムを途中終了します。
何度も書いていることですがＢＡＳＩＣインタプリタだからこそ、こういうことがこんなにも簡単にできてしまうのです。
超便利です。

プログラムを実行しました。

おお。
ＣＣＰ１ＩＦはＴＭＲ１Ｌが１０になったときに１になっているようです。
プログラムはそこで実行を中止しましたがＰＩＣの側ではカウントはまだ続いています。
ダイレクトモードでｐｒｉｎｔ文を実行してその時点でのＴＭＲ１Ｌの値を表示させてみたところ６が表示されました。
おそらくＴｉｍｅｒ１が１０をカウントしたあと次の入力パルスの立ち上がり時点でクリアされてカウントを続けているのだということが推測できます。

本当にその推測通りなのかどうか、そこのところをもう少ししつこく追及してみます。
さらにプログラムを変更しました。

７６行と７７行を追加しました。
さきほどのプログラムでは”ｂｒｅａｋ”とＴＭＲ１Ｌの値とＰＩＲ１の値を表示してそこでプログラムを終了しました。
今回はそのあと続けてＴＭＲ１Ｌの値の表示を続けます。
ＴＭＲ１Ｌの値が１０ではなくなったらそこで実行を中止します。
今回の追加によって８０行と９０行は実行されなくなります。
ＰＯＲＴＣの出力は行なわれなくなりますが今回のプログラム変更の目的としてはＰＯＲＴＣの出力を確認する必要はありませんからそういうことで構いませんでしょう。

プログラムを実行しました。

上で推測しましたようにＰＩＲ１＝４（ＣＣＰ１ＩＦ＝１）になったあともＴｉｍｅｒ１はカウント値を保持したままカウント状態を維持していて（おそらくは）次のパルスの入力によって０クリアされるらしいことが見て取れます。
うむむ。
まだ推測の域をでませんねえ。
それでは「次のパルス」が入力されなかったらどうなるでしょうか？

それを簡単に確かめることはちょっと難しいのですがとにかくやってみました。

あらかじめ左側のコマンドプロンプトで
ｐｉｃｏｕｔ　ＩＮＴＣＯＮ，０
まで入力してその位置にカーソルを置いたままにしておいて右側のプログラムを実行しました。
右側のプログラムの実行を開始したあと左側のコマンドプロンプトに戻っていつでも［Ｅｎｔｅｒ］が押せるようにしてそこでスタンバイしました。
そして右側のコマンドプロンプトでｂｒｅａｋと表示された直後に［Ｅｎｔｅｒ］キーを押しました。
なんともアナログですなあ（オジイはそんなもんです）。
予測していた通りＴｉｍｅｒ１の値は１０のままクリアされずそのままの表示が続きました。
これでＴｉｍｅｒ１が０クリアされるためには次のパルスが入力される必要があることがはっきりしました。
なぜこういう仕組みになっているのか本当のところはわからないままですが、実用上はＴｉｍｅｒ１のカウント上限値をＣＣＰＲ１にセットするときにその値−１をセットするようにすることで正しく対処できると思います。

とそこまで書いてきて、そういうことかもしれない、とひとつの解釈を思いつきました。
そういうことではないかも知れませんが、納得がいくひとつの解釈です。
下の上側の図がその解釈を図で示したものです。

それに対して下側の図は私が今まで考えていた解釈を図にしたものです。
両方ともカウント０の期間があってそこからカウントが始まります。
上側ではカウント１０の期間の次にカウント０の期間があります。
下側ではカウント１０は一瞬で終わりすぐにカウント０の期間になります。
まあ考え方ですけれど、確かにこうして図にしてみると上側の図のほうが無理が無いようにも思えます。
結果として上側では１１カウントで繰り返すのに対して下側では１０カウントで繰り返すことになります。
ＰＩＣのＣＯＭＰＡＲＥモードでは上側の図の動作になっています。

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

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