MCU AIトレーニング資料

STマイクロの日本語トレーニング資料(組込みAI編)
STマイクロの日本語トレーニング資料(組込みAI編)

STマイクロの日本語トレーニングサイト内に、9個の組込みAI資料を見つけたので紹介します。日本語のMCU AI資料は嬉しいです。STマイクロへのログインが必要ですが、どなたでも閲覧(PDFダウンロード)可能です。

MCU AIトレーニング資料8個の内容

トレーニング資料8個の内容です。1~8の内容に加えて10月3日に行われたウェビナー資料:コンピュータ・ビジョン編の計9個MCU AI資料が公開中です。

MCU AIトレーニング資料8個の内容
MCU AIトレーニング資料8個の内容

AI解説(Page 2)記載の8トレーニング資料の説明範囲:「AI基本概念には触れるが、AI、深層学習、Pythonプログラミングの詳細解説はしない」は、Edge AI/MLツールを利用しMCU開発を行う者に最適な内容だと思います(MCU AI現状と対策、1章:Edge MCI AI課題数参照)。

1~8資料は、読者のお好きな時間に読んでください。

本稿は、9個目のウェビナー資料:コンピュータ・ビジョン編から筆者印象に残った点をピックアップします。

コンピュータ・ビジョン編もくじ

コンピュータ・ビジョン編もくじ
コンピュータ・ビジョン編もくじ

ピックアップしたコンピュータ・ビジョン編のもくじです。コンピュータ・ビジョンとは、MCUが、AIを使って画像、動画、その他入力データから目的とする情報を抽出する手法です。

印象点が以下です。

  • Edge AI/ML MCU(Tiny ML Devices)は、2030年に25億台と予測(P4)
  • Edge AI/ML MCUは、クラウド接続無しで低レイテンシ(P9)
  • STM32MCUのAI開発ツールは、STM32Cube.AIとNanoEdgeStudioの2種類あり(P12)
  • 主要STM32汎用MCUは、AI開発ツール2種類両方が使える(P13)
  • STM32Cube.AIは、深層学習アプリケーションを簡単実現(P18)
    • ※NanoEdgeStudioは、前回投稿に記載中
    • ※深層学習とは、ニューラルネットワークによる機械学習手法

つまり、MCU開発者は、2030年の数年前までに、ソフトウェアで他社差別化できるEdge AI/ML(組込みAI)知識獲得と開発が必要と言えます。

Summary:STM32Cube.AIとNanoEdgeStudio差は継続調査

Edge AI/ML MCUが、クラウド接続不要でスタンドアロン動作であることは、大歓迎です。RTOSや高度セキュリティTrustZoneなどのネットワーク技術の必要性が低いからです。

従って、Edge AI/ML MCU開発は、ベアメタル開発の延長線上にあると言えます。25億台/2030年予測の内、Edge AI/ML MCU比率がどの程度かは不明です。しかし、RTOS/TrustZone MCU比率より多いことを筆者は期待します。

前回投稿のMCU AI開発ツール:NanoEdgeStudioと本稿のSTM32Cube.AIの特性差が何かは、現在不明です。もう少しAI/ML知識を獲得すれば、判ってくると思います。継続調査項目とします。

Afterword:判り難さは、馴染み無い用語起因

RTOS/TrustZone MCUよりもEdge AI/ML MCUの方が開発簡単とは言いません。

しかし、ベアメタル開発に近いのはEdge AI/ML MCU開発です。IoT MCUに必須なRTOS/TrustZoneは、AI/MLよりも馴染みが薄い用語が多く、しかも開発にその詳細理解も必須です。

一方、AI/MLは、AI解説編が示すようにAI/ML詳細理解よりMCU AIツールの効率的活用で十分開発できそうなことも理由です。

※望むらくは、AI/ML同様、RTOS/TrustZone開発支援ツールがあると嬉しいですね!

この意味でSTマイクロの組込みAI日本語資料は、MCU開発者に非常に役立ちます。是非一読(何度も読むこと)をお勧めします。馴染み無いAI/ML用語が、だんだん身近なります!

10月2日発表のWindows AI/CopilotもMCU AI/ML普及の追い風になるハズです。


MCU AI現状と対策

今秋リリースWindows 11 23H2は、AIによる作業支援:Copilot機能が追加される予定です。AIがより身近になるでしょう。

AIは、MCU開発へも押し寄せつつあります。ルネサス、STマイクロのEdge MCU AI現状と対策を示します。

MCU開発者に押しよせるAI/MLの風
MCU開発者に押しよせるAI/MLの風

Edge MCU AIとWindows AIの課題数

1: MCU開発へAIをどのように実装するか、2: 実装したAIをどのようにMCU製品メリットへ変えるか、そして、3: Edge MCU AI製品をどのように顧客に活用してもらうか、MCU開発者は、これら課題解決が必要です。

一方、Windows AIは、3:相当 のPCユーザとしてどのようにWindows AIを活用するかが課題です。

Edge MCU AIは、使うだけでなく開発も必要ですので課題の数が異なります。MCUベンダ各社は、AI MCUツールを発表しています。

本稿は、特に1:AIのMCU実装についてルネサス、STマイクロの現状とMCUソフトウェア開発者の対策を示します。

ルネサス:Reality AI Toolをe2 studioへ統合

2023年9月21日、ルネサスは、Edge AI専用ツール:Reality AIを、既存MCU開発環境:e2 studioへ統合しました。これにより、AIプロジェクトとe2 studio間のデータ共有が可能となり、開発効率が上がります。

動画はコチラ

STマイクロ:NanoEdge AI Studio

NanoEdge AI Studio Workflow(出展:NANOEDGE AI STUDIO V3)
NanoEdge AI Studio Workflow(出展:NANOEDGE AI STUDIO V3)

2023年8月3日、STマイクロは、Edge AI 専用ツール:NanoEdge AI StudioとST開発ボードを使って簡単・迅速にAI/ML:Machine Learning関連データを収集・検証し、機械学習アルゴリズムをわずか数ステップで生成できると発表しました。

動画はコチラ

AI/ML必然性

既存MCU開発環境へEdge AIツール出力をライブラリとして取込むことは、ルネサス/STマイクロ共に簡単です。

しかし、非力なMCUに最適なAI出力ライブラリを得ることが簡単か否かは、現在、筆者は分かりません。多分、この判断には、多少なりともAI/ML知識が必要になるでしょう。

AI/ML担当者とEdge MCU担当者、2人いれば問題は少ないです。しかし、Edge MCU開発者が両者を兼務することが、既存MCU IDEへAIツール統合の流れとマッチすることから必然だと思います。

ハードウェアとソフトウェア担当が別れるように、AI/MLとMCUソフトウェア担当が分離することを筆者は想定しにくいです。

Summary:急増Edge MCU AI対策

Edge MCU AI製品とAIなしのMCU製品を比較したSTマイクロの動画(7:34)は、興味深いです(リンク先下方に動画あり)。AI実装有無が、MCU製品の差別化要因になることを示しています。

また、Windows AI:Copilot機能の普及は、MCU製品顧客へも大きな影響を与えると思います。PCでのAI活用事例が多くなり、AIメリットを認識する顧客が増えるからです。

MCU開発者は、Windows AI普及に合わせて増加するであろうEdge AI/ML知識も備えておく必要があります。MCUベンダ各社は、Edge AI/MLセミナを活発化します。是非参加して、基礎知識を獲得しましょう!


STM32C0で最新32ビットMCU開発短期習得

STM32 Nucleoボード一覧(1M Flash以下 出展:STM32 MCU Developer Zone)
STM32 Nucleoボード一覧(1M Flash以下 出展:STM32 MCU Developer Zone)

STマイクロの1MバイトまでのFlash搭載STM32 Nucleo評価ボード一覧です(STM32 MCU Developer Zone掲載図から抜粋)。紺色のMainstream:汎用MCU評価ボードが多いことが判ります。

今回は、2023年3月発売の評価ボード:NUCLEO-C031C6を使って、最新Cortex-M系32ビットMCU開発を短期習得する方法を示します。

1. 短期習得に適すSTM32C0シリーズ

この評価ボードのMCU:STM32C031C6(Cortex-M0+/48MHz、Flash/32KB、RAM/12KB、LQFP48)は、STマイクロが8/16ビットMCU置換えを狙った新しい32ビットSTM32C0シリーズです。開発のし易さ、価格の低さ、入手性の良さが特徴です。

STM32C0シリーズの「C」は、Compact、またはCost-effectiveのCを表していると思います。同じLQFP48のSTM32G0シリーズとブロッグ図を比べると差分が判ります(「G」は、多分Generalを表す)。

STM32C031とSTM32G081の比較
STM32C031とSTM32G081の比較

どちらもCortex-M0+コア採用の汎用MCUです。違いは、STM32C0は、アナログや通信などの内蔵周辺回路、Flash/RAM容量を、8/16ビットMCU置換目的に必要最小限にし、G0比コストダウンを図っていることです。

つまり、STM32C0は、STM32汎用MCUシリーズの中で、最もBasicな周辺回路のみを備えたシリーズです。この周辺回路の少なさが、MCU開発をシンプルにし、短期習得に適す理由です。

2. 入手性・開発拡張性良いNUCLEO-C031C6評価ボード

NUCLEO-C031C6
NUCLEO-C031C6

STM32C0搭載の評価ボードNUCLEO-C031C6は、低価格で入手性が良く、ボード上にユーザLED/SW、拡張シールド接続用Arduinoコネクタ、デバッガ(ST-LINK/V2-1)が実装済みです。

関連投稿:Arduinoコネクタが評価ボードに多い理由

PCとUSB接続すれば、MCUプログラミングとデバッグ、PC Tera-Termで評価ボードとのVirtual-COM通信が可能です。Virtual-COMは、MCUでの様々な処理結果をPCで直接確認できるので便利です。

NUCLEO-C031C6が、最初の図で多くの汎用MCU評価ボードの一番下(Basic)であることもポイントです。

NUCLEO-C031C6で開発したHAL API利用ユーザソフトウェアは、MCU差に依存しない移植性の高さがありますので、処理性能不足時は、より上側の高性能ボードへユーザソフトウェア載せ替えも容易な訳です。

関連投稿:HALとMCUソフトウェア開発

3. サンプルコードが多いNUCLEO-C031C6評価ボード

MCUソフトウェア開発には、慣れが必要です。この慣れには、STM32C0シリーズサンプルコードを読み、かつ動作させるのが近道です。

NUCLEO-C031C6は、全73個のサンプルコード動作環境として使えます(2023年9月現在)。これは、他のSTM32C0評価ボードと比べ格段の多さです。

お勧めは、下図に示すHAL API利用の16個サンプルコードです。この16個HALサンプルコードだけを理解しても、STM32MCU開発初心者卒業と言えると思います。

NUCLEO-C031C6で動作するHAL APIサンプルコード(出展:AN5892)
NUCLEO-C031C6で動作するHAL APIサンプルコード(出展:AN5892)

初めはサンプルコードを詳しく理解する必要はありません。初期設定と無限ループの2つに分けて動作させれば、コード内容は自ずと判ってきます。ボード搭載デバッガは、ブレークポイント設定やRAM内容表示もできるので便利です。

関連投稿:組込み処理の基本のキ

4. 情報整理に役立つSTM32C0オンライントレーニング

STM32C0オンライントレーニングは、MCU開発情報の整理・習得確認に便利です。

但し、初めからこれらトレーニング資料を読むことはお勧めしません。おぼろげながらでも、開発全体像が見えた段階で、各資料読むと理解・整理が進むからです。前章サンプルコードを試した後がお勧めです。

サンプルコードやトレーニング資料は、エキスパートが作成します。残念ながらエキスパート作成資料は、初めての方には難解だと思います。

MCU習得も「習うより慣れろ」が当てはまります。案外簡単なことでも文章では難解さが強調されます。評価ボードとサンプルコードがあれば、とにかく動作が目視確認できます。

トレーニング資料は、動作目視後に頭の中を整理し、習得度を確認する際に便利と言えます。

Summary:STM32C0で最新32ビットMCU開発の短期習得

本稿は、最新汎用STM32C0を使って、回り道や障壁がなるべく低くなるMCU開発習得方法を示しました。

  1. 8/16ビット置換え用周辺回路厳選の低価格32ビットMCU:STM32C0
  2. デバッガとユーザLED/SW実装で入手性良いNUCLEO-C031C6評価ボード
  3. NUCLEO-C031C6で即実行できる多数の周辺回路サンプルコード
  4. 習得・情報整理に役立つSTM32C0オンライントレーニング

これらSTM32C0シリーズ特徴を持つ4つの開発環境を使うと、個人でも最新STマイクロ32ビットMCU開発の短期習得が簡単にできます。

Afterword:個人レベルスキル向上で老化日本対策

老化は、国レベルでも進行します。日本の少子・高齢化がもたらす2040年問題。全体同調意識の強い老化日本では、その対策は期待できません。

残る策は、個人レベルのスキル向上です。IoT MCU開発スキルは、激変技術世界でも生き残る有力策の1つと思います。


HALとMCUソフトウェア開発

HAL:Hardware Abstraction Layer APIを使えば「MCUデバイスに依存しないソフトウェア開発」ができる。そこで、汎用MCUでプロトタイプソフトウェアを作り製品MCUを選択。これが、前投稿でした。
主題は、製品MCU選択方法です。

今回は、この方法の基になる「MCUデバイスに依存しないソフトウェア開発ができる」部分を、もっと具体的に説明します。

MCUソフトウェア開発の鍵HAL API

前投稿最後に示したSTM32デバイスとユーザアプリケーション移植性の両方を満たすHALスタック図を具体化します。

弊社STマイクロ関連テンプレートに採用したSTM32F0/F1/G0/G4デバイスとNucleo評価ボード、一般的なベアメタルソフトウェア開発を想定し作り直したHALスタック図が、下図です。UtilityやMiddlewareは使いませんので空白にしています。

User ApplicationとHAL間は、HALドライバを用います。例として、GPIO接続のLEDをトグル出力するHAL API関数:HAL_GPIO_TogglePin(LED_GPIO_Port, LED_Pin)で説明します。

ベアメタルソフトウェア開発のHALスタック図
ベアメタルソフトウェア開発のHALスタック図

HAL_GPIO_TogglePin(LED_GPIO_Port, LED_Pin)

STマイクロのHALドライバは、接頭語に必ずHAL_が付きます。ソース上も判別し易いです。

HAL_GPIO_TogglePin(xPort, yPin)は、MCU Port名xのPin番号yを使うGPIOに対して、トグル(HighからLow、またはLowからHigh)出力するドライバ関数です。

例えば、STM32G0評価ボード:Nucleo-G071RB実装ユーザLED:LD4は、PA5接続です。トグル出力は下記です。

HAL_GPIO_TogglePin(GPIOA, GPIO_PIN_5)   //物理GPIOポートA、5番ピンをトグル出力

STM32G4評価ボード:Nucleo-G474RE実装済みユーザLED:LD2も、同じくPA5接続ですので、全く同じHALソフトウェア記述で、ユーザLD2のトグル出力ができます。

Nucleo評価ボードBSP

Nucleo-G071RBとNucleo-G474REは、どちらも64ピンMCUパッケージで、たまたま同じ物理記述ポート名とピン番号が、ユーザLEDに接続済みでした。

しかし、一般的には開発MCUや評価ボードで異なるポートとピンへユーザLEDが接続されます。

そこで、物理記述GPIOAやGPIO_PIN_5と、評価ボードの論理記述LD2やLD4を結び付けるのが、BSP:Board Support Packageです。この結び付けにより、異なる物理記述ポート、ピン番であっても、同じ論理記述のDemonstrationやUser ApplicationでLEDを動作させることが可能になります。

具体例で示すとNucleo-G071RBのBSPは、STM32CubeIDEのmain.hに展開され、LD4関連は下記です。

#define LD4_GPIO_Port  GPIOA  //LD4_GPIO_Portを物理GPIOポートAと定義
#define LD4_Pin  GPIO_PIN_5     //LD4_Pinを物理5番ピンと定義

Nucleo-G474REのBSPは、LD2関連main.hが下記です。

#define LD2_GPIO_Port  GPIOA  // LD2_GPIO_Portを物理GPIOポートAと定義
#define LD2_Pin  GPIO_PIN_5     // LD2_Pinを物理5番ピンと定義

LD2とLD4の部分が異なります。BPSは、評価ボードのハードウェア毎に異なります。

各評価ボードのソースコードを読む時は、LD2やLD4と論理記述した方が、物理記述のGPIOAやGPIO_PIN_5よりも判り易いため、これらdefine文を使います。

評価ボード非依存ソフトウェアテクニック

評価ボード単位のソースコードを読む時は、実装中のLD2やLD4と論理記述した方が判り易いです。

では、様々な評価ボードで共通に動作するUser Applicationを開発する場合は、どうすれば良いのでしょうか?

答えは簡単です。論理記述をLD2やLD4から、より上位の論理記述へ結び付ければOKです。例えば、下記です。

#define BOARD_LED_PORT  LD4_GPIO_Port    //BOARD_LED_PORTをLD4_GPIO_Portと定義
#define BOARD_LED_PIN  LD4_Pin         //BOARD_LED_PINをLD4_Pinと定義

このように評価ボード単位のdefine文を、上位実装LEDや論理ピンへ再定義すれば評価ボード非依存のソフトウェアが開発できます。

define文は、開発者が、ソースコードを読み易くするための機能です。define文で再定義しても、コンパイル時に最終物理対象(GPIOAやGPIO_PIN_5)に置き換わるため、処理速度が遅くなるような弊害はありません。

STM32Cube MCU Packages Manager

さて、HALスタック図では1個のHALも、実はMCU毎に異なります。

このMCU毎に異なるHALを、STM32CubeIDEへ実装するツールが、STM32Cube MCU Packages Managerです。

MCU毎に異なるFirmware(HAL)をSTM32CubeIDEへ実装するSTM32Cube MCU Package Maneger
MCU毎に異なるFirmware(HAL)をSTM32CubeIDEへ実装するSTM32Cube MCU Package Maneger

STM32Cube MCU Packages Managerは、プロジェクトのハードウェア設定ファイル(icoファイル)を開いた状態で、Help>Manage Embedded Software Packagesで表示できます。上図は、STM32C0/F0/F1/G0/G4のPackage部分を抜粋しています。

このSTM32Cube MCU Packages Managerで、最新のFirmware Packageを開発に使うか、それとも、古いFirmware Packageを使うかが選択できます。上図は、STM32G0ソフトウェア開発に最新Firmware V1.6.1を開発に使うことを選択中の例です。

Firmware Package版数の訳

このMCU Firmware Packageが、HALの実体です。

例えば、STM32G0 Firmware V1.6.1は、旧Firmware V1.6.0と上位のUser Applicationに対しては同じHAL APIを提供しますが、その実体は、旧HALのバグ修正や販売中のSTM32G0 MCUに応じて中身が変わります。

つまり、このFirmware Packageが、MCU差や過去のHAL版に依存しないHAL APIを、User Applicationへ提供する仕組みそのものです。

MCU発売後、経過時間が長くなると、同一MCUでも多くのFirmware Package版が選択可能になります。

お勧めは、最新Firmwareです。

複数のFirmware版が存在する理由は、STマイクロがMCU供給を最低10年保証しているためです。新MCUパッケージ追加発売時は、新しいFirmware版で対応します。簡単に言うと、MCU開発履歴が版数に現れる訳です。

つまり、開発者が、顧客提供時Firmwareをそのまま継続開発に使いたい場合には、最新版だけでなく過去のFirmwareも選択肢になる訳です。

実際の選択は、icoファイルのProject Managerタブの一番下、Firmware Package Name and Versionで設定します。

Summary:HAL APIソフトウェア開発

BSPとMCU Firmwareによりハードウェア依存性が無いHAL APIsが提供
BSPとMCU Firmwareによりハードウェア依存性が無いHAL APIsが提供

MCUソフトウェアは、HAL APIを使うとMCUに依存しない移植性の高いUser Applicationソフトウェアの開発ができることを説明しました。

User ApplicationとHAL API間のハードウェア依存性を無くす手段として、評価ボード毎に異なるBSPや、MCU毎に異なるMCU Firmware Package(HAL)を用います。

汎用MCUを使ったHAL APIプロトタイプ開発ソフトウェアは、MCU変更に対して移植性が高いため、User Applicationソフトウェアの資産化も期待できます。

Afterword:MCU説明の難しさ

本稿の内容は、中級以上のMCU開発者にとっては、自明の理です。しかし、この自明の理を説明するのは、結構大変です。本稿も、説明不足の箇所が多々あります。

MCU開発では、この自明の理の部分が多いため、開発者レベルを上げる障壁は高くなります。例えて言うと、スマホが初めての方に、その取扱い方法を文書だけで説明するようなものです。

本稿は、STマイクロのHALを例に説明しました。これは、現在MCU毎に販売中の弊社STM32F0/F1/G0/G4テンプレートを、MCU共通のSTM32MCUテンプレートへ発展させる布石でもあります。

本稿内容が、すんなり判る開発者には、STM32共通MCUテンプレートは、多分不要(ご自分で開発できる)ですし、判らない方には、STM32共通テンプレートよりも個別STM32F0/F1/G0/G4テンプレートの方が使い易いと思っています。

今回のような長文は、筆者の苦手な分野です。が、時々は挑戦すべきと考えております。ご質問や判り難い箇所のご指摘も大歓迎です。読者の方々からのレスポンス、お待ちしております。



ソフトウェア視点のMCU選び方

MCU選び方をソフトウェア開発視点から示します。
具体例としてSTマイクロのSTM32MCUで説明しますが、他MCUベンダでも同様です。

Summary:HALドライバ+汎用MCUプロトタイプ開発で選定

例え同じベンダでも色々な内蔵ハードウェアと、処理性能、価格も異なるMCUは、製品MCUの選択肢が広すぎるのが難点です。

製品MCUハードウェア選定ミスを少なくし、かつ、ソフトウェア開発も効率的にできる方法として、汎用MCUを使いHALドライバで早期に製品プロトタイプ開発を行い評価する方法を示しました。

製品MCU選択肢の広さ

STマイクロのSTM32MCUポートフォリオ(出展:STM32ウェビナー資料)
STマイクロのSTM32MCUポートフォリオ(出展:STM32ウェビナー資料)

ベンダ例としてSTマイクロのCortex-Mコア系MCU選択肢の広さを示します。

STM32MCUポートフォリオを性能やシリーズ別に示したのが上図です。この図でターゲット製品のMCUシリーズを大まかに選定するのが、第1選定段階です。

第2段階では、各シリーズのFlash/RAM容量、内蔵ADCやUASRT数など製品時に必要になる周辺回路からハードウェア的に最適なMCUデバイスを選定します。

STM32MCU製品セレクタ例
STM32MCU製品セレクタ例

この選択方法は、MCU処理性能やソフトウェアを格納するFlashやRAM容量は、最終製品にならないと実際は判りません。しかし、周辺回路や動作電圧などのハードウェア条件は、明らかなのでこれらからMCU選定はできます。

但し、メインストリーム、つまり汎用MCUであっても、STM32C0、STM32F0/F1、STM32G0/G4シリーズと選択肢があり、処理性能も異なります。更に、ハイパフォーマンスSTM32H5/H7や、超低消費電力STM32U5などの汎用MCU比性能を極めたシリーズもあります。

これら多く広いMCU選択肢から、入手性やコストから製品MCUを決めるのが、一般的に用いられる「ハードウェア視点MCU選択方法」です。

HALドライバソフトウェア開発メリット

HALとは、Hardware Abstraction Layerドライバです。このハードウェアは、MCUを指します。つまり、MCU差を抽象化=隠して開発できるAPIを上位ユーザアプリケーションへ提供するのがHALです。

例えば、STM32C0でも、STM32G4でも同じHALドライバでGPIOアクセスができます。つまり、HALドライバを利用すれば、STM32C0とSTM32G4で同じアプリケーションが使える訳です。

従って、STM32C0で性能不足の場合には、開発ソフトウェアはそのままSTM32G4へ移植ができます。逆の性能過多の場合でも同様です。ユーザ開発アプリケーションのMCU間移植性が高いのがHAL利用ソフトウェアのメリットです。

HAL+汎用MCUプロトタイプ開発

汎用MCUを使って製品のプロトタイプ開発を行えば、製品化時、よりハイパフォーマンスMCUの必要性や、より低消費電力MCUの必要性が、使用した汎用MCUとの相対比較で可能です。

また、HALを使えば、プロトタイプ開発アプリケーションが製品MCU上でも動作します。

つまり、製品MCUのオーバー/アンダースペック選定ミスを減らす評価ができ、かつ、プロトタイプ開発アプリケーションの製品移植性も高いため、結果として効率的な製品開発が可能になるのが、「ソフトウェア視点MCU選択方法」です。

拡大MCUハードウェアとMCUソフトウェア移植性を満たすHAL

拡大STM32MCUデバイスとユーザアプリケーション移植性の両方を満たすHAL
拡大STM32MCUデバイスとユーザアプリケーション移植性の両方を満たすHAL

MCUベンダは、最初の図で示したように進化する半導体製造プロセスやよりアプリケーション寄りのコストパフォーマンス最適MCUデバイスを提供し続けます。

MCU製品開発側は、増え続けるMCUデバイス間のソフトウェア移植性や開発時間の短縮も必要です。

HALドライバは、これら進化・拡大するMCUハードウェアとMCUソフトウェア移植性要求を同時に満たす機能です。

HALによる汎用MCUプロトタイプ開発は、参考になるサンプルコードが多いため開発時間も少なく、開発アプリケーションがユーザ資産として多くのMCUでの活用も期待できます。

Afterword:汎用MCU選び方

汎用MCUも多くの選択肢があります。STマイクロのお勧めデバイスは、最新製造プロセスで入手性が良く低価格なSTM32G0/4シリーズ評価ボードです。

Flash/RAM容量も入手性優先で選定して構いません。容量不足時は、機能分割しプロトタイプ化すれば済むからです。

ソフトウェア視点MCU選択方法は、プロトタイプ開発が必要です。短期間で効率的に製品プロトタイプを仕上げ、このプロトタイプから製品MCU要求条件やソフトウェア動作ポイントなどを評価します。

プロトタイプと最終製品が近ければ近い程、これら評価精度は上がります。しかし、精度に拘る必要はありません。製品企画時に、とにかく製品のように動くプロトタイプを早く仕上げ、これから製品MCUを評価すれば、闇雲に選定するより良いからです。

MCU開発者は、手元にベンダ汎用MCUシリーズの評価ボードと弊社テンプレートがあれば、直ぐに製品のように動くプロトタイプが仕上がります。


MCUテンプレート海外販売開始

MCUテンプレート海外販売に向けWordPressサイト多言語化を行ってきました。本日より下記MCUテンプレートの海外販売を始めます。

RA BeaeMetal、STM32G0x、STM32F0/F1、3種MCUテンプレート販売開始

既存日本語テンプレート10種のうち、第一弾は、ルネサス)RA6/4/2ベアメタルテンプレート、STマイクロ)STM32G0xテンプレートSTM32F0/F1テンプレート3種のテンプレート資料を英語化し販売します。

多言語対応ページの使い方

多言語対応ページの使い方
多言語対応ページの使い方

ブログトップを示すHomeから③テンプレート購入手順は、多言語対応済みページです。従って、サイト右上のプルダウンメニューから、お好きな言語を選べば、日本語表示から選択言語へ変換されます。

①Template list掲載の3種テンプレート説明資料の冒頭3ページは、無料ダウンロード可能です。

テンプレート利点やTipsなどは、②Template Benefits & Tipsに、Template購入方法は、③Template purchase procedureをご覧ください。

お好きな言語でテンプレート概要やメリットなどをご覧になり、MCUテンプレートのご購入を検討頂ければ幸いです。

日本語テンプレート販売は従来通り

日本語MCUテンプレート10種は、従来と同じMCUテンプレートサイトから販売中です。

第一弾の多言語MCUテンプレート3種以外をご要望の方は、日本語MCUテンプレートサイトからもご購入が可能です。

但し、テンプレート説明資料は、全て日本語表記です。ご購入後、Google翻訳などを使ってご自分で翻訳してください。なお、テンプレートソースコード内の冗長な日本語コメントは、コンパイル時に全て削除されますので、制御には無関係です。

Google翻訳の感想

Google翻訳は、便利なツールです。しかし、日本語からの英語翻訳時、英単語間に余分なスペースが挿入されます。例えば、「これはペンです。」をGoogle翻訳すると、「This__is__a__pen.」となります。

この英単語間の2スペースは、Wordなどの置換ツールを使って通常の1スペースへ一括変換できます。しかし、余分なスペースがなぜ挿入されるのかが不明です。理由がお解りの方は、弊社に教えてください。

Afterword:テンプレート役割

テンプレート付属資料の英語化は、手間が掛かりました。ただ、第一弾英語化を期に、3種説明内容を横断的に見直す良い機会にもなりました。

その結果、初心者の効率的MCU習得にテンプレートが適す、テンプレート応用例SimpleテンプレートとBaseboardテンプレートは、プロトタイプ着手時のMCUプロジェクトに適す、これらを再確認しました。

MCU習得やプロトタイプ開発に、弊社テンプレートは役立ちます。是非、ご活用ください。



STM32 Developer Zone

STマイクロが、STM32 MCU/MPU開発者向け総合ポータルサイトSTM32 Developer Zoneを開設しました(2023年6月)。ベテラン/初心者ともに開発に役立つページリンクが多数集約されています。

ポータルサイトのリンク構成を解かり易くするため、フォルダ形式の一覧表示にしました。

STM32 MCU Developer Zone

STM32 MCU Zone (Home) MCUプロジェクトを開始
1-MCU製品ポートフォリオ
2-開発ボード&ハードウェアツール
3-ソフトウェア開発ツール
4-組込みソフトウェア
5-ソリューション
6-開発リソース
アプリケーション別ソリューション AIソリューション
ワイアレス&コネクティビティ
セキュリティフレームワーク
コミュニティ&サポート STコミュニティ
ナレッジ共有
パートナ設計サービス
オンラインサポート(要ログイン)

下図マイクロプロセッサ:MPU(STM32MP1/Cortex-A7+Cortex-M4)以外の全マイコン:MCU情報が、このSTM32 MCU Developer Zoneに集約されています。

STM32 MCUとMPU境界(出展:STM32C0シリーズセミナ資料に加筆)
STM32 MCUとMPU境界(出展:STM32C0シリーズセミナ資料に加筆)

MPUに比べ、AIソリューション等のアプリケーション別ソリューション情報も豊富です(関連投稿:AI MCU)。

また、初心者向きMCUプロジェクト開始リンクがあり、Step1で評価ボード選択、Step2でSTM32CubeIDEを使ったMCU開発手順の説明もあります。

STM32 MPU Developer Zone

STM32 MPU Zone (Home) MPU組込みソフトウェアツールの詳細
1-MPU製品ポートフォリオ
2-開発ボード&ハードウェアツール
3-組込みソフトウェア
4-ソフトウェア開発ツール
5-ソリューション
6-開発リソース
コミュニティ&サポート STコミュニティ
ナレッジ共有
パートナ設計サービス
オンラインサポート(要ログイン)

高度なHMIや複雑処理向けのCortex-A7搭載MPUは、現在STM32MP1シリーズだけです。従って、STM32 MPU Developer Zoneサイト構成は、MCU比シンプルです。

2023年第4四半期にこのSTM32MP1に加え、Cortex-A35、Cortex-M33搭載でセキュアIndustry 4.0、およびエッジ・コンピューティング・アプリケーション向けSTM32MP2シリーズが追加予定です。

ポータルサイトHTMLとリンク構成

ウェブサイトの図や文字、ハイパーリンクの表示には、HTMLが使われます。HTMLで記述したリンク集約ポータルサイトは、肝心のリンク構成が読者に解り難い欠点があります。モニタで一度に表示できる領域が限られるため、リンク構成は、読者がサイト全体を把握した後になるからです。

そこで、本稿は、誰でも見慣れたフォルダ形式で、STM32 MCU/MPU Developer Zoneのリンク構成を示しました。

ポータルサイトは随時更新されますが、リンク構成を把握していれば、常に所望最新リンクへのアクセスも容易です。

注)本稿は、2023年6月9日現在のリンク先を示しています。最新リンクへは、MCU/MPU Developer Zoneホームからアクセスしてください。

Afterword:European Chips Act(欧州半導体法)

欧州半導体法は、EU内の製造活動強化、欧州設計エコシステム刺激、バリューチェーン全体スケールアップとイノベーションを支援するもので、これによりEUは、世界市場シェアを2030年に20%倍増させるという目標を目指しています。

STマイクロとGlobalFoundriesは、2023年6月5日、フランス・クロルで両社共同運用の300mmウエハー工場新設計画の合意を締結と発表しました。総投資額は75億ユーロの見込みで、フランス政府が最大29億ユーロを援助します。

生産だけでなく、より開発し易いMCU/MPUへ向けたオランダ)STマイクロの活用、今後も注目が必要です。



クリエイタ的エンジニア

エンジニアには、「作業的な人」と「クリエイタ」の2種類が存在。クリエイタ的エンジニアが、New Worldを作っていく。(その3より)

2030年向け先進テクノロジとの正しい付き合い方について、元ソニーCIO(最高情報責任者)、現在はガードナージャパン)エグゼクティブ プログラム シニアアドバイザー エグゼクティブパートナーの⻑⾕島眞時⽒と、ガードナージャパン)アナリストの亦賀忠明⽒の全3回対談記事(2022-10-28、ZDNET Japan)で、筆者が最も印象に残った箇所です。

ごく簡単に内容を抜粋し、クリエイタ的エンジニアへと成長するための記事提言をまとめました。

対談は、マネジメントとエンジニア双方への提言です。本稿は、読者の多いエンジニアに絞って抜粋しました。対談全文は、その1その2その3をご覧ください。

2030年のNew WorldとスーパーパワーAPI

2022年のテクノロジは江戸時代。2030年のテクノロジは、スーパーパワーを持つNew Worldへ劇的変化。
2022年のテクノロジは江戸時代。2030年のテクノロジは、スーパーパワーを持つNew Worldへ劇的変化。

2022年令和4年の現在を、手作業、企業論理中心の江戸時代と呼び、テクノロジ変化がもたらす2030年は、ハイブリッド・ワーク、メタバース、スーパーパワーAPIの新しい時代、これがNew Worldです。

わずか8年間で、テクノロジは、江戸時代から劇的に進化し「全く別のNew World」になります(その1)。

スーパーパワーとは、進化により想像を絶する能力をデジタルテクノロジが持つこと、そして2030年以降は、このスーパーパワーを使いこなせる企業と、そうでない企業が、明確に別れると予想しています(その2)。

スーパーパワーAPIを使ったモノづくりができるエンジニアと企業がNew Worldを作る、と結論しています(その3)。

※スーパーパワーAPI:多様化、高度化した進化テクノロジ境界がAPI(application programming interface)。様々なテクノロジ個々の深い理解は困難だが、API経由での利用は可能。つまり、1つのテクノロジ領域スキルを磨けば、他領域スーパーパワーを利用することは、比較的容易。

自分事、主体的に考える

短期間で劇的変化するNew Worldへは、人も、金も、時間も、他人事、もしくは当事者意識に欠けていては対応できません。

初めから完璧にやる必要はなく、これまで以上にアンテナの感度を上げ、注意深く、主体的に探索し、自ら的確にアクションすることが重要です(その2)。

作業的とクリエイタ的エンジニア

これまでは、決められた作業を的確にこなせる作業的エンジニアが求められました。これらの作業は、自動化やAI、さらにハイパーオートメーションが、とって代わります。

New Worldでは、いろいろな想像・発想ができ、創造ができる「クリエイタ的エンジニア」が活躍する時代です(その3)。

まとめ:クリエイタ的エンジニアは1日にしてならず

クリエイタ的エンジニアは1日してならず
クリエイタ的エンジニアは1日してならず

2030年向け先進テクノロジとの正しい付き合い方の記事は、対談形式のため長文です。盛りだくさんな内容の中から、エンジニア向け提言を抽出しました。

テクノロジが急変、高度化、多様化する時代は、初めから完璧を目指すより継続的改善を行い、主体的に2030年New Worldスキルを持つクリエイタ的エンジニアになれ、と提言しています。

「ローマは一日にして成らず」、クリエイタ的エンジニアも同じです。

2030年はすぐそこです。あせりは禁物ですが、できない理由を考える暇があるなら、できることを認識・判断・実行し、クリエイタ的エンジニアへの第1歩としましょう。

筆者個人は、IoT MCU RTOSテンプレート開発を最初の目標とします。



Cortex-MとRISC-V

NVIDIA買収先で成立見通しが未だに不透明なARM社Cortex-Mと非営利団体運営のRISC-V、両MCUコアの顧客利用動向記事が公開されました(2022年1月14日、ITmedia)。

極簡単に要約すると、ARM顧客の多くが現在NVIDIAと競合関係にあるため、買収成立時、Cortex-M利用の顧客将来製品の代替コア用意(=Plan B)が必要で、代替コアにRISC-Vが急浮上している、という内容です。

ARM顧客とは、エッジAIや車載半導体製品を供給中のMCUベンダ(Renesas、NXP、STマイクロなど)を指します。Plan Bは、代替案と訳されます。これは、実行案Aのトラブル時、Aの次のBが、第2の案という意味です。

半導体業界は常に変化し、これに伴い案A達成に何らトラブルが無くても、その将来性に変化が生じる可能性もあります。“Backup”としてのPlan B必要性を感じた記事です。

オープンアーキテクチャRISC-V

Cortex-M代替として急浮上のRISC-V
Cortex-M代替として急浮上のRISC-V

RISV-Vは、カルフォルニア大学バークレイ校開発のオープンアーキテクチャMCUコアで、Cortex-MのようなCISC(Complex Instruction Set Computer)命令系を、より縮小した命令系(Reduce Instruction Set Computer)へ変え、低電力動作に適すなどの特徴を持ちます。

Cなどの高級言語ソフトウェア開発者にとっては、CISC/RISC差はあまり気になりませんが、コンパイラを開発するMCUベンダにとっては、他社差別化を生む重要なパラメタです。

MCU性能の支配項は、

・MCUコア(CISC or RISC)
・コンパイラ
・製造プロセス(≒最高動作周波数)
・内蔵周辺回路

の4項目で、ARM Cortex-M使用中ベンダなら、MCUコアとコンパイラはARM供給品なので各社共通です。つまり、製造プロセスと内蔵周辺回路でしか他社差別化手段がありません。

NVIDIAがARMを買収した場合、競合他社へのMCUコアやコンパイラ供給に、自社利用品と差を付ける可能性もあります。Cortex-M使用中のMCUベンダ各社が、ARM買収成立を嫌う理由が、これです。

そこで、オープンアーキテクチャでコンパイラ開発自由度も高いRISC-Vコアが、競合他社のCortex-M将来製品コアのPlan Bとして急浮上した訳です。

ARMコアMCU開発で出遅れたRenesasは、早々とRISC-V対応MCU開発を発表しました。NXPやSTマイクロのRISC-Vコア利用は不明ですが、Renesas同様、Plan Bを持っているのは確実です。

我々開発者が、今すぐRISC-V開発を始める必要性は低いと思います。むしろ、Cortex-M代替に、低価格高性能無線機能付きESP-WROOM-32を習得した方が役立つと個人的には思います。RISC-VESP-WROOM-32の関連投稿は、リンク先を参照してください。

MicrosoftのOffice、Windows分離売却可能性

Microsoftが買収を発表した大手ゲーム会社Activision Blizzard
Microsoftが買収を発表した大手ゲーム会社Activision Blizzard

半導体業界の大きな一角を占めるMicrosoftの大手ゲーム会社Activision Blizzard買収ニュースが1月19日発表されました。買収理由は、コチラの記事が示すメタバースです。COVID-19が大きく影響しているコンタクトレス・テクノロジのメタバースは、関連投稿の3章を参照してください。

Microsoft動向で気になるのは、確定内容ではありませんが「OfficeとWindowsを売却すべき」という1月17日発表記事です。Microsoftは営利団体です。Windows 11不具合の多さ、新機能の魅力無さなど、最近のWindowsに対するMicrosoftの力の入れようの低下とも符合します。

OfficeやWindows(特にGUI)は、既に製品完成の域に達しています。手間暇が掛かるDOS-VベースのコンシューマーOS企業と、最新コンタクトレス・テクノロジやAzure、高度セキュリティ投資との親和性も高いパブリッククラウド企業とは、別会社の方が、利用者、投資家にとっても判り易いと思います。

エンタープライズ顧客重視で将来性も高いパブリッククラウド企業地位を、MicrosoftがAmazonやGoogleよりも高めたいなら、足枷の可能性もあるOffice、Windows分離売却も可能性ありと思います。

Plan B評価の違い

M&A:Mergers(合併)and Acquisitions(買収)は、半導体業界では当たり前です。激変する半導体業界のMCUベンダとMicrosoft動向記事を紹介しました。

日本社会では、Plan B評価がまだ低いのですが、MCU開発者として、「個人レベルのPlan B必要性」を感じた記事でした。日本人と外国人上司のPlan B評価の違いは、コチラの記事を参照してください。

組込み開発 基本のキ:RTOS vs. ベアメタル

RTOS vs. BareMetal
RTOS vs. BareMetal

2022年最初の投稿は、RTOSとベアメタルを比較します。RTOSを使わないベアメタルMCU開発者が多いと思いますので、RTOS開発メリット/デメリットをベアメタル側から評価、RTOSデバッグツール紹介とベアメタル開発の意味を考えました。

RTOS目的

Flexible Software Package構成
Flexible Software Package構成

ルネサスRAファミリのFlexible Software Package構成です。左上Azure RTOSやFreeRTOSの中に、ConnectivityやUSBがあります。これらMCU共有資源を管理するシステムソフトウェアがOSで、PCのWindowsやMac、Linuxと機能的には同じです。

Real-Time性が必要な組込み用OSをRTOSと呼び、FreeRTOSやAzure RTOSが代表的です。これは、IoT MCU接続先が、Amazon Web Services(AWS)クラウドならばFreeRTOSライブラリ、Microsoft AzureクラウドならAzure RTOSライブラリ(図のConnectivity)利用が前提だからです。

※2021年のIoTクラウドシェアは、コチラの関連投稿からAWS>Azure>GCPの順です。

RAファミリに限らず、クラウド接続のIoT MCUは、これらRTOSライブラリを使ったRTOS開発になります。

RTOSメリット/デメリット

例えば、ベアメタルでUSB制御を自作する場合は、USB 2.0/3.0などの種類や速度に応じた作り分けが必要です。ライブラリがあるRTOSなら、USBポートへの入出力記述だけで利用可能です。RTOSが共有資源ハードウェア差を吸収し、アプリケーションが使い易いAPIを提供するからです。

RTOSの資源管理とは、MCUコア/Flash/RAM/周辺回路/セキュリティなどの共有資源を、アプリケーション側から隠蔽(≒ブラックボックス化)すること、とも言えます。

RTOSアプリケーションは、複数タスク(スレッドと呼ぶ場合もあり)から構成され、タスク間の優先制御もRTOSが行います。開発者は、単体処理タスクを複数開発し、それらを組み合わせてアプリケーションを構成します。RTOSアプリケーション例が下図、灰色が開発部分、コチラが関連投稿です。

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

RTOS利用メリット/デメリットをまとめます。

メリットは、

・RTOSライブラリ利用により共有資源活用タスク開発が容易
・移植性の高いタスク、RTOSアプリケーション開発が可能
・多人数開発に向いている

デメリットは、

・複数タスク分割や優先順位設定など、ベアメタルと異なる作り方が必要
・共有資源、特にRAM使用量がタスク数に応じて増える
・RTOS自身にもバグの可能性がある

簡単に言うと、RTOSとベアメタルは、「開発作法が異なり」ます。

ソフトウェア開発者は、RTOS利用と引換えに、自己流ベアメタル作法を、RTOS作法へ変えることが求められます。RTOS作法は、標準的なので多人数での共同開発が可能です。もちろん、ベアメタルよりもオーバーヘッドは増えます。このため、RTOS利用に相応しい十分なMCUコア能力も必要です。

RTOSタスク開発 vs. ベアメタルアプリケーション開発

最も効果的なRTOS作法の習得は、評価ボードを使って実際にRTOSタスク開発をすることです。弊社FreeRTOSアプリケーションテンプレートは、この例です。

それでも、RTOSタスク開発作法を文章で記述すると、以下のようになります。

開発対象がアプリケーションからタスク(スレッド)へ変わることが、ベアメタルとの一番の違いです。Windowsタスクバーにあるフィルダ表示や、ペイントなどと同様、タスクは、単機能の小さいアプリケーションとも言えます。

このタスクを複数開発し、複数タスクを使ってRTOSアプリケーションを開発します。タスクには、それぞれ優先順位があり、他のタスクとの相対順位で実行タスクがRTOSにより決まります。タスクの状態遷移が、RTOSへの備え:第2回、タスク管理で示した下図です。

FreeRTOS Task States
FreeRTOS Task States

ベアメタルアプリケーションとは異なり、優先順位に応じてタスクが実行(Running)され、その実行も、定期的に実行可能状態(Ready)や待ち状態(Suspended)、停止状態(Blocked)へRTOSが変えます。これは、リアルタイムかつマルチタスク処理が、RTOSの役目だからです。遷移間隔などは、RTOS動作パラメタが決めます。

ベアメタル開発は、開発者が記述した通りに処理が実行されますが、RTOS開発のタスク実行は、RTOS任せです。RTOS開発難易度の上がる点が、ここです。

一般的なIoT MCUは、シングルコアですので、実行タスク数は1個、多くの他タスクは、Not Running(super state)状態です。RTOSがタスクを実行/停止/復活させるため、スタックやRAM使用量が急増します。

これら文章を、頭の中だけで理解できる開発者は、天才でしょう。やはり、実際にRTOSタスクを開発し、頭の中と実動作の一致/不一致、タスク優先順位やRTOS動作パラメタ変更結果の評価を繰返すことで、RTOS理解ができると凡人筆者は思います。

ベアメタル開発者が手早くRTOSを理解するには、既にデバッグ済みの複数RTOSタスク活用が便利で、FreeRTOSアプリケーションテンプレートは、この要求を満たしています。概要は、リンク先から無料ダウンロードできます。

文章でまとめたFreeRTOS解説が、コチラの弊社専用ページにあります。また、本ブログ検索窓にFreeRTOSと入力すると、タスク開発例などが参照できます。

RTOSデバッグツール

percepio tracealyzer
percepio tracealyzer

さて、RTOS作法に則ってタスク開発し、RTOS動作パラメタも適切に設定しても、思ったように開発タスクが動作しない時は、ブラックボックスRTOS自身のバグを疑う開発者も多いでしょう。RTOSのバグ可能性もありえます。

この疑問に対して強力にRTOS動作を解析できるFreeRTOSデバッグツールがあります。資料が無料でダウンロードできますので、紹介します。

※このツールを使うまでもなく、弊社FreeRTOSアプリケーションテンプレートは、正常動作を確認済みです。

まとめ:RTOS vs. ベアメタル

IoT MCUのクラウド接続 → 接続クラウド先のRTOSライブラリ必要 → RTOSライブラリ利用のRTOS開発が必要、という関係です。

RTOS開発は、ベアメタルと開発作法が異なる複数タスク開発です。タスクは、優先順位に応じてRTOSがMCU処理を割当てます。また、MCU共有資源がRTOSアプリケーションから隠蔽されるため、移植性が高く多人数での大規模開発にも向いています。

一方で、RTOSオーバーヘッドのため、ベアメタルよりも高いMCU能力が必要です。

シングルコアMCUでは、RTOSとベアメタルのハイブリッド開発は困難です。開発者がRTOSを利用するなら、慣れたベアメタル開発から、RTOSタスク開発への移行が必要です。

ベアメタル開発経験者が、効果的にRTOSタスク開発を習得するには、評価ボードと複数RTOSタスクが実装済みの弊社RTOSアプリケーションテンプレートの活用をお勧めします。

ベアメタル開発意味

RTOSのタスク処理待ち(セマフォ/Queue)を使うと、ベアメタルよりも排他/同期制御が簡単に記述できます。それでも、全てのMCU開発がRTOSへ移行することは無いと思います。様々なセンサデータをAD変換するエッジMCUは、ベアメタル開発、エッジMCUを複数個束ねクラウドへ接続するIoT MCUは、RTOS開発などがその例です。

MCU開発の基本は、やはりRTOS無しの「ベアメタル開発」です。

IoT MCU開発者スキルの階層構造
IoT MCU開発者スキルの階層構造

ベアメタル開発スキルを基にRTOSを利用してこそ、RTOSメリットを活かしたタスクやアプリケーション開発ができます。共有資源ブラックボック化、多人数開発のReal-Time OSは、「ベアメタル開発の補完」が起源です。

PC OSとは全く逆のこの生い立ちを理解していないと、効果的なRTOS利用はできません。近年MCU性能向上は著しいのですが、向上分をRTOSだけに振り分けられる程余裕はなく、IoTセキュリティなどへも配分する必要があります。

この難しい配分やRTOS起因トラブルを解決するのが、ベアメタル開発スキルです。弊社マイコンテンプレートは、主要ベンダのベアメタル開発テンプレートも販売中、概要ダウンロード可能です。

組込み開発 基本のキ:バックナンバー

2022年最初の投稿に、筆者にしては長文すぎる(!?)のRTOS vs. ベアメタルを投稿したのは、今年以降、RTOS開発が急速に普及する可能性があるからです。

クラウド接続からRTOS必要性を示しましたが、セキュリティなど高度化・大規模化するIoT MCU開発には、移植性の高さや多人数開発のRTOSメリットが効いてきます。

また、半導体不足が落ち着けば、RTOS向き高性能MCUの新しいデバイスが、各ベンダから一気に発売される可能性もあります。スマホ → 車載 → IoT MCUが、半導体製造トレンドです。

※現状のMCUコア関連投稿が下記です。
Cortex-M33とCortex-M0+/M4の差分
Cortex-M0からCortex-M0+変化
Cortex-M0/M0+/M3比較とコア選択

IoT MCU開発が複雑化、高度化すればする程、前章のベアメタル開発や、組込み開発の基礎技術:基本のキの把握が、開発者にとって益々重要になります。

組込み開発、基本のキ:バックナンバーを示します。年頭、基本を再確認するのはいかがでしょう?
組込み開発 基本のキ:組込み処理
組込み開発 基本のキ:IoT MCUセキュリティ