先日のエントリで広げた風呂敷を徐々に実現していく段階。
ひとまず、NewSoftSerialから。GPSを接続して、NEMA形式のデータが取得できることを確認。これでシリアル接続のデバイスが試せることと、GPSをどう扱うかの検討課題が見えてきた。
まず、ドリトルのいまの実装に対する課題が、引数がひとつしかとれないこと。現在は1バイトのコマンドに1バイトの返答をする実装のため、新しいシリアルポートを作成するために必要な、RX, TXの2つの引数を渡すことができない。
もうひとつ重要なのは、返答も1バイトなので、GPSのデータのような不定長の文字列をドリトル側に渡すことができない。
また、例えばシリアルLCDなどに文字列を出力することを考えれば、ドリトルから送信するデータも不定長を許すことにしなければならない。
というわけで、まずコマンド（というよりもバイトコード）の再設計と、ハンドシェイクを行い確実に通信できる実装が課題ということがわかった。ドリトル側の送信タイミングは環境によっていろいろあることが予想されるので、あまりナイーブな実装はするべきではなさそうに思う。
次にGPSなのだが、生のNEMAフォーマットの文字列をドリトル側で処理するのはコストが見合うのかどうか考えたほうがよいと思った。なぜなら、GPSが1度に送信するデータの行数は様々で、補足できる衛星の数も機種によって様々、ロックできる衛星の数は場所による、データ送信間隔も毎秒1セットから5セット（1/5秒ごとに送信）までいろいろあるから。
率直なところ、屋内で衛星が見えない状態では意味のある情報は得られない。だから、衛星をロックしたかどうかを確認してから値を取得する必要がある。ドリトル側にそれを調べる命令を用意すべきか、Arduino側がお世話を焼くかも検討課題。
また、コンマ区切りの長い文字列をドリトルが受け取っても、いくらV2.2で文字列処理命令が充実したといっても効率的にどうか、ということもある。実用を考えればすべての情報はドリトル側には不要なのではないか、というのが現在の予想。日付、時刻、緯度、経度、高度、方角ぐらいあれば十分ではないだろうか。速度などは車載でもしなければ不要ではないか、など。そうなると、Arduino側で実用的なデータに整理してから単純なフォーマットで送るべきではないか、ということになる。幸いNewSoftSerialの作者がTinyGPSというライブラリを作成していて、これを追加したペナルティは100バイト程度とのことだから、これを使ってみたいと思っている。
とりあえずいまの段階はそこまで。あとはあした考えるつもり。
