楽しいAVRでGPS時計を作ってみる
- 2009/12/08 14:09
- カテゴリー：make:
先日，MakeTokyoMeeting04を見学し，Maker達の熱意にずいぶん影響を受けたのですが，ともあれGPS Laboさんでわけて頂いた，GPS時計プログラムを書き込んだATtiny2313を生かさねばなりません。
とにかく簡単に試せるという事で，MTM04の直後にGPSモジュールを秋月電子に手配を済ませてあり，翌週の土日から検討に入っています。
LCDは昨年の今頃，大阪のデジットで入手した大型のLCDモジュールを使う事としましたが，予想通りあっさり動いてしまいました。
元々，PICをアセンブラで使い慣れている私としては，個性の強いMSP430やPSoCならまだしも，個性の弱いAVRを今さら使うのもどうかなあ，と感じて試す気にならずにいました。
ところが，GCCが使える（つまり無制限で優秀なCコンパイラが使える）ことと，tiny2313であれば秋月価格で1つ100円と圧倒的に安いことが私にとっては強烈な個性に見えて，軽く遊んでみることにしました。幸いライタは昨年のデジット詣の際に購入済みです。
GCCが使えるという事から，プロセッサのアーキテクチャが無個性であることがうかがい知れるわけですが，逆にPICでは個性が強すぎてGCCをインプリ出来なかったわけですね。先日も話していたのですが，PICは「クセの強さをアセンブラで味わうマイコン」です。
開発環境であるAVRstudioも使いやすいですし，tiny2313はちょっとメモリが少ないですが，最大20MIPSという高速処理と，レジスタと内部メモリが1クロックアクセス出来る事もあり，プログラムを作る上で速度低下に気をつけながらコードを書かずに済むため，コンパイラ任せでも精神的に随分楽です。
わずか100円で20MIPS，豊富なI/OポートをCでグリグリ動かせますから，もうPIC18F84とはおさらばです。ということで，すっかり私はAVRのファンになってしまいました。
AVRを使うと決めた以上，いろいろ試しておきたくなるのが人情というもので，USIという原始的なシリアルインターフェースモジュールを使ってSPIを実現する（8MHzのクロックで4MHzの転送クロックが出せます）プログラムや，LCD関連のライブラリをひと通り準備しました。
これは，MacBookPro上にSunのVirtualBoxという仮想マシンを入れて，Windows環境が実現出来たことが随分大きいです。後日書こうと思っていますが，このVirtualBox，かなり出来がよいです。無償ですが，有償の仮想マシンを買う必要を全く感じません。
余談ですが，x86には仮想マシンを実装するにはやや問題があり，普通に仮想マシンを実装しようとしてもパフォーマンスががた落ちになり，うまくいきません。有償の仮想マシンとして有名なVMwareはこの問題をうまく解決したソフトとして知られていますが，Core2Duoなど仮想マシンを前提とした新しいx86であれば，あまりおかしな事をしなくても仮想マシンをちゃんと実装出来ます。だから，無償の仮想マシンでもなんら問題はないというのが，私の考えだったりします。
実際の所，VirtualBoxがどうやっているかはわかりませんが，仮想マシンを支援するハードウェアを使うかどうかのオプションがあるので，少なくともパフォーマンスへの貢献はあるのでしょう。
話が逸れてしまいましたが，開発関連ツールはWindowsが前提なだけに，自宅にまともなWindows環境が手に入ったことはとても大きなことで，今回のAVRを楽しむことだって，その恩恵だと思います。
それで，GPSクロックですが，どうもうまくありません。
GPS Laboさんは，処理などに時間がかかり，表示された時刻が正確な時刻ではない，という話をされており，これをきちんと表示させるには1PPSの信号のあるGPSモジュールを使うしかない，といわれていました。
実際，平気な顔をして1秒くらい表示が遅れています。いかにGPSが原子時計の精度を持っているといっても，表示が1秒もずれたら，正確な時計としては存在価値がありません。
GPS Laboさんのソフトは，時刻情報の含まれているGPGGAセンテンスを割り込みで一気に80バイトのバッファに取り込み，その後文字列から時刻情報を抽出し，JSTに変換してLCDに転送する仕組みです。初期設定が終わったらひたすら空ループを回すのが，main()の中身だったりします。
それはそれでいいのですが，割り込みは出来るだけ軽く，という考えからすると，時刻情報の抽出やJSTへの変換，LCD表示などはやはりmain()で処理したいところです。ごく普通に，UARTからの割り込みで1バイトをバッファに取り込む，という処理だけを割り込みで行うと，1センテンスの取り込み完了を待たずに続きの処理が出来る事になるので，表示のアップデートにかかる時間が短縮されて，表示の遅れが小さくなりそうです。
そこで，UARTの練習も兼ねて，プログラムの書き直しをしてみることにしました。センテンスの処理を行って時刻情報を抽出する部分は流用させて頂きますが，それ以外は他の方のコードを参考にするか，自分で作るかします。
UARTから受信割り込みがきたら，割り込み処理の関数で1バイトをリングバッファに取り込み，ライトポインタを進め，割り込みから復帰させます。
main()ではループのなかで$をリングバッファからサーチし，以下に続くGPGGAが見つかったら，続けて取得した文字列をデコード，時刻情報を取り出しJSTに変換，LCDへの転送を行います。
リングバッファは1センテンス分というより処理が間に合うだけという感じですので，当初は64バイトを確保しました。
また，ついでにGPRMCセンテンスから日付情報も取得するようにしてみました。
ところが，これでもやっぱり遅れます。考えてみると，UARTから80バイトを取り込むのにかかる時間は多くても100ms程度ですから，これをゼロにしても，1秒の遅れが解消されるわけではありません。なにが原因なんだろう・・・やっぱり1PPS出力がないとダメなのでしょうか。
GPSモジュールとしては，MNEA-0183で送り出す測位情報を外部のマイコンで記録してくれることを期待しているわけですから，必要なのはその測位を行った時刻が正確であることです。リアルタイムで正確な時刻を吐き出すことはしていなくても当然です。だからGT-720Fを使う限りは，もう無理なのかなあと思ったのですが，あきらめずにもう少しだけ頑張ってみることにします。
GT-720Fには，ボーレートを変更するためのツールがあります。9600bpsではなく，これを38400bpsにすれば1センテンスの受信にかかる時間が1/4に短縮されます。
ということでいろいろツールをいじっていると，別の端子から専用のパルスを出すのとは違いますが，UARTへの出力を1秒で正確に出すことで1PPSが可能になったり，測位を1秒に2回とか4回といったように，測位周期を変えるたり出来ます。また，送り出すセンテンス種類を制限したり，それぞれの送信頻度を調整できたりします。
タイムゾーンの設定が出来るとJSTへの変換もいらなくなるのでいいなと思ったのですが，設定を行っても反映されないようなのであきらめました。
これらの設定をいろいろ試行錯誤したところ，AVR側の処理速度と受信バッファの大きさから，38400ボーでは取りこぼしが起きています。64バイトの受信バッファでは，あと数バイトたりない感じです。
悔しいので，96バイトまで増やすことにしました。
64バイトだと，リングバッファを実現するのに，リードポインタもライトポインタも0x3fでANDするだけでサイクリックに回せるのですが，96では真面目に96になったかどうかを判定し，真ならゼロにリセットという処理をせねばなりません。せっかくボーレートを上げても，処理が増える事で速度低下が起きるようなら本末転倒ですが，まあやるだけやってみます。
また測位周期は1秒に1度から1秒に2度にします。これまでは1秒に1度しかGPGGAセンテンスが飛んでこず，よって1秒に1度しか表示が更新されないことになるので，表示のズレが1秒くらい出てきてしまうことは避けられないように思いました。
しかし，1秒に2回にすれば，500msごとにGGAセンテンスが送られてきて，表示も1秒に2回更新されることになりますから，GPSモジュールが本当に1秒未満のズレで時刻を送ってこなければ，表示のズレは500ms以内に収まるはずです。
さらに，処理を軽くするために，GPGGAとGPRMC以外のセンテンスの送信を停止し，さらに日付情報が欲しいだけのGPRMCセンテンスの送信頻度を10秒に一度にします。こうすると，GPGGAが運んでくる時刻情報が他のセンテンスに邪魔されず，1PPSを守って送られてくると考えたのです。
また，AVRの処理速度を根本的に向上させるため，これまで内蔵クロック8MHzだったものを，外部クリスタルによる20MHz駆動としました。UARTのボーレートも正確になり，一石二鳥です。
そんなこんなで，こんなコードになりました。
