MCU:マイコン,Cortex-M0+コア,Cortex-M0コアIoTマイコン,IoTデバイス,RISC-V,エッジ端末

2021年2月19日、東工大は、ARM Cortex-M0比1.4倍、電力効率2.7倍、エネルギー効率3.8倍のIoT向き新MCU:SubRISC+を65nmプロセスで開発しました。本稿は、このIoT MCU:SubRISC+と、IoTエッジ端末ソフトウェア開発にJavaを使う手法を紹介します。

これらが何をIoTエッジ端末の開発課題にとらえ、それにどのように対処しているかを知るメリットを示します。

様々なIoT開発課題と対処方法

開発プロジェクトが始まると、数か月~数年はその対象デバイスや開発方法に、開発者は係りっきりになります。具体的なIoT開発課題や対象デバイスを深く知ることができますが、問題のとらえ方や視野が狭くなる弊害もあります。

開発と並行して競合する別のアプローチを知ると、この弊害を抑え、課題や問題を多角的、効果的に解決する手立てになります。

例えば、開発中のCOVID-19ワクチンが、変異済み、または変異が予想されるウイルスへも十分な効果が見込めれば、人類にとって役立つでしょう。このための第一歩が、変異ウイルスを知ることと同じです。

SubRISC+

IoTエッジ端末の課題を、「小型化と低消費電力性」と捉え、解を示したのが東工大のSubRISC+です。

従来のプロセサは、実務アプリケーションでは殆ど使われないムダな命令も準備されています。このムダを削減し開発されたプロセサをRISC(リスク、Reduced Instruction Set Computer)プロセサと呼びます。従来プロセサは、RISCに対してCISC(シスク、Complex Instruction Set Computer)と呼ばれます。

関連投稿:ARM MCU変化の背景

SubRISC+は、このRISC手法をIoTエッジ端末の心電図、加速度センシングなどのヘルスケアや、ウェアラブル端末アプリケーションで必須となる命令4個に適用し、CISCのARM Cortex-M0(命令60個)比、小型化省電力化を両立、条件次第ではLR44アルカリボタン電池で約100日連続稼働が可能となります。

小型マイクロプロセッサの比較(出典:東工大ニュース 2021.02.19へ加筆)
小型マイクロプロセッサの比較(出典:東工大ニュース 2021.02.19へ加筆)

なお、SubRISC+は、想定アプリケーション以外へも汎用性(チューリング完全)を持つのでIoTセキュリティ向けなどへの応用も今後目指しています。

Java利用の組込みソフトウェア開発

「C/C++を使った組込みIoTソフトウェア開発の困難さ」の課題に対して、Java開発キット(JDK)で解を示したのが、Azul System社の“IoT組み込みソフトウェア開発に、オープンソースJavaの利用が最適である理由”です。

出展:Ian Skerrett, IoT Developerへ加筆
出展:Ian Skerrett, IoT Developerへ加筆

IoTエッジ端末にもC/C++の代わりにJava利用の仮想マシン(JVM)開発を提案し、ハードウエア非依存のIoTアプリケーション開発ができること、C/C++特有のポインタ利用なし、メモリ管理不要、マルチスレッド環境の無料またはオープンソースIoT APIがあること、などの特徴があります。

結果として、IoT市場への製品投入時間短縮、組込み以外のルータ/クラウド開発者採用が可能、開発コスト削減が可能になるそうです。

他社を知るメリット

例えば、Cortex-M0よりも電力効率が良いCortex-M0+コアとLR44電池を使ってIoTエッジ端末を開発中なら、「100日連続稼働がセールスポイント」になることがSubRISC+から判ります。1個のLR44で足りないなら、複数並列で使うなどの対策も開発中にとれます。

また、IDEシミュレーションを活用し「センサセンシングの電力消費を抑える工夫」を重点的に行うと差別化に効果的など、製品改良プライオリティを付ける手掛りにもなります。

筆者はJava利用開発経験がありませんが、IoTエッジ端末開発に必要となる無線機能やセキュリティなども含めたAPIが提供され、しかもハードウエア非依存だとすると、「本来のIoTエッジ端末アプリケーションそのものに注力した開発」ができます。また、顧客対応に横展開するのも容易でしょう。

IoT市場の変化は激しく、無線やセキュリティ仕様などは、国や地域により大きく変わる可能性もあります。少しでも早く低コストでIoTエッジ端末を市場投入できれば、デファクトスタンダード製品になる可能性もあります。

東工大開発IoT MCU:SubRISC+とAzul 社IoT端末ソフトウェア開発Java利用を例に、IoTエッジ端末開発中に陥りがちな視野狭窄を防ぎ、課題を効果的、プライオリティ付けて解決するために、開発と並行して他社アプローチを知るメリットを示しました。

MCU:マイコン,STM32マイコンARMマイコン,Cortex-M0,STM32F1x,STM32F103RB,Cortex-M3,STM32F0x,STM32G0,RISC-V

1月28日、EE Times Japanに“互換チップが次々と生まれる中国、半導体業界の新たな潮流”という記事が掲載されました。スイス・ジュネーヴ本社のSTマイクロエレクトロニクス(以下STM)のSTM32互換MCUが、中国で製造プロセス縮小、ローコスト化し販売中だそうです。

STM32F030、STM32F103互換MCU

記事記載の互換デバイスは、STM32F030(Cortex-M0、64KB Flash、8KB RAM)と、STM32F103(Cortex-M3、72MHz、128KB Flash、20KB RAM)の2種。どちらもSTM純正180nmプロセス製造MCUを、130nmプロセスで製造しており、ローコスト化、低電力化、動作周波数アップが狙いです。

STM32F103搭載のNucle-F103RB評価ボード
STM32F103搭載のNucle-F103RB評価ボード

さらに、ARM Cortex-Mコア部分のみをオープン仕様RISC-Vコアへ変えた、STM32互換RISC-V MCUもあるそうです(記事、図4参照)。

記事筆者の清水氏(テカナリエ)は、これら中国製互換デバイスを否定するのが目的ではなく、現状の事実、互換製造ができる高い技術力、STM32MCUが汎用MCUデファクトスタンダードであること、中国半導体業界のこの方向性が、ますます加速する可能性があると報告しています。

日本が見習うべきもの

RISC-Vはオープン仕様ですが、Cortex互換MCU販売には、ARMライセンスフィーなど気になる事柄もあります。但し、本ブログ筆者も清水氏と同じく、その背景にある技術力、ビジネスセンスについて見習うべきものが多いと思います。

STM互換MCUは、純正品よりも安く、しかも高性能です。開発環境や評価ボード、開発ソフトウェアはそのまま互換MCUでも動作します。欧州ベンダのSTM互換MCU開発・販売は、米国ベンダ互換よりもハードルが低いでしょう。世界情勢なども反映された成功事例だと思います。

例え安く高性能な部品(BOM:Bill Of Matrix)が提供されても、それを使って開発できる技術者がいなければ製品化はできません。技術者スキルが最も伸びるのは、開発中です。中国技術者は、高性能製品を低価格で、次々と提供できている事実があります。

もちろん失敗事例もたくさんあるハズです。しかし、技術者にとっては、成功失敗を問わずどんな事例でも開発経験はスキルに直結します。

一方、日本の環境は、時短や効率化など見た目の生産性や成功例のみに注目しがちです。ただ、技術者スキルは世界レベルで評価されるので、このままの環境では、先々の日本開発案件は無くなるのではと危惧しています。

例えば自動車は、日本メーカを選択する人はいても、それが日本開発かは問題にしません。むしろ世界各地で開発されています。
※日産の先進自動運転技術(ADAS)は、米国女性技術者が中心で開発されたと、何かで読んだ記憶があります。

5G、6G世代のネット高速化、自動翻訳やAIなどの環境変化で、日本開発に拘るユーザは、減少の一途となるでしょう。

日本技術者は、次世代の自分自身のため、世界で通用するスキルを身に付ける必要があります。

弊社STM32F0/F1に使えるSTM32FxテンプレートSTM32G0xテンプレートその他ベンダのMCUテンプレートは、初心者~中級レベルソフトウェア技術者向きです。初級~中級技術を効率的に習得し、さらに高度なスキル獲得に少しでもお役立てれば幸いです。と、最後は自社広告になってしまいました😌。

MCU:マイコン,LPCマイコン,Kinetisマイコン,STM32マイコン,PSoC/PRoCマイコン,MSP432マイコン,Cortex-M0+コア,Cortex-M0コア,Cortex-M3コア,Cortex-M23コア,Cortex-M4コアアプリケーション,ARMマイコン,Cortex-M0,Cortex-M0+,IoTマイコン,Cortex-M23,RTOS,Cortex-M4,セキュリティ,ハイエンド,高速化,マルチコア化

昨今のARM MCU事情、そして今後の方向性”という記事が、2019年11月22日TechFactoryに掲載されました。詳細は記事を参照して頂き、この中で本ブログ筆者が留意しておきたい箇所を抜粋します。その結果、ARM MCU変化の背景を理解できました。

現在のARM MCUモデル

Cortex-Mコアだけでなく、周辺回路も含めた組み合わせARM MCUモデルが、端的に整理されています。

・メインストリームは、Cortex-M4コアに周辺回路搭載
・ローパワーは、Cortex-M0+に低消費電力周辺回路搭載
・ローコストは、Cortex-M0に周辺回路を絞って搭載

例えば、STマイクロエレクトロニクスの最新STM32G0xシリーズのLPUART搭載は、ローパワーモデルに一致します。各Cortex-Mコアの特徴は、コチラの投稿の5章:Cortex-M0/M0+/M3の特徴などを参照してください。

ARM MCUの新しい方向性

2019年10月時点で記事筆者:大原雄介氏が感じた今後のARM MCU方向性が、下記4項目です。

  1. ハイエンドMCU動作周波数高速化、マルチコア化
  2. RTOS普及
  3. セキュリティ対応
  4. RISC-Vとの競合

以下、各項目で本ブログ筆者が留意しておきたい箇所を抜粋します。

1.ハイエンドMCU動作周波数高速化、マルチコア化

動作周波数高速化は、NXPのi.MX RT 1170のことで、Cortex-M7が1GHzで動作。i.MX RT1170は400 MHz動作のCortex-M4も搭載しているディアルコアMCU。

これらハイエンドMCUの狙いは、性能重視の車載MCU比べ、コスト最重視の産業機器向け高度GUIやHMI:Human Machine Interface用途。従来の簡単な操作パネルから、車載のような本格的なGUIを、現状の製造プロセスで提供するには、動作周波数の高速化やマルチコア化は必然。

2.RTOS普及

普通はベアメタル開発だが、アプリケーション要件でRTOS使用となり、ポーティング例は、Amazon FreeRTOSが多い。マルチコアMCUでは、タスク間同期や通信機能実現には、ベアメタルよりもRTOS利用の方が容易。また、クラウド接続は、RTOS利用が前提となっている。

3.セキュリティ対応

PAS:Platform Security Architectureというセキュリティ要件定義があり、これが実装済みかを認証するPSA Certifiedがある。PAS Certified取得にはTrustZoneを持つATM v8-MコアCortex-M23/33が必須ではなく、Cortex-M0やM4でも取得可能。但し、全MCUで取得するかは未定で、代表的なMCUのみになる可能性あり。

4.RISC-Vとの競合

ARM CMSISからずれるCustom Instruction容認の狙いは、競合するRISC-Vコアへの対抗措置。RISC-V採用製品は、中国では既に大量にあり、2021年あたりに日本でもARMかRISC-Vかの検討が発生するかも?

ARM MCU変化背景

本ブログ対象の産業機器向けMCUの1GHz動作や、ディアルコアMCUの狙いは、ADAS(先進運転支援システム)が引っ張る車載MCU+NVIDIA社などのグラフィックボードで実現しつつある派手なGUIを、10ドル以下のBOM:Bill Of Matrixで実現するのが目的のようです。また、産業機器向のMCUのAIへの対応も気になる点です。これにら向け、各種ツールなども各ベンダから提供されつつあります。

ハイエンドMCU開発でRTOS利用が一般的になれば、下位MCUへもRTOSが利用される場面は多くなると思います。タクス分離したRTOSソフトウェア開発は、タスク自体の開発はベアメタルに比べ簡単で、移植性や再利用性も高いからです。ベアメタル開発は、RAMが少ない低コストMCUのみになるかもしれません。

RTOS MCU開発も、Windowsアプリケーション開発のようにOS知識が(無く!?)少なくても可能になるかもしれません。

MCUベンダのセキュリティ対応は、まだ明確な方針が無さそうです。RTOSと同様、IoTアプリケーション要件がポイントになるでしょう。総務省による2020年4月以降IoT機器アップデート機能義務化予定などもその要件の1つになる可能性があります。

Custom Instructionは、コチラの投稿の5章でベンダ独自のカスタム命令追加の動きとして簡単に紹介しましたが、その理由は不明でした。これが、競合RISC-Vコアへの対抗策とは、記事で初めて知りました。

本ブログ記事範囲を超えた、広い視野でのMCU記事は貴重です。

来年開発予定のベアメタルCortex-M4テンプレートへ、RTOSの同期や通信機能を簡易実装できれば、より役立ち、かつRTOS普及へも対抗できるかもしれないと考えています。クラウド接続IoT MCUは、Amazon FreeRTOSやMbed OS実装かつ専用ライブラリ利用が前提なのは、ひしひしと感じています。