MCU:マイコン,LPCマイコン,Cortex-M4コアmbed OS,RTOS,semaphore,Amazon Web Service,Amazon FreeRTOS,IoT,IoTエッジMCU,queue,Azure RTOS

IoT MCUクラウド市場は、AWSとMicrosoft Azureがリードしており世界収益の半分以上を占めるという記事に掲載されたのが下図です(EE Times 2021年6月7日、横軸:市場シェア、縦軸:年平均成長率)。Microsoftは徐々にAmazonに迫っており、市場シェア差は、過去1年で2ポイント縮まったそうです。

クラウトプロバイダの市場シェア(出典:記事)
クラウトプロバイダの市場シェア(出典:記事)

多様化MCU RTOS

AWSへの接続にはAmazon FreeRTOS、Microsoft AzureにはAzure RTOSを用います。IoTクラウド接続ウェビナーでは、どのMCUベンダでも先行しているAmazon FreeRTOSを使った接続例が主流です。しかし、最近は、Azure RTOS利用の接続資料やウェビナーも見られます。AWSとMicrosoft Azureの差が縮まりつつある証左でしょう。

また、第3勢力として急成長中のGoogleクラウド接続にはARM mbed OSが使われます。IoT MCUに実装するRTOSは多様化してきました。

IoT MCU RTOSとPCブラウザ

IoT MCU RTOSとPCブラウザ比較
IoT MCU RTOSとPCブラウザ比較

この状況は、PCブラウザが現状、複数共存しているのに似ています。

機能的には同じブラウザですが、表示/印刷/広告などの使い勝手が少しずつ異なるため、必要に応じて複数ブラウザを使い分ける方も多いでしょう。記憶容量の大きいPCでは、ブラウザ併用・共存も簡単です。

しかし、限られた容量しか持たないMCUの場合は、複数RTOSの中からMCU搭載RTOSは1つに絞られると思います。

例えば、AmazonやMicrosoft、Google各社の強み(販売/文書/広告)や特徴を活かし、IoT機器制御サービスやAI活用サービスなど魅力的クラウドサービスを各社各様で提供し、その価格、顧客との結びつきの強さなどがサービス選択の決め手となるでしょう。

いずれにせよ顧客が、利用するクラウドサービスを決め、その接続手段として各社RTOS接続ライブラリの使用、加えてRTOS環境での上層MCUソフトウェア開発を行うことになります。

問題は、RTOS環境のMCUソフトウェア開発手法がベアメタルと異なること、各社RTOS仕様が少しずつ異なることです。

多様化RTOS対策

仮に、Cortex-M4/M0+ディアルコアMCUで、クラウド通信処理全てを、Cortex-M0+コア側のRTOSライブラリで行い、通信とアプリケーションが完全分離された構成であれば、問題は解決します。接続サービス毎にRTOS通信ライブラリを変えさえすれば、対応できるからです。

BluetoothやThreadなど複数無線通信規格から1つを選んで処理するなど、この構成に近いベアメタルソフトウェア対応のMCUが既にあります。

しかし、主流ウェビナーで用いられる高性能Cortex-M4シングルコアを使って、クラウド通信とアプリケーションの両方を処理する場合には、接続先のクラウドに応じて「FreeRTOS/Azure RTOS/Mbed OSなど様々なRTOS環境の上層アプリケーション開発」になります。

RTOSの目的は、MCUハードウェア隠蔽と開発ソフトウェア流用性向上なのに、複数RTOS存在で開発アプリケーションが異なるとは、皮肉な結果です。

最初の図は、IoT MCU開発者が、今後急増するクラウド接続IoT MCU開発に、これら複数RTOSを効率的に習得し、かつ、顧客が選ぶ1個のRTOSアプリケーションを早期に開発できるスキルを獲得しなければならない現状や将来を示しているとも言えます。

こういう状況での常套手段は、共通部分と個別部分の分離、共通部分からの段階的習得です。

どのRTOSでもSemaphoreやQueueは、ほぼ共通の基本機能です。先ずは、この2機能をしっかり把握し、より高度なミューテックスやイベントグループなどRTOS毎に特徴があり機能も異なる対象へ発展するのが効率的でしょう。

※RTOSは、複数タスク(AzureはThread)を、優先順位に応じてリアルタイムに実行/待機/状態保存復帰の切替えを行います。タスク間同期手段がSemaphore、データ送受手段がQueueで、この2つはどのRTOSでも共通の基本機能です。

まとめ

IoT MCUクラウド市場シェアから、クラウド接続IoT MCU RTOSもPCブラウザ同様、様々な仕様併存の可能性があります。

顧客が選ぶRTOSに柔軟対応し、そのRTOS上層の様々なRTOSアプリケーションを早期開発するには、先ず、各RTOS共通機能のSemaphoreとQueueを把握し、より高度でRTOS毎に異なる個別機能へ発展する習得アプローチが効率的です。

6Eリリース予定の弊社FreeRTOSアプリケーションテンプレート(税込2000円)は、主流のAmazon FreeRTOSを用い、NXP)LPCXpresso54114(Cortex-M4/150MHz、Flash/256KB、RAM/192KB)にて動作確認済みです。

添付するRTOSプロジェクトは、各RTOS共通機能SemaphoreとQueueを利用しており、上記習得アプローチを満たすツールとして、また、全ての物をつなげる主役IoT MCU RTOS基礎固めに最適です。

MCU:マイコン,STM32マイコン,Cortex-M0+コア,Cortex-M23コア,Cortex-M4コアCortex-M0+,IoTマイコン,Cortex-M4,セキュリティ,IoT,IoTエッジMCU,Cortex-M33

STマイクロエレクトロニクスが、STM32マイコン体験実習(セキュリティ編①~⑤)という動画でCortex-M33 TrustZone解説とSTM32L5(Cortex-M33/110MHz、Flash/256/512KB、RAM/256KB)のセキュリティ実習を行っています。

このセキュリティ編①:31min17secから、IoT MCU向けセキュリティ強化Cortex-M33コアのARM TrustZoneマイコンと、通常Cortex-M0+/M4コアマイコンとの差分を抽出しました。TrustZoneマイコン基礎知識の習得が目的です。

Cortex-M33とCortex-M0+/M4差分

セキュリティ編動画①~⑤概要

①P3(動画①、スライドP3を示します)に、動画①~⑤の概要が示されています。動画①でCortex-M33コアの解説、②でSTM32L5開発環境の準備、後半③~⑤でSTM32L5評価ボード:NUCLEO-L552ZE-Q(¥2,303 Mouser)を使ったセキュリティ演習という構成です。

本稿は、動画①から、ARM TrustZone Cortex-M33コアと通常Cortex-M0+/M4コアとの差分を一覧表にしました。

※ARM公式差分情報を知りたい方は、①P48の参考文献が参考になります。

Cortex-M33とCortex-M0+/M4の差分

オンデマンド動画ですので、好きな個所で止める、再生読度を変えるなどが可能です。動画①は、筆者が経験したTrustZone解説の中で最も分かり易い動画です。

特にP36/P37/P39は、4段階に増えたステート処理内容が具体的に判りTrustZoneマイコン特徴理解に役立ちます。
また、P19は、様々なセキュリティレベルと対応STM32MCUのセキュリティ機能差が一目で判る重要な資料です。

要旨(ARM TrustZone Cortex-M33と通常Cortex-M0+/M4差分)
7 ソフトウェア攻撃防御策がTrustZone。物理攻撃対策はセキュアマイコン(≠汎用MCU)が有効。
12 Secure呼出し=予め決めた手順で内蔵周辺回路(I2C/SPI/RAMなど)へアクセスする技術
Security Isolation=Secure呼出しを使い通常アクセスと隔離・分離する技術
ARM TrustZone=Security Isolationを対象MCUで柔軟に構成する技術
16 タンパ=物理攻撃を検出→検出後バックアップレジスタやSRAM自動消去
JTAGピン無効化→設定後はGPIOなどで運用
WRP(WRite Protection):数KB単位設定可能
RDP(ReaD Protection):JTAG読出し禁止→読出検出でプログラム実行停止→PORで解除
Secure Memory=起動時のみ読出し可能な領域
17 MPU(Memory Protection Unit):最大16個メモリ領域の読書き、命令実行許可/禁止設定
18 セキュリティは単独では効果が薄く、複数重ね攻撃への敷居を上げ強化(暗号鍵保存例掲載)
19 STM32マイコン内蔵セキュリティ機能差一覧。TrustZone対応はSTM32L5のみ(2020/12時点)
STM32G0/G4(Cortex-M0+/M4)でもSRAM RDP機能などあり
22 TrustZoneは、アドレス空間とバス通信の両方をハードウェア監視しアクセス制御
23 アドレス空間監視=コア内蔵SAU IDAU、バス通信監視=TZ(TrustZone) ControllerとAHBバス
24 STM32L5は、内部FlashアクセスにST独自Flashレジスタとオプションバイトで保護
26 TrustZone-aware周辺回路=DMA1&2/GPIO…などAHB接続回路は個別セキュリティ設定要
上記以外がSecurable周辺回路=UART/SPI…などでAHB/APBブリッジがアクセス監視
29 従来MCUベアメタル開発は、mainループも割込みハンドラも常に特権モード動作の1段階
30 従来MCUのRTOS開発は、割込みハンドラ/RTOSが特権モード、ユーザタスクは非特権の2段階
32 Secureステート追加TrustZoneは、4段階化→各層の処理配置がTrustZoneソフト設計第一歩
35 Secureソフトと従来ソフトのプロジェクト差一覧
(セキュリティ関連設定はSecureソフトのみ可能でmain関数はあるがmainループなしなど)
36 TrustZoneマイコンベアメタル開発の4段階ステート処理配置例(TrustZoneソフト設計例1)
37 TrustZoneマイコンRTOS開発の4段階ステート処理配置例(TrustZoneソフト設計例2)
38 TrustZoneソフト開発時、Secureソフトと通常ソフトの2プロジェクト作成必要
39 TrustZoneソフトの基本実行フロー(Secureソフトから通常ソフトへの処理内容一覧)
40
41
42
Secureステートと通常ステートのアドレス空間の見え方差まとめ
44 動画①全体まとめ
45 STM32L5開発時のキーポイント一覧(全18項目)
46 STM32L5開発時のキーポイント演習項目一覧(18項目中9項目を動画③~⑤で演習)
48 おすすめARMv8-M(Cortex-M33コア)TrustZone参考文献一覧

TrustZoneマイコン開発は工数2倍、スキルも必要

動画①は、他ベンダのARM Cortex-M33 TrustZoneマイコン開発でも基礎知識が得られます(※P24のST独自Flashレジスタとオプションバイト保護は除く)。IoT MCU向けセキュリティ強化Cortex-M33コアで導入されたTrustZoneを活用するには、①の理解は最低限必要です。

従来Cortex-M0+/M4に比べ、Cortex-M33シングルコア開発でもSecureと通常(Normal)ソフトウェアの2プロジェクト必要、メモリ空間と周辺回路のセキュリティ設定必要(メモリ分割損も生じると予想)、JTAGピン無効化など、従来のアプリケーション開発とそのデバッグに加え、ソフトウェア攻撃対策TrustZone導入による工数やその動作確認/解除などの手間が余分に必要になります。

このTrustZone導入オーバーヘッドは、少なくないです(セキュリティ編②~⑤でオーバーヘッド工数が判ります。補足章に動画②~⑤リンク添付)。Cortex-M33コア最高速度が110MHzと他コア比高速で、Flash/RAMも大容量なのは、このオーバーヘッドのハードウェア対策だと思います。

TrustZoneマイコンのソフトウェア開発工数は、同じアプリケーションの通常マイコン開発の2倍程度は必要になると思います。また、TrustZone起因のトラブルに対する分析スキルも必須です。

ソフトウェア攻撃に対する防御壁の高さは、言い換えると、ソフトウェア開発のし難さと等価です。セキュリティレベルが上がるにつれ、開発コストも上がります。

全てのIoT MCUがTrustZone対応MCUである必要は無いと思います。コスト重視の場合は、従来Cortex-M0+/M4コアでセキュリティ強化対応(例えば、関連投稿:STM32G0/G4のRoot of Trust(1)~(3)など)でも使える可能性があります(関連投稿:IoT MCUコア次世代像のIoT MCUコアの3層構造最下層のFront End IoT MCUに相当)。

セキュリティは、強固な方が良いのは当然ですが、それ相応の追加コストも生じます。セキュリティ対コストの観点からIoT MCUの選択が必要となるでしょう。

* * *

セキュリティ対策は、いわば自動車保険のようなものです。保険代金の負担は、開発者かエンドユーザか、エンドユーザがTrustZone導入オーバーヘッドを理解することは難しいと思いますので悩ましい問題です😅。

Cortex-M33 TrustZoneマイコンは、ソフトウェア開発者が記述した処理を攻撃とマイコンが誤認識(正常認識)した場合は、無視、あるいは最悪、マイコンを使用不能にします。見つけにくい無視された処理が、開発者起因か、あるいはTrustZone起因かを分析できるスキル、これが、通常マイコン開発との最大の差分です。

STM32マイコン体験実習は、TrustZone起因スキルを習得できるよく考えられた教材です。

補足

STM32マイコン体験実習(セキュリティ編②
STM32マイコン体験実習(セキュリティ編③
STM32マイコン体験実習(セキュリティ編④
STM32マイコン体験実習(セキュリティ編⑤

関連投稿:STM HTML版マンスリー・アップデートの見かた4章の全体像リンク集なども役立ちます。

Cortex-M33コア以外でTrustZone技術を用いたマイコンは、Cortex-M35P、Cortex-M23があります。

RL78マイコン,MCU:マイコン,LPCマイコン,MPU/SBC:IoT用プロセサ,Kinetisマイコン,STM32マイコン,PSoC/PRoCマイコン,MSP432マイコン,Cortex-M0+コア,Cortex-M0コア,Cortex-M3コア,Cortex-M23コアIoTマイコン,Bluetooth Low Energy,Bluetooth,IoT,IoTエッジMCU,Wi-Fi6,Bluetooth LE 5.2

IoTに適した無線LANの条件とは?(TechTarget、2020年11月27日)記事を紹介し、IoT MCU関連のプライベート網無線LAN規格を説明します。

IoT向き無線LAN条件と規格

纏まった良い記事なので、一読をお勧めします。

記事を要約すると、IoT向きの無線LANの選定には、3つの検討ポイントがあります。

  1. 省電力性:バッテリーだけで長時間無線LAN通信ができる
  2. 長距離伝送性:アクセスポイント(AP)から1km以上離れる場合がある
  3. 国より異なる利用周波数の空き状態確認

各ポイントを満たす無線LAN規格として下記3つを挙げ特徴を説明しています。

  • IEEE 802.11ah(別名Wi-Fi HaLow):Target Wake Time(TWT)により通信タイミングを調整しAP通信競合を防ぐと同時にスケジュールタイムまでスリープし電力消費を抑える
  • IEEE 802.11ba:TWTに加えWake-Up Radio省電力機能を利用しAPからの通信要求に対応
  • IEEE 802.11af: 54MHz~698MHz利用で900MHz~1GHzの802.11ah/802.11baより長距離伝送可能
    ※11afは、テレビ用ホワイトスペースのVHF/UHFバンド(54 MHz~790 MHz)利用なので空き状態により耐ノイズ注意

IoT向き無線LANとBluetooth

無線LANには、2.4GHz利用、数m~10m程度の「近距離無線通信規格」:IEEE 802.15.1(別名Bluetooth)もあります。コイン電池で1年以上動作できるなど超省電力動作ですが、低速です。PCやスマートフォンでは、マウス/キーボード/ヘッドホンなどの周辺機器との接続に使われます。

より高速、より長距離(400m程度)、より高スループットを目指し、Bluetooth v4.2、Bluetooth 5などと規格が変化しています。

IoT MCUへの実装は、Bluetooth 5内蔵MCUBluetooth 5モジュールとMCUを接続する方法があります。

IoT 向き無線LANとPC/スマホ向き無線LAN

2020年12月時点のPC/スマートフォン無線LAN規格が下表です(出展:NTT西日本公式ホームページ)。

規格 周波数帯 最大通信速度
IEEE 802.11b 2.4GHz 11Mbps
IEEE 802.11g 2.4GHz 54Mbps
­­­­IEEE 802.11a 5GHz 54Mbps
IEEE 802.11n 2.4GHz 600Mbps
5GHz
IEEE 802.11ac 5GHz 6.9Gbps
IEEE 802.11ad(WiGig) 60GHz 6.8Gbps
IEEE 802.11ax 2.4GHz 9.6Gbps
5GHz

IoT向き無線LANと異なるのは、周波数帯がより高周波の2.4GHz/5GHzを利用する点と、新規格11ac/11ad/11ax、従来規格11b/11g/11a/11n、ともにデータ伝送速度が速い点です。スマホのAPは、家庭や店舗に設置された無線LANルータで、高周波利用のため伝送距離は精々100m程度、60GHzの11adでは10m程度です。公衆網5G高速化に伴い新無線LAN規格:11ac/11ad/11axが普及しつつあります。

動画再生などの利用形態も多いPC/スマホ向き無線LANは、「高速大容量化」が求められます。IoTの「長距離省電力」要求とは、異なる無線LAN規格となっています。

まとめ:IoT MCUプライベート網の無線LAN規格

無線LANアクセスポイントからの伝送距離変化
無線LANアクセスポイントからの伝送距離変化

プライベート網無線LAN規格は、APからの伝送距離により、

  1. 「近距離(10m以下)超省電力」規格(周辺機器向き):Bluetooth(IEEE 802.15.1)
  2. 「短距離(100m程度)高速大容量」規格(PC/スマホ向き):IEEE 802.11a/11b/11g/11n/11ac/WiGig(11ad)/11ax
  3. 「長距離(1km以上)省電力」規格(IoT向き):Wi-Fi HaLow (IEEE 802.11ah)/11.af/11.ba

の3種類があります。

IoT MCUには、最新のBluetooth 5や屋外や1km半径の広い敷地内でも使える長距離省電力規格のWi-Fi HaLowが望まれるようです。

但し、普及済みのPC/スマホ向き無線LAN規格が使えると、屋内の既存PC/スマホ無線LANルータをインターネット空間へのAPに利用でき、常時電力供給も可能なため、低コストIoT MCUを実現する方法になりうると思います。


MCU:マイコン,MPU/SBC:IoT用プロセサ,Windows,PC:パソコンIoTマイコン,セキュリティ,IoT,暗号化,侵入,脆弱性,多要素承認,デジタル後進国

MCU開発中、進捗が詰まることはだれでもあります。そんな時にスタックした気分を変えるMCUセキュリティ関連話題を投稿します。

MCU開発には集中力が必要ですが、その持続は、精々数時間です。人のスタック深さは有限ですので、開発を経過時間で区切るのが1つ、別方法として集中気分を切替て開発詰まりを乗切る時の話題を示します。

気分転換が目的ですので、硬い話ではありません😁。

セキュリティ更新終了

Microsoftが、Office 2010は今年2020年10月13日、Windows 10バージョン1903は2020年12月8日にサポートを終了します。これらソフトウェアご利用中の方は、新ソフトウェアへの入替が必要です。

サポート終了とは、「セキュリティ更新プログラム配布終了」のことです。ソフトウェア自体がPCで使えなくなる訳ではありません。しかし、ハッカーなどによる新たなサイバー攻撃を防ぐ手段が無くなりますので、安全・安心な利用ができなくなります。

ところで、安全・安心の根拠、セキュリティ、セーフティ、セキュア…などの日本語は、あいまいに使われます。しかし、英語の「SecurityとSafetyは別物」です。

オンラインセミナー:STマイクロエレクトロニクスのTrustZone対応マイコンによるIoTセキュリティによると、

  • Security:外部からの危害(攻撃や改竄)から、MCU内部が保護されている状態
  • Safety:MCU誤動作や故障などが原因で、MCU外部へ衝突や爆発などの危害を与えない状態

英語でのSecurityとSafetyの使い分けは、対象がMCU内部ならSecurity、MCU外部ならSafetyと、明確な区別があります。

MCUセキュリティ関連資料を英語で読むときは、対象は単語で解ります。日本語訳資料を読むときは、対象がMCU内部か外部かを区別して理解する必要があります。

IoT機器侵入調査

総務省、IoT機器に侵入を試みる際のIDとパスワードの組み合わせを、従来の100通りから600通りに増やし、侵入できたIoT機器所有ユーザへ対策を呼び掛けた。2020年9月11日、ITmedia。

つまり、ハッカーの代わりに総務省)国立研究開発法人情報通信研究機構(NICT)が、NOTICE:National Operation Towards IoT Clean Environmentに参加しているISP 62社のIPアドレスに対して、疑似攻撃をしかけ、問題があったIPアドレスユーザへ注意を促した、ということです。

過去のサイバー攻撃にあったIDとパスワードにたまたまなっていた場合、たとえ厳重な管理であっても安全でない(!Security)訳です。IoT機器のアクセス方式、「IDとパスワード」には、限界があるかもしれません。

多要素承認

金融庁、銀行・決済各社に本人確認の徹底を要請。2020年9月16日、ITmedia。

ハッカーによるドコモ口座の不正利用が、多要素認証で防げるのかについてのセキュリティ専門家解説は、筆者には正直言って判りません。

多要素認証とは、セキュリティ情報アクセス時、スマホなどの本人しか持たないモバイルデバイスへ送った認証コードなどを使ってログインする仕組みです。「パスワードレスログイン」とも言われます。

海外ドラマでは、スマホの乗っ取りも簡単です。モバイルデバイスの2要素認証コード入力で十分なのでしょうか? スマホを持たない人は、決済サービスを利用できない、またはさらに生体認証が必要なのでしょうか?

この多要素認証をMCUへ実装する場合、どうすれば良いのでしょうか?

暗号化脆弱性

TLS 1.2とそれ以前に脆弱性、2020年9月16日、マイナビニュース。

ブラウザ経由でクレジットカード番号を送る時、通信データを暗号化し盗聴を防ぐしくみが、TLS:Transport Layer Securityです。このTLS 1.2に脆弱性が見つかり、TLS 1.3を使うなどの対策が示されています。

MCUで以前は問題無かった暗号化技術にこのような対策を実施するには、組込み済みソフトウェア、またはハードウェアの一部更新が必要です。

暗号化部品が壊れた、または脆弱性発見時、対象部品のみ交換できるMCU機器があれば良いのですが…。

デジタル後進国

“デジタル後進国”で検索すると、「日本はデジタル、IT後進国」だという記事概要が多く見つかります。

セキュリティ用語の区別もあいまいなままの日本です。先進国開発済みのMCUセキュリティ技術を、理解不足のまま流用しても当面は良いのでしょうが…、セキュリティとあいまい性、本質的に相反する気がします。
ハッカーの攻撃は、あいまい性で生じるMCUセキュリティのすきまを狙うのですから。

MCUセキュリティに関しては、何事にもあいまい性が好まれ日本不得意な「明確さ」、これが必須だと思います。

*  *  *

MCU開発時、スタック気分を変える時に役立つMCUセキュリティ関連話題を5つ投稿しました。

IDとパスワードで保護するMCUセキュリティ
IDとパスワードで保護するMCUセキュリティ

MCU:マイコン,LPCマイコン,Kinetisマイコン,Cortex-M0+コア,Cortex-M0コア,Cortex-M3コア,Cortex-M23コア,Cortex-M4コアNXP,セキュリティ,IoT,自動車,IoTエッジMCU,AI,ロボティクス,製造プロセス

6月5日投稿NXPのFreeMASTERの最後の章で紹介したNXP新CEO)カート・シーヴァーズ(Kurt Sievers)氏へのEE Times Japanインタビュー記事が16日掲載され、NXPの日本市場位置づけと事業戦略が語られました。

  • 日本の自動車関連企業との強固な関係は、一層強める
  • 日本の産業・IoT関連企業との関係は、自動車関連企業と同様、強い関係を構築していく
  • 日本のロボティクス企業とNXPのエッジコンピューティング技術の親和性は良く、ともに成長できる

本ブログの投稿は、MCUソフトウェア開発者向けが多いです。が、今回はNXPビジネスをピックアップします。というのは、多くの開発者が使っているWindows 10の今後を考えるには、Microsoftビジネスを知る必要があるのと同じ理由です。NXPビジネスを知って、MCUの将来を考えます。

以下、2020年5月のNXP semiconductors corporate overview抄訳バージョンを使います。※EE Japan記事もこのNXP資料を使っています。

NXPターゲット4市場

NXPのターゲットは、P8記載のオートモーティブ、インダストリアル&IoT、モバイル、通信インフラストラクチャの4市場です。そして、これらを包括的にサポートする半導体デジタル/アナログ技術である、Sense、Think、Connect、Act全てをNXPは提供中です。

NXPのターゲット4市場(出典:NXP semiconductors corporate overview)
NXPのターゲット4市場(出典:NXP semiconductors corporate overview)
NXPの提供する半導体デジタル/アナログ技術(出典:NXP semiconductors corporate overview)
NXPの提供する半導体デジタル/アナログ技術(出典:NXP semiconductors corporate overview)
NXPの提供するフルシステムソリューション(出典:NXP semiconductors corporate overview)
NXPの提供するフルシステムソリューション(出典:NXP semiconductors corporate overview)

NXPの強み

NXPの強みは、ユーザである我々開発者へ、半導体技術をもれなく提供できることだと筆者は思います。この分野は近い将来、セキュア/セキュリティ無しでは存在しえません。ネットワークで繋がり、セキュリティが弱い箇所が一か所でもあれば、全てが使えなくなる危険性があるからです。

例えインタフェースが確立されていても、技術同士を接続すると、上手く動作しないことはよくあります。※俗に相性問題などとWindowsでは言われます。

全技術を他社より先に提供するNXP同志の技術接続は、競合他社間の技術接続より容易、低リスクであることは明らかです。後追いの競合他社は、差別化の特徴を持たないと生き残れず、この特徴が逆に他社との接続障害になることもあります。

P12に記載されたように技術単独では存在意味が弱く、各技術がセキュアに繋がって初めてソリューションとしての市場価値が生まれます。

EE Japan Times記事によると、AI関連技術は、NXPで独自開発を行うとともにM&Aも検討中のようです。このように、選択と集中、差別化戦略ではなく全ての半導体技術を開発し、ユーザである開発者へ提供できることがNXPの強みだと思います。

エッジコンピューティングMCUの将来

PC → スマホ → MCUへとセキュリティや半導体技術をけん引してきたデバイスは変わりつつあります。

COVID-19パンデミックで経済活動が停止したのは、コロナワクチンが無いからです。半導体製品にサイバー攻撃があった時、対応ワクチンや追加のセキュリティがThink主役のMCUへ必要となります。

これらからMCUは、今後さらなるセキュリティ実装やWiFi-6などの新しい無線LAN規格への対応など、より高性能化、低消費電力化へ進むと思います。NXPは台湾TSMCの5nm製造プロセスを次世代自動車用MCUに使う(2020/6/12)ことを明らかにし、実現へ向けてスタートしています。

NXP日本市場位置づけ、事業戦略、開発者の対策

以上のNXP概要を見たうえで、最初に示した日本市場位置づけ、事業戦略を振り返ると、NXPの提供する広範囲な半導体技術を自動車、産業機器、ロボティクスへ適用していくことがより解ると思います。

我々開発者は、NXP製品の第1次利用者です。MCU開発者は、次々に導入される新しい技術を焦ることなく効率的に習得・活用し、開発製品へ応用しましょう。そして、我々の製品利用者(NXP製品の第2次利用者)へ新しい価値を提供できるよう努めましょう。

EE Japan Times記事に記載はありませんが、残念ながら日本市場の相対的地位は、低下しつつあります。また、パンデミック再来に備え、開発者個人のスキルアップや自己トレーニング重要性も再認識されたと思います。より広く・早い開発技術の習得が、MCU開発者には必要となるでしょう。

Windows 10の将来

市場に溢れるWindows 10情報は、トラブル対策のものが殆どで、MicrosoftのOSビジネス情報は見当たりません。ただ、ここ数年のWindows 10状況は、最終PC利用者の価値を高めるというよりも、Windowsブロガへの記事ネタを増やすことに役立っています。

このWindows現状を、Microsoftがどのように回復するのか知りたいです。ビジネスなので、利益なしの解はありません。しかし、安心してWindows 10が使えないなら、PCのOSは、安定感のあるiOSやLinuxへ変わるかもしれません。

アプリケーションのマルチプラットフォーム化や、WindowsアプリケーションでもiOSやLinux上でそのまま動作する環境も整いつつあります。折しも、32ビットPC OSは、2020年で終焉を迎えようとしています。ハードウェア起因ならまだしも、ソフトウェア、特にOS起因の生産性低下は、許されないと思います。

MCU:マイコン,STM32マイコン,Cortex-M0+コアテンプレート,ARMマイコン,Cortex-M0+,IoTマイコン,STM32CubeMX,汎用,ADC,IoT,TrueSTUDIO,STM32Fx,STM32G071,STM32G0x

STM32G0x専用テンプレートの開発着手にあたり、汎用STM32Fxテンプレート開発から2017年9月のテンプレート発売までをざっと振り返り、今回の専用開発との差分になりそうな箇所を示しSTM32G0x専用テンプレート開発全体像を俯瞰、力を入れる投稿予定を示します。

汎用STM32Fxテンプレート開発History

汎用STM32Fxテンプレート開発時の主な投稿と内容
年月日 投稿タイトル 主な内容
2017年5 STM32マイコンIDE構築 SW4STM32の構築
2017年6 STM32CubeMXの使い方 HAL APIの選定理由と利用法
STM32CubeMX生成ファイルのユーザ追記箇所 HAL利用時のユーザ追記箇所
2017年8 評価ボードの利用ピン指針 Baseboardとの接続指針
2017年9 STM32Fxテンプレート発売 汎用STM32Fxテンプレート発売

2017年5月当時は、4種ある無償IDEの中からマルチOS(Windows/MacOS/Linux)対応、仏/AC6社のSW4STM32を使いました。2017年末、無償IDE TrueSTUDIO提供のスウェーデン/Atollic社がSTマイクロエレクトロニクス(以下STM)に買収され、公式にはTrueSTUDIOがSTM32マイコンの純正無償IDEに昇格(!?)したようです😅。

関連投稿:STM32のStep-by-Step Guideの、気になる点1:TrueSTUDIO参照

STM32G0x専用テンプレート開発IDE:TrueSTUDIO

そこで、STM32G0x専用テンプレート開発には、TrueSTUDIO無償版(Windows/Linux対応、MacOSなし)を使います。現在SW4STM32を使っている方にも判り易いようにTrueSTUDIOとの差分を説明する予定です。

但し、筆者はSW4STM32利用中の開発者が、あえてTrueSTUDIOに変更する必要は、今のところ少ないと考えています。ソフトウェア開発の主役は、STM純正コード生成ツールSTM32CubeMXだからです。最新STM32CubeMXを使えば、IDE差は少ないと今は思っています。

勿論、TrueSTUDIOの買収昇格時点でBetterなのは当然だと思います。専用テンプレート開発を通じBetterよりもSW4STM32からTrueSTUDIOへ変更するMust条件が判れば、本ブログでお知らせします。

Tips:STMの日本語資料強化の一環なのか、TrueSTUDIOはEclipseベースIDEなのにインストーラは日本語対応、メニューも日本語になっています(下図参照)。但し、C\ユーザ名\Atollic\TrueSTUDIO for STM32 9.3.0\Manuals\Generalにある重要マニュアル5種は全て英文です。例えば、SW4STM32プロジェクトのTrueSTUDIOインポート方法や注意点は、User GuideのP75~に英文で詳しく説明されています。

日本語対応のTrueSTUDIOメニュー
日本語対応のTrueSTUDIOメニュー

STM32CubeMX:LL API(Application Programing Interface)利用

STM32G0x専用テンプレートは、汎用STM32Fxテンプレート開発で使ったHAL(Hardware Abstraction Layer)APIに変わりLL(Low Layer)APIを使います。LL利用により、STM32CubeMX生成ファイルの初期化コードやユーザ追記箇所がHALとは異なります。LL APIの利用は、専用テンプレートの肝ですので、ブログで詳しく説明します。

IoTサービス例:2.5Msps12ビットADC必須+α

汎用STM32Fxテンプレートは、Baseboardと評価ボードを接続し、基本動作完成形のBaseboardテンプレートを開発しました。STM32G0x専用テンプレートは、Arduinoコネクタに何らかのIoTサービスを示すシールドを接続する予定です。しかし、最悪の場合、汎用と同じBaseboard接続にする可能性もあります。

ただし、特に2.5Mspsの12ビットADCは、3タイプある全STM32G0xデバイスに実装済みで、IoTサービス必須機能ですので、このADCを活かしたIoTサービスは実装必須にします。その他のIoTサービスに関しては、今後決めます。

2.5Msps12ビットADC (RM0444より)
2.5Msps12ビットADC (出典:RM0444)

STM32G0x専用テンプレート発売:2019/3Q~

汎用STM32Fxテンプレートは、5か月の期間で開発しました。STM32G0x専用テンプレートは、HALよりもLL API利用難易度が高いことを考慮すると、最低でも同じ開発期間が必要だと思います。

STM32G0x専用テンプレート開発全体像俯瞰の結果

以上、STM32G0x専用テンプレート開発の全体像を俯瞰しました。
SW4STM32からTrueSTUDIO IDEへの変更必要性、STM32CubeMX のLL API利用法、全STM32G0xデバイス実装済みでIoTサービス必須機能2.5Msps12ビットADC使用法、これらを読者の方々が理解できよう力を入れて投稿記事を作成します。

MCU:マイコン,STM32マイコン,Cortex-M0+コアARMマイコン,Cortex-M0+,IoTマイコン,MCU,HAL,API,STM,IoT,STM32Fx,STM32G0x,Edge,LL

本稿は、STマイクロエレクトロニクス(以下STM)のSTM32G0xデバイス(Cortex-M0+/60MHz)が、汎用MCUのSTM32Fx(F0/Cortex-M0/48MHz、F1/Cortex-M3/72MHz)と異なり、IoT向きの新世代Edge MCUであること、そのテンプレート開発も汎用STM32Fxテンプレートと異なること、これら理由を説明します。

まとめ

はじめに内容をまとめた表1と表2、図1を示し、次章からその詳細理由を説明します。

要するに、STM32G0xデバイスのIoT Edge MCU向きの広いハードウェア性能を活かすには、LL(Low Layer)APIを利用したSTM32G0x専用Edge MCUテンプレート開発が得策だということです。

表1 STM32G0xデバイスとSTM32F0/F1デバイスのハードウェア差
デバイス名 製造プロセス コア 最大動作周波数 Edge MCU向き周辺回路
STM32G0x
デバイス
70nm Cortex-M0+ 60MHz 2.5Msps 12ビットADC、USB Type-C、暗号化処理
STM32F0/F1
デバイス
120nm Cortex-M0/M3 48/72MHz 特になし(汎用MCU)
表2 STM32G0x Edge MCUテンプレートとSTM32Fxテンプレートの違い
テンプレート名 使用API 流用性 動作確認評価ボード IoTサービス 重点ポイント
STM32G0x Edge MCU
テンプレート
LL(+HAL) 低い STM32G071RB 今後決める(TBD) STM32G0x性能発揮
STM32Fx
テンプレート
HAL 高い STM32F072RB
STM32F103RB
特になし(汎用) デバイス間移植・流用性
テンプレート開発の方向性
図1 テンプレート開発方向性。同じメインストリームMCUでもSTM32G0xデバイスは専用性、STM32Fxデバイスは汎用性重視。

STM32G0xデバイス(Cortex-M0+/60MHz)の特徴

STMの場合、新世代Edge MCUと従来MCUの最も異なる点は、製造プロセスです。STM32G0xは70nm、STM32Fxは120nmの製造プロセスです。

製造プロセスによる性能差は、Intelプロセサでお馴染みだと思います。ごく簡単に言うと、製造プロセスを小さくすると、全く同じMCUでも、動作周波数が上がり、消費電力は下がる、販売コストも下がるなど、良いこと尽くめの効果が期待できます。

さらにSTM32G0xは、Cortex-M0の電力消費を改良しCortex-M3の良さを取り入れたCortex-M0+コアを採用しています。つまり、コアと製造プロセスの両方でCortex-M0のSTM32F0デバイスを上回り、動作周波数をCortex-M3のSTM32F1デバイス72MHzに近い60MHzとしたことで、STM32F1と同程度の高性能なのに超低電力動作します。まさに新世代のIoT MCUです。

また、2.5Mspsの12ビットADC、USB Type-C、暗号化処理などEdge MCUに相応しい周辺回路を実装しています(3タイプあるデバイスで実装周辺回路を変え、低価格供給中)。

STM32G0xデバイスとSTM32F0/F1デバイスのハードウェア差をまとめたのが表1です。STM32G0x出現で、STM32F1/F0デバイスで開発する意味は、低下したとも言えるでしょう。
※但し、他デバイスへの移植性・流用性を重視した開発ならSTM32F1/F0デバイスを使い汎用STM32Fxテンプレート使う意味は依然として大きいです。

現在はSTMから何のアナウンスもありませんが、STM32G0xと同じ70nm製造プロセスでCortex-M3/≦100MHzの上位デバイスSTM32G1xが発売されれば、なおさら低下します。

関連投稿に上記特徴の出典などがあります。
関連投稿:守備範囲が広いSTM32G0
関連投稿:STM新汎用MCU STM32G0

STM32G0x専用Edge MCUテンプレートと汎用STM32Fxテンプレートの違い

STM32Fxテンプレートは、ハードウェア差を隠蔽するHAL(Hardware Abstraction Layer)APIを使い、万一性能不足などでデバイスを変える事態が生じても、同じソフトウェアを使えます。従って、STM32F0とSTM32F1の両デバイスで動作するアプリケーションが、ほんの少しの修正で素早く作成できます。

これは、HALのおかげです。HALがデバイスや周辺回路差を吸収するため、アプリケーション側は移植性の高いシンプルな記述ができるのです。その副作用として、アプリケーション記述コードは少なくてもコンパイル後のコードサイズは、周辺回路を直接制御するLL(Low Layer)に比べ大きくなります。

関連投稿:STM32CubeMXの使い方、STM32CubeMXの2種ドライバライブラリの章参照

HALを使うと言うことは、たとえデバイスが変わっても開発したソフトウェアとその労力を無駄にせず、流用・応用できることが最大のメリットです。

汎用「STM32Fxテンプレート」は、この流用・応用に適したテンプレートです。動作確認評価ボードは、STM32F072RBとSTM32F103RBのみですが、全ての汎用STM32Fxデバイスへ応用できます。勿論、ここで示したSTM32G0xデバイスにもこのHALを使う手法は適用可能です。

一方、「STM32G0x専用Edge MCUテンプレート」は、LL APIを使います。つまり、STM32G0x専用のテンプレートです。※LL APIは、使用デバイスにより異なるので専用テンプレートになります。

STM32G1xデバイスが持つCortex-M0からCortex-M3までをカバーする広い適用力と超低電力動作を活かすには、ソフトウェア開発にHAL比60~80%の高速処理のLLを使った方が得策と判断しました。

つまり、STM32G0xデバイスをEdge MCUと認め、そのSTM32G0xの性能や能力を十分に発揮する専用テンプレートがSTM32G0x専用Edge MCUテンプレートです。
※但し、流用性が高い一部機能には、HAL活用も考慮中です。LLとHALは混在可能です。

STM32G0x専用Edge MCUテンプレートと汎用STM32Fxテンプレートの違いをまとめたのが表2、テンプレート開発の方向性を示したのが図1です。

STM32G0x Edge MCU評価ボード選定

STM32G0x専用Edge MCUテンプレートの動作確認評価ボードには、Nucleo-G071RB(¥1,203)を予定しています。

前投稿で示したEdge MCUテンプレート評価ボードの3要件を再掲します。

  • R1. 低価格、入手先豊富なEdge MCU評価ボード <¥3,000
  • R2. 最新Edge MCU使用(2018年後半の新しいIoTトレンドに沿って開発されたEdge MCUであること)
  • R3. 何らかのIoTサービス例を簡単に示せる

これら3要件のうち、R3:何らかのIoTサービス例を示す要件がNucleo-G071RB 単独ではNGですが、Arduinoコネクタに何らかのIoTサービスシールドを追加することで満たす予定です。

評価ボードNucleo-G071RB
評価ボードNucleo-G071RB。64ピンパッケージでも電源供給が2本のみのなのでアートワーク担当者が喜ぶ。

※STM32G0xデバイスの評価ボードで、IoTのUSB Type-Cサービスを示すSTM32G0 Discovery Kitや、暗号化処理サービスを示すSTM32G081B-EVALは、両方ともR3要件を満たしますが、価格要件R1<¥3,000を満たさないので利用を断念しました。

RL78マイコン,MCU:マイコン,STM32マイコン,Cortex-M0+コアテンプレート,IoTマイコン,評価ボード,IoT,Edge MCU,STM32G0,STM32G071,要件,サービス,Mouser

前稿で示したEdge MCUテンプレート構想を具体化します。MCU動作だけでなく、IoTサービス例を、開発者個人が、低価格かつ簡単に示すことを目的とするこの新しい「Edge MCUテンプレート」は、弊社が従来から販売してきた「汎用MCUテンプレート」のアプローチとは少し異なります。

それは、テンプレート出力がMCU動作だけでなくIoTサービスも含めるからです。たとえEdge MCUであっても普通のデバイスです。ベンダーは、その評価ボードでEdge MCUの特性を活かしたIoTサービスを示す場合が多いです。
従って、Edge MCUテンプレートのポイントは、いかに上手くIoTサービスを示すベンダー評価ボードを選べるかに掛かっています。

本稿は、Edge MCUテンプレートに用いるEdge MCU評価ボードの3要件と、これら要件を満たす評価ボード検索方法を示します。

Edge MCUテンプレートに用いるEdge MCU評価ボードの3要件

以下3要件を、Edge MCUテンプレートに用いるEdge MCU評価ボードと考えます。

  • R1. 低価格、入手先豊富なEdge MCU評価ボード <¥3,000
  • R2. 最新Edge MCU使用(2018年後半の新しいIoTトレンドに沿って開発されたEdge MCUであること)
  • R3. 何らかのIoTサービス例を簡単に示せる

要件(Requirements)を満たさない場合は、どの項目がNGかが解れば、開発者や場合によってはOKの場合もあります。¥3,000が低価格かは懐具合次第ですし、開発年度が新しいか古いか、何らかのIoTサービスなど、全て主観です。

ただ主観であっても、Edge MCU評価ボード選択にあたりR1~R3の要件があると、採否が簡単になります。仮に、最新Edge MCUでは無いが、低価格でIoTサービスも示せる評価ボードがあった場合には、「R2_NG」だが採用するなどの特例も取れます。そこで次に、この3要件を満たすEdge MCU評価ボードを効率的に選ぶ方法を示します。

3要件を満たすEdge MCU評価ボード検索方法

最新Edge MCUで、R1~R3要件を満たすEdge MCU評価ボードを選ぶには、Mouserの新製品(メーカー別)ページが便利です。DigiKeyやチップワンストップにも同様ページがありますが、サムネイル写真と概要付きなのでMouserが最も使いやすいと思います。

Mouser新製品ページ
Mouser新製品(メーカー別)ページ。メーカーロゴクリックで集計される。カテゴリ別や週別でも選べて便利。

例えば、STマイクロエレクトロニクス(以下STM)をクリックすると、「発売日順」にサムネイルと商品名、概要が列挙されます。この中から、Edge MCUテンプレートに使えそうな評価ボードの商品詳細を読み、3要件で採否を判断すれば良いという訳です。

STマイクロエレクトロニクスの発売日順検索結果
STマイクロエレクトロニクスの発売日順検索結果。写真、製品名、概要が判る。

守備範囲が広いSTM32G0投稿で示したNucleo-G071RB(¥1,203)もこの方法で上位ページ、つまり新商品順に表示されるので、直に探せます。
※年始には1ページ目上部に示されたNucleo-G071RBが、2ページ目下部に示されました。STMは他ベンダー比、新製品が多いのにも驚かされます!
※このようにベンダー毎の新製品数、評価ボード搭載デバイスの単体価格なども簡単に分かる点がマウザー新製品ページの利点です。

NXP、サイプレス、ルネサスとベンダーを変えて上記検索をすれば、R1~R3要件を満たすEdge MCU評価ボードが簡単に見つかります。

ルネサスは投稿時3要件を満たすEdge MCU評価ボードなし

残念ながらベンダーをルネサスで検索しても、2月末時点では価格要件:R1を満たすEdge MCU評価ボードが見つかりません。

例えば、RL78ファミリのロードマップ投稿で示したRL78/G11評価ボードYQB-R5F1057A-TB(¥3,961…!)やYRPBRL78G11(¥6,437)※秋月電子でも¥4,320は、ともに¥3,000を超えます。

また、低価格がセールスポイントのRX評価ボードTarget Board for RX130/231/65NでもR1を満たしません。

つまり、ルネサスEdge MCU評価ボードは、他ベンダー比、どれも価格高めです。企業レベルでの購入なら問題ないでしょう。しかし、これら価格は、実装部品から推測しても“個人開発者は顧客として眼中に無いのでは(!?)”、とも疑われるコスパだと思います。

※東洋経済Online2月19日に、ルネサス急ブレーキのしかかる1兆円買収記事が掲載されています。ルネサスを応援したいのですが、Edge MCU評価ボード入手も含め、手を出しにくい状況です。

RL78マイコン,MCU:マイコン,LPCマイコン,Kinetisマイコン,STM32マイコン,PSoC/PRoCマイコン,Cortex-M0+コア,Cortex-M0コア,Cortex-M3コア,Cortex-M23コアテンプレート,ARMマイコン,IoTマイコン,セキュリティ,IoT,Edge MCU,トレンド,予想,産業IoT,通信事業者との連携,ウェアラブルデバイス

セキュリティ、産業IoT、通信事業者との連携、ウェアラブルデバイスという4テーマで2018年IoTドレンドとその予想結果、2019年のそれらを予想した記事がTechTarget Japanに掲載されています。

本稿はこの記事内容を、マイコン:MCU、特に本ブログ対象Edge MCU開発者の観点から読みたいと思います。

IoTサービス観点からの顧客目線記事

一言でIoTと言っても様々な観点があります。本ブログ読者は、殆どがMCU開発者なので、顧客がどのようなIoT開発を要求し、それに対して自社と顧客双方のビジネス成功をもたらす「ソリューション提供」が最も気にする点だと思います。

一方、要求を出す側の顧客は、記事記載の「IoTサービス」に注意を払います。そのサービス実現手段として、ベンダー動向やMCU開発者自身の意見を聞いてくるかもしれません。そんな時、日頃の技術動向把握結果を具体的に顧客に提示できれば、顧客案件獲得に有効なのは間違いありません。

顧客と開発者のIoT捉え方は異なる。
顧客はサービス観点でIoTを捉える。開発者はソリューション提供でIoTを捉える。

そこで、記事の4テーマ毎にEdge MCU開発者の観点、特にEdge MCU最新動向を関連投稿とともに示します。

セキュリティ

Edge MCUセキュリティ強化策として、昨年頃からMCUにセキュリティ機能を内蔵するか、または、MCU外付けに専用セキュリティチップを追加する動きが出始めました。
要するに、IoTではEdge MCUでデジタルデータ暗号化機能実装が必須になりつつあるのです。
関連投稿:守備範囲が広いSTM32G0のアクセス・ライン製品
関連投稿:IoTマイコンとセキュリティの色々なセキュリティ強化方法

産業IoT

産業機器データ収集と分析の重要性は顧客に認識されていますが、IoT導入は記事にあるように初期段階です。Edge MCUも、産業用にも流用できるメリットを示すIoT MCU新製品もありますが、車載用の新製品が多い状況です。
関連投稿:NXP新汎用MCU S32K1

通信事業者との連携

国により大きく異なる通信事業者とそのサービスや連帯を一言で表すことは困難です。ただし、日本国内でのIoTフィールドテストは、今一つ盛り上がりに欠ける感じが個人的にはします。やはり、黒船(海外発のIoT通信デファクトスタンダードとその普及)が必要かな?と思います。

ウェアラブルデバイス

Edge MCUに近距離無線通信(NFC)機能を搭載したり、AI機能(機械学習)を搭載しHuman Activity Recognition:人間活動認識を実現したりする新しいEdge MCI製品が登場しています。
関連投稿:NFCを使うLPC8N04のOTA
関連投稿:MCUのAI機能搭載

2019年2月18日速報:タイムリーなことに、Motor Fan Techという自動車関連の情報誌で、次世代ARM v8.1-Mアークテクチャが、業界最小の組み込みデバイス向けに、強力な信号処理を実現が掲載ました。次世代Cortex-Mプロセサは、機械学習(ML)パフォーマンスを最大15倍、信号処理パフォーマンスを最大5倍向上させるそうです。

IoTサービス例を顧客に示せるEdge MCUテンプレート構想

2018年3月の弊社LPC8xxテンプレートV2.5改版以降、新開発のマイコンテンプレートはありません。その理由は、記事にもあるIoTの急速な普及・変化が無かったことも1つの理由です。

これまでの弊社マイコンテンプレートの目的は、「開発者個人が低価格でMCU開発を習得すること」でした。このため、各ベンダーの汎用MCUとBaseboardを使い、そのMCU基本的動作開発までを1つの到達点としてきました。

2018年後半から新しいIoTトレンドに沿った新Edge MCUが各ベンダーから発売済みです。そこで、マイコンテンプレートも、顧客目線やその観点を取り入れた到達点へステップアップしようと思います。

顧客は単にMCUが動作するだけでなく、何かしらのサービス提供をしているIoT MCUを見たいでしょう。この「IoTサービス例を、開発者個人が、低価格かつ簡単に示せるマイコンテンプレート」が新しいEdge MCUテンプレートの構想です。

IoTサービス例を示すEdge MCUテンプレート
IoTサービス例を示すEdge MCUテンプレート

この場合の顧客とは、ビジネス顧客に限らず、開発者の上司や同僚、さらに、開発者自身でも良いと思います。開発結果がIoTサービスに関連していれば、誰でもその効果が判り易いハズです。

期待されているIoTサービスならば、開発者もMCU開発がより楽しく、その習得や応用サービスへの発展もより具体的かつアグレッシブになると思います。と言っても、クラウドを含めたIoTサービスを開発・提供するのは、個人レベルでは無理です。
従って、ほんの触り、一部分のIoTサービスになります。それでも、見る側からは、開発内容が解りやすくなります。

もはやMCUが動作するのは、当たり前です。その上で、+αとしてEdge MCUがIoTで出来るサービス例を示し、さらに、Edge MCU習得も効率的にできるのがEdge MCUテンプレートです。

今後開発するEdge MCUテンプレートは、IoTサービス指向の結果、これまでマイコンテンプレートが持っていた汎用性が少し犠牲になる可能性もあります。ただ、従来の汎用MCUの意味・位置づけもIoTで変わりつつあります。
関連投稿:RL78ファミリから解る汎用MCUの変遷
関連投稿:STM新汎用MCU STM32G0

MCU基本動作に加え、何らかのIoTサービス提供例を示す工夫をEdge MCUテンプレートへ加えるつもりです。

MCU:マイコンMCU,マイコン,IoT,市場予測,販売額,出荷数,平均価格,年平均成長率

米)市場調査会社IC InsightsのMCU市場予測記事、“マイコン市場、IoTを追い風に安定成長”が、EE Times Japanに掲載されました(2018年9月19日)。

MCU市場予測(出典:IC Insighs、EE Times Japan記事)
MCU市場予測(出典:IC Insighs、EE Times Japan記事)

2022年までの5年間世界MCU市場は、販売額は年平均成長率7.2%続伸、出荷数は年平均成長率11.1%続伸、平均価格は年平均成長率3.5%下落と予測しています。センサー普及やIoT台頭で安定成長の見込みとの結論です。

我々MCU開発者は、ますます忙しくなるでしょう (^^♪。

MCU販売額予測(Markets)

2018年販売額は、前年比11%増加で過去最高186億米ドルと見込み、2019年は9%増で204億米ドルと予測。
今後5年間、年平均成長率7.2%で続伸し、2022年は239憶米ドルと予測。

MCU出荷数予測(Units)

2018年出荷数は、前年比18%増加の306億個の見込み。
今後5年間、年平均成長率11.1%で続伸し、2022年は438億個と予測。

MCU平均価格予測(ASP)

2017年に過去最低に落ち込み、2018年も同じペースで下落するが、過去5年間の年間下落率は、その前の10年間に比べ緩やかになったと分析。
2017年から2022年は、年平均成長率3.5%で下落と予測。

※1$以下のMCU平均価格内訳を知りたいところです。下記、過去関連投稿内容ともほぼ合致しています。

関連投稿:2018年IoT市場予測
関連投稿:IoTマイコン市場規模予測