First, ran a Nordic sample program on the BLE Nano.
番外編なんか書いたりして混乱してきましたが、話を戻します。そう、BLE Nano を購入したけどソフトの開発環境がいろいろあるので悩む、という話でした。
ARM の世界はベンダが多いので事情は複雑です。開発環境を一意に決めようとすると、思いつくだけでも次のような条件の組み合わせ存在します。
- コンパイラはどうするか? ARM 純正 ARMCC? GNU の GCC?
- ライブラリは何を使うか? Nordic SDK だけ? mbed SDK も使う?
- デバッグはどうするか? print デバッグ? JTAG/SWD (Serial Wire) デバッグ?
- 統合開発環境（IDE）は使うのか? mbed? Keil uVision (MDK-ARM)? Eclipse? あるいはコマンドライン?
ただしユーザー視点に立つと、おおむね以下が現実解のようです。これはほぼ、Red Bear 社のウェブサイトにもある通りです。
- ライブラリには Nordic の SDK だけを使い、GCC でコンパイルし、MK20 USB でフラッシュメモリに書き込む。デバッグは、まあ UART print にて。
- GDB の環境を用意して、J-LINK あるいは CMSIS-DAP 経由でデバッグする。
- GCC でなく Keil uVision（ARMCC）で開発し、J-LINK 経由で SWD デバッグする。
- mbed と mbed SDK で開発する。当然、コンパイラは ARMCC。デバッグは UART printf。
今回の私のケースでは、まずは Nordic の SDK を使うだけのサンプルコードを動かしたかったため、上記最初の方法を試すことにしました。そこで、前回紹介したような方法で Mac OS X 上に GCC ARM と Nordic SDK をインストールし、make でハートレートサービスのサンプルコード（nrf51822/Board/nrf6310/s110/ble_app_hrs）をビルドしてみました。hex ファイルは、
$ srec_cat s110_nrf51822_7.1.0_softdevice.hex -intel ble_app_hrs_s110_xxaa.hex -intel -o hrs.hex -intel --line-length=44
のようにして生成できます。MK20 USB ボード（ドングル）に BLE Nano を接続すると USB メモリとしてデバイスが見えるので、そこに hrs.hex をドラッグ&ドロップすれば完了します。あとは、iPhone 上で Nordic 社のアプリ nRF Toolbox を動作されれば、無事に HRM（ハートレートモニタ）の動作を確認できます。（ちなみに、iPhone には Bluetooth LE (BLE) の機能が載っていることが必要です。当たり前だろうと思われるでしょうが、最初私は iPad 2 で試そうとして、そこには BLE の機能がないことに気づくまでしばし時間を要しました。）
なお、Mac OS X でファイルのドラッグ&ドロップは、コマンドインターフェイスに慣れた開発者には面倒に感じます。試しに cp で
$ cp hrs.hex /Volumes/MBED/
のようにファイルを置いて見たのですが、なぜかうまく動きませんでした。いろいろ先達の情報を参考にして、dd コマンドで
$ dd if=hrs.hex of=/Volumes/MBED/foo.hex conv=notrunc
のようにしたらうまくいきました。cp コマンドは、何か特殊なことをしていて、MK20 USB のフラッシュファイル操作と相性が悪いのかも知れません。御参考まで。
とりあえずハートレートモニタが動いたところで、今日はおしまい。次回は mbed 開発環境の評価について書こうと思います。