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適用や弊社のマイコンテンプレートになるかもしれません。

英語環境のすすめ

ルネサス2015会計年度と第4四半期(2016年1月~3月期)業績の解説記事から、マイコン開発者に英語環境をすすめる理由を示します。

汎用向け売上げ2割減、日本市場比率44%へ減少

2015年半導体シェアは、先のブログのようにNXP1位、ルネサス2位が確定したようですが、解説記事によると「産業・家電」、「OA・ICT」、「汎用製品」の3分野からなる「汎用向けの売上げが2割減、売上げに占める日本比率は、54%から44%へ減少」したそうです。また、「従業員数も設立当初より4割削減」だそうです。

(日本語)ガラパゴス環境の先行き

汎用マイコンを扱う本ブログは、各社開発環境を一覧表で示しています。これを見ると、ルネサス独自開発のCS+以外は全てEclipseベースのIDEです(Arduino IDEは除外)。また、マイコン開発ボードもArduino互換が標準となりつつあります。

つまり、マイコン開発環境のデファクトスタンダードは、「ARMコア+Eclipse+Arduino+英語」です。開発者の情報交換コミュニティも英語です。

デファクトスタンダードが最適とは言いませんが、特に「汎用の分野」では、ガラパゴスよりもスタンダードが良であることは間違いありません。

Apple iPhoneは、圧倒的大多数を市場で占めているのでガラパゴスでも生き残れます。

地震国日本の部品生産工場が停止した際、連動して製品生産も停止する自動車は、他社流用や使いまわしができない専用品を使っているからです。

コスト重視のマイコン制御系もまた自動車のように最終的には製品専用品になるかもしれません。しかし、マイコン開発者は、少なくとも日本語に拘らず「英語の開発環境に慣れていく」必要があると思います。記事から抜粋したルネサス売上高推移の青部分(日本市場比率)が示す今後を予想してみてください。

日本市場比率の推移(解説記事の図に加筆)
日本市場比率の推移(解説記事の図に加筆)

マイコンIDE更新

扱うMCUデバイスの追加、WindowsやiOSなどのOS変更、Eclipseそのものの変更、バグ修正など様々な要因によりマイコン開発環境:IDEの更新は発生します。今回は、マイコンIDE更新について解説します。

更新通知と更新理由

マイコンアプリケーションソフト開発中ならば、リスクが増える可能性もあるIDE更新は避けたいものです。
このため「開発者が更新をするか否かを選択」できるのがマイコンIDEの特徴です。Windowsと大きく異なる点ですね。

更新判断には、「更新が発生」したか、「更新の理由」は何か、この2つを知る必要があります。この情報をIDEのWelcome画面のWebリンクで教えてくれるのがEclipseベースのIDEです。NXPのLPCXpressoの例を示します。

LPCXpresso Welcome page
LPCXpresso Welcome page

赤矢印のリンク先をみると、最新版IDEと、変更内容などが解ります。使用中のIDEと版数が異なる場合には、この内容を読んで更新判断ができます。新旧LPCXpressoは、緑囲いで示した版数毎に別フォルダへインストールされるので、IDE更新リスクがフォルダ内に閉じ込められるので安心です。

また、NXPに買収された旧FreescaleのKinetis Design Studio: KDSの例が下図です。Welcome画面に加え、Help>Check for Updatesで更新確認と新版インストールまでバックグラウンドで可能です。この機能は、LPCXpressoにはありません。

Kinetis Design Studio Check for Updates
Kinetis Design Studio Check for Updates

但し、私の環境では、ベースとなるEclipseのメジャー更新が関係しているのかもしれませんが、KDS V3.1からV3.2への更新ができませんでした。V3.2更新は、別途インストーラで可能です。やはりIDE更新確認ツールがあっても、時々サイトでIDEの最新版確認は、必要だと思いました。

また、CypressのPSoC Creatorは、Update Managerツールで更新確認とインストールができます。旧版はアーカイブ保存されるので、万一最新版にトラブルが発生しても安心です。

Cypress Update Manager
Cypress Update Manager

以上3社のマイコンIDEは、どれもEclipseベースのIDEですが、更新方法や旧版の扱いは各社異なります。

一方、ルネサス独自仕様のIDE:CS+もアップデート・マネジャーツールで更新します。独自仕様なので、細かい更新内容確認や、一部選択更新なども可能です。ツール・ニュースなどで更新、バグ情報を知らせてくれるのも役立ちます。
また、更新前に、「開発ツールをパックして保存(K)…」を実行すると、更新トラブル対策も可能です。

Runesus CS+ Packing tool
Runesus CS+ Packing Tool

マイコンIDE更新を安全にするには

マイコンIDEの更新トラブル回避には、OS起因でない場合は、旧版のIDEへ戻せることが必要です。また、Eclipseのメジャー更新時などは、操作方法が変わることもあるので注意が必要です。
開発案件のキリが良い時期に更新するのが安全策でしょう。

マイコンIDE開発経験を活かすには

弊社マイコンテンプレートで使用中の各社IDE特徴を示します。マイコンIDEは、Eclipseベースに集約されつつあるようです。今回は、同じベースでもIDEの更新方法が異なることを示しました。

これは、EclipseベースのIDEを使う時に覚えておくと役立つのが、各社共通のエディタやデバッグなどのコア機能であることを暗示しています。他社IDE使用時に、この経験が活かせるからです。

MCU IDE Comparison
マイコンIDE比較

マイコンIDE習得のコツやTipsは、コチラのページにもまとめています。参考にしてください。

PSoC 4 BLE Pioneer Kitサンプルソフト改版

弊社推薦PSoC 4 BLE/PSoC 4開発キットのPSoC 4 BLE Pioneer Kit:CY8CKIT-042-BLE付属サンプルソフトが、2016/02/12 Revision *Hへ改版されました。Cypress Update Manager起動でUpdate可能です。

Update Manager更新失敗時の対処

殆どの場合Update Managerで更新は成功します。しかし、Windows 10の煩いセキュリティのおかげ?で時たまCY8CKIT-042-BLEのみUpdate失敗があります。この時は、CY8CKIT-042-BLEサイトから直接Download CY8CKIT-042-BLE Kit Only Packageをダウンロードし実行すれば、更新は成功します。

Cypress Update Manager成功時
Cypress Update Manager成功時

更新内容

今回の更新は、PSoC 4 BLEキットに搭載可能なBluetooth 4.2対応のPSoC 4 BLEとPRoCモジュールが増えた事への対処です(コチラの記事も参照)。但し、キットに初めから搭載されているサンプルソフトとモジュールに変更はありません。キットガイト抜粋のサンプルソフトと対応モジュール一覧が下記です。

PSoC 4 BLEサンプルソフトと対応モジュール一覧
PSoC 4 BLEサンプルソフトと対応モジュール一覧

キット搭載のROM 128KBでBluetooth 4.1対応モジュールのPSoC 4: CY8C4247LQI-BL483と、PRoC: CYBL10563-56LQXIが、デフォルトで対応するモジュールのデバイスです。(デバイス差明示のため赤表記)。

PSoC 4 BLEモジュールでは、
Bluetooth 4.1でROMが128KBから256KBへ増えたCY8C4248LQI-BLE483、
Bluetooth 4.2でROMが256KBのCY8C4248LQI-BL583、
PRoC モジュールでも、同じく
Bluetooth 4.1でROMが128KBから256KBへ増えたCYBLE10573-56LQXI、
Bluetooth 4.2でROMが256KBのCYBL11573-56LQXI、
BLEドングルもBluetooth 4.2対応のCYBL11573-56LQXIのサンプルソフト、Projectが対応します。

弊社テンプレートの適用例であるBLE_PSoCプロジェクトのリソースメータが示すように、簡単なアプリケーションでも128KB ROM/RAMの6割以上を使用しますので、デバイスROM容量が256KBへ増えたのは、納得できます(販売中のPSoC 4/PSoC 4 BLE/PRoCテンプレートはコチラを参照してください)。

テンプレート応用例BLE_PSoCのリソースメータ
テンプレート応用例BLE_PSoCのリソースメータ

残念ながら、わずか15$で追加できるBluetooth 4.2対応モジュールを未入手なので確認はできていませんが、モジュール変更時は、デバイス再選択と使用コンポーネントをBLE 4.2へ更新しさえすれば簡単にサンプルソフトを適用できそうです。

この追加モジュールのROM容量とBluetoothの対応が解りやすいのが、ガイトA.5表です。

実装モジュールのROMとBluetooth対応
実装モジュールのROMとBluetooth対応

CySmartアプリソースコード公開

Cypressは、BLEドングルの代わりにAndroidやiOSで使えるCySmartというスマホアプリも公開中です。今回、これらのソースコードも公開されました。時間と能力があれば、モバイルアプリ開発も是非トライしたいと考えています。

※弊社BLE動作テンプレートは、全てBLEドングルを使ってBLE通信動作を確認済みです。CySmart+私のNexus 5:Android 6.0.1という組合せは、原因はNexus側にあると思いますが上手く接続できないのが理由です。

ブログカテゴリ変更とテンプレートサイト更新のお知らせ

本ブログカテゴリを下記のとおり変更しました。

「MCU:マイコン」と「MPU/SCB:IoT用コンピュータ」を別カテゴリにしました。

※MCU: Micro Controller Unit…    ARM Cortex-M0+/M0、NXP) LPC, Kinetisシリーズ、Cypress)PSoC 4 /PSoC 4 BLE/PROCシリーズ、ルネサス)RL78/G1xシリーズなど

※MPU/SCB: Micro Processor Unit or Single Board Computer…      Raspberry Piシリーズ、DragonBoardなど

→ MCUとMPU/SCBのIoT階層構造は、コチラを参照してください。

マイリンクも下記とおり変更しました。

マイコンテンプレートサイトに、「マイコンテンプレートを利用する際に知っていると便利なTipsやコツ」のページを追加しました。

今後、MPU/SCB:IoT用コンピュータの内容も充実させる予定です。

NXPとCypress動向

NXPは2015年にFreescale、Cypressは2014年にSpansionを買収しました。買収後のNXPとCypressのマイコンラインアップがどう変わるかが気になります。
日経テクノロジーOnlineで両社のマイコン新製品と今後の開発動向に関する記事がありましたので、要点をリストアップしました。

NXP: LPCとKinetisを徐々に統合

“新生NXP初のマイコン、旧NXP系で低消費電力がウリモノ” 2016/02/24より

  • NXPのマイコンシェア、車載MCUは世界第2位、車載を除くMCUは世界第1位
  • LPCマイコンと(旧Freescale)Kinetisマイコンは、徐々に統合(Geoff Lee氏談)
  • 新製品は、NXP系のLPC54000シリーズ(Cortex-M4FでコプロセサにCortex-M0+搭載可)

弊社マイコンテンプレートで使った、NXPのLPC8xx/LPC111xと旧FreescaleのKinties Eも現在NXPから全て供給中ですが、統合される可能性があることが解ります。

Cypress: PSoC 4へCortex-M0+コアを採用

“FMマイコンもPSoCも同じツールで開発、Cypressがアルファ版をデモ” 2016/02/29より

  • 新製品PSoC 4 Sは旧Spansionライセンス取得のCortex-M0+を採用。今後新開発PSoC 4もM0+を使う
  • PSoC 4 S搭載の第4世代CapSenceは、第3世代比、雑音耐性向上と低電力化
  • PSoC 4 S Pioneer Kit ($49)、PSoC 4 S Prototyping Kit ($10)発売
  • PSoC CreatorでFM0+マイコン(旧Spansion)も開発できるよう強化中

Cortex-M0+とM0を比較すれば、M0+が優れているので、新開発のPSoC 4系にM0+を採用するのは理解できます。
数あるマイコンIDEの中で私が最も使いやすいと評価するPSoC Creatorですが、PSoC 4とFM0+はアーキテクチャが異なり、さらにPSoC 4系にM0+が採用されれば、ますますFM0+を使う機会は減ると思います。
通常のマイコンソフト開発では、M0+とM0を区別することも少ないので、Creator強化は静観したいと思います。