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

［第８７回］



●ＰＩＣＵＳＢＩＯ−０３（３６）Ｔｉｍｅｒ１（１８）ＣＡＰＴＵＲＥモード（９）謎の解明

前回はプリスケーラを１：２にしてテストしたところ異変がおきました。
計算によるＴｉｍｅｒ１のオーバーフロー回数は２＊２＝４なのですがプログラムを実行した結果はその倍の８回になってしまいました。
下位１６ビットの値もその前のプリスケーラを１：４に設定したときの１／２になると予想されるところが１／２ではなくて同じ値になってしまいました。
続けて行なったプリスケーラ無しの設定でのテストでも全く同じ結果になりました。
計算によるＴｉｍｅｒ１のオーバーフロー回数は２回なのですがプログラムを実行した結果はその４倍の８回です。
下位１６ビットの値もプリスケーラを１：４に設定したときと同じ値です。

この問題はオーバーフローの回数が鍵になっています。
それは原因がわかった今だからこそ言えることなのですが。
ついでに言ってしまいますがより正確に言いますと入力パルスの１周期の時間が鍵になっています。
入力パルスの１周期の時間に注目すると問題の原因が見えてくるようになります。
ここで重要なのは入力パルスの１周期の期間をＴｉｍｅｒ１の総カウント数から求めるのではなくてＴｉｍｅｒ０のカウント数を元にして計算しなければならないということです。
左側のＰＩＣＵＳＢＩＯ−０３から出力されるパルスの１周期はＴｉｍｅｒ０が２回オーバーフローする時間です。
プリスケーラが１：８のときのＴｉｍｅｒ０の入力クロックは１２／８（ＭＨｚ）ですからＴｉｍｅｒ０が１カウントする時間は８／１２（μｓｅｃ）です。
Ｔｉｍｅｒ０が２回オーバーフローする時間は（８／１２）＊６５５３６＊２です。
プリスケーラの値が１：８以外のときの計算もしていきますから”８”を残したまま上の式を少し整理すると８＊６５５３６／６になります。
計算すると８７３８１μｓｅｃ（８７．３８１ｍｓｅｃ）になります。

同じ計算をプリスケーラが１：４、１：２、１：１のときについてもやってみます。
プリスケーラが１：４のときは。
４＊６５５３６／６ですから１：８のときの１／２です。
４３６９１μｓｅｃ（４３．６９１ｍｓｅｃ）です。

プリスケーラが１：２のときは。
２＊６５５３６／６ですから１：４のときの１／２です。
２１８４５μｓｅｃ（２１．８４５ｍｓｅｃ）です。

プリスケーラなしのときは。
６５５３６／６ですから１：２のときの１／２です。
１０９２３μｓｅｃ（１０．９２３ｍｓｅｃ）です。

このように計算してみますと出力パルスの１周期の期間はプリスケーラの値に比例しています。
すると右側のプログラムで計算した入力パルスの１周期をカウントするＴｉｍｅｒ１の総カウント数も左側のＴｉｍｅｒ０のプリスケーラの値に比例するはずです。
ところが入力パルスの１周期が４３．６９１ｍｓｅｃまではそのようになっているのにそれよりも小さい値になると総カウント数が正しく表示されない現象が発生します。
不思議なことにその値は周期が４３．６９１ｍｓｅｃのときと同じになってしまうように見えます。

周期がある値よりも小さい値になるとＣＣＰＲ１の値が正しい値ではなくて、まるで値が「飛んでいる」ように見えます。
ここまで考えて「そうだったか！」とやっと気が付きました。
もっと早く気がつくべきでした。
ＵＳＢ通信（ＨＩＤ）は遅いのでＰＩＣにアクセスするのに時間がかかります、と何回も書いてきましたのに。
原因はそこだったのです。

ＰＩＣＵＳＢＩＯ用ＢＡＳＩＣインタプリタでＰＩＣにアクセスするにはｍｓｅｃ単位の時間がかかります。
何回もＰＩＣにアクセスする処理では数十ｍｓｅｃの時間がかかります。
右側のプログラムは［第８４回］にあります。
下に再掲します。

７０行から１３０行までが繰り返し実行されます。
１回の繰り返しごとに１回のカウント数の表示が行なわれます。
その期間がどのくらいの時間なのかを確かめてみました。
上右のプログラムを下のように少し変更することでそれを確認することができます。

６５行でＰＯＲＴＣのｂｉｔ７の出力を毎回反転させるようにしました。
そのようにするために５行を追加しました。
ＰＯＲＴＣのｂｉｔ７を出力にしています。
今回のテストでは左側のＰＩＣＵＳＢＩＯ−０３と右側のＰＩＣＵＳＢＩＯ−０３とはこのテストのために作成した専用のフラットケーブルを使って接続しています。
ＲＣ４（パルス出力）とＲＣ５（パルス入力）を結線するほかはＧＮＤのみを結線しそのほかのラインはつないでいません。
ですから左側のＲＣ７の出力と右側のＲＣ７の出力がぶつかることはありません。

プログラムを実行して出力波形をオシロで観測しました。

上側（ＣＨ１）が入力波形で下側（ＣＨ２）がＲＣ７の出力波形です。
これはプリスケーラが１：４のときの波形です。
ＣＨ１は上の方で計算した通り１周期が約４０ｍｓｅｃになっています。
それに対してＣＨ２はＣＨ１が１回立ち下がるごとに１回反転していますから正しくカウントできていると思われます。

下は水平時間軸を１０ｍｓｅｃ／ｄｉｖにした波形です。

この波形を見るとＣＨ２が反転しているのはＣＨ１の下がりエッジの約１０ｍｓｅｃ前ということがわかります。
余裕は１０ｍｓｅｃほどしかありません。

プリスケーラを１：２にしました。

ＣＨ１の周期は約２０ｍｓｅｃです。
それに対してＣＨ２の反転出力はさきほどとほぼ同じ約４０ｍｓｅｃです。
やはり右側のプログラムの１回の処理には４０ｍｓｅｃほどの時間がかかってしまうようです。
ＣＨ２が１回反転する間にＣＨ１は２回立ち下がっています。

水平時間軸を１０ｍｓｅｃ／ｄｉｖにしました。

ＣＨ１の最初の立下りエッジでラッチしたカウントデータはＢＡＳＩＣプログラムで表示されますが次のラッチデータはおそらく表示される前にさらにその次の立下りエッジでラッチされるデータのために失われてしまうであろうことが見て取れます。

プリスケーラなしの設定にしました。

ＣＨ１の波形が細かくなってちょっと見にくくなりました。
水平時間軸を１０ｍｓｅｃ／ｄｉｖにしました。

ＣＨ１の周期は約１０ｍｓｅｃです。
それに対してＣＨ２の反転出力はさきほどとほぼ同じ約４０ｍｓｅｃです。
ＣＨ２が１回反転する間にＣＨ１は４回立ち下がっています。

これでやっと謎が解けました。
ＢＡＳＩＣプログラムがＣＡＰＴＵＲＥモードでラッチする１回のＴｉｍｅｒ１のカウントデータを表示するためには約４０ｍｓｅｃの時間が必要なのでそれよりも短い周期のパルスが入力されるとラッチしたデータを読み飛ばしてしまいます。
それが異常な値が表示されてしまう原因だったのでした。

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

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