RA4E1 Fast Prototype BoardのFreeRTOS使い方

RA4E1 Fast Prototype BoardへFreeRTOSを適用
RA4E1 Fast Prototype BoardへFreeRTOSを適用

RAファミリ評価ボードRA4E1 Fast Prototype Board (Cortex-M33/100MHz、Flash/512KB、RAM/128KB)(以降FPB)の、スイッチS1でLED2を点灯するFreeRTOS適用例を示します。RAファミリビギナーズガイド9章記載のEK-RA6M4評価キットを使った処理内容と同じです。

e2 studio 2021-10は、Project>Change Deviceで対象MCUデバイス変更機能がありますが動作しません。そこで、ガイド掲載のEK-RA6M4を手動でRA4E1へ変更し、FPBでFreeRTOSのセマフォを利用し、S1押下げ割込みとLED2トグル点灯を同期させるFreeRTOSサンプルコードを示します。

このコードを使い、前稿よりも具体的にFPBとFlexible Software Package(以降FSP)の使い方、今回は使わないTrustZoneのメリットを示すのが、本稿の目的です。

RA4E1 Fast Prototype Board(FPB)のRTOSとTrustZone

IoT MCUをクラウド接続するには、RTOSが必要です。AWS(Amazon Web Services )接続にはFreeRTOSライブラリ、Microsoft Azure接続にはAzure RTOSライブラリの利用が前提だからです。

また、クラウド接続には、TrustZoneなどハードウェアによるセキュリティ対策も要求されますので、RTOSとTrustZoneは、IoT MCUの必須2技術です。

ハードウエアセキュリティは、開発後、簡単に追加することが困難です。今回はTrustZone未使用ですが、IoTプロトタイプ開発にTrustZone内蔵Cortex-M33を用いるのは、例え未使用でも製品セキュリティ処理の具体的検討ができるなど、IoTセキュリティを開発初期から考慮した設計となるからです。

これが使わないTrustZoneのメリットです(TrustZone使用例も、いずれ投稿予定)。

本稿は、先ずFreeRTOSをFPBへ適用します。FreeRTOS新規プロジェクト作成、API生成ツールFSP設定、FSP生成ファイルへのタスク追記の順に説明します。

Step1:FreeRTOS新規プロジェクト作成

最新版e2 studio(2021-10)の新規FreeRTOSプロジェクトは、File>New>C/C++Projectとクリックし、①~⑥の手順で作成します。

FreeRTOS新規プロジェクト作成
FreeRTOS新規プロジェクト作成

②プロジェクト名は、任意です。③Boardは、PFB-RA4E1を選択します。

④TrustZone未使用時のプロジェクトを、“Flat”と呼びます。これは、TrustZone使用時、セキュアと非セキュアの2プロジェクト並存が必要となりメモリ領域を分割することに対する、平坦なメモリ使い方に起因していると思います。

※メモリ領域分割は、PCハードディスクのパーティション分割をイメージして頂ければ判り易いでしょう。例えサイバー攻撃を受けても、物理的に侵入できないメモリ領域を作り、ここへ最重要情報やソフトウェアを保存する訳です。

⑤FreeRTOSを選択します。ベアメタル(No RTOS)とAzure RTOSも選択可能です。⑥Minimalを選択し、FinishクリックでFreeRTOS(TrustZone未使用)新規プロジェクトが完成です。

各選択肢を変えると、前稿で説明した多種類の新規プロジェクトが作成できることが解ります。

Step2:Flexible Software Package(FSP)設定

Flexible Software Package (FSP)設定
Flexible Software Package (FSP)設定

新規プロジェクト作成のFinishクリックで、FSPパースペクティブオープンを聞いてきますので、開きます。

①プロジェクトSummaryが表示されます。Stacksタブを選択、②New Stackをクリックし、External IRQ Driver on r_icuを選択します。新しい外部割込みドライバがStackに追加され、③プロパティが表示されます。

FPBのユーザスイッチS1は、P205(IRQ1)に接続済みです。そこで、③プロパティのirq0をirq1、TriggerをFalling、Digital FilteringをEnable、Callbackをexternal_irq1_callbackに変更します。

次にセマフォ追加のため、④ObjectsのNew Objectsをクリックし、Binary Semaphoreを選択します。⑤プロパティSymbolをg_s1_semaphoreに変更します。

RA4E1 Fast Prototype BoardのSW1 P205(IRQ1)の確認
RA4E1 Fast Prototype BoardのSW1 P205(IRQ1)の確認

最後に、⑥pinsタブをクリックし、ユーザスイッチS1:P205(IRQ1)とIOピン割当てをGUIで確認します。

以上でFSP設定は完了です。Generate Project Contentをクリックすると、APIや割込みコールバック関数、関連ファイルが自動生成されます。

Step3:FSP生成ファイルへタスク追記

FreeRTOSセマフォ同期処理
FreeRTOSセマフォ同期処理

FSPが生成したファイル:led_thread_entry.cに上記コードを追加します。このコードは、LED初期化と無限ループ処理から構成されます。RAビギナーズガイド掲載のirq10をirq1へ変更したLEDタスクです。

コールバック関数external_irq1_callbackは、Developer AssistanceのLED Threadを開くと一番下に割込みコールバック関数が生成済みですので、これをドラッグ&ドロップして追加します。

LEDタスク追加後、ビルドしFSBへダウンロード、デバッガ起動後、再開を2回クリックして実行中の様子が上図です。FSBのS1クリックでLED2がトグル点灯します。

FreeRTOS Queueサンプルコード

前章は、RAファミリビギナーズガイド9章のEK-RA6M4評価キットFreeRTOSセマフォサンプルコードを、RA4E1 Fast Prototype Board(FPB)へ流用したコードです。変更箇所は、irq10をirq1へ変えただけです。

FSPには、FreeRTOS Queueサンプルコード:freertos_fpb_ra4e1_epも付属しています。これら2つのサンプルコードを理解すれば、セマフォとQueueを使う基本的なFreeRTOSソフトウェア開発が可能です。

FreeRTOS待合せ手段としては、セマフォ/Queue以外にもMutexやイベントグループなどの手段もあります。弊社ではFreeRTOS基礎固めを目的として、Hardware Independent FreeRTOS Exampleを応用したセマフォ/Queue活用のFreeRTOSテンプレート化を目指しています。RA/REテンプレートもこの方針で開発する予定です。

この方針で開発したNXP版FreeRTOSアプリケーションテンプレートは、コチラから概要がダウンロード可能です。

まとめ

RA4E1 Fast Prototype Board(FPB)へ、RAファミリビギナーズガイド掲載FreeRTOSサンプルコードを流用し、ユーザスイッチS1とLED2点灯をセマフォで同期させました。

FreeRTOS新規プロジェクト作成、Flexible Software Package(FSP)設定、FSP生成ファイルへのタスク追記の具体的操作手順を示しました。

ガイド9章には、更に詳細な説明がありますので、参考になります。例えば、スイッチ割込み優先度12を利用する理由、systick優先度15が予約済みであるなどです。

TrustZoneは未使用ですが、プロトタイプ開発初期からIoTセキュリティを考慮した設計ができるメリットがあります。

FSP付属Queueサンプルコードと本セマフォコードを使ってFreeRTOS基礎固め目的のRA/REテンプレート開発を進めます。

RA4E1 Fast Prototype Boardの使い方

前稿のRAファミリ評価ボードRA4E1 Fast Prototype Board(以降FPB)を入手、RA/REテンプレート検討に着手しました。

FPB開発に用いるルネサスIDE:e2 studio(以降e2)とAPI生成ツール:Flexible Software Package(以降FSP)は、NXPやSTマイクロなどのEclipseベースIDEの利用者が?に思う箇所があると思います。

ルネサスIDE:CS+ユーザでも、同様にこの?を感じると思いますので、対策と評価ボードFPBの使い方を示します。

RA4E1 Fast Prototype Boardとe2 studio
RA4E1 Fast Prototype Boardとe2 studio

e² studio

Eclipse IDEをベースとしたRAファミリ統合開発環境:IDEが、e2、API生成ツールが、FSPです。

e2は、ARMコアを含む全てのルネサスMCU開発用の新世代IDEで、古くからあるRL78ファミリやRXファミリなどのルネサス独自コア専用統合開発環境CS+の後継IDEとして登場しました。但し、CS+は、現在でもRL78/RXファミリ開発に使えます。

e2は、MCUファミリ毎にコンパイラを切替えることにより、全ルネサスMCUの共通IDEとして動作します。MCUファミリのコンパイラは、普通1種類です。ところが、RAファミリには、GNUとARM Compiler V6の2種類が用意されており、どちらも無償です。

GNUとARM Compiler V6?

e2インストール時、デフォルトでインストールされるコンパイラは、GNUです。ARM Compiler V6は、後から追加インストールが必要です。最初の?は、両コンパイラの“違いは何か”です。

次章で示すFSPやTrustZone利用に差が生じるのであれば、問題です。

ルネサス資料を探しましたが、結局、コンパイラ差は分かりません。最近では殆ど行わないアセンブラデバッグが無ければ、コンパイラはどちらでも構いませんので、デフォルトGNUで当面はOKとします。

Flexible Software Package (FSP)?

RAファミリ専用のAPI生成ツールが、FSPです。動画:Generating Your First RA FSP Project(8:25)で使い方が分かります。

Flexible Software Package構成
Flexible Software Package構成

簡単に説明すると、スタックと呼ぶ開発プロジェクトで使用するHALドライバやRTOSなどのミドルウェアパタメタをGUIで設定後、e2のGenerate Project Contentをクリックすると、Developer Assistance内に全てのAPIが自動生成され、その中から使用するAPIを、ユーザ自身でソースコード任意場所にドラッグ&ドロップする使い方です。

ソースコード任意場所にAPIを配置できるのは、親切とは言えません。NXPやSTマイクロのコード生成ツールでも、API追加箇所にコメント付きのソースコードが生成されます。しかし、FSPは、ソースコード上のどこにでもAPIを設置できます。

API使用順序、設置場所、パラメタの意味が予め解ってないと、適切なコーディングは困難でしょう。後述する多くの公式サンプルコード(スタック利用例)がありますので、これらを参考に習得する必要があります。

hal_entry.c?

e2 studioのra_genとsrcフォルダ
e2 studioのra_genとsrcフォルダ

Generate Project Contentのクリックで生成されるのがAPI本体、つまり、ra_genフォルダ内のmain.cを含むスタックのドライバ関数群です。ra_genフォルダは、FSPが生成するコードの格納場所です。

これらとは別のsrcフォルダ内に見慣れないhal_entry.cファイルがあります。srcフォルダは、ユーザが追加するコードの格納場所です。

FPB出荷時にインストール済みのquickstart_fpb_ra4e1_epプロジェクトを読むと、main.c→hal_entry.c→user_main.cとコールされ、結局、user_main.cに一般的なIDEでユーザが追記する初期設定と無限ループを記述するのが、FSPでのユーザソースコード記述作法のようです。

※一般的なIDEでユーザが追記する初期設定と無限ループについては、基本のキ3章まとめを参照してください。

quickstart_fpb_ra4e1_epのuser_main処理
quickstart_fpb_ra4e1_epのuser_main処理

readme.txt?

公式サンプルコードをe2へインポート後、readme.txtでサンプル動作内容やFPB追加配線の必要性が分かります。バグだと思いますがe2(2021-07)は、サンプルコード付属readme.txtがプロジェクト内へインポートされません。

筆者は、手動でインポートしました。例えば、sci_uart_fpb_ra4e1_epプロジェクトは、追加配線無しではTera Term動作確認ができませんので、readme.txtを読み、追加配線が必須です。

RA4E1 Fast Prototype Board(FPB)の使い方

IoT MCUの機能と消費電力を最適化したRAファミリのRA4E1グループ評価ボード:RA4E1 Fast Prototype Board(FPB)の特徴は、以下2点です。

  • TrustZone
  • 低電力動作(Sleep > Snooze > Software Standby > Deep Software Standby)
RA4E1ブロック図
RA4E1ブロック図

TrustZoneの使い方は、RAファミリビギナーズガイドの11章が参考になります。

FreeRTOS利用を含むサンプルコードはコチラ、低電力動作サンプルコードはコチラからダウンロードできます。前章のquickstart_fpb_ra4e1_epやsci_uart_fpb_ra4e1_epプロジェクトは、初めのサンプルコード内にあります。

RTOSは、IoT接続先クラウドに応じてFreeRTOSかAzure RTOSの2種から選択可能です。また、通常の低電力動作:Sleepに加え、SnoozeやDeep Software Standbyなど超低電力動作モードも備えています。

プロジェクトは、ベアメタルまたはRTOS、TrustZone利用または非利用、の各選択肢がありますので4種類、FreeRTOSかAzureの選択を加えると、合計6種類の新規プロジェクト作成方法が可能です。

つまり、IoT MCUエッジ開発で必要となる様々なプロジェクト開発に、FPBだけで対応可能です。応用範囲の広い評価ボードで、IoTプロトタイプ開発に適しています。サンプルコード内容も豊富です。

まとめ

ユーザ視点からのベンダ各社がEclipse IDEをベースIDEに使うメリットは、IDEインタフェースがEclipseに似てくるので、ベンダが変わっても同じIDE操作性が得られることです。各社IDEで異なる部分は、周辺回路設定やAPI/コード自動生成の部分に限られるのが一般的です。

これら部分に加え、RAファミリ開発に使うe2 studioとFlexible Software Package は、無償コンパイラ選択、生成APIのソース追加方法、hal_entry.cなど、一般的なEclipseベースIDE利用者にとって?が生じる箇所が多数ありました。

ルネサス資料は多いのですが、肝心の?ポイントが解りにくいとも感じました。RAファミリ開発着手時は、これらに対し慣れが必要かもしれません。そこで、備忘録として本稿を作成しました。

なお、同じく前稿で示したREファミリについては、非常に良くまとまったREマイコンの使い方がルネサスサイトより入手できます。

RA4E1 Fast Prototype Board(Cortex-M33/100MHz、Flash/512KB、RAM/128KB)は、低価格で入手性もよくTrustZoneやRTOS、低電力動作など、幅広い知識や技術が要求されるIoT MCU開発の素材として優れています

現状RAファミリ資料の纏まりは、REファミリと比べると今一歩ですが、改善されると思います。開発に必要となる技術レベルが少し高いのですが、e2 studioとFlexible Software Package (FSP)、RA4E1 Fast Prototype Board(FPB)と豊富なサンプルコードを使ったIoT MCU開発は、好奇心を満たすIoT MCU習得へ向けたお勧めの開発環境と評価ボードと言えるでしょう。

弊社ブログは、RA/REテンプレート開発を目指し、継続して関連情報を投稿します。

Windows 11アップグレード可能通知:FYI

Windows 11を実行できます
Windows 11を実行できます

10月5日リリースWindows 11アップグレード可能通知が弊社PCへ届きました。今月リリースWindows 10 21H2で運用し、1年程度の11評価結果を見てアップグレードを予定しております。ご参考まで。

IoVとIoT

IoV:Internet of VehiclesやV2X:Vehicles-to-Everything通信により、車載半導体チップとソフトウェア需要が指数関数的に増加、ユーザの自動車選択基準が、エンジンなどのメカから車載ソフトウェアへ移行しつつある、という記事がEE Timesに記載されました。

これらIoV状況が、IoTへ与える影響について考えてみました。

IoVとIoT

IoVでユーザ選択基準が車載ソフトウェアへ変化
IoVでユーザ選択基準が車載ソフトウェアへ変化

車のカタログから、エンジン特性や足回りのメカ説明が消え、スマホ連動性や運転支援など車載ソフトウェアによるサービスの説明に変ったのはここ数年です。記事によると、車の新しいユーザ選択基準になりつつあるカーエレクトロニクスが、半導体業界にとってはスマホ以来の最大チャンスだそうです。

また、「CASE」で車載半導体はどう変わるのか(2021年9月15日、EE Times Japan)でも、自動運転と電動化が今後の車載半導体動向を左右すると結論付けています。
※CASE:Connected(通信機能)、Autonomous(自動運転)、Shared&Services(共有化/サービス化)、Electric(電動化)

年々向上するユーザのソフトウェア指向を満たす車載IoV業界、COVID-19の影響で停滞気味の民生IoT業界とは雲泥の差です。

車載半導体需要予測は初めの記事数値を参照して頂くとして、両記事のポイントは、ソフトウェア差別化や付加価値追加には、カスタムチップまたは、IP(Intellectual Property)などの組込みハードウェアが効果的という点です。これらIPには、セキュリティやエッジAIなどIoTへ流用できるものが数多くあります。

従って、IoVは、結果としてIoTも牽引すると思います。

但し、世界的半導体不足が続く状況では、優先度、調達コスト、多くの数量が確実に見込めるIoVが優勢、IoTはこの影響で、しばらくチップ供給不足や停滞が続くでしょう。

停滞気味のIoT側開発者として今できることは、IoV同様、IoTソフトウェア差別化に備えることだと思います。

IoT MCUのTrustZone、SOTB

IoTの観点から、IoTソフトウェア差別化や付加価値追加のための組込みIPと言えば、ARM TrustZone内蔵Cortex-M33コア、ルネサスの新製造プロセスSOTB:Silicon On Thin Buried Oxideなどが相当します。

アクティブ消費電力とスリープ消費電力両方を減らせるSOTBプロセス(出典:ルネサスサイト)
アクティブ消費電力とスリープ消費電力両方を減らせるSOTBプロセス(出典:ルネサスサイト)

例えば、TrustZoneが、高いセキュリティ効果を発揮するのはご存知の通りですし、SOTB製Cortex-M0+搭載ルネサスREファミリは、超低スタンバイ電流により太陽光発電環境などのエナジーハーベストでも電池交換不要を実現するなどです。

SOTBは、超低消費電力動作と高速動作を両立する革新的製造プロセスです。全てのルネサスMCUへ採用すれば強力な差別化技術になると思いますが、今のところ出し惜しみなのか(!?)戦略的なのか、REファミリにのみ採用中です。

一見、ASSP:Application Specific Standard Produceのようですが、これら差別化技術は、汎用MCUに採用された時に最も効果を発揮します。

従来のエッジMCUでの単純なアナログデジタル変換に加え、セキュリティや超低電力動作などのIoT化に伴う付加機能がIoT MCUには必須です。IoT付加機能内蔵MCUが、汎用IoT MCUになります。

IoT開発者は、これらIoT付加技術を今のうちに習得しておくことが必要です。

IoVとIoTの最も大きな差は、車載と民生半導体の電源仕様でしょう。IoVは、EV(Electric Vehicle)のモータ高出力要求に伴いバッテリーが12V供給から48Vへ高電圧化しつつあり、万一の耐圧やフェイルセーフが求められます。IoTは、低電圧(≦3.3V)電源で低圧化しつつあります。

RA/REテンプレート構想

残念ながらSOTB製REファミリ評価ボードは、まだ値段が高く、個人レベルでは手が出しにくい状況です。そこで、SOTBプロセスではありませんが、REファミリとソフトウェア互換性があると思われるCortex-M33コア搭載ルネサスRAファミリを、弊社テンプレート対象にと考えています。

RAファミリは、TrustZoneでIoTセキュリティへ対応しています。また、9月22日発売のRAファミリRA4E1グループの評価ボード:RA4E1 Fast Prototype Boardは、20米ドル台と低価格です。ルネサス独自コアではないため、コンパイラFlash容量制限もありません。

FPB-RA4E1 Fast Prototyping Board(出典:クイックスタートガイド)
FPB-RA4E1 Fast Prototyping Board(出典:クイックスタートガイド)

RL78/G1xテンプレートから新しいルネサスMCUをテンプレート対象に出来なかった理由の1つが、この容量制限です。ARMコア他社同様、GNUまたはARM Compiler V6が、e2 studioでRAファミリ開発に無償で使えます。

今のところRAテンプレートは、REへも使えると考えています。ARMコア差は、CMSIS:Cortex Microcontroller System Interface Standard やHAL:Hardware Abstraction Layerで吸収できるハズだからです。

ADC、SW、LED、UART(VCOM)などのIoT MCU基本動作をRA/REテンプレート共通部分でサポートし、TrustZoneや超低電力動作などRA/RE特徴を活かす部分は、共通部分へ特徴サンプルコードを追加する方法で実現できれば嬉しいと考えています。構想段階ですが、詳細は今後投稿します。

STM32CubeIDE/MX Major Release

2021年7月19日、STマイクロエレクトロニクスのMCU統合開発環境が、STM32CubeIDE v1.7.0とSTM32CubeMX v6.3.0へ更新されました。Major releaseです。開発済みMCUのSTM32CubeMX設定を、簡単に別ターゲットMCUへ移植する機能を解説します。

Major Release

STM32CubeIDE(以下、CubeIDE)は、ベースのEclipse IDE 更新に追随し年数回更新があります。今回のCubeIDE v1.7.0更新内容に、特に気になる点はありません。

一方CubeIDE付属コード生成ツール:STM32CubeMX v6.3.0(以下、CubeMX)には、開発済みMCUのCubeMX設定を、別MCUや別シリーズMCUへ簡単に移植する機能があります。移植性の高いHAL(Hardware Abstraction Layer)APIと併用すると、開発済みソフトウェアの再利用が簡単で強力なAPI生成ツールになりました。

STM32CubeMX設定移植機能

CubeMXには詳細な英語ユーザマニュアルUM1718 Rev35(全368ページ)があり、p1に主要機能説明があります。本ブログでもCubeMXコード生成機能の使い方やその重要性、STM32F0からF1へのソフトウェア移植方法などを何度か紹介してきました(検索窓に「STM32CubeMX」と入力すると関連投稿がピックアップされます)。

従来投稿は、MCUのCubeMX設定を、ターゲットMCUへ各項目を見ながら手動移植する方法でした。この方法は、予めターゲットMCUとの互換性が解っている場合や、移植周辺回路が少ない場合には有効です。

しかし、MCUの種類が増え、別シリーズMCUへ、または多くの周辺回路設定を個別に移植したい場合は、事前チェックは面倒です。そんな時に役立つ2機能が、UM1718 p1太文字記載の下記です。

  • Easy switching to another microcontroller
  • Easy exporting of current configuration to a compatible MCU

どちらもCubeMX画面のPinout & Configurationタブ選択、Pinoutプルダウンメニュー>List Pinout Compatible MCUs (Alt-L)をクリックすると、Full Compatible/Need Hardware change MCUが一覧表で表示されます。

List pinout compatible MCUs
List pinout compatible MCUs

STM32G0xテンプレート例

販売中STM32G0xテンプレートで使用中の汎用MCU:STM32G071RB(Cortex-M0+/64MHz、Flash/128KB、RAM/36KB)の例を示します。これは、評価ボードNUCLEO-G071RB搭載MCUです。

STM32G071RB Full and Partial match MCU List
STM32G071RB Full and Partial match MCU List

評価ボード搭載のLQFP64パッケージでフィルタ設定すると、青色:完全互換の汎用STM32G0シリーズMCUが12アイテム、黄色:一部ハードウェア変更が必要な低電力STM32L0シリーズMCUが17アイテムリストアップされます。

例えば、FlashやRAMを増量したい場合には、STM32G0B1RBへ開発ソフトウェアがそのまま移植できることが解ります。また、より低電力化したい場合には、STM32L071RBへも移植可能です。あとは、ターゲットMCUを選択し、STM32G0xテンプレートのCubeMXプロジェクト設定を全て移植するか、または一部周辺回路のみを移植するかの選択も可能です。

つまり、開発済みソフトウェアを別MCUへ移植する際に、容易性(完全互換/一部HW変更)と方向性(大容量化/低電力化など他MCUシリーズ適用)を評価でき、かつ、ターゲットMCU選択後は、ダイアログに従って操作すれば、CubeMX設定全て、または周辺回路毎にターゲットMCUへ自動移植ができる訳です。

CubeMX設定の移植後は、ターゲットMCU上で通常のようにコード生成を実行すれば、周辺回路初期設定や動作に必要となる関数群の枠組みが作成されます。その枠組みへ、STM32G0xテンプレートのHAL API開発済みソフトウェアをコピー&ペーストし、ターゲットMCUへのソフトウェア移植が完了です。

汎用MCUとHAL APIプロトタイプ開発

最新メインストリーム(汎用)プロトタイプ開発イメージ
最新メインストリーム(汎用)プロトタイプ開発イメージ

CubeMX設定の自動移植が簡単なことは、前章まででご理解頂けたと思います。

前例STM32G0xテンプレート開発ソフトウェアの移植可能なMCU数が12+17=29と大きいのは、汎用MCUとHAL APIを使ったソフトウェア資産だからです。

最新IoT MCU開発でも、STM32G0/G4シリーズなどの移植性が高い汎用MCU(=メインストリームMCU)とHAL APIを使って主要機能をプロトタイプ開発し、CubeMX移植機能を使ってターゲットIoT MCUへ移植すれば、最新IoT MCUの差分機能開発に集中できます。

つまり、「汎用MCUとHAL API利用のプロトタイプ開発は、他MCUへの移植性が高く、汎用との差分開発に集中できる高い生産性」をもたらす訳です。

※STM32G0/G4シリーズは、新プロセスで従来汎用STM32F0/F1/F3シリーズを高速・低電力化・セキュリティ強化した新しい汎用MCUです。コチラの関連投稿や、STM32U5発表と最新IoT MCU動向を参照してください。

STM32G0とG4のセキュリティ対応(出展:STM32 Security対応表に加筆)
STM32G0とG4のセキュリティ対応(出展:STM32 Security対応表に加筆)

まとめ

STマイクロMCU統合開発環境が、STM32CubeIDE v1.7.0とSTM32CubeMX v6.3.0へMajor Releaseされました。

開発済みMCUのCubeMX設定を、別MCUへ簡単に移植する機能があり、移植性が高い汎用(メインストリーム)MCUとHAL APIによるプロトタイプ開発ソフトウェア資産を、効率的に他MCUへ再活用できる統合開発環境になりました。

補足:NUCLEO評価ボードのユーザLED不足対策

汎用MCUとHAL APIプロトタイプ開発には、低価格で入手性も良いNUCLEO評価ボードが適しています。

但し、NUCLEO評価ボードのユーザ緑LED(LD2)とSW(B1)が、各1個と少ない点が残念です。CubeIDEサンプルプログラムは、単機能サンプル動作なので各1個でもOKですが、少し複雑な例えばRTOS並列動作確認などには、特にLEDが不足します。

お勧めは、赤LED 2個、SW 1個が実装済みのArduinoプロトタイプシールドです。残念ながらNUCLEO評価ボードSW(B1)は操作できないのでシールドSWで代用します。評価ボードArduinoピンとの配線や、付属ブレッドボードへの回路追加も簡単です。ST以外の様々なMCUベンダのArduinoコネクタ付き評価ボードでも使えます。

NUCLEO評価ボードLED不足対策のArduinoプロトタイプシールド。付属ブレッドボードに回路追加も容易。
NUCLEO評価ボードLED不足対策のArduinoプロトタイプシールド。付属ブレッドボードに回路追加も容易。

NUCLEO-G474REとArduinoプロトタイプシールドの使用例を示します。ArduinoプロトタイプシールドのLED1は、Lpuart受信、LED2は、SW操作、評価ボードのLD2は、1s/500ms/40ms点滅の動作確認に使っています。

STM版RTOSアプリケーションテンプレート構想もこの環境で検討中です(関連投稿:STM32RTOS開発3注意点(前編)、(後編))。

組込みMCU開発お勧めブログ

組込み開発全般に参考となる英語ブログを紹介します。特にRTOS関連記事は、内容が濃く纏まっていて、実践開発時の示唆に富んでいます。

JACOB's Blog
JACOB’s Blog

RTOSカテゴリー

組込み開発コンサルティングも行うBeningo Embedded社は、高信頼の組込みシステム構築と低コスト・短時間での製品市場投入を目標としています。この目標に沿って、複雑な組込み開発概念を、シンプルに解り易く解説しているのが、同社ブログです。

特に、RTOSカテゴリーは、FreeRTOS開発方法を整理する時、参考になります。最新RTOSの3投稿をリストアップしたのが下記です。

2021年5月4日、A Simple, Scalable RTOS Initialization Design Pattern
2020年11月19日、3 Common Challenges Facing RTOS Application Developers
2020年10月29日、5 Tips for Developing an RTOS Application Software Architecture

Data flow diagram for a smart thermostat(出展:JACOB'S Blog)
Data flow diagram for a smart thermostat(出展:JACOB’S Blog)

開発中の弊社FreeRTOSアプリケーションテンプレートは、「ベアメタル開発経験者が、FreeRTOS基礎固めと、基本的FreeRTOSアプリケーション着手時のテンプレートに使えること」が目的です。従って、必ずしも上記お勧めブログ指針に沿ったものではなく、むしろ、ベアメタル開発者視点でFreeRTOSを説明しています。

弊社テンプレートを活用し、FreeRTOSを理解・習得した後には、より実践的なRTOS開発者視点で効率的にアプリケーションを開発したいと思う方もいるでしょう。もちろん、弊社FreeRTOSアプリケーションテンプレートからスタートすることを弊社は推薦しています。

しかし、Windows上でアプリケーション開発する時は、初めからWindows作法やGUIを前提として着手するように、RTOS上でMCUアプリケーションを開発する時も、従来のベアメタル開発に固執せず、RTOSオリエンテッドな手法で着手するのも1方法です(ベアメタル経験が少ないWindows/Linux世代には、親和性が高い方法かもしれません)。

推薦ブログは、この要望を満たすRTOS手法が豊富に掲載されています。

また、上記RTOS関連3ブログを(掲載図を「見るだけでも良い」ので)読んで、ピンとこなければ、RTOS理解不足であると自己判断、つまり、リトマス試験紙としても活用できます。

問題整理と再構築能力

ベアメタル開発経験者が、RTOSを使ってMCUアプリケーション開発をするには、従来のBareMetal/Serial or Sequential動作からRTOS/Parallel動作へ、考え方を変えなければなりません。弊社FreeRTOSアプリケーションテンプレートは、この考え方を変えるための橋渡しに最適なツールです。

橋を渡りきった場所が、RTOSの世界です。RTOS環境での組込み開発問題を整理し、シンプルに解決策を示すには、知識や経験だけでなく、問題再構築能力が必要です。JACOB’S Blogをご覧ください。RTOSに限らず組込み関連全般の卓越した問題再構築能力は、掲載図を見るだけでも良く解りますよ😄。

半導体不足とMCU開発案

3月26日投稿で危惧した半導体供給不足が深刻化しており、MCU開発者へも影響が出始めています。コチラの記事が、具体的な数字で深刻さを表していますので抜粋し、MCU開発者個人としての対策私案を示します。

半導体不足の深刻さ

今回の半導体不足は、通常時に比べ2倍以上のリードタイム増加となって現れています。

通常時と現在(半導体不足時)のリードタイム比較
発注から納品までのリードタイム 通常 現在
MCU、ワイヤレスチップ、パワーIC、Audio Codec、

パワーモジュール、GPUチップ

8~12週 24~52
ロジックIC、アナログIC、ASIC、電源用MOSFET、受動部品 8~12週 20~24週
LCDパネル 6~8週 16~20週
CPU 8週 12~20週
メモリ、SSD 6~8週 14~15週
PCB(基板)製造 2~4週 8~12週

記事によると、特にMCUとワイヤレスチップのリードタイムが長くなっており、52週!ものもあるそうです。

表記した第1行目の部品で半導体不足が語られることが多いのですが、PCB(基板)製造へも影響しているのは、MCU/ワイヤレスチップ供給不足により、基板作り直しが生じるため、またロジックIC以下の部品も同様に製品再設計の影響と推測します。

MCU、ワイヤレスチップの供給不足がリードタイム激増の主因、それ以外の部品リードタイム増加は、主因の影響を受けた結果と言えるでしょう。

半導体供給の意味

日本では半導体は、別名「産業のコメ」と言われます。世界的には、「戦略物資」という位置付けです。半導体で米中が対立するのは、政治体制だけでなく、近い将来の経済世界地図を大きく変える可能性があるからです。

半導体製造は、国際分業化が進んできましたが、今回の半導体不足の対策として、国や企業レベルでは全て自国や自社で製造を賄う動きもでてきました。持続的経済成長には、食糧と同じように半導体の自給自足が必須だということです。

MCU開発対策案

MCU開発者個人レベルでの半導体不足対策は何か、というのが本稿の主題です。

MCU開発者は、半導体を使った顧客要求の製品化が目的です。半導体不足の対策は、「代替MCUの開発能力と製品化方法の見直し」だと思います。例えると、COVID-19収束のため、複数ワクチンの中から入手しやすいものを利用するのと同じと言えば解っていただけるかもしれません。目的と手段を分けるのです。

製品化方法の見直しとは、評価ボード活用のプロトタイプ開発により製品完成度を上げ、最終製品化直前まで制御系の載せ替えを可能とすることです。CADやIDE消費電力シミュレーションなどを活用し、プロトタイプの製品完成度を上げます。

製品完成度を上げる段階で、更なるMCU能力の必要性や低消費電力性などが判明することも多々あります。載せ替え可能な制御系でこれら要求に対応します。プロトタイプ開発着手時に、候補となる複数ベンダのMCU評価ボードを事前準備しておくのも得策です。

MCU評価ボード載せ替えプロトタイプ開発案
MCU評価ボード載せ替えプロトタイプ開発案

現在も様々なMCU新製品が発表されています。評価ボードは、これら新MCUの販売促進ツールですので、個人でも比較的安く、早く調達できます。また、ワイヤレスチップ搭載済みでArduinoなどの標準インターフェースを持つ評価ボードならば、この標準インターフェースで独自開発ハードウェアと分離した製品設計ができるので、制御系を丸ごと別ベンダの評価ボードへ載せ替えるのも容易です。

つまり、第2 MCU開発能力と評価ボードを標準制御系とし、自社追加ハードウェアと分離したプロトタイプ開発により、第1 MCU供給不足と顧客製品化の遅れを少なくすることができます。標準インターフェース分離により、PCBを含めた自社追加ハードウェア開発部分の作り直しは無くすことも可能です。少なくとも、1章で示した半導体不足主因(MCUやワイヤレスチップの不足)に対して対処できます。

複数ベンダのMCU開発を経験すると、ソフトウェアやハードウェアの作り方も変わります。

ソフトウェア担当者は、万一のMCU載せ替えに備え、共通部分と個別部分を意識してソフトウェア化するようになります。ハードウェア担当者は、自社追加ハードウェアの単体試験をソフトウェア担当者に頼らずテストプログラム(TP)で自ら行うようになり、次第にソフトウェア開発能力も身に付きます。

このプロトタイプ開発の最終製品化時は、制御系評価ボードの必須部品のみを小さくPCB化するなどが考えられます。制御系は、他の部分に比べ故障率が高く、制御系のみを載せ替え可能な製品構成にしておけば、故障停止時間の短縮も図れます。

MCU評価ボードの制御系のみを小さくPCB化するイメージ(出展:マルツ超小型なRaspberry Pi)
MCU評価ボードの制御系のみを小さくPCB化するイメージ(出展:マルツ超小型なRaspberry Pi)

最新MCU情報

上記プロトタイプ開発でも通常時は、第1 MCUで開発完了でしょう。実際に第2 MCU制御系へ載せ替えるのは、半導体供給リスクに対する最後の手段です。そこで、最新MCU情報をピックアップし、第2 MCUを選ぶ参考にします。

・2021年3月31日、ARMv9発表

Cortex-M33などのセキュリティ強化コアARMv8発表から約10年ぶりに機械学習やデジタル信号処理能力強化の最新コアARMv9をARMが発表。MCUベンダ評価ボードはこれから。

・2021年4月6日、STマイクロエレクトロニクスSTM32G0で動作するエッジAI

AIによる推論だけでなく学習も行えCortex-M0+コアでも動作する新アルゴリズムMST:Memory Saving Tree搭載のSTM32G0により既存機器のエッジAI実現可能性が拡大。販売中の弊社STM32G0xテンプレートは、コチラを参照。

・2021年4月15日、MCUXpresso54114の150MHz動作:

開発中のFreeRTOSアプリケーションテンプレートで使うMUCXpresso54114評価ボード搭載のCortex-M4コア最高動作周波数は、旧データシートでは100MHzでした。しかし、MCUXpresso SDKベアメタルサンプルプログラム診ると、追加ハードウェア無しで1.5倍の150MHz動作例が多いのに気が付きます。

LPCXpresso54114の150MHz動作
LPCXpresso54114の150MHz動作

動作クロックを上げるのは、MCU処理能力を上げる最も簡単な方法です。そこで、最新データシートRev2.6(2020年9月更新)を確認したところ、Maximum CPU frequencyが100MHzから150MHzへ変更されていました(Table 44. Revision History)。

データシートも最新情報をチェックする必要がありました。製造プロセスが新しいMCUXpresso54114やSTM32G4(170MHz)などの最新Cortex-M4コアMCUは、どれも150MHz程度の実力を持つのかもしれません。

STM32U5発表と最新IoT MCU動向

STマイクロエレクトロニクス2021年2月25日発表の先端性能と超低消費電力動作両立のSTM32U5を紹介し、STのIoT MCU開発動向をセキュリティ、MCUコア、製造プロセスの観点から分析しました。

先端性能と超低消費電力動作のSTM32U5

STM32U5ベンチマーク(出典:公式ブログ)
STM32U5ベンチマーク(出典:公式ブログ)

公式ブログから抜粋したSTM32U5のベンチマークです。従来の超低消費電力MCU:STM32L0~L4+シリーズと、Cortex-M33コア搭載STM32L5、今回発表のSTM32U5をメモリサイズとパフォーマンスで比較しています。

STM32U5は、従来Cortex-M0+/M3/M4比、Cortex-M33搭載により後述のセキュリティ先端性能と、従来Cortex-M33搭載STM32L5比、230DMIPS/160MHzと大幅向上した超低消費電力動作の両立が判ります。STM32U5の詳細はリンク先を参照ください。

本稿はこの最新STM32U5情報を基に、STのIoT MCU開発動向を、セキュリティ、MCUコア、製造プロセスの3つの観点から分析します。

セキュリティ

STM32マイコンセキュリティ機能一覧(出典:ウェビナー資料)
STM32マイコンセキュリティ機能一覧(出典:ウェビナー資料)

昨年10月27日ウェビナー資料:ARM TrustZone対応マイコンによるIoTセキュリティのP17に示されたSTM32マイコンセキュリティ機能一覧です。セキュリティ先端性能のTrustZoneは、Cortex-M33コアに実装されています。

関連投稿:Cortex-M33とCortex-M0+/M4の差分

今回の超低消費電力STM32U5発表前なのでSTM32L5のみ掲載されていますが、STM32U5もL5と同じセキュリティ機能です。STM32WLは、後述するワイヤレス(LoRaWAN対応)機能強化MCUです。

この表から、後述する最新メインストリーム(汎用)STM32G0/G4も、STM32U5/L5と同じセキュリティ機能を実装済みで、STM32U5との差分はTrustZone、PKA、RSSなど一部であることも判ります。

STM32U5のSTM32L5比大幅に動作周波数向上と低消費電力化が進んだ背景は、セキュリティ機能に対するより高い処理能力と40nm製造プロセスにあることが2月25日発表内容から判ります。

STM32ファミリMCUコア

STM32ファミリMCUコア(出典:STサイトに加筆)
STM32ファミリMCUコア(出典:STサイトに加筆)

STM32ファミリMCUコアは、ハイパフォーマンス/メインストリーム(汎用)/超低消費電力/ワイヤレスの4つにカテゴライズされます。前章のSTM32WLがワイヤレス、STM32U5/L5は超低消費電力です(STM32U5は加筆)。

STM32WLとSTM32WBの詳細は、コチラの関連投稿をご覧ください。

STM32U5と同様、従来の120nmから70nmへ製造プロセスを微細化して性能向上した最新メインストリームが、STM32G0/G4です。

新しいSTM32G0/G4は、従来汎用STM32F0/F1/F3とソフトウェア互換性があり、設計年が新しいにも係わらずデバイス価格は同程度です。従来メインストリームのより高い処理能力と低電力動作の顧客ニーズが反映された結果が、最新メインストリームSTM32G0/G4と言えるでしょう。

製造プロセス

製造プロセスの微細化は、そのままの設計でも動作周波数向上と低電力消費、デバイス価格低減に大きく寄与します。そこで、微細化時には、急変するIoT顧客ニーズを満たす機能や性能を従来デバイスへ盛込んで新デバイスを再設計します。STM32U5やSTM32G0/G4がその例です。

MCU開発者は、従来デバイスで開発するよりも製造プロセスを微細化した最新デバイスで対応する方が、より簡単に顧客ニーズを満たせる訳です。

関連投稿:開発者向けMCU生産技術の現状

まとめ

セキュリティ、MCUコア、製造プロセスのそれぞれを進化させた最新のIoT MCUデバイスが、次々に発表されます。開発者には、使い慣れた従来デバイスに拘らず、顧客ニーズを反映した最新デバイスでの開発をお勧めします。

また、短時間で最新デバイスを活用し製品化する方法として、最新メインストリーム(汎用)デバイスSTM32G0/G4を使ったプロトタイプ開発もお勧めします。

最新メインストリーム(汎用)プロトタイプ開発イメージ
最新メインストリーム(汎用)プロトタイプ開発イメージ

前章までで示したように最新メインストリームSTM32G0/G4は、他カテゴリデバイスの機能・性能を広くカバーしています。メインストリームプロトタイプ開発資産は、そのまま最新の他カテゴリデバイスへも流用できます。

従って、他カテゴリデバイスの特徴部分(セキュリティ、超低消費電力動作やワイヤレス)のみに注力した差分開発ができ、結果として短期製品化ができる訳です。

ちなみに、プロトタイプ開発に適したSTM32G0テンプレートは、コチラで販売中、FreeRTOS対応のSTM32G4アプリケーションテンプレートは、6E目標に開発中です。

あとがき:文字伝達

ソフトウェア開発者ならソースコード、ハードウェア開発者なら回路図が、最も直接的・正確に技術内容を使える手段です。文字は、記述者の理解を変換して伝える間接的手段です。両者に違い(文字化ノイズ)が生じるのは、やむを得ないと思います。

報ステのTSMCのニュースに頭の抱えてしまった”、“TSMCは日本で何をしようとしているのか“からも分かるように、マスメディアは文字や画像で情報を伝えます。受けての我々開発者は、これらノイズを含むと思われるマスメディア情報を、自分の頭で分析・処理し、理解する必要があります。

と言うわけで本稿も、筆者が文字化ノイズを付けて分析した例です……、という言い訳でした😅。

非接触型体温計と放射温度計

COVID-19の影響で、どこの入口でも見かける非接触型体温計は、遠赤外線センサとLCD温度表示で1000円台から購入できます。一方で、「体温計ではありません」と明記した放射温度計も見た目は同じですが、価格は2倍程度違います。

同じ温度センシング機器でも、価格が異なる理由を探ります。

温度センシング設計ガイド

エンジニアのための温度センシング設計ガイド
エンジニアのための温度センシング設計ガイド

アナログセンサの老舗、Texas Instrumentsのホームページから“エンジニア向け温度センシング設計ガイド”が無料でダウンロードできます。体温、システム温度、周囲温度、液体温度の4種類の温度センシング設計上の課題とその解決方法、センサ利用のアナログデジタル変換(ADC)基礎知識が記載されています。

主にハードウェア設計ガイドですが、MCUソフトウェア開発者も、各種センサ特徴、線形性、第7章の温度補償などが参考になると思います。

温度検出テクノロジーの比較(出典:エンジニアのための温度センシングガイド)
温度検出テクノロジーの比較(出典:エンジニアのための温度センシングガイド)

価格と利益

ビジネスは、利益の上に成立します。低価格でも大量に開発機器が売れれば利益も増えます。機器の価格は、様々なパラメタから成る関数ですが、ここではごく単純化し下式と仮定します。

価格=f(実装機能、想定利用者(≒販売数量))

同じ温度センシング機器でも価格が異なるのは、実装機能が異なるからです。

そこで、TI温度センシング設計ガイド第4章、体温監視から課題と解決方法をピックアップします。

実装機能と想定利用者

想定利用者を疾患患者やアスリートとすると、国際標準に準拠した医療体温計要件である校正後、精度±0.1℃以内、35.8℃~41.0℃の読取りと表示が必要です。但し、アプリケーションの温度読取り間隔は、電池節約のため10秒~60秒でも十分です。

これら機能を非接触型体温計へそのまま実装すると、開発に時間がかかるだけでなく、価格も上がるのは当然です。

CODIV-19の現状では、入口対象者の多くはコロナ患者ではない可能性が高いので、医療体温計レベルの要件は不要でしょう。また、計測機器に必須の測定値校正処理も、一般向けには無理な作業です。

このように、機器使用者/利用者を限定すれば、開発機器への実装機能も絞ることができます。

例えば、電源投入時にのみセンサ校正をソフトウェアで行い、温度読取り間隔は数秒以内に早くし、販売価格を2000円前後に目標設定すれば、一般向け非接触型体温計としてベストセラーになるかもしれません。

開発速度

目標設定が適切でも、開発が遅れれば先行他社に利益を取られます。早く開発できるスキルは、日頃の自己鍛錬が必要です。最新の開発手法やその試行も、通常の開発と並行して行うとスキルに磨きがかかります。

弊社マイコンテンプレートは、複数の公式サンプルソフトウェア流用・活用が容易で、アプリケーションの早期開発ができるなど、自己鍛錬にも適しています。

まとめ

Texas Instrumentsの温度センシング設計ガイドを基に、非接触型体温計と放射温度計の機器価格差は、ADC実装機能、想定使用者が異なるためと推測しました。利益を得るには、開発速度の向上努力も重要です。

ソフトウェアとハードウェアのインタフェースさえ解れば機器開発は可能です。しかし、ADCは、IoT MCUの最重要技術です。ソフト/ハードの垣根を越えた知識や理解が、結局は利益を生む機器開発に繋がることを言いたかった訳です。

IoT MCUとAI

ARM Cortex-Mコア利用のIoT MCU現状と、次のムーア則を牽引すると言われるAI(人工知能)の関係についてまとめました。

Cortex-Mコア、IoT/組込みデバイス主要ポジション堅持

ARMベースチップ累計出荷個数は1,800億個以上(出展:ニュースルーム、February 16, 2021)
ARMベースチップ累計出荷個数は1,800億個以上(出展:ニュースルーム、February 16, 2021)

2021年2月16日、英)ARM社は、ARMチップの2020年第4半期出荷が過去最高の67憶個、累計出荷個数1800憶個以上、Cortex-Mチップも4半期最高44憶個出荷で「IoT/組込みデバイス主要ポジション堅持」と発表しました(ニュースルーム)。

Cortex-Mチップの出荷内訳は不明ですが、Cortex-M4やCortex-M0+などコア別の特徴が解るARM社の解説は、コチラにあります(フィルタのProcessorファミリ>Cortex-Mを選択すると、提供中の全10種Cortex-Mコア解説が読めます)。

筆者は、セキュリティ強化コアCortex-M23/33/35P/55を除く汎用IoT/組込みデバイスでは、Cortex-M4/M0+コア使用数が急増していると思います。

関連投稿:Cortex-M33とCortex-M0+/M4の差分

半導体ムーア則、牽引はチップレット

ムーアの法則 次なるけん引役は「チップレット」、2021年2月16日、EE Times Japan

次のムーア則を牽引するAI処理能力(出典:AI Hardware Harder Than It Looks)
次のムーア則を牽引するAI処理能力(出典:AI Hardware Harder Than It Looks)

半導体製造プロセスを牽引してきたのは、PCやスマホでした。しかしこれからは、人工知能:AIで急増するAIデータ処理能力を実現するため、レゴブロックのようにコアの各モジュールを歩留まり良く製造・配線するチップレット手法が必要で、このチップレット、つまりAIが次の半導体ムーア則を牽引するというのが記事要旨です。

このチップレット手法で製造したIoT MCUやMPUへ、主にソフトウェアによるAI化は、シンギュラリティ後のAI処理量変化にも柔軟に対応できると思います。

関連投稿:今後30年の半導体市場予測

ルネサス:ハードウェアアクセラレータコアCNN(Convolutional Neural Network)

ルネサスのCNNアクセラレータ(出典:ニュースルーム)
ルネサスのCNNアクセラレータ(出典:ニュースルーム)

2021年2月17日、ルネサスは、世界最高レベルの高性能/電力効率を実現するディープラーニング性能を持つCNNアクセラレータコアを発表しました(ニュースルーム)。これは、主にハードウェアによるAI化の例です。

ADAS実現に向け、性能と消費電力を最適化した車載用コアです。このコアに前章のチップレット手法を使っているかは不明です。3個のCNNと2MB専用メモリの実装により、60.4TOPS(Tera Operations Per Second)処理能力と13.8TOPS/W電力効率を達成しています。

車載で実績を積めば、IoT MCUへも同様のハードウェアアクセラレータが搭載される可能性があります。

まとめ

凸版印刷社は、画像認識AIを活用し、古文書の“くずし字”を解読支援するツールを開発しました(2021年2月16日、IT media)。このように、AIは、半導体技術のムーア則だけでなく、IoT MCUアプリケーションや人間生活に浸透し、牽引しつつあります。

エッジAIをクラウド接続IoT MCUへ実装する理由は、クラウドAI処理とクラウド送信データ量の両方を軽減することが狙いです。AI処理をエッジ側とクラウド側で分担しないと、チップレット手法を用いて制御チップを製造できたとしても、コスト高騰無しに急増するAIビックデータ処理を実現することが不可能だからです。

IoT MCUのエッジAIが、ソフトウェアまたはハードウェアのどちらで処理されるかは判りませんが、必須であることは確実だと思います。実例を挙げると、STマイクロエレクトロニクスは、既にSTM32Cube.AIにより汎用STM32MCUへAI/機械学習ソフトウェアの実装が可能になっています。

今後30年の半導体市場予測とルネサス動向

Runesas

半導体不足が騒がれています。これがCOVID-19の一時的なものか否かが判る下記記事と、最新のルネサスエレクトロニクス動向を関係付け、今後のMCU開発について考えました。

2050年までの半導体市場予測~人類の文明が進歩する限り成長は続く、2021年1月14日、EE Times Japan

今後30年の半導体市場予測

本ブログ読者は、殆どが現役の「日本人」MCU開発者です。定年退職が何歳になるかは分かりませんが、上記記事の2050年まで、つまり、今後30年の半導体市場予測は、在職中のMCU開発を考える上で丁度良い時間の長さです。

予測ですので、大中小のシナリオがあります。我々開発者にも解り易い結論だけをピックアップすると、概ね下記です。

  • 今後、先進国と新興国中間層人口は、COVID-19で人類滅亡しない限りそれぞれ5億人/10年で増加し、2050年に先進国が30億人、新興国中間層が40億人、貧困層が20~30億人の人口ピラミッド構成へ変遷
  • 1人年間の半導体消費量は、先進国が150ドル、新興国中間層が75ドル
  • 2050年の半導体市場は、2010年比2.5倍の7500憶ドルへ成長

ルネサス動向

英)Dialog買収車載半導体改良「AI性能を4倍に」など、SoCアナログ機能増強、ADAS実現やIoTに向けた動きが、2021年になってからのルネサス最新動向です。

これら動向の結果が出るまでには、年単位の時間が必要です。しかし、前章の2050年半導体市場2010年比2.5倍へ向けての行動の1つとすると、なぜ今か(!?)という疑問に対して、理解できます。

2倍化MCU開発

2倍化MCU開発

MCUも半導体の1つです。半導体市場が増えれば、それらを制御するMCU量も増えます。2010年比2.5倍なら、現在の2倍程度MCU開発も増えると思います。

従来と同じ人員と開発方法では、量が2倍になれば、2乗の4倍の労力が必要になります。新しい手法やその効率化なども導入する必要がありそうです。ルネサス同様、今スグに着手しなければ乗り(登り)遅れます。

使用した半導体の貴金属部分はリサイクルされますが、搭載ソフトウェアやハードウェアパターンは回収されずに消費されます。開発物の資産化、最新プロセスで大容量Flash搭載の新開発MCU、新開発手法にスグに対応できるMCU開発者が生き残るかもしれません。

関連投稿:開発者向けMCU生産技術の現状

MCU利用者

先進国だけでなく、新な対象として新興国中間層へもMCU利用者が広がります。新興国中間層は、先進国よりも10億人も多い予想で、1人当たりはより低コスト半導体(=MCU開発)が求められます。

この新興国中間層向けのMCUアプリケーションを検討するのも良いかもしれません。

2045年のシンギュラリティ

Singularity:和訳(技術的特異点)は、人類に代わって人工知能:AIが文明進歩の主役になることです。

最初の記事にも、2045年と言われるシンギュラリティは、一層半導体市場を広げる可能性があるとしています。IoT MCUにもエッジAIが組込まれるなど、今後のMCU開発もAI化は必然です。