UARTは何事もなく正常に戻った。ISPのリセットとグランドは逆にしてもファームウエアの書き込みが出来ることを始めて知った。ISPはリセットをグランドにして動くので書き込みは問題なく動くが、終わったあとにおかしくなるものと思われる。配線もOK」という思い込みが招いたお粗末だった。何事にも絶対は有り得ないということである。カウンターのロジックはこれはこれで難しい(10/26/08)Webに沢山あるからと、たかを括っていたがまともに調べ始めると、周波数カウンターのロジックはたくさんあるが、簡単なロジックで正確に測るのは結構難しいことがわかった。今度は信号発生器用の表示なので、測定器のように、正確な1秒の間、パルスをカウントして、1サイクルまで測るという直接的な方法は余り実用的ではない(一番正確だが)。周波数を変えていったときの表示が1秒毎というのは、いくらなんでも遅すぎる。微調整に時間がかかってしまう。使う側からみれば、測定間隔は短ければ短いほど良い。周波数を変化させて表示がそれに自然に対応すると言えば、最低でも1秒2回、出来れば3~4回は欲しい。1秒より測定ゲート(カウントを数える区間)を短くすると分解能は単純に下がっていき、数をカウントするだけでは、低い周波数では、荒すぎて話にならない。最低でも3桁の有効数字がでないとカウンターとは呼べないだろう。100Hz以下で例えば、1秒間に3回の計測では、3Hz刻みになってしまい、いくら自分しか使わないにしても気分が良くない。面倒だがレシプロカル方式のように、パルスの間隔時間を測るようにしないと低い周波数では使い物にならないことがわかる。今度のプロジェクトに想定しているTiny2313はフラッシュが2Kしかなく、測定を2本立てにするとコードサイズが厳しい。ひとつのロジックで低周波も高周波も測りたい。Webの情報を参考に、あれこれ頭を捻った結果、とりあえず出来たのは次の仕様であった。バイト程度のカウンターと、タイマー値の変数を用意する。16ビットタイマーを300ms程度でオーバーフローするようタイマーのプリスケール値を決める。測定開始の最初のパルスと同時に16ビットタイマーをスタートさせ時間を測りながらパルスをカウントしていく(直接計数方式とレシプロカル方式を併用)。パルスカウントが最大になるか、タイマーのオーバーフローで測定を打ち切り、そのときのカウントと経過時間で周波数を求める。これにより低周波から、高周波まで同じロジックで周波数を出す。マイコンの測定限界を超える周波数は、プリスケーラーからの分周パルスを入力パルスとし、所定の倍率をかけて表示する。入力が測定限界を超えた周波数かどうかは、予備的に短くプリスケール値をカウントし、どちらの入力を選ぶか判定する。いずれにしても、マイコンが測れる最大周波数を実験で調べてからでないと、このあたりの緒元は決められない。ターゲットチップのTiny2313は、8bitタイマーひとつと16bitタイマーひとつを持っているのでカウンターのリソースに不足ない。ロジックに凝らなければLCDの表示まで2Kのフラッシュで出来る(だろう)。クロックを20Mhzとすると、一命令は、0.05μs。カウンターのクリアや、オーバーフローのインクリメントなどを含めて測定ループは10~15ステップに納まるだろう。すると1ループ0.5~0.75μs。1Mhzあたりの周波数が上限か。WINAVR(GCC)のコンパイラーはオプションを最小(Os)にすると結構効率的なコードを作ってくれるので始めはこれで書いて、駄目ならアセンブラーにしよう。参考:以下の横河電機の測定器入門講座のカウンターの記事は入門とは思えない詳細な解説で大変ためになる。http://www.yokogawa.co.jp/tm/TI/keimame/torjikan/index.htmこの方法では525Khzが限界(10/29/08)やっとのことで、安定して周波数が測定できるようになった。始め、頻々とMCUそのものがリセットし、最初は割込みなどを疑ったが、原因はヒューズビットの設定ミスというお粗末な原因だった。今度のマシンは周波数カウンターなのでクロックを20MHzという最高速で動かしている。今まで、Tiny2313をこんな高速で動かしたことがない。ヒューズビットの設定が8Mhz以下と以上で違うことに気づかず、あれこれ悩んでしまった。何となく動くと言うのも原因解明には障害になる。UARTから結果が出ては来るのだけど、動きが不安定なのである。UARTがハングアップしたり、MCUにリセットがかかる。それに100Khzくらいで測れなくなる。タイマーの割込みをやめて、全部ループで組んでも同じ。そこで、計測ルーチンそのものをコメントアウトしてみたらそれでも起きる。ありゃりゃ、これは別の問題だ。残るはUARTだが、これまでと全く同じコードでこれが原因とは考えられない。試しに、シグナルジェネレーターからの信号を止めてみたら、トラブルが止まった。えー、ピン入力だけでおかしくなる?入力に使っているPD2ピンは、2313では多目的ピンで設定がおかしいのかとデータシートを確かめる。データシートを見ていて、気がついたのがヒューズビットであった。思わぬところに原因があるものだ。何となく動いていたので今まで気がつかなかった。この前のリセットピンの配線違いと同じことである。基本からの積み上げが大切であるということを痛感した。ヒューズビットを8MHz以上に設定して(CLSEL3~1を111)、2313は全く問題なく周波数を表示するようになった。測れた最高周波数である。サイトのみなさんの周波数カウンターを見ていると、カウンターやCPLDなどでハードを追加されているのが多く、MCUチップだけで作られているのが意外に少ない。今作っているロジックは至極簡単で、ピンに入ってくるパルスを読み、立ち上がりパルスを律義に数えているだけである。程度だと20Mhzのクロックで1Mhzまで測れるはずだが、結果は、残念ながら500Khz程度に留まった。理由ははっきりしている。Tiny2313は8bitマシンなので、カウンターのような大きい数字は、1バイトづつの命令で2回かけて処理しなければならない。WINAVR(GCC)で書いたコードを、.lssリスト(アセンブラになった命令が見える)で見てみると、立ち上がりパルスのときにタイマ時間と回数を記録するループは一周34ステップもあった。20Mhzのクロックでは一命令の時間は0.05μsで、一回1.7μs。理論上でも最大周波数は、588Khz。計測できた最大周波数は525Khzだったので、ほぼ想定どおりである。「AVR」カテゴリの記事ソフトI2Cはクロックストレッチまで手を出してあえなく沈没(2017.09.02)オシロのテストどころかソフト開発で大はまり(2017.07.26)超音波方式の人感センサーI2C化と新しいオシロ(2017.06.29)motionの動体検知はRaspi3の電源が安定しない(2017.04.16)赤外線学習リモコンはデータ再現で挫折したまま進まず(2016.07.21)コメントweb上ではPIC16Fで100MHZまでの記載を見ました。02時02分コメントを書く名前:メールアドレス:(ウェブ上には掲載しません)アドレス(URL):この情報を登録するコメントは記事投稿者が公開するまで表示されません。2方式の周波数カウンターを2313で動かす。