■エンジンをATMEL社ATmega128に変更してのGPSロガー再構築。作っちゃ壊し、作っちゃ壊して３つめ。最初に作ったPIC18Fベースの使い勝手がやっぱり良かったので、今の試作もデザインとしてはそちらにもどっている。ただ、LCDは20x4のサイズ。GPSロケーター、最終的にはロガーにするけれど、MCUのあらかたのプログラミングは学べるんじゃないかしらん。
今のところ、GPSからのリードアウトを割り込みで処理して文字列判定し、LCDに座標表示させている。GPSから出力される緯経数値は度・分・秒のうち、秒が10進表記になっているので、これを60進表記に変換する。その過程で、BCD変換とBCD演算が入る。
供給電圧モニタとして、1.2Vの電圧制限ダイオードの電圧を適時AD変換している。AD変換は供給電圧そのものをリファレンスとしているので、1.2Vの観測値は供給電圧に対する相対値として得られる。そのため1.2Vの観測値からリファレンスである供給電圧を求めることができる。
プログラミング言語はCを使っている。ただ、コンパイルがされた後に生成されるコードをどうしても意識してしまう。だから、変なコーディングをしている。コンパイラが良ければあんまり意味がないかもしれない。たとえば、BCDの6倍演算処理を、x2とx4の結果を足し合わせる形で行ったり。Cで楽するなら、BCDからintなりなんなり数値を扱う型に変換した値を6倍してからBCDに変換すればいいと思う。でもそれでは実行ステップを喰ってしまう。BCDで扱うのは、BCD(1バイト)で格納された各桁の値に'0x30'(ASCIIの'0')をOR演算していけば、数値文字列と見なせ、そのままLCDでの表示データに使えるから（逆も言える。数値文字列の上位4ビットを0でマスクするとBCDになる)。こういう発想は、データオリエンテッドを重んじる最近の言語に慣れてしまうと、もしかすると難しいかもしれない。そもそも'BCD'という発想がデータ型ではないのだし。
２倍、４倍と２の倍数を使うのも、CPUはシフト演算のコストが低いからだ。これはCPUの基底レベルではバイナリ演算を模した振る舞いをすることによる。（ここらへん、情報処理の午前試験前半程度のレベル）
抽象度が高いrubyだって、突き詰めれば同じようなものになってしまう。いわゆる「高級言語」の階梯を上がっていくことで、しだいにフィジカルな実体は見えなくなってしまうけど、消えてなくなってしまったわけじゃない。でも、ウェブアプリケーション界隈で流行っている言語から物理的な実装はとても遠い。もちろん、それじゃあ、とAVRのコードでウェブアプリケーションというのは気が遠くなるというか、寝言は寝て言えという話になるわけで、何事にも得意・不得意というものはあるという話。
今回のGPSロケーターにはこれまでと同じでは芸が無いというわけで、３軸加速度センサを載せてみました。ADコンバータの使い方の練習というか、そんな感じで。加速度センサを載せて傾きを拾ったとしても実際にGPSロケータ(ロガー)を使っている場面ではバックパックに入れられて姿勢が固定されているわけではないので、意味のある状態を拾えるとは思えない。温度の方がまだましかな。
座標も出せたし、３軸加速度も出せたし、で、あとはSDカードを実装するだけ。PICの時はアセンブラの塊で見通しの悪さったらない代物になったのだけど、Cでコーディングするとどうだろう。世にAVRのCで作ったSD/FATアクセスルーチンは公開されていたりもするのだけど、そこはあえて作る。まあ、趣味だしね。老化防止という意味もこめて。
