IoTマイコン無線規格

6月の本ブログは、ThreadやBluetooth 5など、マイコン:MCUとIoTコンピュータ:MPU/SCB間の無線通信規格に関する記載が多くなりました。モノをインターネットへ接続するIoTの要となる無線インタフェースが、今変動中であることが解ります。

私は、コスト重視のMCUは、最終的にはどれか1つの規格(Threadが良いと思います)になり、カバー範囲重視のMPU/SBCは、複数規格(Wi-Fiは必須で、BluetoothやThread…)を実装すると思います。

このMCUとMPU/SCB間の無線規格の現状を考えた面白い記事を見つけたので紹介します。

IPアドレスとの親和性

記事によると、無線規格の要件として、よく言われる低消費電力動作の必要性以外にも、既に出来上がったWi-Fi世界との親和性が重要だとしています。IEEEでもこの線に沿った「Wi-Fi Halow」と「Passive Wi-Fi」規格検討が進んでいるそうです。

かつて私も有線通信:ATMの研究開発にたずさわったので多少解りますが、IEEE(アイトリプルイー)の規格化が済むと、直ぐに商用製品が発売され、Businessに裏打ちされた規格が開発される場、それがIEEEです。そして、MCUとMPU/SCB間の無線技術を含む多くの通信課題が解決される場でもあります。

確かに、IPアドレスとの親和性が高いと、NIC: Network Interface Cardのハードやソフトが流用でき、これらを実装したMCUでのパケット化処理(UART over IP)も簡単になるかもしれません。

MCUとMPU/SCB間の無線技術

UART、つまりSCIを実装しないMCUはありません。
SCI入出力を簡単に無線化できるソフト/ハード技術、これがIoT MCU無線規格の本命になると思います。今日時点の内容は以下ですが、この技術の一覧表を固定ページに追加しました。固定ページは、適宜、内容を更新します。

IoT MCU Wireless Specifications
無線規格 特徴 備考
Bluetooth 4.2 128ビットAES対応など従来比セキュア機能拡張 スマホへ普及中
Bluetooth 5 4.2比通信速度、通信距離、ブロードキャスト容量拡大 2017年初めリリース予定
Thread メッシュ網構成
Wi-Fi Halow Wi-Fiとの親和性高く、室内外40m、屋外1㎞通信 IEEE 802.11ah
Passive Wi-Fi IEEE 802.bベース、超低消費電力(電池駆動10年)目標

 

Bluetooth 5仕様

6月18日記載のBluetooth 5の仕様が記事になり、内容を一覧表にしてみました。

Bluetooth 5 Specification
項目 Bluetooth 5仕様 備考
通信モード 2Mbps 最大100m(100mW出力) 従来バージョンと後方互換、2Mbpsを追加
1Mbps
125Kbps 最大400m(100mW出力) 従来比4倍の通信距離
通信範囲 メッシュ機能リリース予定 従来Bluetooth 4.2などもメッシュ利用可
消費電力 従来と同等 2Mbpsなら従来比短時間通信のため低消費電力
ブロードキャスト機能 最大255文字 URL送信可能(従来31文字)

 

Threadと同様、一軒の家の範囲をくまなくカバーする「メッシュ網」と、2020年に450億台と予想されるIoT機器のうち、3分の1の140億台のIoT機器への搭載を目標にしているそうです。

Atom新規開発中止とPSoCアナログ特化製品追加

IntelがAtomプロセサの新規開発を中止すると発表しました。
Cypressは、アナログ制御に特化したPSoC 4ベース新製品投入を発表しました。
所感を記載します。

Atom新規開発中止

Surface 3やEdisonなどの既存Atomを使った製品の今後も怪しくなってきますね。Galileoは Pentiumを使ったSoC: System on Chipなのでとりあえず安心ですが…。

少品種大量生産が 半導体メーカーのビジネスモデルなので、マッチしない製品群は、開発停止というユーザにとっては避けてほしいオプションが常に付きまといます。

マイコン開発者にとって、「代替品が可能なデバイス」に魅力を感じるのは、この最悪オプションのためです。

これはIntelの話でしたが、日本メーカー競争力と継続性強化のための方策についてコチラに興味深い記事があります。

PSoCアナログ特化新製品追加

一方Cypressは、Spansion買収で得たCortex-M0+ライセンスを使ったPSoC 4に、オペアンプやコンパレータ、アナログ・マルチプレクサなどのアナログに特化したプログラマブルアナログブロックを統合したPSoC Analog Coprocessor(Cy8C4Axx)新製品を追加しました。

コプロセサ化により、センサの変更を、ホストプロセサソフトへ及ぼさずに短時間でプロトタイピング開発できるメリットがあります。

PSoC Analog Coprocessor Merit
PSoC Analog Coprocessor Merit(記事より抜粋)

モーション、照度、湿度、近接センサ、サーミスタなど搭載の評価ボードCY8CKIT-048を使うと、アナログ・フロント・エンド(AFE)がPSoC Creatorで開発できるので、一般的に40時間かかる方法と比べ4時間で開発できるそうです。「1週間のスケジュールを、半日でできる!」、夢のようです。

無線通信規格の変更容易なコプロセサ化

評価ボードにはArduinoシールドコネクタも実装済みなので、Raspberry Pi 3などのIoTコンピュータ:MPU/SBCに直接搭載も可能でしょう。

また、対ホストプロセサ通信には、UARTが使えます。ここにUART over BLEやUART over Threadの適用が予想できます。

MCUとMPU/SBC間の無線通信規格が流動的な現状では、このアナログコプロセサ機能配分も適していると思います。CY8CKIT-042搭載のBLE 4.1がBLE 4.2に簡単に変更できたように、無線規格変更に対して柔軟に対応できるからです。

Bluetooth 5 2017年初頭リリース予定

住宅全体、ビル全体、屋外での利用も可能なBluetooth 5が2016年末~2017年初頭にリリースされる予定だそうです。

前回のThread記事で書いたように、現行版Bluetoothがスマホとウエラブルデバイス間に適しているのを、通信到達距離を4倍、通信速度を2倍にし、しかも現行版と同じ低消費電力で実現するのがBluetooth 5です。

メッシュのThreadと、スターのBluetoothの違いがありますが、どちらも狙いはIoTエンドポイントのマイコンへの普及です。

より軽く「UART over Bluetooth」または「UART over Thread」を実装できる方が望まれると思います。マイコン:MCUにとって、デバッグの容易さから、UARTは消えゆくレガシー周辺回路ではなく必須回路と考えるからです。

一方、現在のIoTコンピュータ:MPU/SBC側の対MCU通信インタフェースはBluetoothです。こちらにその理由と、ネットワーク構成を示します。
ThreadとBluetooth 5の普及状況に応じてMPU/SBCでは、両サポートになりえます。

IoT無線規格「Thread」

Threadは、Wi-FiやBluetoothなどの既存無線通信と異なりメッシュメットワーク構成の2015年7月発表の新しいIoT無線規格です。詳しい記事はコチラ、またThread詳細はWebを参照して頂くとして、ここでは記事要旨を示します。

Threadの特徴

Thread System Messaging Model
Thread System Messaging Model(2016_05_10_ThreadPresentation.pdfより抜粋)

メッシュ網構成: Wi-FiやBluetoothの1対1(多)のスター網構成に対し、通信堅牢性と通信範囲の確保を目的にメッシュ網で通信。

ネイティブIP通信:OSIのネットワーク層とトランスポート層の仕様策定が目的で、超低消費電力で短距離通信のIP通信を行うオープン仕様。上下層は、既存レイヤー仕様をそのまま使用。

ネットワーク管理機能と高セキュリティを両立:ノードトラブルや網障害に対し、自己修復し通信継続。

長期電池駆動が可能:長期電池駆動が可能なデータ送受方法を採用。

などホームネットワーク要件を全て満たす。

主要参加メンバー

Thread Group Sponsor BoD Members
Thread Group Sponsor BoD Members(2016_05_10_ThreadPresentation.pdfより抜粋)

ホームコントロール大手Somfy、ホームセキュリティ大手Tyco、Qualcomm Technologies、照明大手OSRAMなどの企業と、マイコン大手NXP、ARMなどが主要メンバーとして参加。

以上が記事要旨にWebから得られる情報を追加したものです。以下の理由で私はThreadに期待しています。

BLEは重い

BLE: Bluetooth Low Energyは、少量データの送信には理想的ですが、アプリケーション規格などが厳格で、「スマホとウエラブルデバイス間通信」に適しています。

しかし、これをマイコンで「単に土管として無線を使いたい」場合には少し重たい気がします。例えば、マイコンUART入出力をIoTコンピュータ:MPU/SBCへ無線で接続する時などです(BLEとROM量はコチラに記載)。

※土管として無線を使うとは、例えば、UART over BLEなどです。

莫大な販売量が見込まれるとしてもIoTエンドポイントマイコンは、ROM/RAMが少なく低価格デバイスが向いていると思います。BLE機能を実装するとROM量は64KB超が予想されます。

Threadが、BLEより軽くマイコンへ実装できれば、IoTエンドポイント通信の本命になるかもしれません。

Node-REDとGenuino 101

Node-RED

トラ技2016年6月号記載のNode-REDは、強力な開発ツールです。ターゲットは、本ブログのマイコンやシングルボードコンピュータなど全てを含むことができます。但し、あくまでNode-RED動作環境の下での動作が前提です。

つまり、WindowsやLinuxなどのリッチOSアプリの1つがNode-REDで、これを使えば、Raspberry Pi 3とArduino/Genuino 101両方で動作するプログラムが開発できます。マイコンの動作オブジェクトコードは(今のVersion0.13.4版では)出力されません。

今回は、このNode-REDがデバイスに依存せずにプログラミングできる仕組みとprintfデバッグについて考察します。

デバイス非依存性

マイコン開発で苦労する部分は、センサやモータなどの個別制御プログラムです。しかし、この制御プログラムが予めライブラリで提供されていて、しかも、制御する側のデバイス、マイコンかシングルボードコンピュータかもGUIで簡単に選択できれば、苦労はかなり減ります。

残りの部分は、どの順番でどのように個別制御プログラムを動かすかというフローチャートのイメージに近い部分です。このフローチャートに近い部分を、Node-REDでは「flow」と呼び、ブラウザを使ってGUIで開発します。

Node-REDのflow例
Node-REDのflow例

ChromeやFirefoxなどのお馴染みのブラウザが使えますので、Windows であってもiOSでも、Linux:Raspbianであっても開発できます。RaspbianをインストしたRaspberry Pi 3もデフォルトブラウザはEpiphanyですが問題なく動作します。

トラ技6月号のP65の図8:GPIOライブラリnode-red-contrib-gpioとJohnny-Fiveの位置づけが、「デバイス非依存性」を端的に示しています。

図8で示されたライブラリとNode-REDのFlowは、オンラインFlowライブラリで多くのサンプルが公開されており、6月4日時点で778個です。☑nodeがライブラリです。

トラ技では、P66のArduino系ボードの中にArduino/Genuino 101は入っていませんが、Firmateプロトコルスケッチをボードへ書き込めますので記事と同様に動作します。このFirmateもCPUやマイコンボードに依存しないプロトコルなので、対象ボードがFirmateさえサポートすればNode-REDから制御できます。

Arduirno/Genuino 101でFirmateプロトコルスケッチを利用
Arduirno/Genuino 101でFirmateプロトコルスケッチを利用

このように、制御に必要なflowサンプルやnodeライブラリを部品として全てネットからダウンロードでき、この部品の加筆修正も簡単にできるNode-REDは魅力があります。ソフト開発時にハード準備が間に合わないことは良くあることですが、実ハードがなくても代替ハードで動作確認し、最後にGUIでポート番号を変更しさえすれば実ハードでも動作することが可能だからです。

printfデバッグ

Arduino IDEも同様ですが、Node-REDには、本格的なデバッガ機能が(今のところ)ありません。

プログラマがprintf(Node-REDは、デバッグ出力ノードに相当)を使って変数などを一時出力してデバッグすることはできますが、動作を一時停止しRAM内容をダンプしたり、変数を変更後に停止位置から再実行したりすることは簡単にはできません。

printfデバッグは、ダウンロードした部品が完全でバグが無いブラックボックスとして扱える場合には効果的かもしれません。例えば、ハードウエア開発で、74シリーズロジックを組み合わせて開発する場合に、ロジックにバグがあると考える開発者はいません。自ら開発したハードをデバッグする際には、プローブとオシロスコープを使って、ロジック間の信号を読み解きバグ取りをします。このプローブがprintfに相当します。

少し前は、マイコンソフト開発でもprintfデバッグが盛んでした。デバッガは高価だったからです。しかし現在は、シリアルーUSB変換機能と兼用でデバッガ機能を持たせた低価格マイコンボードが多数あります(LPC、Kinetis、Cypressマイコンボードなど弊社利用の評価ボード)。

ソフトウエアもハードウエアのように部品化が進めば、printfデバッグで完成する時代がくるかもしれません。しかし、かなり先の話だと個人的には思います。
個別マイコンボードのデバッガ機能がプラグインで追加できる開発ツールを望んでいます。EclipseベースのIDEは、この要望に最も近いのかもしれません。

Arduino/Genuino 101用マイコンテンプレート

因みに、Arduino/Genuino 101のIDEは、今のところArduino IDEです。

Intelは、デバッグ機能付きのEclipseベースIDE、Intel® System Studio for MicrocontrollersのQuark™ SE版をアナウンスしていますが、未だにリリースされていません。私は2016年版Eclipse:Neonをベースに使うと思いますので、今少し時間がかかるかもしれません。

従って、Arduino/Genuino 101用のマイコンテンプレートの発売ももう少し後になります。昔ながらのprintfデバッグには、戻りたくないというのも本音です。ご容赦ください。

IoTコアにIntel入ってる

Intel製IoTマイコンコアのCurie 32MHzを搭載した開発ボード「Genuino 101」が4880円で発売されました。

Genuino 101
Genuino 101

Arduino UNO互換でArduino IDEが使え、右下のBluetooth LEアンテナ実装でROM/RAM=196KB/24KBです。

インテルのIoTコアデバイス

インテルは、先にIoT向けコンピュータEdisonを発表済みで、これを使った開発ボードも販売中です。
つまり、マイコンとIoTコンピュータ両方のデバイスを供給し、かつ、入手性も良い開発キットを提供できる半導体ベンダがインテルとなりました。

私が想定しているIoTデバイスの構成は下図です。

IoT Devices
IoT Devices

マイコンとIoTコンピュータ間は、Bluetooth LE:BLE通信です(理由はこちらの記事)。

BLEの複雑なプロトコルスタックから、たとえBluetooth認証マークが付いていても複数ベンダが混在する空間で、MCUとMPU/SBC間の無線BLE通信が上手く行くかは、やってみないと判りません。杞憂ですが、同一ベンダ同士でのみ安定に通信できる可能性もあります。

そうなると、パソコンCPUのデファクトスタンダードがインテルであるように、IoTコアも「インテル入ってる」つまり、インテル独占状態になるかもしれません。自社デバイス生産能力も持っているインテルですので供給価格の安さも含めて他ベンダには脅威でしょう。やはり杞憂ですね…(^_^;)。

本ブログのIoTデバイス

Curieマイコンも本ブログの対象とする必要がありそうです。
こちらの固定ページに、対象デバイスの特徴などを簡単に列記しておりますので合わせてご覧ください。

マイコンでBLE実現の3方法

レガシーなUARTは簡単に使えるマイコン開発者でも、BLE:Bluetooth Low Energyは、新しくかつ仕様も追加されつつあるので手を出しにくいものです。しかし、いざBLEを仕事で使う段になれば、いつものように、厳しいスケジュールでの開発が要求されます。

そのような開発者個人が、入手性が良いマイコン:MCUで電波法の縛りがある日本国内でBLE通信を自習する方法を3つ紹介します。

BLE習得3方法

仕事での開発と違い、個人でBLEの開発環境を整える場合は、「入手性とその金額」が問題になります。金額ベースで安い順に3方法を評価したのが下図です。

BLE実現3方法
BLE実現3方法

Cypress PSoC 4 BLE利用の方法1は、低コスト($49)で環境構築可能ですが、多少BLE仕様を理解する必要があります。しかし、BLEを習得するならお勧めの方法です。

BLEモジュール追加の方法2は、マイコンUART入出力にBLEモジュールを追加する方法です。
マイコン以外にBLEモジュールが必要なため、追加コスト(図示、浅草技研BLESrialの場合4000円)が必要ですが、BLEを無線のドカン(UART over BLE)として使えるので、BLEをブラックボックスとして扱えるのが魅力です。
方法1と方法2のコスト差は、使用マイコンにも依存するので大差ありませんが、後で示す仕様変更時に差が出ます。

ルネサスRL78/G1D利用の方法3は、BLE機能を持つルネサスRL78マイコンを使うので技術資料が日本語ですが、開発には高価な有償版CS+と評価ボードが必要になります。RL78マイコンを仕事で使っている場合は、有利かもしれません。

BLE仕様が変わる現状への対処

マイコンBLEの通信相手は、前回示したMPU/SBCなどのIoT向けPCの他に、スマホが使えます。

スマホBLEには、「BLE 4.0/4.1/4.2など様々な仕様」があります。多くの通信仕様のように、下位互換性がありますが、セキュリティなどの機能強化が図られており、結果、対応マイコンにはますます大容量ROMや高性能化が要求されます。

このようなBLE仕様の変化や仕様追加に対して、PSoC 4 BLE: CY8CKIT-042-BLEは、実装CPUモジュール($15)の載せ替えで対応します(コチラの記事を参照)。一方、BLEモジュール追加の方法は、モジュール購入時で仕様が固まっているので、変更には対応モジュールの再購入が必要です。

総合評価結果

入手性とその金額、BLE仕様変更への対応から、PSoC 4 BLEを使った方法1が、コスト的にも、BLEに関するCypress日本語資料も少なからずありますので、個人でBLE習得するには最も優れた方法だと思います。

IoT時代は、UARTと同じレベルでBLEを使うことが必須です。仕事でせかされる前にBLE技術を習得しませんか? 弊社PSoC 4 BLEテンプレートもお役に立てると思います。

Raspberry Pi 3 Model Bの意味

Raspberry Pi 3 Model Bが発売されました。前のRaspberry Pi 2との差分は、処理能力向上とIEEE 802.11b/g/n、Bluetooth 4.1 (BLE: Bluetooth Low Energy)の無線通信機能搭載です。

Raspberry Pi 3 Model B(記事より抜粋)
Raspberry Pi 3 Model B(記事より抜粋)

IoTでは、数億~数十億個とも予想される情報収集マイコン(MCU)と、これらマイコンを束ねてクラウド側処理に適した変換処理をするRaspberry Piのようなコンピュータ(MPU、SBC)が必要です。

今回Raspberry Pi 3でIEEE 802.11b/g/n、Bluetooth 4.1(BLE: Bluetooth Low Energy)が追加実装されたことは、MCU、MPU/SBC間の通信手段としてこれら方式が有力であることを示しています。また、セキュリティや通信に処理能力が必要なので高性能化も解ります(既にこれら機能実装済みのDragonBoard 410cは、こちらを参照)。

低消費電力が要求されるマイコンMCUとの通信にはBLE、高速大容量が要求されるクラウドとの通信には無線LANが適用されると思われます。

IoT階層構造
IoT階層構造

今後のマイコン開発者には、従来通信の「UARTと同レベルでBLE習得が必須」です。

弊社マイコンテンプレートは、CypressのPSoC 4 BLEテンプレートでこの要求に対応済みです。最新のPSoC Creatorは、よりセキュリティを強化したBLE 4.2へも対応しています。BLEをUARTと同様に簡単に使ってみませんか?

次期マイコンテンプレートのターゲット考察

NXPとFreescaleの合併、予想さえしなかったことです。激動するマイコン世界ですが、現在のマイコンテンプレート状況を整理し、次期テンプレートのターゲットとなるマイコンについて考えます。

入手性の良いマイコンとテンプレート販売状況

以前紹介した入手性が良いマイコンが一目で解る、チップワンストップサイトのマイコン/開発ツール検索を今回も利用させていただきます。サイト中央のマイコン/ボードタグをクリックすると、8/16/32bit処理ビットとベンダ毎に分けられたマイコンが表示されます。

一覧表が以下です。緑色がARM仕様のマイコン、青色がベンダ仕様マイコン、赤囲みがテンプレート対応マイコンで、現在4種のテンプレートを1000円(税込)で販売中です。

入手性の良いマイコンとテンプレート提供状況
入手性の良いマイコンとテンプレート提供状況

表中NXPはARM Cortex-M0のみですが、Cortex-M0+のLPC8xxも供給しています。
32bitマイコンの主流は、緑のARMマイコンです。表内のARMコアの特徴をまとめたものが下表です。

ARMコア 名称 概要
Cortex-Mx エンベデッド プロセサ 32bitの高い処理効率を維持し、業界最先端の動作と最小限のスリープ/ダイナミック電力、最小限のダイ面積を目指し設計。以下の4サブ構成。
Cortex-M0:低消費電力マイコン
Cortex-M0+:超低消費電力マイコン
・Cortex-M3:汎用マイコン
・Cortex-M4:デジタル信号制御マイコン
Cortex-Ax アプリケーション プロセサ 高度なオペレーティングシステム:OSが実行可能なメモリ管理ユニットMMU搭載マイコン
ARMx Classic プロセサ ARM11、ARM9、ARM7などコスト効果の高いマイコン

 

32bitマイコンのテンプレート対象は、Cortex-M0/M0+です。
Cortex-M3クラスになると、高価なうえに動作周波数も70MHz以上でControlよりもComputeが得意になります。IoT向けPCのEdisonRaspberry Pi 2(Cortex-A7搭載)と競合する可能性もあります。Cortex-M0/M0+は、16bitマイコン市場の置換えも視野に入れたマイコンですので、今後の普及も期待できます。
16bitマイコンは、ルネサスの超低消費電力マイコンRL78に、RL78/G1xテンプレートを販売中です。

4種テンプレートに付記した動作電圧からみえるのは、そのマイコンの想定アプリケーションです。
FreescaleのKinetis Eは、5V耐性やノイズ耐力を高めたマイコンです。また、NXPのLPC8xxは、バッテリ駆動ができ、小ピンですがスイッチマトリクスによりピン配置の自由度が高く、LPC111xも同じくバッテリ駆動可能で、第3世代でアクティブ消費電流が116uA/MHzまで低下したマイコンです。ルネサスのRL78は、広い動作電圧がセースルポイントのマイコンです。

以上が現状マイコンテンプレートの状況です。「16bitのHigh Performanceマイコンから32bit Entry+alphaのマイコンで、容易に入手できメジャーなもの」へテンプレートを提供し、「対象マイコンの速習と早期アプリ開発」が誰でもできます。テンプレートの詳細は、マイコンテンプレートサイトを参照してください。

IoTアプリケーション向きの超低消費電力マイコンと次期テンプレート

開発アプリケーションに適したマイコンを選ぶこと、これが最も重要です。汎用マイコンでも、想定した応用の範囲内で能力を発揮するように設計されているからです。
次期テンプレートは、よりアプリケーション指向の強いマイコンを選びます。当りハズレはありますが、当たればより多くのテンプレートが売れる可能性があるからです。

プログ記載の2015年1月~2月に集中して最新マイコンドレンドを分析した結果、各ベンダは、巨大マーケットを持つ「IoTアプリと車載アプリ」へのマイコン開発に力点を置きつつあることが解りました。特に車載マイコンでのこの動きの結果、NXPとFreescaleの合併となったとも言えるでしょう。

次期テンプレートもこのドレンド:IoTアプリ向けの超低消費電力マイコンに開発します。例を挙げると、ARM Cortex-M0/M0+コアでは、より低い消費電力、高エネルギー効率と低コストを狙ったFreescaleのKinetis LシリーズやNXPのLPC82x、ルネサスRL78:S3コアでは、RL78/I1Dなどです。

これらには、従来テンプレートに添付したシンプル/メニュードリブンテンプレートに加え、IoTアプリ開発の重要なポイントになる省電力テンプレート(仮称)も加える予定です。

 

IntelシニアフェローStephen Pawlowski氏によると、「これからの10年は、エレクトロニクスのイノベーションの歴史で最もエキサイティングな時代になるだろう。」だそうです。弊社マイコンテンプレートが、このエキサイティングな時代に活躍する技術者/開発者の方へ、少しでもお役立てれば幸いです。