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

各社から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であれば、できます。そういう進め方で、いいようなきがするのです。

nRF52 Global Tech Tour 2015 Nordic Semiconductor は、Nordic Semiconductor社のBluetooth Low EnergyシングルモードチップnRF52の開発者向けイベントです。

世界各国で開催されていますが、日本では12月8日に東京そして12月10日に大阪で開催されます。東京 六本木ヒルズでの回に参加してきたので、レポートします。

ツアーの雰囲気や飲食

ツアーに参加すると最後に、9500円位するnRF52版開発ボードが参加者全員にプレゼントされました。各国の電波法の適用は受けていないので、外部に電波が出てしまわないようにシールドボックス内部などで使う必要がありますが、太っ腹です。

会場や集まった方々の雰囲気

場所は アカデミーヒルズ でした。360席ほどある会場が満員でした。 周りをざっと見渡すと、年齢は30代から50代、9割位の方がスーツ、またほとんど9割以上が男性でした。 日本の電気工学系の学部は、女性比率が2%程度だったりするので、こうなってしまうのだろうと思います。

プレゼンテーションは英語ですが、日本語の同時通訳が提供されていました。質疑応答も通訳の方がサポートしてくれるので、日本語で大丈夫でした。 同時通訳のイヤホンを使われている方は、見渡すと1割くらいで、普通に英語に慣れている方ばかりなのだな(大手電機メーカの方もきっと多いと思うので、それが当然なのかもしれませんが) と思いました。

フロアにあるお手洗いは1つで、男性12人程度で一杯になるもので、休憩のたびに少し行列ができていました。私は出口付近の席にいたので、いの一番に外に出られたので、並ばなくてすみました。座る場所は指定されず、どこでもよいので、早めに出かけて場所を確保しておくのが、いいのかもしれません。

飲食など

お昼にはお弁当が出ました。

会場の直ぐ側には、飲み物とお菓子がたくさんありました。 紅茶、コーヒー、ペットボトルの水、そしてマフィンのようなお菓子が常に補充されていました。紅茶ばかり頂いていましたが、美味しい紅茶でした。

スライド抜粋

nRF52の概要

nRF52シリーズは、Nordic Semiconductor社にとって第3世代となるBluetooth Smart Socです。

nRF51シリーズは、2.4GHz帯の汎用無線回路と周辺回路そしてプロセッサを組み合わせて、通信処理をプロセッサに担わせることで規格の機能追加に柔軟に対応できる構成をとっています。

nRF52でも、その構成はnRF51と同じです。プロセッサの処理能力を高めフラッシュおよびRAM容量を増加、電源制御や周辺回路の数や能力を強化、そしてNFCを搭載しています。

nRF51はBluetooth 4.0までの無線通信技術に対して最適化されている感じがします。

nRF52は、Bluetooth4.2で追加されたセキュリティおよびIoTに向けた機能、また今後のBlueototh無線通信技術に追加されていくかもしれない、通信の高速化、音情報のやりとり、またIoTに向けたネットワーク技術への対応などに対応できる構成となっています。

プレゼンの構成

セミナーの流れとその雰囲気は、 nRF52 セミナー のまとめ がよくまとまっています。とくに@ksksueさんの一連のTWは、詳細までまとまっていて、素晴らしいです。

セミナーの資料は当日ダウンロード配布されていました。セミナーで配布された資料全体を不特定多数に勝手に配布したりするのは、やめてくれという話でしたが、ブログで技術紹介をするときに、スライドの一部を参照するのはできるっぽいらしいので、このブログでは必要な部分を掲載しています。

全体のプレゼンテーションは、半導体のハードウェア構成、その特徴と活用のポイント、そしてソフトウェア・スタックやSDKのファームウェア・開発、そしてIoT系の話題で構成されていました。また最後に、日本のモジュール・メーカ各社(太陽誘電、富士通、ブレイブリッジ、ホシデン)から、nRF52の無線モジュールについてのプレゼンテーションがありました。

プレゼンテーションは、ほとんどがハードウェアよりの内容でした。BLEは2015年時点では、スマートフォンと連携するハードウェアによく使われています。ですから、スマートフォンおよびそのアプリケーションとの連携や開発情報は重要だと思うのですが、そういったものは今回はカバーされていませんでした。その代わり、2015年はいろいろなところで話題にされたIoTについて、1セッションが取られていました。

プロセッサとその周辺

• プロセッサの処理能力の強化
• EasyDMAとPPIを組み合わせたプロセッサを使わずに済む仕組み
• スリープ時の消費電流をより低減

などが特徴です。

処理能力の強化

nRF52は、デジタル信号制御市場向けに開発されたARM社のプロセッサCortex-M4Fをコアに採用しています。

Cortex-M4自体、デジタル信号処理に適した命令が追加されてDSP機能が強化されています。Cortex-M4Fは、Cortex-M4に、さらに32ビットの単精度浮動小数点ユニットというハードウェアを追加したものです。

nRF52の動作周波数は 64MHz RAM 64 kByte フラッシュROM 512 kByte です。

nRF51は、Cortex-M0 で、動作周波数 16MHz、 RAM 16 kB または 32kB、 フラッシュROM 128 kB または 256 kB です。

Nordic Semiconductor社のnRF51822は、BLEシングルモードのSoCとして数多くのモジュールに採用されていて、開発でもよく使います。

SoCのなかにあるCortex-M0はMDK-ARMを使うと、J-Link liteでブレークポイントを4つまで設定できます。通常の組み込み機器のファームウェア開発であれば、デバッグしたければブレークポイントを設定して値や実行フローを確認します。しかしBLEのファーム開発では、止めてしまうと通信が止まってしまいます。

Nordicの開発環境には、SDKにある debug.h をみると、シリアル端子からのprintfデバッグと、フラッシュメモリにログメッセージを貯めておく2つの方法が提供されています。シリアル端子はよく使うのですが、製品化の基板ではIO端子を使いきってしまっていたり、基板に余裕がなくて端子をつけられないなどで、デバッグ専用のシリアル端子が確保できないこともあります。

そのようなときに、SWD (Serial Wire Debug) http://www.arm.com/ja/products/serial-wire-debug.php 経由で、ターミナルにテキスト出力する機能が、SEGGERの Real Time Terminal (RTT) https://www.segger.com/jlink-real-time-terminal.html です。

チュートリアルとソースコードを公開されています。

https://devzone.nordicsemi.com/tutorials/6/debugging-with-real-time-terminal/

printfを、このターミナルにリダイレクトすることもできますが、簡単にsprintfで内部的に切り替えてしまうのもいいのかもしれません。

#define RTT_PRINTF(...) \
do { \
     char str[64];\
     sprintf(str, __VA_ARGS__);\
     SEGGER_RTT_WriteString(0, str);\
 } while(0)

#define printf RTT_PRINTF

IoTとか単語が盛り上がっているので、そういうニュースを見ると影響を受けて、自分が考えていることが変化していくと思う。なので、2015年3月3日の時点で、自分が何を考えていたかのメモ。

IoTって自分がしばしば目にするけど、なぜ話題になるのだろう? わからん。

世の中が動くときは、必ずお金の動きがそこにあるはず。なので、例えばものからデータを取り出すことができるようになったことが世の中を変えるとすれば、その流れは、データを取り出す、そこから意味を取り出す、行動に反映されるの1ループ。

つぎに、どんなものの何のデータ(質や種類)か、意味を取り出すのは誰か(データを生み出した人の端末、データを取得したネットワーク側、データを購入した何者か)、行動に反映する(購買の推薦、道順の提案、割引クーポンを提示する)。3つの段階それぞれに、主語と目的語と動詞、を当てはめて生み出される無数の組み合わせ、それらすべてがIoTと呼べる何かだろうし、その中の幾つかは、強烈なお金の流れを伴ってきそうな気は、なんとなくするといえばしそう。

1. ニュースの話題が少なくて、取り上げやすいIoTという単語で特集を組むところが多い。

タイトルをみて買う買わない読む読まないを判断する人が多いならば、盛り上がっているならば、タイトルにIoTという単語を入れておきたい。 技術系の話題であれば、ネットワークに接続するものであれば、およそあらゆる話題をIoTという単語に結びつけて話ができる。なので、結びつけてしまえばいい。いろいろな媒体がそれをすると、自然と同期して、全体でなんとなく盛り上がり感がでて、さらにその流れが強まるフィードバックがかかる。

2. モバイルのニュースに意味がなくなった。

iOSも登場して、新しいサービスやアプリケーションへの関心は、もうない。iPhoneそれ自体、新機種がでても薄い板の別種がでたのか程度でしかない。性能が向上して、初めて手にする人が多い時期は、どんなアプリケーションを使おうかと興味関心が高い。その時期であれば、新しいアプリを紹介して、その広告やインストール実績でお金を得ることもできた。だが、スマフォが日常になれば、いちいちゲームを探すのは、もともとゲームが好きな極めて一部だけに戻る。たいていは、リアルの人脈で、口コミでという流れに、戻るだろう。

3. 前提が変化した。

スマートフォンが普及したので、データ収集するネットワークに常につながった、いわゆるエッジのデバイスが大量に世にあふれた。また、スマートフォンにアプリケーションを簡単に配布できるので、その普及した装置をインフラとしてとらえて、サービス展開もできるようになった。またAzureなどで機械学習がサービス化されて、データの蓄積とあわせて手軽に運用できるようになっている。

どこかのだれかしかできない特殊な技術だったり、技術自体は公開されても高度すぎて理解できなかったり、あるいは実行環境が高価すぎて、その環境を使いこなせる人の数が少なすぎて、誰か雇って業務として割り当てようにも人がいないとかだと、絵に描いた餅に終わる。また、競合他社も同じ状況だろうから、ちょっと試して効果を見たい程度のモチベーションだろう。そうすると、高価で希少ななにか、に投資する気にはならない。

BLE系を見ていても、センサーやスマートフォンという環境が整い、開発者も何万人単位でいる。いままで絵に描いた餅だった前提が、一気に崩れてる気がするので、もしも競合他社がひっそりそれを試して知見を蓄積していたら?と思えば、手を付けない理由が消えていく気がする。

4. サービスだとネットワーク側にデータを蓄積することが価値にもなりそう

機械学習やら実行していくとなると、今後の変化にあわせて追従していくなら、フィルタしない生のデータを蓄積しておきたくなる。適当なクラウドサービスを使うとしても、バイト数でみて現実的に引っ越し可能な量を簡単に超える。だから、クラウドサービスを提供する側から見れば、適切な価格で他社にもある機能を同程度に提供しているなら、顧客は簡単には契約先を変えないだろうと思いそう。

サービス提供側も、十分なデータ量をもっているかが、サービスの提供の振る舞いにつながるだろうから、データは貯めるだろうし。

5. 人間の習慣の変化。

スマフォの経路案内を見て移動するのが日常になってきているから、画面を見て行動するのが、習慣化していそう。また購買活動も画面を見て、気に入ったらその場で発注とか。

6. IoTというけど先行事例はウェブ系、ただ参考にはならないか

データ収集がはじめから仕組みとして入っていて、ネットワークに接続していて、人の行動を変化させることで利益を得るなら、ウェブ系のあらゆるサービスはそれになる。開発投資も何年もされているから、IoTといえど仕組みはそこにありそう。ただ、成績評価の指数が、人間が何かを買う、人間がリンクをクリックする、人間が画面を見る、なので、その指標がIoTで同じように使えるか?は気をつけないと、仕組みが違うものを無理やりウェブの仕組みで理解したら、勘違いしかなさそう。

7. 端末機器メーカ

IoTといって、スマートウォッチ(自称)を発表する端末機器メーカがたくさん出てきています。端末機器メーカは、より多くのハードウェアを販売すること、が本能です。そのために、外観デザインやスペックの高さ、あるいは価格の値ごろさをアピールします。

スマートウォッチ(自称)は、Androidなどが提供する通知の仕組みなどに対応することで、Androidのアプリ開発者が用途を開発して利用場面を提供してくれそうですから、ハードウェアだけで閉じこもれるので、手をつけやすそうです。また、端末機器メーカは売上の絶対値もですが、シェアが勝負です。競合他社が持っている商品ジャンルが自社にはないのは、売る本能からすれば恐怖になりそうです。

スマートフォンも、最初の1台が売れる黎明期、年々性能が高まり、その性能に合わせてより魅力的なゲームやアプリケーションが登場する成長期を超えて、いまではたいていの端末でたいていのアプリケーションは快適に動く、必要だから買うだけの成熟あるいは飽和期です。人とは違うものや、必要を超えたハイスペックなど、趣味性の高いものも出せば売れるでしょうが、それはパソコンの時代でも同じように、主流ではありません。

コモディティ化したパソコンの世界では、製造会社は残りませんでした。Dell、あるいはThinkPadを買収したLenovoのように、製造と販売とサポートを統合した会社が、たまたま製造をしていると見るくらいが良さそうです。

8. 半導体関連

次の半導体のシェアを競う場面として、車載、そしてIoT系も話題としてはありそうです。

車載のキーワードを上げると、安全、事故回避、自動運転系があります。イメージセンサや高周波レーダーのセンサーデバイスからの情報を統合、事前に学習しているデータから危険性があると判断すれば、運転操作に干渉して危険度を引き下げる仕組みです。今の技術や半導体の製造費用が、実用範囲に入り話題になっているのだと思います。技術開発競争は進むでしょうから、基本、人間よりも信頼度は高くなるでしょう。

自動車の動力源が、電気であろうがガソリンであろうが、高度な電子回路が不可欠になります。電気であればモータの制御、ガソリンであっても高い燃費の実現には機械制御が不可欠です。それらの動力源、またブレーキを含めた操作など運転操作の基本機能を支えるために、半導体が不可欠です。その一方で、前に上げた安全装置あるいはカーナビやカーオーディオに人間の目に入るメータ表示など、より多くの台数を売るために、アプリケーションの魅力を高める必要も出てきます。

この組み方は、携帯電話の半導体は、アプリケーション・プロセッサと、通信を制御するベースバンド・プロセッサに分かれて開発されてきた歴史によく似ています。今までの携帯電話での半導体会社の競争と同じパターンを、なぞりそうです。

IoT系は、開発ツールなどを各社で足並みをそろえつつ、独自色を追加して行く感じでしょうか。マイクロプロセッサを販売するためには、開発環境、コンパイラ、そしてそれらに慣れた大量の技術者が必要です。独自のプロセッサコアでは、最後の大量の技術者が確保しづらいでしょうから、今のようにARMに集中する、ライセンス料が高くて払えない場面はMIPSも登場する感じでしょうか。

mbedというハードウェアを抽象化したオンライン開発環境に、各社のクラウドとすぐに連携する評価キットまで登場して、なにか動くものを作るならばスキルも理解すら必要がなく、手順にしたがいサンプルを動かして、ちょっと変更するだけで要望を満たせるまでになってきています。

どうやって半導体会社は儲ける気なのでしょうか。

ウェブ系の開発が参考になるかもしれません。パソコンさえあれば、基本ウェブサービスは開発できます。テキストエディタを開いて、JavaScriptを書いて、ブラウザで動かせばいいでしょう。Node.jsなどもありますから、サーバサイドをローカルで閉じて開発し切ることもできます。開発したものは、AWSなどに乗せてサービスとしてデプロイできます。サービスを開始するまでのコストは金額的にはゼロに限りなく近いです。

ウェブの世界で、開発キットで儲けているところはあるでしょうか。ありません。ウェブ系での儲けは、サービスを提供する側の売上、そしてサービスを提供するインフラを提供する会社の使用料を回収です。半導体自体はサービスが売れれば自動的に売れます。ネットと連携している土俵が同じなら、自社製品も他社製品も価格は同じで、IOやADCなどの周辺、あるいは静電気に強いとか、電源電圧範囲や消費電力、あるいはロジックブロックやアナログブロックを内蔵しているなど、マイコンとしての価値自体でうる、純粋に半導体での商売になりそうです。

9. ハッカソン

そうはいっても、会社を作って事業となると、雇いたい人は、取りあえず動くものを一人完結で作れる人になりそうです。それは、人数が小さいほうが、やりとりの手間と時間を省けるので早い場合がある。トライ・アンド・エラーをするときには、一人もしくは数人程度の小さいほうが、変なトラブルを巻き込まず純粋に技術だけで動きやすい。など。

そんな人材は教育でどうなるものではなく、たいていは天然物なので、そういう人が反応しそうな面白そうなイベントを開催して、まずリアルな場面に寄せ付ける。そのうえで、フィルタリングをかけて、誰がどの程度できるのかをあぶりだして、雇用を持ちかけるとかに、ハッカソンは便利に使えそうです。

iOS8のvisit monitoring

iOSは、位置情報取得が初めて登場した時から、電池消費量に注意して設計されています。位置情報を調べる物理手段は、携帯電話基地局、WiFiルータの識別子、GPS などがありますが、アプリケーションが位置情報を取得するときに、どの物理手段を使うかを直接していすることはありません。必要とする位置精度にあわせて、iOSが最適な物理手段を選択して、アプリケーションに位置情報を通知してくれる作りになっています。

毎年新しい位置情報の技術と機能が導入されているiOSですが、iOS8では、visit monitoring という訪問先の自動記録機能が導入されました。これは24時間365日、ユーザが訪問した場所とその滞在時間を記録し続ける機能です。

Githubのサンプルアプリ。visit monitoringで取得したデータをテキストで表示し続けるだけのサンプルアプリです。

https://github.com/reinforce-lab/ObjC_Codes/tree/master/visitMonitoringTest

visit monitoringの使い方はとても簡単です。

iOS8は、位置情報取得の権限が、when in use, アプリが実行されている間のみ(画面表示されている間のみ)と、always, バックグラウンドなど常に取得、の2つにわかれました。

まず、訪問先を記録し続けるなら、アプリケーションが画面に表示されていない時(バックグラウンド)でも情報が取得できなければ意味がないので、常に情報取得する権限を要求します。

CLLocationManagerのオブジェクトにデリゲートを設定して、 requestAlwaysAuthorization メソッドを呼び出し常に位置情報を取得する権限を要求します。初回呼び出し時には、iOSがユーザに権限要求のダイアログを表示してくれます。

Xcodeで、プロジェクトの Capabilities の Background Modes で Location updates にチェックを入れておくのも、忘れないようにします。

    CLLocationManager *_locationManager;
    ...
    _locationManager = [[CLLocationManager alloc] init];
    _locationManager.delegate = self;
    
    // requesting a permission. NSLocationAlwaysUsageDescription key must be in your app’s Info.plist file.
    [_locationManager requestAlwaysAuthorization];

アプリケーションが実行されると、必ず CLLocationManager のステータス変更が通知されます。権限があれば、位置情報取得を開始したいので、この didChangeAuthorizationStatus: のなかで startMonitoringVisits

    -(void)locationManager:(CLLocationManager *)manager didChangeAuthorizationStatus:(CLAuthorizationStatus)status {
        switch (status) {
            case kCLAuthorizationStatusAuthorizedAlways:
                [_locationManager startMonitoringVisits];
                break;
            // 権限がない場合は、なにもしない
            case kCLAuthorizationStatusAuthorizedWhenInUse:            
            default:
            break;
        }
    }

    - (void)locationManager:(CLLocationManager *)manager didVisit:(CLVisit *)visit {
        //ログを残す
        [self write:[NSString stringWithFormat:@"%@", visit]];
    }

visit monitoringは、イベントが発生するたびに iOSは CLVisitのオブジェクトを渡して デリゲートの didVisit: を呼び出します。訪問場所に入った時点、訪問場所を去った時点それぞれ通知が来ます。