新WordPressテーマ

WordPressテーマ変更が完了しました。従来テーマに慣れていた方のために、簡単に使い方を説明いたします。

マイコンテンプレートサイトとブログメニューの分離

本ブログは、「日々変動するIoTデバイス関連の内容を中心」に、時系列で記載、整理し、まとめます。

このまとめた結果を、各社マイコンのソフトウエア作りに反映し、各社毎のマイコンテンプレートとして開発、各¥1000で販売します。この「まとめた結果とマイコンテンプレート」を説明するのがマイコンテンプレートサイトです。

以前のWordPressテーマは、マイコンテンプレートサイトとブログを一体化してメニューにしておりました。

新しいテーマでは、ブログのメニューとマイコンテンプレートサイトのメニューが、下図のように2つに分かれています。

新テーマの2メニュー
新テーマメニューは、マイコンテンプレートとブログでメニュー分離

ブログを読んで弊社マイコンテンプレートに興味を持って頂いた方は、マイコンテンプレートサイトのメニューを活用してテンプレートへもアクセスしてください。

※新テーマは、レスポンシブ対応ですので、ブログのメニュー表示は、表示画面サイズに応じて変わります。一方、マイコンテンプレートサイトのQuick Linksメニューは、常時画面最上位に表示されます。

IoT無線規格「Z-Wave」

欧米のホームセキュリティと室内温度コントロール、ホテルなどで実績があり普及が進むIoT無線規格が「Z-Wave」です。Z-Waveの国内動向記事によると、2015年のZ-Wave認証製品の累計出荷台数は6000万デバイス超、2016年には1億デバイス出荷が確実だそうです。

日本では未知な部分が多いIoTを、実サービスへ適用した例と、その出荷台数がインパクトある内容ですので、記事要旨を示します。

BLEの課題とZ-Waveの対策

  1. Wi-Fi環境下での干渉
  2. 石造りの家庭が多い欧州では、減衰が多い
  3. 通信距離が最大7~10m程度と短い
  4. 端末の増設に弱い

スマホ等で普及しているIoT無線通信の1つBLE:Bluetooth Low Energyの上記4課題に対して、Z-Waveは、これら課題を解決する下記特徴を備えているそうです。

  1. Wi-Fiとの干渉に強い
  2. 150m四方の通信距離
  3. 最大232個の端末増設が容易
  4. 低消費電力でバッテリー駆動の完全互換センサに数多く採用中

記事より抜粋したZ-Waveと他のIoT無線規格の比較を示します。

Z-Waveと他IoT無線規格の比較
Z-Waveと他IoT無線規格の比較(記事より抜粋)

日本国内でZ-Wave普及が遅れる理由

利用できる周波数解禁が海外比10年以上遅れていること、スマホによる家電や照明操作が電気用品安全法により規制されていること、火災警報器の厳しい基準などが原因だそうです。

また、欧米スマートホームのスタイルをそのまま導入できない日本の治安の良さも一因だそうです。

メッシュ網

技術解説記事によると、端末識別のためにMACヘッダにユニークなIDを付与することで232個までノードに対してメッシュ網を構成するそうです。

Z-Wave Singlecast
Z-Wave Singlecast(記事より抜粋)
Z-Wave Multicast
Z-Wave Multicast(記事より抜粋)

Z-Waveデバイスと評価キット

Z-Waveを制御するデバイス開発元の米Sigma-Design製評価キットは、欧州、米国、日本向けに用意されています。

日本でも医療/介護の分野で普及する可能性があるので要注意のIoT無線規格だと思います。MCUとMPU/SCB間の無線規格一覧ページへZ-Waveを追加し、今後も注視します。

WordPressテーマ変更

使用中のWordPressテーマが、テーマディレクトリから削除されました。削除理由は、私には良く解りませんが、テーマ作者が管理者との交渉の末の決定ですので、尊重いたします。

現行版は、殆どのカスタマイズがGUIででき、気に入っていただけにとても残念です。

そこで、現行版と違和感が少ない代替テーマを探しています。
個人的には、レスポンシブレイアウトなどは好まないのですが、今はほぼ全てのテーマがレスポンシブ対応です。また、私がカスタマイズしたい内容に対して、直接ソースコードを変えなければならないなど結構手間暇がかかります。

近日中に本ブログにアクセスされた時に、異なるフォームが表示されるかもしれませんが、より良く分かりやすいブログを心掛けて代替テーマへ変更しますので、ご安心ください。

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エンドポイント通信の本命になるかもしれません。

解説:マイコン評価ボード

マイコン開発には、各社が低価格で提供している評価ボードは必須です。
弊社マイコンテンプレートも、各ベンダの評価ボードで開発しています。この評価ボードを解説します。

採算度外視の低価格、高信頼ハードウエア

ソフト開発者に「確実に動くハードウエア」を「低価格」で提供する、これが評価ボードです。

マイコン開発には、「専用」のソフトウエアと「専用」のハードウエアの両方が必要です。そして片方のデバッグには、もう片方にバグが無いことが必須です。つまり、ソフトデバッグには、バグなしのハードが必須なのです。そこで、バグなしで確実に動作する「汎用」ハード、これが各ベンダ提供の評価ボードです。

但し、専用ハードがいずれ開発されるので、汎用の評価ボードは低価格とならざるをえない運命です。高ければ誰も買ってくれないからです。しかし開発者にとっては、以下のように優れた教材と言えます。

  1. ソフト開発者が、専用ハードが出来上がる前にソフトデバッグ可能な環境を自由に構築できる
  2. ハード開発者が、そのまま専用ハードにも使える高信頼ハード設計を学べる
  3. マイコン初心~中級者が、ベンダ標準のデバッグ技術で低価格な開発環境を使って自習できる
  4. 評価ボードは、各ベンダフォーラムで多くの情報が記載されており、適用サンプルソフトも多い

ターゲットMCU、デバッグインタフェース、拡張コネクタの3構成

評価ボードは、ターゲットMCU、デバッグインタフェース、拡張コネクタの3つから構成されます。

NXPの評価ボード:LPCXpresso LPC812とルネサスのRL78G13-Stick、CypressのCY8CKIT-042 の例を示します。

LPCXpresso LPC812構成
NXP LPCXpresso LPC812構成
RL78G13-Stick構成
Runesus RL78G13-Stick構成
CY8CKIT-042構成
Cypress CY8CKIT-042構成

ターゲットMCU

ターゲットMCUとは、開発MCUそのものの部分です。残りのデバッグインタフェースと拡張コネクタは、ターゲットMCUが異なっても同一です。

拡張コネクタ

最近はArduino用シールドコネクタを拡張コネクタに用いる評価ボードが多いです。これは、市販Arduinoシールドの種類が増えたため、上手く探せれば汎用の評価ボードに複数のArduinoシールドを拡張コネクタで接続し、専用ハードに近い、いわば「疑似専用ハード」を市販品のみで作れます。ボード単位のハード部品化がもたらした結果と言えます。

個人的には、シールドよりも、mbed – Xpresso Baseboardの方がより低コストで疑似専用ハード実現ができると思っています(こちらに詳しく記載しました)。

デバッグインタフェース

デバッグインタフェースは、IDEデバッグ機能を使うために必要な部分で、ターゲットMCUのシリアル入出力とパソコンUSBを変換する機能もここに含みます。この機能専用のマイコンが実装されることが多くなりました。このマイコンでデバッガ機能も代行するので、別途デバッガを購入せずにソフトデバッグが可能です。

MCUがARM Cortex-M0/M0+の場合には、ARM標準のCMSIS-DAPでMPUコアをデバッグできるインタフェースも実装されます。CMSIS-DAPはこちらの記事も参照してください。

CMSIS-DAPは、ターゲットMCUとデバッグインタフェースを切り離した後に、ソフトデバッグする時、別途ARM専用デバッガが必要ですが使えます。このように、1つの評価ボードで複数のデバッグ方法が使えるのも特徴です。

ARM系コアの場合は、ベンダ評価ボードもほぼ同じ構成で、ARM専用デバッガを1台持っていれば、ベンダ各社の評価ボードをまたがっても使えるのがメリットです。マイコン開発のデファクトスタンダートになりつつあります。

一方、デバッグインタフェースをE1コネクタでしか持たないルネサスのCPUボードをデバッグする際は、別途E1デバッガを接続しないとデバッグができません。この点は、Cortex-M0/M0+コアのMCUと比べるとコスト的に劣ると言えるでしょう。

Runesus QB-R5F104LE-TB構成
Runesus QB-R5F104LE-TB構成

デバッガ機能なしの統合開発環境:IDEの背景

シールドなどのボード単位の部品化が進んだ結果、専用ハードは、もはや既存ハードを組み合わせて、その小型化のみを行う設計、つまり専用基板化が主な開発内容と言えるかもしれません。

同様に、ソフト開発もベンダが、多くのライブラリを提供することで、専用ソフトをライブラリの組合せで完成できるレベルを目指しているようです。IDEにデバッガ機能がないArduino IDEなどは、この現れのような気がします。

ハードとソフトのオープンソース

ハード版オープンソースとしてArduinoシールドコネクタを持つ既成基板は、増えつつあります。

オープンソースを活用したソフト開発は、Unix系では当たり前です。この流れがマイコンソフトへも徐々に浸透する可能性を感じています。この場合、ハードの専用基板化開発に相当するのは、RTOS適用や弊社のマイコンテンプレートになるかもしれません。

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デバッグには、戻りたくないというのも本音です。ご容赦ください。