わふうの人が書いてます。

iOSアプリケーション開発、BLEのファームウェアとハードウェア試作のフリーランスエンジニア。

nRF52の印象

モジュールの種類と選定ポイント

各社からnRF52を搭載した無線モジュールが、評価版が1月から2月、量産が3月から4月に開始される予定です。nRF52はnRF51とピンコンパチブルなので、モジュール利用者から見れば、nRF51の無線モジュールをそのまま置換できるイメージでよいでしょう。無線モジュール開発会社にとっては、バランがオンチップになったりと高周波周りは再設計で手間がかかるとは思いますが、それが仕事ですから、作ってくるだけの話だと思います。

モジュールは、大きさで2種類に分類できます。一つは10x13mmくらいのもの、もう1つは11x5mmあるいは更に薄く小さくしたものです。nRF52は、6×6mm QFN と小型の3.0×3.2mm CSPの2種類のパッケージで提供されます。小さいモジュールはCSPを使っていたりします。

10mm角程度のモジュールは、汎用的に作られているものです。nRF52のすべてのIO端子が外部に取り出されている、たいていの場合ではDC/DCの外付け部品と32kHzの発振素子がモジュール内部にあります。小さいモジュールは、ものによりますが、すべてのIO端子は取り出されていない、DC/DCおよび32kHzの部品が省略されていることがあります。

モジュールを選ぶときには、極端に消費電力を気にするのか、IO端子はどれだけ必要か、の2点で決めればよいです。大きさが制約条件になる場合は、小さなモジュールでならば実装できるとしても、技術的には、独自に実装してしまったほうが早いかもしれません。ただし開発費用が1000万円ほど上乗せになりますから、そのあたりは技術ではない選択になるでしょう。

BLEで電池を使うものは、使い捨てのCR2032などのコイン型電池あるいは充電可能な40mAh程度のリチウムイオン電池を使うでしょう。コイン型電池で直径16mmか20mm、リチウムイオン電池でもその程度の大きさなので、腕に巻く細いバンドでもない限り、どちらの大きさのモジュールでも使えるくらいです。

消費電力を気にする場合は、DC/DCは必須です。(32kHzの発振素子もあったほうが、たぶんよい。nRF51の場合では、32kHzの発振素子がない場合は平均4マイクロアンペア程度消費電流が増えます。nRF52でそれがどうなるかは未確認ですが、増えるんじゃないかしらん?)

nRF51からnRF52へ移行すべきか

nRF51を使っている既存製品の次モデルをnRF52にしておくとメリットがあるのか、あるいは新規開発でnRF51とnRF52を選ぶとすれば、何を基準に判断すればよいのか、いろいろあると思います。

nRF51それ自体は今後も提供されていくでしょう。ですが特にnRF51を選ぶ理由がないならnRF52を選んでおくのがいいと思います。

nRF52はnRF51と内部構造は同じです。またパッケージはピンコンパチブルです。ファームウェアやSDKあるいはソフトウェア・スタックなどのソフトウェアのバージョンの違いは出てきますが、nRF52はnRF51の上位版として使えます。

極端に消費電力を気にする場面では、採用する価値が大いにあります。

これは無線回路の低消費電力化もさることながら、周辺回路のPPIおよびEasyDMAの活用が可能になったことがあります。逆に、それらの機能をファームウェアが活用しないならば、nRF52の価値はないです。機能を達成するためには、ハードウェアの選定時には、その旨を共有するために、ファームウェア開発者も同席させておくべきです。

nRF52から見えるファーム開発手法

nRF51でもそうでしたが、nRF52ではさらに、ハードウェアっぽい開発のやり方が適していると思います。1つはRAMの使い方、もう1つは周辺回路のリソースです。

ヒープ領域つまり動的に確保解放するメモリ領域は、BLEでは使う必要はないと思います。nRF51のSDKを見ると、例えばタイマーなどは、必要なタイマーの数をコンパイル時に指定してしてしまいます。1つ1つの機能が必要とするRAM領域を静的に確保し、使い続ける感じです。

これはアプリケーションが使えるRAMサイズが8kBもしくは24kBのnRF51だったから、そういうコードを書いていただけで、RAMが64kBになったnRF52では、ヒープ領域を活用すればいいだけかもしれません。

ヒープは、処理を時間軸で見た時に、処理が開始/終了する場合に、メモリ領域の確保と解放によって、小さなメモリでも処理を収めることができます。ある処理について、処理時に必要なメモリ量がかなりあるとします。しかし、処理が終わればメモリは解放できるとします。そんな処理を、1つ1つ処理していくならば、ヒープ領域を使うべきです。

ですが、BLEのハードウェアは、電源が入ってからずっと、それぞれの機能自体が最初からずっと動き続けるものがほとんどです。ソフトウェア処理であっても、とてもハードウェア的です。このようなものは静的メモリ確保がよいです。メモリが不足して処理が停止することがないか、というワースト・ケースの検証がむちゃくちゃやりやすくなります。

この方法では、メモリ不足の例外が生じた時には、動的に確保されるのはスタックを見るだけでよいです。スタックは処理順番と処理過程の情報を全て含みますし、静的に機能しているものは静的なメモリ領域を見ればよいので、例外発生時のデバッグが楽です。

極端な話をすれば、動的なメモリ確保では、メモリダンプをしても、どこにどんな値があるのかを読み取るのは、とても大変です。静的な割当であれば、シンボルテーブルを見ながら人力ですら、目視デバッグ可能です。

nRF52は周辺回路すべてにEasyDMAが入りました。nRF51でのPPIは、タイマーやGPIOを組み合わせて一定周波数のパルス波形を出す程度にしか、活用できませんでした。しかしメモリ転送が組み合わせられるので、TWI経由でのデータ収集がPPIとEasyDMAでできます。

if then elseが入らないかぎり、また演算処理をしないかぎり、プロセッサを起動する必要はないでしょう。またデータをためてから一気に処理をすることで、プロセッサのスタートアップ時間40マイクロ秒で消費する電力を最小化できるでしょう。

通常であれば、プロセッサが制御を行うもので、周辺回路は割り込みでプロセッサに処理を委譲するファームウェアを書くと思います。nRF52でも、電力を気にしないならば、普通のそのようなファームウェアは書けますし、それで機能します。

nRF52であればできること

nRF51ではできなかったがnRF52であればできることは、デジタル信号処理が必須になる利用場面です。音声のやり取り、音の送受信、また万歩計などライフログ的な機能などがあります。

例えば万歩計であれば、3軸加速度データを1000サンプル/秒で収集、合計3kB程度のデータを貯めて1秒ごとに一気に演算処理する、なんてことができます。プロセッサがスリープから起動する40マイクロ秒よりも、演算処理時間が十分に長く取れる程度に、IOをバッファリングさせることがnRF52なら、可能です。

IoTの話題

IoT系の話題に乗りたいなら、nRF52を採用すべきです。今後、IoTに向けた規格拡張がなされていきますが、nRF52はそれらに最適な対応ができるハードウェアに、たぶん、なっています。

IoT系の話題が盛り上がっています。BLEでも、IoT系で必要になるメッシュネットワークに必要な技術を提供しています。また今後のBluetooth規格には、メッシュネットワークが規格もしくは実装推奨など何らかの形で、SIGからの提供があるでしょう。

IoT系でのBLEの立ち位置は、2.4GHzで電池持ちがやたらといい超低消費電力無線通信技術で、スマートフォンやパソコンが通信相手になれる普及した無線通信技術です。

920MHzのように100メートルを超える距離の通信や、Zigbeeなどのメッシュネットワークを始めとした工業用途での実績はありませんが、スマフォが対応している1点だけでも、一般消費者に使いやすさを提供できる技術です。

隣のBLEデバイスとの通信の確保、つながったデバイスがパケットを中継して、遠く離れたデバイスにパケットを届けるくらいまでは、技術が提供されるかもしれません。しかし、WiFiなど他のIoT系と同じく、通信スタックをどうするか、デバイスの管理機構やそのための通信仕様、あるいはデバイスのデータ表現の方式などは、標準規格が乱立していきます。

このあたりは、BLEとしては、上層には何を採用してもプロセッサにその処理を実装すれば作れます。何をどうするかは、ハードウェアの製造会社が決めれば良いだけの話です。

雑感:BLEだけでよいのだろうか?

nRF52に限らずnRF51でも成り立つ話なのですが、複数のBLEデバイスが身の回りにあふれる状況で、BLEだけでよいのだろうか?、と思うことがあります。IoTやスマートホームの話題にかぎらず、身の回りにわんさとデバイスがある場面であれば、1台ごとにユーザが管理するのは、ユーザ体験として無理があります。

そのときに、開発としては、メッシュネットワークやIoTの標準技術になるだろうIPv6などの通信技術や規格を求めたくなるかもしれません。しかし、通信技術とは通信相手があって初めて意味がある技術です。身の回りにあふれるデバイスとの通信相手は、なんでしょうか? 必ず、WiFiに接続する何らかのデバイスあるいはスマートフォンがルータになります。このルータと複数のデバイス間はBLEしかありえません。しかし、デバイス間がBLEである必然性はあるのでしょうか?

またIPv6が規格としてかたまり利用可能になったとしても、デバイス管理システムは、おそらく自社で構築する他ないでしょう。これはIPという技術は通信を提供するだけで、その上のアプリケーション、管理システムにはまったく関わらないからです。おそらく、会社ごとの管理システムが乱立して、誰も使わない暗闇の時代になるでしょう。

IPv6でBLEデバイスが直接インターネットに繋がることは、デバイス管理上、ありえないと思います。家庭用のWiFiを見ていても、防壁がなければいろいろなところからちょっかいをかけてくるのがわかります。BLEデバイスであれば、通信はすなわち電池の消費に繋がる場面もあります。セキュリティの意味でも、BLEを直接外部の任意の通信にさらしてもしかたないです。インターネットとBLEの間にあるルータには、フィルタリング機能が入るでしょう。

では、デバイス間では? BLEをベースにしたメッシュネットワークなど、これから実現される技術を使っても良いのですが、自社製品だけで固めるならば、独自の技術でも良いはずです。nRF51およびnRF52には、Time Slot APIという、BLEが無線回路を使っていない間、無線回路を使うAPIがあり、任意の通信プロトコルが実装可能です。そういったAPIを活用して、BLEに準拠しない自社で閉じた通信で、デバイス間連携と管理システムを作ってしまうのでよいのでは、そう思います。

また、技術が標準化されたならば、ファームウェアを更新することで、その技術への対応がnRF51/52であれば、できます。そういう進め方で、いいようなきがするのです。