mbedでNMEA-0183 Libraryを動かす

「NMEA-0183メッセージの解析」で書いた通り、さてこれからSTM32 Primer2でGPSモジュールを動かすぞ！と意気込んだ矢先に電源ショートでGPSモジュールがお亡くなりになっていました。スイッチサイエンスさんからの取り寄せで、めでたく(?)GPSモジュールが復活したため、NMEA Libraryを使って実際にGPSモジュールが出力するNMEA-0183メッセージの解析を行ってみました。

ただ３月初めからmbedにはまっており、STM32 Primer2でなく、mbedで動かしています。使用したライブラリは、前回記事と同様のNMEA Libraryです。

■ mbedプロジェクトへの外部ライブラリコードの取り込み

以下のキャプチャー画面に示すように、NMEA Libraryのコードを格納するフォルダー(nmea)を作成して、ライブラリファイルを格納します。

xxx.hファイルはImport Fileメニューから取り込めるのですが、xxx.cファイルはImport Fileで取り込めないため（x.cppは対応）、空のファイルを作ってコピペでインポートしました。

■ コーディングとコンパイル

main.cppとgps.hのみが今回コーディングした部分になります。ソース一式はmbedのwebページに格納してありますので、こちらを参照してください。

前回も書きましたが、NMEA Libraryはメッセージの行単位に依存せず、一定の文字数単位でパーサーにデーターを渡して解析ができます。今回のプログラムでは、シリアル接続したGPSモジュールからデーターを受信する毎に割り込み処理でバッファーに受信データーを蓄積し、バッファー長が200Byteを超えた時点でパーサーを呼び出します。

パーサーを呼び出す瞬間もデーターを受信していますので、バッファを２面用意して、割り込み停止中にバッファー面の切り替えを行っています（いわゆるダブル・バッファー）。割り込みの停止はmbedのSerialライブラリ関数呼び出しだけで行っています。そのため、割り込みハンドラーの登録機能を使い、過渡的にハンドラーのポインターをnullに書き換えることで割り込みON/OFFの制御を行っています。このあたりの制御は、通常コントロールレジスターの割り込み許可フラグクリアクリアで行いますが、今回は手っ取り早く開発することを優先し（LPC1768のデーターシートを読むのが面倒で、、）、標準ライブラリの機能で実装しています。

コンパイルしてみると、NMEA Libraryの部分は、殆ど無修正でコンパイルが通りました。直したのは、malloc関数の戻り値をポインターに代入するコードが型の不一致でエラーになったため、キャストを追加しただけです。当初VC++でコンパイルした際は全くエラーがなかったので、mbedのコンパイラの方が型チェックを厳しく行っているのでしょうか。

メッセージの解析が完了すると、nmeaINFO info構造体に結果が格納されます。構造体からのデーターの取り出しは前回の記事に示した通りです。

パーサーの動作とは直接関係がありませんが、ブレッドボード上でmbedとGPSモジュールを隣あわせに配置すると、ノイズのせいかGPSの受信感度が低下しました。そのため、両者の距離を離して配置しています。mbedのクロック周波数を47MHzに下げるとさらに感度が改善できました（厳密な比較はできていませんが）。MACチップのクロックもノイズ源だと思うため、ついでにMACチップの停止も行っています。クロック周波数の変更とMACチップの停止もmbed.orgのNotebook（blog相当）で公開されているmbed Clock Controlとmbed Power Controlを使用しました。

■ 動作イメージ

今回作成したプログラムは、以下の２つの出力に対応しています。

1) USBシリアルに以下のような結果を出力（gps.hの#define SERIAL_OUTPUTをuncommentする）

Trace: $GPGSA,A,2,29,18,22,,,,,,,,,,5.0,4.8,1.0*39
Trace: $GPGSV,3,1,11,22,45,225,32,18,24,186,34,29,16,148,32,30,82,102,*73
Trace: $GPGSV,3,2,11,14,59,327,,05,53,049,,01,47,321,31,12,47,048,*75
9140, Lat: 35.xxxxxx, Lon: 139.xxxxxx, Sig:1, Fix:2, Inuse:3
  sat_id:22, sig:32, Inuse:1
  sat_id:18, sig:34, Inuse:1
  sat_id:29, sig:32, Inuse:1
  sat_id:01, sig:31, Inuse:0

2) 「mbedのライブラリ作成」で使用したeDISPライブラリを使ってLCDに結果を表示する（SERIAL_OUTPUTをcomment outする）。表示イメージを以下に示します。

■ mbed開発環境の感想

まだ２週間程度ですが、mbed開発環境を使ってみた感想は以下です。

利点：

• お手軽さでは、Arduino以上。組み込みプログラミングやC++の心得のある方なら、箱から取り出してから数時間でそこそこの作品ができてしまいます
• mbedの開発環境はいわゆるSaaSというヤツで、クラウド上に開発環境があり、ローカルPCに開発環境を構築する必要がありません。開発環境構築やメンテの工数が不要というのは、非常に便利なことがよく分かりました。これまで、Google Appのようなクラウド/SaaS系のサービスは、ローカルアプリに比べて使い勝手で劣るという先入観があり使ったことがなかったのですが、mbedでクラウドの可能性を実感した次第です
• コンパイラ画面からワンアクションでコードを一般公開できます。また、Notebookと呼ばれるBlog機能もセットになっており、成果やノウハウをコミュニティー内で共有できるようになっている。クラウド開発環境に加えてこちらも興味深い試みだと思います
• 今回のように、出来合いのライブラリを組み合わせて、ちょこちょこっと作品を作る用途では最強かも。ArduinoだとSRAM容量の制約にぶち当たることもありますが（328でNMEA Libraryは動かない）、mbedなら問題なしです

欠点：

• ドキュメント類がまだ貧弱なため、ライブラリの挙動が分かりづらい
• デバック環境が貧弱。というか、ないに等しいですが、今回のように出来合いライブラリの組み合わせでは特に問題にはなりませんでした
• リンカーのメモリー割付結果が分からないため、ヒープをどの程度使っているかなど、メモリーの使用状況が分からない
• コアライブラリのソースが非公開など、一部オープンでない部分がある。コアライブラリのソースが公開の理由は、APIのアーキを早く固めることが優先事項のためらしい。今オープン化してAPIのサブバージョンが一杯できるのを懸念しているのかな。将来的にはオープン化すると言ってはおりますが

メモリ管理の自由度が弱点と書きましたが、ヒープポインターをプログラムから取得することや、ペリフェラル用の16K + 16K SRAM領域をバッファとして使うことは、mbed開発環境上でもできそうなため、別途調べてみようと思います。