1~10)を紹介します。ContentsBLEやThreadソフト開発者必見のLessons内容、質ともに優れたVideoでMCUXpressoとSDKの使い方も良く解ります。興味深い内容とその出所が以下です。10)BLEやThreadに関する情報は多くありますが、ソフト開発者の立場からは、本Lessonsが最も要領よくポイントをまとめています。KW41Zの評価ボードは、以下の2種(Digi-Key価格)です。$145.00低価格で有名なFRDM評価ボードですが、さすがに両プロトコル対応のKW41Z搭載ボードとなると$100以上します。Videoで使っているR41Z-EVALは、約$60と安く入手できます。10のBLEとThreadメッシュ切り替え接続の動作確認を行うには、同時に3台の評価ボードが必要です。ThreadのみサポートのKW21、BLEのみのKW31もありますが、無線規格が乱立していて、どれが本命かを見極めるのが困難な現状では、両プロトコルサポートのKW41が安全でしょう。IoTMCUXpressoとSDKを使って、BLEまたはThread通信機能を持つIoT端末を開発する際に、プロトコルのどの部分の変更/修正が必要で、それがソース上のどこにあるか、全体の開発手順などはVideoを観ると良く解ります。Stackまた、LEDなどのGPIO制御を行うSDKデモソフトとIoT通信の並列処理は、FreeRTOSを使って実現していることも解ります。簡単なIoT端末なら、このデモソフトに、外部センサ値をAD変換し、その変換データをクラウドのサーバーへIoT経由で送信する機能を追加しさえすれば、直ぐに開発できそうです。※簡単なIoT端末は後述BLEやThreadは、IoT通信の有力な候補です。IoTの通信プロトコルが何になるにせよ、IoT通信向けのAPIが決まれば、あまり気にする必要がない、というのが全Lessonを通しての私の感想です。その理由は、デモソフト実装済みのGPIO制御はそのまま使えますし、FreeRTOSを使っていますので、外部センサ入力を定期的にADCする処理(ADCスレッド)と、ADC変換データをIoT通信APIへ出力する処理(IoT出力スレッド)の2処理を追加開発すれば良いからです。ADCスレッドは、IoT通信規格には無関係です。APIが使える(用意される)と思います。APIの例で示すと、Chip_UART_SendBlocking()が、Chip_IoT_SendBlocking()に代わるイメージです。API利用条件が初期設定で満たされれば、ユーザは、通信速度や、通信プロトコルを意識せずにIoT通信を使えるようになると思います。*IoT通信規格が不確定な状況で、少しでも早くIoTやRTOSに慣れるには、R41Z-EVALは良い評価ボードです。RAMで簡単なIoT端末が開発できそうな見通しもこれらLessonは、与えてくれました。ご自分でご覧になってください。簡単なIoT端末のイメージデータ入力とGPIO出力を行うMCU端末で、IoT無線通信機能を備える。通信セキュリティを確保できるAES-128などの機能も備え、対象機器から取得したデータを安全にクラウド内のサーバーへ送信する。サーバーは、対象機器データを人工知能を使って予測分析し、結果を端末へ送信する。端末は、受信結果を基にLEDなどのGPIO出力を行い、オペレータまたはロボットが対象機器メンテナンス作業の手助けをする。5の仕様が記事になり、内容を一覧表にしてみました。URL送信可能(従来31文字)Threadと同様、一軒の家の範囲をくまなくカバーする「メッシュ網」と、2020年に450億台と予想されるIoT機器のうち、3分の1の140億台のIoT機器への搭載を目標にしているそうです。5が2016年末~2017年初頭にリリースされる予定だそうです。メッシュのThreadと、スターのBluetoothの違いがありますが、どちらも狙いはIoTエンドポイントのマイコンへの普及です。Thread」を実装できる方が望まれると思います。マイコン:MCUにとって、デバッグの容易さから、UARTは消えゆくレガシー周辺回路ではなく必須回路と考えるからです。現在のIoTコンピュータ:MPU/SBC側の対MCU通信インタフェースはBluetoothです。こちらにその理由と、ネットワーク構成を示します。5の普及状況に応じてMPU/SBCでは、両サポートになりえます。WithHappyThreadは、Wi-FiやBluetoothなどの既存無線通信と異なりメッシュメットワーク構成の2015年7月発表の新しいIoT無線規格です。詳しい記事はコチラ、またThread詳細はWebを参照して頂くとして、ここでは記事要旨を示します。Wi-FiやBluetoothの1対1(多)のスター網構成に対し、通信堅牢性と通信範囲の確保を目的にメッシュ網で通信。ネイティブIP通信:OSIのネットワーク層とトランスポート層の仕様策定が目的で、超低消費電力で短距離通信のIP通信を行うオープン仕様。上下層は、既存レイヤー仕様をそのまま使用。可能:長期電池駆動が可能なデータ送受方法を採用。ホームネットワーク要件を全て満たす。Technologies、照明大手OSRAMなどの企業と、マイコン大手NXP、ARMなどが主要メンバーとして参加。以上が記事要旨にWebから得られる情報を追加したものです。以下の理由で私はThreadに期待しています。Energyは、少量データの送信には理想的ですが、アプリケーション規格などが厳格で、「スマホとウエラブルデバイス間通信」に適しています。これをマイコンで「単に土管として無線を使いたい」場合には少し重たい気がします。マイコンUART入出力をIoTコンピュータ:MPU/SBCへ無線で接続する時などです(BLEとROM量はコチラに記載)。莫大な販売量が見込まれるとしてもIoTエンドポイントマイコンは、ROM/RAMが少なく低価格デバイスが向いていると思います。BLE機能を実装するとROM量は64KB超が予想されます。Threadが、BLEより軽くマイコンへ実装できれば、IoTエンドポイント通信の本命になるかもしれません。