nRF5で使えるリアルタイムオペレティングシステムを見てみる

ポエムです

nRF5で使えるリアルタイムオペレティングシステム(RTOS)を見てみました。RTOSとか、全然知識ないです。なので、ポエムです。

SenStick http://senstick.com を開発していて、イベント駆動の開発をC言語で自分で関数を組み合わせて作るのが辛くなってきたので、今時の開発ライブラリあるいはRTOSを使えば先人の苦労の結晶の恩恵で、楽ができるのかなと思ってRTOSを探してみました。

今時のRTOSは、IPv6なTCP/IPスタックやHTTPSやCoAPなどのプロトコルを提供しているから、RTOSをベースにしておけば、将来的にIP系の技術を使うときに安心だとも思います。こういう、今使わないけど将来使うかもしれないっていうのは、将来もずっと使うことはない定番ですから、多分意味ないですけど。

nRF52対応なRTOS

オープンソースなnRF5対応RTOSをぐぐってみると:

があります。

BLEスタックを独自で持っているか、持たないか

nRF5対応RTOSは、BLEスタックを独自で持っているか、Nordicのソフトデバイスを使っているかの2つに分類できます。

nRF5のソフトデバイスは、ユーザのファームウェアの処理にかかわらず、BLEの通信を扱うために、BLEの通信処理が必ず最優先で実行される作りになっていて、またユーザのアプリケーションが暴走してもBLEのの通信スタックには影響しないよう、割り込みやメモリ領域のアクセスレベルを設定します。

RTOSは、タスクのプリエンプション(実行の横取り)など、割り込みを利用するものは、特権モードが使えること前提のコードもあります。そういった仕組みだと、特権モードはソフトデバイスが持っているので、RTOSをそこに入れることができません。

やるとすれば、BLEスタック自体を独自開発してソフトデバイスの役割を自前で持つか、特権モードを使わないで作るかになります。特権モードがないと、メモリアクセス保護は使えませんが、ソフトウェア割り込みはソフトウェアデバイスがユーザアプリに開放していますから、プリエンプションの実装などはそれらを使えば実装も可能でしょう。

nRF5はBLEのパケットをマイコンで処理するため、マイクロ秒単位の応答速度が必要です。そして、1チップでBLEの通信とユーザのアプリケーションが実行される構成で、スタックがBLEの認証を取るためには、ユーザのコードがどれほど馬鹿なことをしても、BLEの通信に影響しない作りが求められます。また通信スタックが使っているメモリ領域を外部から変更して破壊されないためには、メモリ領域の保護が必要です。

Nordicのソフトデバイスは、nRF5が採用しているCortex-Mの実行モードを利用して実装しています。Nordicのソフトデバイスは、ハンドラモードで実行され、ユーザのファームウェアはスレッドモードで実行されます。ハンドラモードは全ての特権モードへのフルアクセスができ、メモリアクセス権限も設定できます。スレッドモードで実行されるユーザのファームウェアは、許されていない割り込みへのアクセスや、ソフトデバイスが使うメモリ領域へのアクセスなどができないようになっています。 Cortex-Mの動作及び実行モード http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0203hj/Cihhfga3.html

BLEスタックを独自に持つのが、zephyr と mynewt 。それ以外はBLEスタックにソフトデバイスを使います。ですから前者であれば割り込みやメモリ保護など特権モードを活用した実装ができます。後者では特権モードは使えず、スレッドモードの範囲で実装したものになります。

zephyr

インテルが主導してLinuxファウンデーションの活動を通じてコミュニティで作られているRTOSです。ライセンスは、Apache 2.0 license。

ターゲットはIntel Edisonなどがあるので、x86やIntel Curieの中にある独自32ビットプロセッサARC、それにnRF52やTI社のWiFiモジュールCC3200があります。

カーネルの割り込みや特権モードの機能は、それぞれのプロセッサの種類ごとarchごとに、アセンブラコードとC言語のソースファイルがあります。Cortex-MのソースコードはWindRiverの名義になっていますが、WindRiverはIntelに買収されているので、その資産がここにあるのでしょう。

ドキュメントもしっかりしていますし、ソースコードを読んでもきれいなコードだと思います。BLEのスタック部分は、無線通信のハードウェアに直接関わる部分はNordicの中の人が参加してソースコードを書いているようです。L2CAPよりも上のレイヤはインテル名義になっています。nRF52以外でBLEを使えるように、HCIでシリアル通信でコントローラを接続しても使えるようになっています。スタックのQIDは取得しているっぽい?

プロジェクトを見る限り、RTOSを作りました、それ以上でもそれ以下でもないです。Linuxで同じことができるけれども、Linuxが動くメモリも豊富なリッチなものでも、メモリが64kBのものでも、1つのOSのAPIで開発を統合できる、そんな感じに見えます。

Intelは、Intel EdisonやCurieなどを出してIoTの時代に向けた自社半導体製品の販売に力を入れています。IoT系は、Linuxを走らせられないメモリの小さな数多くのデバイスと、それらを統合してイン−ネット側との橋渡しをするLinuxも走らせられるほどリッチなハブデバイスの2つに別れるでしょう。その2つの開発基盤として、これまで買収したRTOSのリソースを公開、また発展させていくコミュニティとして位置づけているのかしら?

でもnRF51のI2Cがサポートされていないっぽい? 移植してBLE通信ができましただけしか確認していないのじゃないかな。

本当にRTOSでしかないので、Intelが組込みやっぱり辞めましたになると、プロジェクトが止まるのかなと思えます。

mynewt

ApacheのインキュベーションにあるRTOSです。nRF51/nRF52/RISC-Vなどをサポートしています。

NimBLEという独自のBLEスタックを持っていて、Nordicのソフトウェアデバイスよりも2倍同時接続数が多いなど、その特性の高さをアピールしています。BLEの規格を決めている中心メンバーのNordicが作っている半導体を使って、そのBLEスタックであるソフトウェアデバイスに対して、何も真正面から喧嘩売るようなアピールしなくてもと思うのですが、そうらしい。

米国の runtime.io という会社が主体になって開発しているようです。デバッグどうするのかな?と思ったら、社内ではEclipseを使ってデバッグしているそうですが、その環境構築手順はまだ解説を書いていない、そのうち書くかもと、メーリングリストで2017年1月にやり取りされていました。めちゃくちゃうちわっぽい。

このプロジェクトの立ち上げのきっかけが、ネットで制御できるIoTな街灯をATMELのマイコンで開発したら、その制御ハードウェアの種類がいくつもできたり、ファームウェアのバージョン管理の手間が爆発したりと、管理面で散々なことになったことらしいです。

ソースコードを見ると、徹底してモジュールにして管理していて、しかもモジュールごとにGitのレポジトリを参照させている。テストコードがけっこう多い。そしてファームウェアの更新にブートローダがあり、署名したファームウェアを受取り更新する。デバイスの管理ツールもある。ネットに繋がったデバイスを管理するところからスタートしたのだろうなと思わせるコードです。

Cortex-Mのスレッド/ハンドラモードは使っていないっぽい。32-bitマイコンで動きますというのは、優先権限がない場合でも移植できるよという意味なのかも。Segger SystemView対応が入っている。開発環境はDockerで提供されている。実機のUSBデバッグは、gdbとかのツールがDockerで動くからVirtualBoxの拡張パックでUSBポートを追加して、仮想化したのがUSBにアクセスできるようにして、という手順。ビルド環境はすぐ手に入るけど、デバッグ環境がめんどくさい。

バイナリのビルドで、ブートローダ、カーネル、それとアプリケーションをそれぞれ分割してバイナリにして配置できる。ブートローダがカーネルもアプリケーションも更新できる仕組み。今時のネットの環境だと、ファーム更新は必ず入れておきたいから、こういうのが根っこで提供されているのは、よいと感じる。自分で作ったら、もしも何かあっても文鎮化しないかのテストって、めちゃくちゃしんどいだろうし。自分のアプリケーションは自分しか使わないから自分が開発する他ないけど、ブートローダみたいなものは、誰かが1回開発したら全員使うものは同じものなのだから、根っこで提供されていればいい。

ARMはソフトバンクグループになりましたが、このプロジェクトはRISC−Vをサポートしているので、そういう面での勢力にもなれるのかしら。

contiki-os

スイス?の大学のセンサネットワークの開発で20年近く使われているみたいです。とにかくメモリを使わない、書き間違いをしにくい平易なコードが書ける工夫がされている感じのコードだなと思います。シンプルですが、見ていると、いい感じです。

特徴的なのは、プロトスレッドという仕組みです。通常のスレッドは実行中のレジスタとメソッド呼び出しのスタックを保持するメモリ領域を確保します。これだとスレッド(あるいは処理単位、タスク)の数だけスタック割り当て(たいてい200バイト程度?)が必要になります。

ContikiOSのプロトスレッドは、そのスレッドの実行場所がどこかを記録する1ワード(実体はポインタです)を保持するだけで、スタックなどは確保しません。すべての実行は1つのスタックで行われます。プロトスレッドは、それぞれのタスクが実行した丁度いい頃合いにリターンして、CPU処理時間を気を利かせて渡し合う、協調的実行をスレッドとしてコードで表現できる仕組みとみると、スッキリします。

組込みでのC言語のソースコードには、データ処理の流れと、時間軸での処理の流れの2つが入ります。例えば、センサーからデータを取得してフラッシュに保存する処理を考えます。処理の流れは、まずI2Cバスに接続したセンサーからデータを取得して、次にSPI接続されたフラッシュに記録する処理です。実際のコードは、これに時間的な処理、例えばI2Cバスからデータを読み出す、プロセッサを待ち状態にするにはもったいない程度に長い時間を別のコンカレントに実行されている処理に渡すとか、が入ります。

データの処理の流れと時間の流れの処理は別の処理ですが、1つのソースコードに入れるために、例えば支時間のかかる処理の終了通知を受け取るために、コールバック関数を使い、そのために処理関数を分割して、さらに関数ポインタを扱う、なんていうややこしいことになります。

プロトスレッドは、そういった時間の流れの処理の記述を、データ処理の流れと統一してシンプルにコードで表現できる、間違いをしにくいコードを書ける、よい仕組みだと思います。

CoAPクライアントのサンプルをnRF52ターゲットにビルドしてみると、text 37kバイト、data 552バイト、bss 15,700バイトでした。nRF52は64kバイトのメモリがあり、ソフトウェアデバイスに13kバイト取られても61kバイトが使えます。通常のスレッドの実装でも十分に足りるメモリ量がありますから、bss16kバイトというのは、特徴的ですが意味はありません。

しかし、NordicのIoTキットはver.0.9でnRF51のサポートを切りました。nRF51はメモリが16kBのものと32kBのものがあります。ソフトウェアデバイスに13kB取られたら、使えるメモリは、それぞれ3kBと19kBです。マウスなどに使うなら16kB版でも足ります。しかしIP層に使うには、32kB版でも19kBでは通常は実装できません。そういう場面で、ContikiOSなら実装できるのは、特徴かもしれません。

ContikiOSのソースコードを見ていると、ファミコンに使われているZ80互換のプロセッサ向けに、通常の意味での、コンテキストスイッチとスタックを実装したスレッドが実装されています。きっと研究を始めた頃は、普通のスレッドで開発していたけれども、研究で超低消費電力にするにはメモリ量が小さいものしか使えないでしょうし、それを打破するためにプロトスレッドを編み出したのかなと、勝手に思いました。

一般的なRTOSとは言えないけれども、プロトスレッドの仕組みは、実行順序を管理するライブラリとして組み込むことも可能です。非常にシンプルで、変わり種だけれども、よくできているなと思います。

FreeRTOS

古くからオープンであるRTOSらしい。GPLライセンスと商用ライセンスのダブルライセンス。今の最新版のver9は全面的にソースコードを書き直したらしい。メソッド名や変数名に、その値型がわかる命名規則を使っているので、ちょっと微妙な名前に見えるけれども、スマートなコード補完機能がないエディタを使っている環境でも安心なのだろうと思う。

nrf5 sdk12 のブートローダの作り方

2017年1月時点で、nRF52のファームウェア開発は、S132 SDK 12.2.0 を使っています。その開発環境でのブートローダの作り方のメモです。NordicのDFUは、SDKのバージョンごとに変更が多く入ります。

ドキュメント: BLE Secure DFU Bootloader

SDK12でのブートローダの作り

まず、ブートローダをセキュアにするために、バイナリ転送に公開鍵暗号方式が使われます。 これまでのDFUには、書き込もうとしているファームウェアが正規の開発元が提供するものかどうかを確認する機能はありませんでした。ですから、DFUに入る方法さえ調べてしまえば、改造したファームウェアを正規のDFU手順で書き込むことができました。 セキュアになったDFUは、転送されたバイナリが開発元しか知らない秘密鍵で署名されているかどうかを確認します。この機能で、開発元しか、ファームウェア更新ができなくなります。

ブートローダの実装では、DFUを開始するinit packetに、protocol buffersが採用されています。 Protocol buffersは、Googleの社内で使われているデータ構造定義ファイルから、シリアライザ/デシリアライザおよびRPCサーバのコードを生成するツールです。 拡張子( .proto )のファイルに、C言語に似たProtocol buffersの記法で列挙型や構造体のデータ構造を表記すれば、そこからC++を始めとする各種言語用のシリアライザ/デシリアライザのコードを生成します。 Protocol buffersのシリアライザには、プリミティブな値型のバイナリを単に並べて詰めていくだけではなく、連続する0は短い表現にしてデータ長を短くする簡単な圧縮機能もあります。

ブートローダの実装では、DFUに入るかどうかを判定するbooleanの値を返す関数が、weak宣言されています。ですから、ユーザがその関数を宣言すればユーザが宣言した関数がリンクされ、もしも宣言していなければデフォルトの関数としてSDK内部にあるweakなその関数がリンクされます。 SDK10のDFUでは、DFUに入るかどうかの判定関数がSDKのソースの一部に入っていました。そのため、そのDFUに入るかどうかの処理を独自に作りたい部分は、SDKから該当のソースコードを取り出して、直接ソースを変更する手間がかかっていました。

ブートローダのサンプルコード

ブートローダのテンプレートプロジェクトは、 /examples/dfu/bootloader_secure/ にあります。pca10xxxという開発ボードの名前ごとに、プロジェクトファイルがあります。

このブートローダに対応する、ファームウェア側でDFUに入るためのコードサンプルは、Experimental: Buttonless DFU Template Application にあるように、 /examples/ble_peripheral/experimental_ble_app_buttonless_dfu のボタンレスDFUのファームウェアです。これはDFU専用のサービスとキャラクタリスティクスを作り、そこに0x01が書き込まれればDFUに入ります。

DFUに入るフラグの保存方法

SDK12のDFUは、デフォルトの実装では、DFUに入るフラグをフラッシュに書き込み、そして再起動してブートローダがそのフラッシュのフラグを読み出して、DFUに入る動作をします。 フラッシュへの書き込みは、専用のライブラリがSDKに用意されています。 experimental_ble_app_buttonless_dfu のソースコードを追っていけば、その関数などが見つかります。

SDK10では、リセットされても初期化されないユーザが任意に使えるレジスタにDFUモードに入るフラグを書き込む実装を使っていました。フラッシュを使おうとすると、BLEの接続切断の完了を待ってから、フラッシュの書き込み処理を行い、それが完了するのを待って再起動をする処理が必要になり、手間だと思ったのでSDK10と同じレジスタに書き込むだけの簡易処理を今回は使いました。

ブートローダの作成メモ

makeコマンドやPythonが必要になります。開発環境はMacで、その上で仮想化したWindowsを使いKeilを使っています。Keilは単なるビルドとデバッグのIDEとなっています。 Windowsにmakeコマンドを入れたりPythonの環境を作るのは手間だったので、はじめからそれらの環境があるMacで、以下の手順を行っています。

まず、テンプレートプロジェクトをコピーしてきます。プロトコルバッファの定義ファイルからのファイル生成は、既存の生成ファイル(dfu-cc.pb.h, dfu-cc.pb.c)を、そのまま使います。

次に、秘密鍵/公開鍵の生成や、ファームウェアのイメージを作る nrfutil をインストールします。nrfutilのバージョンは以下のように、SDK12に対応するバージョンは1.5.0以降です。2017年1月時点では2.1.0になっています。

  • Version 0.5.2 generates legacy firmware packages compatible with nRF SDK 11.0 and older
  • Versions 1.5.0 and later generate modern firmware packages compatible with nRF SDK 12.0 and newer

nrfutilは、https://github.com/NordicSemiconductor/pc-nrfutil/ にインストール手順がありますが、pythonのパッケージ管理システムを使うと便利です。

フリーランスあれこれ

これは フリーランス残酷物語 Advent Calendar 2016 9日目の記事です。

年末の金曜日に何を書いているのだろうとは思いますが

クリスマスもお祭りならば、ネットのお祭りに参加するのも、また祭りです。見ているだけより踊ったほうがより楽しいので、書いてみます。

能ある鷹は爪を隠す、あるいは沈黙は金と言います。しかし、ネット経由でお仕事を募集している身で、またネットに露出しなければ存在すら認識されないため、定期的に書くことは生命線でもあります。

格言なのかどうかはわかりませんが、俺の屍を越えてゆけ、と言います。しかし屍になるようなイベントがあるところに、わざわざ自分から出向いても、死体が1つ増えるだけで意味がないのではと、よく思います。

俺の屍を避けてゆけ、が正しいのではないかと思います。しかしまた、その1つの事例をみただけで、その先には何もないと思ってしまうのも、検討が浅い正しくはないふるまいなのかもしれません。行動するのも、また行動をしないことも、何事も自分の頭で考えて決めていく、あるいは思考を停止して決めることすらやめてしまうなど、自分で決められるのは、それは自由なのかなと思います。

まともなことは昔書いているので、今回はパスで

2009年10月から個人事業主を始めたので、もう満7年が経過しました。どこか相手先で作業をしたりではなく、在宅で作業をして成果物を納品する、完全リモートというか、委託などで業務をしています。いままで運良くいままで生き続けられています。

これまでに行ってきている業務は:

  • iOSアプリ開発
  • iPhoneとイヤホンで連携するハードウェアとファームウエアの試作
  • BLEのiOSアプリとファームウエアおよびハードウェアの試作
  • 著作、講演、技術サポート
  • 技術的な講師やハッカソン主催のお手伝い

などです。

真面目なことは2011年から2012年に、その頃使っていたブログサービスで書いています。退職するときは退職前にクレカを作っておいたほうがいいとか、任意保険や健康保険税とのつきあいかた、あるいは家から一歩も出ずに法人を作る方法とか、そういう自分で調べてやってみた記録です。

フリーランスって、歩兵のイメージがあるけど、じつは重装備で訓練が必要な言葉なのかも

今回のは、お祭りなので、こういうのじゃないことを書けなのかなと、空気を読んでみます。

フリーランスとよく言いますが、自分でランスという槍を持って、自分の身一つと才覚とを携えて、戦場に出向き仕事を探す個人で活動するイメージかと思います。

ランスといえば、騎兵が用いるものです。なんとなくフリーランスは歩兵のイメージがありますが、ランスですから歩兵ではなく騎兵、つまり馬と馬具そして防護の鎧などの道具を一揃い持っていて、かつ馬に乗る訓練など時間がかかる教育訓練の投資もしているわけですから、昨日今日はじめました、と言ってなれるものでもないのかなと思います。

会社をやめた話

会社勤務は10年間していました。奈良先端で修士を取得して、2年間キヤノン株式会社にいました。この時の業務は半導体設計部門でデジタルカメラの映像エンジンのなかの画像コーデックのファームウェア作りです。その後、愛知県蒲郡市に本社がある、日本電産ではない方の、株式会社ニデックに8年間いました。この時の業務は人工視覚デバイスの研究開発でした。

ある5月の朝のことです。起きると目の覚めるような青空でした。愛知県蒲郡のあたりはミカンの産地でもあるように、年間を通じて雨も雪も少なく、冬ですら青空が広がっています。この気持ちよさは、冬は重たい雲と雪に閉ざされる山陰地方出身の人にしか通じないと思いますが。

辞めよう、そう思ったので9月いっぱいで会社をやめて、さて何をしよう?と思ったとき、たまたまiPhoneが話題になっていました。個人でアプリを販売できるストアもあり開発情報はネットですべて入手ができるらしいので、それで食っていけるのかな?と思ったのが、始まりです。

キャリアプランがとか、世界を変えるとか、かっこいい言葉で外向きに飾ることもできるのかもしれませんが、そんな重たい言葉で毎日それをやり続けるのは、しんどい話だろうと思います。飽きた、きっかけは、そんなものです。

最初の1年

2009年10月から個人事業主をはじめました。手続きは、市役所に行って国民健康保険に切り替え、税務署に行って青色申告の申請まですませるだけです。

それまでの業務でFreeBSDで遊んでいたり、C# でWinFormそしてWPFでアプリを作り、組み込みLinuxボードでWinアプリにカメラをストリーミング表示する実験装置を作っていたりしていました。ですがMacは全く触れたこともありませんでした。

iOSアプリの開発を始めるのにObjective-Cを使うのですが、新しい言語を覚えるのを体が拒否してくれて、難儀しました。そのころ、MonoTouchというC# でiOSアプリが開発できる環境がでていたので、それを使って3ヶ月ほどアプリ開発の自習をしていました。3ヶ月後、Obj-Cを覚えちゃっていました。なんじゃそれ。

アプリを作ろうとして気がついたのですが、私には音楽や絵を作る才能が壊滅的にない。かといって、その頃出ていた白い画面を表示するだけのアプリを、“照明アプリです"といってストアに出す、ひらめきキラメキの才覚にあふれてもいなかった。

アプリ作って売るつもりだったけど、作れないやん。どうしよう。

一人でアプリを作るのを、すっぱり、あきらめました。でも他にやれることもないわけです。会社辞めただけで人脈があるわけもなく当然、仕事のつてもありません。

とりあえず、アプリを作るのは無理なので、iPhoneのイヤホン端子で連携する外部ハードウェアを作りました。いままで実験装置を作るのに組み込みの開発をやっていたので、そういうのはできるわけです。とはいえ、iPhoneでハードでといっても売れるとは思えないので、iPhoneで操作できるロボットを作ろう、としました。

その費用をどうしようかと探すと、蒲郡市のサイトに創造的事業育成プログラムがあり応募しました。市役所の方も、なんか正体不明の中年男性が書類を持って、国の流れで特に応募もないだろうものに応募者がふらりと来たのに、親切丁寧に対応してもらって、こういう仕事もあるんだなと思います。

100万円の助成金をうけてiPhoneで操作できるロボットを開発して、メイカーフェアーに出てたりしてました。市役所は定期的にプレス発表会を開催していて、そこで成果として発表して新聞掲載されたりしたのも、もはや懐かしい思い出です。

市役所の方と冗談で、フリーでやっているけど食えなくなったら生活保護のお世話になりに来ることになるかも、と言ったら、あなたは大丈夫でしょう…、と言われたときの顔が、けっこう記憶に残っています。世の中には自分が接したことがない部分があるんだなと、ちょっと感じました。

環境しだいでどうにもなるのだなと

会社を辞めて地元でもないところで一人住まいをしていると、人と接する機会が文字通りゼロになります。集団でいることがあまり好きではない性格ですが、この環境に3ヶ月ほどいると、例えばお風呂に服で飛び込んだり、微妙に面白い行動をしていました。

アマゾンでダンボールの小さな家が4000円くらいで売っていたので、部屋の中でリラックスゾーンを作ってみようとしたら、小さすぎたとか、そんなことをちょくちょくやっている感じです。

/post/2016-12-09-freelance-sowhat/DSCN0863.jpg

奇声を発するような、周りのご迷惑になるようなことはしていなくて、理性はあるのですが、何か思いつきで普通はしないようなことをしてた気がします。環境で人ってどうにでもなるのかなと。

いまはネタにするのですが、市役所からロボットをテーマにイベントをするから、開発したロボットの展示を依頼されました。行ってみると、小学校の入学説明会のあとに同時開催されていて、子供さんがたくさん来て、けっこう楽しそうに遊んでくれて、出した方の自分としてもかなり嬉しかった。

その次の年もイベントがあるからと出展を依頼されて、また子供が来るのだろうと思い、そもそも、この時点で何かおかしいスイッチが入っている気もしますが、今度はキグルミで行ってみようかと思いつきます。一生のうち一回くらい、キグルミしてみたいよねと。

2回めのイベントに出てみると、みなさんスーツの大人ばかりのイベントでした。昨年のイベントは市政55周年くらいの記念で子供も来てたけど、今回は通常イベントで大人しか来ないよと。先にそれ言っといてよ。連絡って、だいじですね。

せっかくなので、スーツで来場される方々相手に、こちらは特製スーツだしと思って、そのまま説明対応していました。でも、熱暴走でもたないんです。やってみると。2月の冷える日で屋内なのでそれなりに暖房が入っていますが、それでも低温な室温ですが、キグルミって15分で中が熱暴走するんだなと、体験しました。

その時の記念撮影:

/post/2016-12-09-freelance-sowhat/DSCN0857.jpg

このキグルミの話には後日談があって、5年後くらいに古巣の奈良先端から、IoTと起業をテーマに講演を依頼されました。

聞くと起業する予定の学生がいるとのことで、起業ってまず失敗するし、うまくいくものも最初の資本政策ちゃんとやらないと、美味しいところ持ってかれるだけで、頭おかしいことやることになる場合が多いよなと思って。これから起業というバカなことをするという人の前で講演するなら、ちゃんとバカだよねって伝えるために、まず自分がバカをやってみようかな、バカやってもいいよね(古巣だし)、と。

着たかっただけです。理由はなんでもいいんです。自宅でレンタルで一人で着てるとか、最高に神経を病むので、それはできない。イベントと聴衆が必要なんです。あと、講演で仕事だと、レンタル費用を経費にできますから。

キグルミで講演を提案したら、先生方、すんなり受け入れてくださいました。ノリノリです。やっぱ、頭おかしいです(褒め言葉)。 たまに、なんとなく、着たくなるんですよね。

/post/2016-12-09-freelance-sowhat/IMG_0114.jpg

ネットのフォームでお仕事の話

お仕事は、おもしろい、そう思います。

iOSアプリを作りますというウェブページを作って、問い合わせフォームを作ってました。そんなフォームでも、まだiOSアプリ開発が今のように会社があったりしない黎明期だったので、いくつか案件が来たりしました。

アプリ改修で2週間くらいの仕事だと思ったので、15万円で見積もりを出して着手、その後、機能追加を要望されたのですが、ちょっと技術的に無理かなと思って、それはできないとお断りしてたら、なぜできない?みたいな雰囲気になって、とか。そんな感じです。

最初に、これはできる、これはできない、これを作るのが今回の見積もりの仕事範囲という書類を、けっこうがっつり作って着手前に送っておいてよかったなって思います。あれがなかったら、泥沼だっただろうなって。

こういう話は、自分は自分にとっての絶対正義なので、自分を悪くいうことも、そもそも自分が悪いと認識することも困難ですから、相手を悪者にしがちなのですが、相手の目線からすれば相手の都合と考えと理由があり、そういうものなんだろうなと思います。

人づてでお仕事の話

メイカーフェアに出展していたときに、iPhoneでこんなものを作りたいのだがという方が、ある人からあなたならできると聞いたのだがとブースに来られました。この時も15万円で見積もりだしてました。2週間くらいなら、30万円くらいの月給の半分で15万円という計算です。バカですよね。いまなら200万円くらいスタートで出すのに。

この時作ったのは、プロ用のステージ機材で、いろんな音を出すというシンプルな機能のアプリでした。ただ画面タッチで動くだけではなくて、外部に接続したスイッチで動くもの、です。iPhoneと連携するハードをやっていので、紹介を受けたのでした。

Swift3でのBLEアプリ開発-その2-

Swift3でBLEアプリを作ってみる

前回 https://blog.reinforce-lab.com/2016/12/01/ble-with-swit3-1/ は、Swift３でBLEアプリを作るときによく使う、バイナリ配列と値型との変換処理を書きました。今回はCoreBluetoothフレームワークとその使い方をまとめます。

ソースコードは https://github.com/ubi-naist/SenStick/tree/master/SenStickSDK にあります。

クラス構成

SDKの役割は、複数のBLEデバイスのセンサーデータの取得、そしてその蓄積データの読み出し機能の提供です。そこで、複数のBLEデバイスの発見と接続処理を SenStickDeviceManagerクラスに、BLEデバイスそれぞれを SenStickDevice で表しています。

これはCoreBluetoothの2つのクラスのラッパーになっています。

  • CBCentralManager - SenStickDeviceManager
  • CBPeripheral - SenStickDevice

SenStickDeviceManager, DispatchQueueの割当とスキャン処理

SenStickDeviceManagerクラスは:

  • Key-Value Observation(KVO)準拠にする
  • 通信処理はディスパッチキューを使う
  • シングルトンにする になっています。
open class SenStickDeviceManager : NSObject, CBCentralManagerDelegate {
let queue: DispatchQueue
var manager: CBCentralManager?

// Properties, KVO
dynamic open fileprivate(set) var devices:[SenStickDevice] = []
dynamic open fileprivate(set) var isScanning: Bool = false

// Initializer, Singleton design pattern.
open static let sharedInstance: SenStickDeviceManager = SenStickDeviceManager()

fileprivate override init() {
 queue = DispatchQueue(label: "senstick.ble-queue", attributes: nil)
 super.init()
 manager = CBCentralManager.init(delegate: self, queue: queue)
}

スキャン中かどうかなどのステートは、読み出し専用プロパティで外部に見せています。SwiftのクラスのプロパティをKVO準拠とするには:

2016年のBLEを振り返る

これは Bluetooth Low Energy Advent Calendar 2016 の12月7日の記事です。

2016年のBLEがどうだったのかを、FacebookのWF-BTLEグループ https://www.facebook.com/groups/563064710384459/ に投稿していたものを素材にして、振り返ってみます。

規格の流れ

2015年に4.2が登場して、2月に名古屋で勉強会をしていたりしました。2016年はBT5のリリース予定が発表されています。

Bluetoothは、物理的に同じハードウェアでソフトウェア的に対応可能な変更は、4.xとマイナー番号を増やしていく、電波を出す物理層に機能が追加される大きな変更がある場合は、メジャー番号を増やしていきます。

Bluetooth5では、BLEの物理層に2Mbpsが出せる変調方式が追加されます。また、パケットにエラー訂正機能を持たせて、通信距離の延長を提供します。電波環境の良いところでは2Mbpsの通信速度を活用した通信の高速化、またエラー訂正の活用で通信速度は出せなくても、より遠くに安定した通信を提供する方向のようです。

通信の高速化と、より遠距離に届くものは、両立するものではなく、場合によって使い分けるものです。BLEはスマートホンに採用されたことで急速に普及しています。ファームウエア更新のように、ある程度まとまったデータをやり取りする場合には、通信速度の高速化がユーザ体験を良いものとするでしょう。また家電に使うような、データ量は小さいBLE本来の使いみちでは、中継装置がなくても家全体どこにいても通信ができるようになるでしょう。

またメッシュネットワークの登場も発表されています。

BLEのメッシュネットワークの仕組みは、4.1で提供されているセントラルかつペリフェラルになれる機能を利用して、ルータの役割をもたせるものです。そのルーティングなどのプロトコルはソフトウェア依存で、任意のものが載せられます。

その仕組の上で、いくつか独自のメッシュネットワークが発表されていますが、独自に実装をしても自社製品でしか使えないとなるといまいちな場合は、決め手にかけるのでしょうか。

本当にメッシュネットワークが必要なところは、さっさと使えるものを独自に実装して自社製品で字固めをしていると思うので、よく開発者がメッシュネットワークとかいうのは、大手の企業で技術動向を調査すれば仕事になるサラリーマンくらいじゃないかなと、さほど意味あるようには思えないのですが、とにかく話題の材料にはなるメッシュネットワークです。

ですからメッシュネットワークはBleutooth5の一部というわけではなく、Bluetooth5の登場タイミングで発表されるBluetoothお墨付きのプロトコル実装、というくらいに見ておけばいいのでしょう。これから発表されるメッシュネットワークは4.2のデバイスでも動作すると発表されています。

メッシュネットワークよりも、IoT系というかIPプロトコルへの対応のほうが重要だとは思うのですが、こちらはパケットさえ通ればIPはRFCか何かで実装すればよいような、Bluetoothが認証するようなものにはならないでしょうから、Bluetoothの仕組みの上で実装が色々出てくればいいだけの話なのかもしれません。

あとは、最近はスマートホンの入力がこれまでのテキスト入力から、急速に音声入力、音声操作になってきています。クラウド側で手軽に音声認識ができるようになっているので、この流れは更に強くなるでしょう。

そうなると、BLEデバイスでも、操作のために音声のコーデックが欲しくなるのですが、こちらはいつワーキンググループが仕様を固めるのか、わかりません。2~3年はかかるのかもです。

自社サービスを作りたいのならば、そんな都合は関係ないので、独自実装でさっさと作ってしまえばいいですが、iPhoneやAndroidのスマホ側に音声データを渡したい場合は、OSがサポートしてくれないと作れない、OS側も独自方式で実装するよりBluetoothの公式が出てくるなら、それを待ってしまうのかもしれないとなると、にらみ合いでロックしてしまいそうです。

企業の流れ

BLEのシングルモードの半導体を出している会社は、こんな感じです。2015年から無線の半導体会社の買収が進み、Silicon LabsはBlueGigaを、CypressはBroadcomを買収しました。またNordicは、LTEの次のIoT向け技術の半導体開発を発表しています。

  • Nordic
  • TI
  • Silicon Labs
  • Cypress (Broadcom)
  • Dialog

流れとして、家庭内での家電のようなデータ量が少ないデバイスの接続には、スマートホンとも接続できる利点だけが利点である、2.4GHzのBLEが使われていくでしょう。

ネットワークにつながることで製品となりうるような製品では、今はスマートホンをハブにする他にネットワークとつながる方法がないので、しばらくはBLEが使われるでしょう。しかしNB-IoTなどが普及すればそちらも採用していくでしょう。

また今年はSigfoxあるいはLoRaなど、半径500メートルをアンライセンスドバンドで1つの基地局でカバーできる広域の無線ネットワーク技術のデモンストレーションがニュースになっていました。どの事業者がどの役割を担うのか、しばらくは力関係の上下をつける争いなのかもしれません。

Facebookの投稿まとめ

https://www.facebook.com/groups/563064710384459/ に投稿していたものです。

1月21日

BLEのモジュール選択は、いろいろな要素を見て、最後はどれかに決めなければならないと思います。 太陽誘電のnRF51822のBLEモジュールには、9.6 x 12.9の普通のサイズと、5.1x11.3というとても小さいもの、2種類があります。 チップワンストップという日本の半導体のオンラインショップで、太陽誘電のBLEモジュールが100個単位であれば800円代になっています。 http://www.chip1stop.com/search.do… BLEモジュールの価格の目安は、1つ5ドル、日本円で800円位が目安です。1個単位で買う場合は、個別に包装するなどの手間のぶん高くなり、何十万個も購入するなら、その分より安くなると思います。 100個単位は、そのちょうど中間、数量による価格の下げの恩恵がまずないところなので、800円台というのは、目を引きました。mouserをみても、なかなかこの価格帯はありません。

1月26日

Arduino Genuine 101 がRSコンポーネントに商品登録されていました。海外から4営業日で届くそうです。1つ￥4,748。 このボードは、フィジカルコンピューティングの分野で広く使われているArudinoでもありますが、ハードウェアそれ自体は、 -Intel® Curie™マイクロコントローラ搭載 -32ビットIntel® Quark™マイクロコントローラ -384 kBのフラッシュメモリ, 80 kB SRAM -DSPセンサハブ, 6軸コンボセンサ と、ウエアラブルデバイスを作ることもできそうな、とてもリッチなハードウェアです。 このボードが、日本の技適を取得しているかはわかりませんが、BLEが搭載されています。また、このチップのOSは3月にはオープンソース化される予定とのことです。 スマートホンと連携するハードウェア、アプセサリのキーテクノロジーであるBLEは、IPv6あるいは6LowPANなどで、IoTのキーテクノロジーへとその勢力範囲を広げつつあります。実験用としても、手軽な価格で1枚単位で購入できるボードが登場することは、その盛り上がりを支える道具として、意味があるなと思います。

4月6日

LoRaとBLEに対応した無線モジュールがあったので、日本の技適は取得されていませんが、リンクをはりました。 http://www.lairdtech.com/products/rm1xx-lora-modules LoRaは低データレートの無線通信規格で、仕様は https://www.lora-alliance.org サイトから入手ができます。いまのver1.0の仕様は1GHz以下のサブギガのいくつかの周波数が記述されているようです。 電波が届く範囲は周波数により決まります。BLEが使う2.4GHzでは家程度の範囲ですが、サブGHzではモジュール次第ですが通信範囲をkm単位に広げることも可能です。 スマートホンとの無線通信として強力なブランド力をもとに急速に普及しているBLEも、さらなる普及のためにIoT系の技術を取り込むなどの、次の大きな変化が来るようです。 また開発案件では、スマートホンとの連携にはBLEを使うが、製品それ自体の魅力を作るためにはBLEという規格の範囲では作れないために、2.4GHz帯の独自の無線通信機能を入れていくものも、出てくるようになりました。 無線通信は技術手段にすぎませんが、その手段の変化の速さを見ていると、BLEのアプせサリまたIoTという単語が、単なる流行語ではなく、実際に需要がありお金が動く分野になってきているのかなと思います。