Azure RTOS習得(3):新規Azure RTOSプロジェクト

Azure RTOS習得3回目は、新規STM32CubeIDE Azure RTOSプロジェクト作成方法と、STM32CubeMX生成ソースコードの、どこに、何を、追加すれば良いかを説明します。

新規「汎用」Azure RTOSプロジェクト

前稿で、STM32G4(Cortex-M4/170MHz)評価ボード:NUCLEO-G474REへArduinoプロトタイプシールドを追加し、最も基本的なAzure RTOS ThreadXサンプルコードのTx_Thread_Creation動作を解説しました。

このTx_Thread_CreationサンプルコードのTx_Thread_Creation .icoから、新規の「汎用」AzureRtos0プロジェクトを作成します。

汎用の意味は、このAzureRtos0プロジェクトへセマフォやキューなどのRTOS機能を追加し、Azure RTOS習得に使うからです。

残念ながら現時点では、STM32G4用Azure RTOSセマフォやキューのサンプルコードは無いため、これらRTOS単独機能を持つプロジェクトを自作する訳です。

AzureRtos0プロジェクトから自作予定のAzure RTOS機能プロジェクトが以下です。

・AzureRtosEventFlagプロジェクト(本稿)
・AzureRtosQueueプロジェクト
・AzureRtosMutexプロジェクト
・AzureRtosSemaphoreプロジェクト

Tx_Thread_Creation .ico

STM32CubeIDE(以下CubeIDE)の新規STM32プロジェクトは、様々な作成方法があります。

ただ、Azure RTOSプロジェクトは、STM32CubeMX(以下CubeMX)の設定に、ベアメタル開発と異なる注意が必要です。このような時は、既に設定済みのCubeMX Configuration File (.ico)を流用すると、注意事項を含んだ新規プロジェクト作成が簡単にできます。

Azure RTOSプロジェクトのCubeMX設定の注意事項は、別途投稿します。本稿は新規Azure RTOSプロジェクト作成に焦点を置き説明します。

新規汎用AzureRtos0プロジェクト作成

Tx_Thread_Creation .icoを流用したAzureRtos0プロジェクト作成手順が下記です。

① CubeIDEのInformation Centerℹ️でStart new project from STM32CubeMX file(.ioc)クリック
② STM32CubeMX ico fileにTx_Thread_CreationのTx_Thread_Creation .ico選択、Project NameにAzureRtos0を入力しFinishクリック

Tx_Thread_Creation.ico流用の新規プロジェクト作成
Tx_Thread_Creation.ico流用の新規プロジェクト作成

③ PA5ユーザラベルをLD2へ変更、PC4とPC5をGPIO Output、ユーザラベルLED1、LED2に設定、PC7をGPIO Input、ユーザラベルS1に設定(LD2は評価ボード、LED1/2、S1は追加Arduinoプロトタイプシールドのポート)

ユーザラベル変更とArduinoプロトタイプシールドポートLED1/2とS1追加
ユーザラベル変更とArduinoプロトタイプシールドポートLED1/2とS1追加

④ Project>Generate Codeをクリックし、初期設定コードとAzure RTOSプロジェクトファイル生成
⑤ main.c L92へ、下記タイトルVCPメッセージ出力HALコード追記

VCPメッセージ出力HALコード追記
VCPメッセージ出力HALコード追記

⑥ ビルドし、評価ボードへダウンロード
⑦ Tera Termなどのターミナルソフトで追記VCPメッセージを確認し、新規汎用AzureRtos0プロジェクト動作確認

新規汎用AzureRtos0プロジェクト動作確認
新規汎用AzureRtos0プロジェクト動作確認

Azure RTOSイベントフラグ機能追加

AzureRtos0プロジェクトへ、イベントフラグを使ってメインスレッドとスレッド1/2間同期を行う機能を追加し、AzureRtosEventFlagプロジェクトを作成します。

このプロジェクトは、Azure RTOS ThreadXサンプルコードと同じ処理内容です。従って、Azure RTOS ThreadXサンプルコードが、AzureRtos0へ追記するコードの代用に使えます。

始めに、AzureRtos0プロジェクトファイルの、どこに、何を追加するかを説明し、次章で実例を示します。

追記ファイル 追加内容
Core>Src>
app_threadx.c
1) UINT App_ThreadX_Init()へ、イベントフラグ生成関数、追加スレッド生成関数
2) 追加スレッドのエントリ関数(メイン関数)
Core>Inc>
app_threadx.h
追加スレッド優先度、プリエンプション閾値などのマクロ

RTOSであっても、ベアメタル開発で機能追加する時と同じ追記ファイルと追加内容です。

違いは、App_ThreadX_Init()の中でイベントフラグや追加スレッドを生成すると、直にRTOS動作を開始(TX_AUTO_START)する点です。従って、ベアメタル関連main.c/hの変更点は、VCP出力メッセージの変更程度です。

つまり、RTOS関連とベアメタル関連、それぞれのメインエントリー(メイン関数)があり、RTOS動作追加だけなら、main.c/hは不変でも構いません。

筆者は、cファイルとhファイルを一緒に記述したい派です。しかし、CubeMXがこれらを分離してRTOS関連ファイルを生成しますので、このファイル分離に従い追記します。

スレッド優先度やプリエンプション閾値を変えれば、Azure RTOS動作が簡単に変わりますので、分離の方が好ましいのかもしれません(動作変更例は、Azure RTOS習得(2)の4章:メインスレッド参照)。

AzureRtosEventFlagプロジェクト作成

AzureRtos0プロジェクトはテンプレートとして様々なプロジェクトで利用しますので、CubeIDEでAzureRtos0プロジェクトをコピーし、別名のAzureRtosEventFlagプロジェクトとしてペーストして使います。ペースト先のAzureRtos0.icoも、AzureRtosEventFlag.icoへRenameします。

これで、AzureRtosEventFlagプロジェクトのひな型ができました。

AzureRtosEventFlagプロジェクトの追記部分抜粋が下記です。追記コードは、Azure RTOS ThreadXサンプルコードです。

CubeMX生成コメントの、/* USER CODE BEGIN … */、/* USER CODE END …*/が、追記ガイドに役立ちます。

※手抜きご希望の方は、Azure RTOS ThreadXサンプルのapp_threadx.cとapp_threadx.hを、そのままAzureRtosEventFlagのapp_threadx.cとapp_threadx.hへ上書きしてもOKです😅。但し、LED1/2への出力は変更してください。

AzureRtosEventFlagプロジェクトへ追記後、ビルドし評価ボードへダウンロードします。

App_threadx.c追加例

app_threadx.c追記ソースコード抜粋
app_threadx.c追記ソースコード抜粋(下線は要変更)

app_threadx.h追加例

app_threadx.h追記ソースコード抜粋
app_threadx.h追記ソースコード抜粋

AzureRtosEventFlagプロジェクト動作確認

AzureRtosEventFlagプロジェクトは、スレッド1がArduinoプロトタイプシールドのLED1制御、スレッド2がLED2制御を行う以外は、Azure RTOS ThreadXサンプルコードと同じ動作です。

従って、同じ動作を確認しAzureRtosEventFlagプロジェクト作成の成功です。

作成したAzureRtosEventFlagプロジェクトを使って、イベントフラグの制御、スレッド1/2優先度やプリエンプション閾値変更によるArduino LED 1/2動作変化を確認し、イベントフラグ機能を習得してください。

本稿で作成したAzure RTOSイベントフラグの機能は、前稿で説明済みですので、割愛します。

まとめ

Azure RTOS ThreadXサンプルコードのTx_Thread_Creation.icoを流用した、新規汎用AzureRtos0プロジェクト作成方法を示しました。

汎用AzureRtos0プロジェクトに、RTOS機能別プロジェクト例として、イベントフラグ機能を追加したAzureRtosEventFlagプロジェクトを作成し、Azure RTOS ThreadXサンプルコードと同じ動作を、評価ボードにArduinoプロトタイプシールド追加し確認しました。

機能追加したAzureRtosEventFlagプロジェクトにより、汎用AzureRtos0プロジェクトソースコードのどこに、何を追記するかを示しました。

今後、AzureRtos0プロジェクトへセマフォなどの機能を追加し、Azure RTOS機能別習得をすすめます。

付記:日本語文字化け対策

デフォルトのSTM32CubeIDEとSTM32CubeMXを使ってプロジェクト開発時、日本語文字化けが発生します。過去投稿済みの対策を付記します。

STM32CubeMXのプロジェクトGenetate Code実行「前」に、
STM32CubeIDEの設定変更
① Windows>Windows>Prefernces>Colors & font>文字セットを「日本語」へ設定
② Project>Properties>Text file encordhingをOthers:「Shift-JIS」へ設定

以上で、Genetate Codeしソースコードが上書きされても、日本語文字化けは無くなります。

Azure RTOS習得(2):Azure RTOS ThreadXサンプルコード

Azure RTOS習得2回目は、STM32G4 Azure RTOS ThreadXサンプルコードを解説します(コチラの投稿3章でAzure RTOS開発ツール動作確認に使ったコード)。

STM32G4 Azure RTOS ThreadXサンプルコードは、スレッド優先度とプリエンプション閾値を、スレッド実行時に変更する例と、スレッド間同期にイベントフラグを用いる例を示しています。

STM32G4 Azure RTOS ThreadXサンプルコードの3スレッド

注意)サンプルコードのプリエンプション閾値とREADME記述が異なります。正しくは下記です。

スレッド名 処理内容

(LD2:評価ボード単体)

優先度 プリエンプション閾値
メインスレッド スレッド1/2優先度と閾値変更→LD2点灯シナリオ制御 5 5
スレッド1 LD2を5秒間500msで点滅 10 10
スレッド2 LD2を5秒間200msで点滅 10 9

評価ボード:NUCLEO-G474REは、ユーザLED:LD2を1個実装しています。1個のLD2を2個のスレッド1/2で制御するため、点滅間隔を変えることでどちらのスレッド制御かを示します。また、メインスレッドとスレッド1/2間の同期に、Azure RTOSイベントフラグを用います。

この評価ボードに、2個LED1/2、1個SWを実装したArduinoプロトタイプシールドを追加し、各スレッド処理を、下記のように工夫しました。

スレッド名 処理内容

(LD2:評価ボード+

LED1/LED2/S1:Arduinoプロトタイプシールド

優先度 プリエンプション閾値
メインスレッド スレッド1/2優先度と閾値変更→LD2点灯シナリオ制御 5 5
スレッド1 LED1を5秒間500msで点滅 10 10
スレッド2 LED2を5秒間200msで点滅 10 9

評価ボード単体で複数スレッド動作を確認するよりも、断然判り易くなります。

もちろん、評価ボード単体でも確認可能です。しかし、イベントフラグだけでなくセマフォなど今後様々なAzure RTOS機能習得にも、Arduinoプロトタイプシールド追加は、役立ちます。

また、VCP:Virtual Com Portへメッセージを出力する工夫も加え、タイトルやエラー表示を行います(評価ボード+Arduinoプロトタイプシールド動作例は、5章図)。

イベントフラグ

Microsoft公式Azure RTOS ThreadXサイト第 3 章:Azure RTOS ThreadX 機能を開き、右コラム“この記事の内容”のイベント フラグをクリックすると、イベント フラグの説明が示されます。要旨を抜粋すると、

・イベントフラグは、スレッド間同期手段。32フラグ単位グループ化可能、待ちタイムアウトなどあり
・tx_event_flags_set でフラグ設定、tx_event_flags_get でフラグ取得(AND/OR演算可能)
第 4 章:APIに、tx_event_flags_setやtx_event_flags_getの詳細記述

例えば、4章でtx_event_flags_set は、ソースコードへひな型をコピー&ペーストできる形で表現されています。

tx_event_flags_setのAPI
tx_event_flags_setのAPI

スレッド1/2

以下、説明が簡単になるので、オリジナル評価ボードソースにコメント追記したコードで説明します。

スレッド1/2は、初期設定+無限ループの簡単で単純な構成です。

スレッド1(評価ボード単体動作ソースコード)
スレッド1(評価ボード単体動作ソースコード)

スレッド1は、500msトグルを5秒間繰返し、5秒経過後、イベントフラグ:THREAD_ONE_EVTをセットします。スレッド2は、200msトグルとイベントフラグ:THREAD_TWO_EVTがスレッド1と異なるのみです。

フラグセットAPI失敗時は、Error_Handle内で停止します。

メインスレッド

メインスレッド(評価ボード単体動作ソースコード)
メインスレッド(評価ボード単体動作ソースコード)

メインスレッドは、LD2点滅シナリオを作成します。優先度が5で高優先なので、低優先スレッド1/2からのイベントフラグセットを常時ゲットできます。

スレッド1/2優先度は同一の10ですが、L170でスレッド1のイベントフラグを永遠に待つので、スレッド2はスレッド1と多重動作ができません。

スレッド2のプリエンプション閾値が9なのに、スレッド1が先に動作するのは、スレッド1がtx_thread_createで先に生成、開始(TX_AUTO_START)するからです。試しに、スレッド2を先に生成すると、LD2は200ms点滅から始まりシナリオは進みません。スレッド1→2の生成順序なら、スレッド2のプリエンプション閾値は、10でもLD2は、同じシナリオで点滅します。

スレッド1のイベントフラグを得た後、スレッド2優先度と閾値を(8、8)へ変更するのは、スレッド2単独動作のためです。その後、L179でスレッド2のイベントフラグを永遠に待ちます。

スレッド2のイベントフラグを得ると、スレッド2優先度と閾値を元の(10、9)へ変更します。このシナリオを3回繰返します。

シナリオ終わりにスレッド1/2をterminateさせるのは、動作不要だからです。terminateしなくても、メインスレッドプリエンプション閾値が5なので、スレッド1/2は動作しません。従ってLD2動作シナリオは変わりません。

シナリオは変わりませんが、terminateをコメントアウトした時のThreadX Thread Listとオリジナルの時のListが下記です。不要スレッドは、Terminate Stateへ入れると他へ影響を与えないメリットがあります。

スレッド1と2 terminate有無の差
スレッド1と2 terminate有無の差

RTOS習得とArduinoプロトタイプシールド追加

ベアメタル開発のLチカ理解に相当するのが、本稿説明のスレッド間同期イベントフラグをはじめとする多様なRTOS機能理解です。

本稿サンプルコード動作程度であれば、ベアメタルで開発する方が簡単です。但し、ベアメタルでは、動作に必要な機能を全てユーザが開発します。

一方、RTOS開発では、RTOSが提供する機能を活用し、残りの差分をユーザ開発しさえすればアプリが完成します。下図のようにベンダー提供資産(RTOS、セキュリティなどのミドルウェアやドライバ)有効活用が、現代的MCUユーザアプリケーション開発の肝です。RTOS機能が多すぎるのが、玉に瑕ですが…😂。

現代的ユーザMCU開発の例(出展:The ST blog)
現代的ユーザMCU開発の例(出展:The ST blog)

RTOS活用で、ユーザアプリケーションが資産化できます(RTOSの目的が、アプリケーション資産化なので当然です)。

メインスレッド章で説明したように、スレッド1/2はそのままで、RTOSのスレッド生成順序やプリエンプション、イベントフラグのみでLD2点滅シナリオ変更が簡単にできます。ソフトウェア規模が大きくなれば、このメインテナンス性の良さが活きてきます。

多様なAzure RTOS機能を手間なく効率的に学ぶには、Arduinoプロトタイプシールドを評価ボードに追加し、思いついたRTOS機能を直に試すことをお勧めします。

Arduinoプロトタイプシールド追加により、スレッド毎の動作を別々のLEDで目視でき、メインスレッドがスレッド2の優先度、閾値を変更しない場合、スレッド1と並列動作するか等々、様々な試行を簡単に確認できます。この試行で、ベアメタル開発経験も活かせます。

つまり、過去に開発したベアメタル機能が、RTOSに有るか無いかを、多くのRTOS機能をふるい(経験)にかけながらRTOS習得ができる訳です。

今後のAzure RTOS習得は、Arduinoプロトタイプシールドを評価ボードへ追加した構成で、新規Azure RTOSプロジェクトをRTOS機能毎に作成し行います。

新規Azure RTOS機能プロジェクト作成方法は、次回投稿予定です。

評価ボードへArduinoプロトタイプシールドを追加しスレッド毎にLED点滅中
評価ボードへArduinoプロトタイプシールドを追加しスレッド毎にLED点滅中

まとめ

STM32G4 Azure RTOS ThreadXサンプルコードを解説しました。本稿で説明したAzure RTOS APIは、下記です。

・スレッド間同期イベントフラグ:tx_event_flags_set/getと、待ち処理
・スレッド優先度、プリエンプション閾値変更:tx_thread_priority/preemption_change
・スレッド終了:tx_thread_terminateと、Terminate State目的
・スレッド生成:tx_thread_createと、TX_AUTO_START、生成順序

優先度とプリエンプション閾値をスレッド実行時に変更できる機能は、スレッド開発が容易で流用性を高め、ユーザ開発アプリケーションの資産化に効果があります。

ユーザLEDが1個のみ搭載の評価ボードを使い複数スレッド動作を確認するよりも、2個LEDやユーザS1搭載のArduinoプロトタイプシールド追加により、RTOS APIパラメタ変更時の各スレッド動作確認が容易です。

意図しないスレッド並列処理も直ぐに判るので、効率的にAzure RTOS習得ができます。Arduinoプロトタイプシールド付属の小さなブレッドボード利用も試行実験に便利です。

多くのパラメタを持つAzure RTOS効率的習得に、評価ボード+Arduinoプロトタイプシールドをお勧めします。

Azure RTOS習得(1):習得方針

Microsoft公式Azure RTOS ThreadXサイト
Microsoft公式Azure RTOS ThreadXサイト

Microsoft公式、Azure RTOS ThreadXサイトを紹介します。

前稿最後で示したSTM32G4 Azure RTOS ThreadXサンプルコード付属readme.html理解には、Azure RTOS ThreadX基礎知識が必要です。基礎知識獲得には、Microsoft公式サイトが最適です。

本稿は、公式サイトを簡単に説明し、今後のAzure RTOS習得方針を示します。

Azure RTOS習得方針

筆者は、物事を効率的に理解する時、初めはあまり細部に拘らず全体を俯瞰的に捉え、次の段階で不明な点を明らかにする、既に知っている事柄と比較する、などの方法を好みます。

Azure RTOS習得も、この方法でアプローチしたいと思います。

これは、FreeRTOS習得(2020年版)と同じ方法です。その結果、開発したのがNXP版FreeRTOSアプリケーションテンプレートです。

最終的には、STM32G4 Azure RTOS ThreadXサンプルコード付属readme.html理解とST版Azure RTOSアプリケーションテンプレート開発、2022年版Azure RTOS習得サイト作成が目標です。

Azure RTOS ThreadX公式ユーザガイド

公式サイトトップページには、Azure RTOS概要と、ユーザガイドのショートカットが掲載されています。概要は、疲れた時や気分転換時に読むとして、肝心のAzure RTOS ThreadXユーザガイドをクリックします。

現れるのが、Azure RTOS ThreadXユーザガイド目次です。

第 1 章:Azure RTOS ThreadX 概要とリアルタイム組込み開発
第 2 章:Azure RTOS ThreadX インストール
第 3 章:Azure RTOS ThreadX 機能動作
第 4 章:Azure RTOS ThreadX API
第 5 章:Azure RTOS ThreadX アプリケーションドライバー作成
第 6 章:Azure RTOS ThreadX デモアプリケーション

第3章が、Azure RTOS ThreadX理解ポイントのようです。

Azure RTOSとFreeRTOS比較:状態遷移図、優先度

Azure RTOS(左)とFreeRTOS(右)状態遷移比較
Azure RTOS(左)とFreeRTOS(右)状態遷移比較

RTOS理解に必須なのが、スレッド/タスクの状態遷移です。左が第3章:記載のAzure RTOS、右が弊社FreeRTOS習得記載のFreeRTOS状態遷移です。Azure RTOSは、全5状態ありFreeRTOS比+1、スレッド登録後、即Suspendedになる遷移もあります。

RTOS処理対象を、Azure RTOSはスレッド、FreeRTOSはタスクと呼びます。

優先度は、Azure RTOSは数値が小さい方が高く、FreeRTOSは大きい方が高い、つまり真逆です。

などのAzure RTOSとFreeRTOSの違いが第3章から判ります。

Azure RTOS ThreadXサンプルコードキーワード

・ThreadX、Thread、Event flags、Preemption threshold

前稿最後で示したSTM32G4 Azure RTOS ThreadXサンプルコード付属readme.html記載のキーワードです。サンプルコード理解には、これらが重要であることを示しています。

公式ユーザガイド第3章日本語訳によると、Preemption thresholdとは、プリエンプション閾値のこと。Azure RTOS独特の高度機能です。この部分の要旨を抜粋すると、

・プリエンプション閾値利用で、プリエンプションを無効にする優先度の “上限” を指定可能。上限より高い優先度スレッドは、引き続きプリエンプト可能だが、上限より低いスレッドは、プリエンプト不可。
・優先度20スレッドが、15~20優先スレッドグループやり取りで説明。優先度20スレッドは、セクション処理中、プリエンプション閾値を15 に設定すると、他の全スレッドのプリエンプションを防止。
・これにより、非常に重要なスレッド (優先度 0 から 14 まで)は、クリティカルセクション処理中でもスレッドをプリエンプトでき、応答性が大幅に向上。
・スレッドでプリエンプション閾値を0に設定し、全プリエンプションを無効にすることも可能。また、プリエンプション閾値は実行時に変更可能。

英語原本の機械翻訳だと思いますので、解り難い箇所もありますが、今はOKとしましょう😂。

プリエンプション:Preemptionとは

プリエンプションとは何かを、IT用語辞典から抜粋しました。

・RTOSが、実行中のスレッド/タスクを強制的に一時中断し、他のスレッド/タスク実行に切り替えること。
・このRTOS切り替えを「コンテキストスイッチ」(context switching)と呼び、プリエンプションで停止していたスレッド/タスクを再開させる操作を「ディスパッチ」(dispatch)と呼ぶ。
・殆どの現代RTOSは、「プリエンプションを利用」し処理を時分割多重。
・歴史的には、スレッド/タスク側が自ら決めたタイミングで自発的にRTOSへ制御を返却するノンプリエンプティブマルチタスク、あるいは、協調的マルチタスクもあった。

Azure RTOS/FreeRTOS、どちらもプリエンプションを利用します(FreeRTOSは本稿:状態遷移参照)。違いは、Azure RTOSが、スレッド毎にプリエンプション閾値を持つこと。RTOS任せにせずスレッドが、明示的に優先度制御を行う点です。

STM32G4 Azure RTOS ThreadXサンプルコードは、このスレッドによる優先度変更とイベントフラグが解れば解析できそうです(次回解析予定)。

まとめ

Microsoft公式Azure RTOS ThreadXサイトを利用したAzure RTOS習得方針を示しました。

STM32G4 Azure RTOS ThreadXサンプルコード付属readme.html理解に、Azure RTOS ThreadXユーザガイド第3章から、

・Azure RTOSとFreeRTOS状態遷移は異なる
・Azure RTOS優先度は0が最高位、FreeRTOSは値が大きい程優先度が高く、両者は真逆
・Azure RTOSスレッド応答性を向上させるPreemption threshold:プリエンプション閾値機能がある

などが判りました。この方針に則って、Azure RTOS習得を続けます。

STM32 Azure RTOS開発ツール拡充

2022年4月20日、STマイクロエレクトロニクス(以下ST)は、Azure RTOS開発ツールを拡充し、より幅広いSTM32MCU対応を発表しました。拡充したSTM32MCUリストが下記です。

List of STM32 with X-Cube-AZRTOS Package(出典:The ST blog)
List of STM32 with X-Cube-AZRTOS Package(出典:The ST blog)

弊社販売中STM32G0xテンプレートで使ったSTM32G0や、テンプレート開発中のSTM32G4も、Azure RTOS開発が容易になりました。

CMSIS RTOSからAzure RTOSへ

今回の発表前までは、販売中のNXP版FreeRTOSアプリケーションテンプレートに続き、STM32G4を使ってST版“CMSIS-RTOS”アプリケーションテンプレートを構想していました。

しかし、今回のAzure RTOS開発ツール充実発表を受け、“CMSIS-RTOS”から“Azure RTOS”対応へ変更することにしました。STのAzure RTOSサンプルコードが活用でき、また、Microsoft公式Azure RTOS情報もあるからです。

※ARM社規定のCMSIS RTOSは、FreeRTOSやAzure RTOSをラップ(wrapper)するRTOSです。同じCMSIS RTOS APIでFreeRTOSまたはAzure RTOSが使え、開発アプリケーション流用性は高まります。但し、ラップ関数分のオーバーヘッドが生じます。詳しくは、構想投稿の4章を参照してください。

STがAzure RTOS開発ツールMCUを拡充した背景は、Microsoft Azureクラウド接続IoT MCUの急増だと思います。リストアップした9種のSTM32MCUが、IoT MCU有力候補と言えます。

Azure RTOS開発ツールインストール方法

STM32G4を例に、Azure RTOS開発ツールインストール方法を示します。現在のSTM32G4開発ツールが、下記版数です。

・STM32CubeIDE v1.9.0               (以下CubeIDE)
・STM32CubeMX v6.5.0               (以下CubeMX)
・STM32Cube FW_G4 v1.5.0        (以下FW_G4)
・X_CUBE_AZRTOS_G4 v1.0.0    (以下AZRTOS_G4)

X-CUBE-AZRTOS-G4が、今回発表したSTM32G4のAzure RTOS開発ツールです。

FreeRTOSは、CubeMXのMiddlewareに実装済みです。一方、Azure RTOS は、ExpansionsパッケージのAZRTOS_G4によりCubeMXへ機能追加します。Expansionsパッケージ追加のため、少し手間がかかります。

① CubeIDEのHelp>Manage Embedded Software Packagesクリック
② Embedded Software Packages ManagerのSTMicroelectronicsタブ選択
③ X_CUBE_AZRTOS_G4のAvailable Version 1.0.0を選択し、Installクリック

X-CUBE AZRTOS-G4のインストール
X-CUBE AZRTOS-G4のインストール

AZRTOS_G4インストール後、使用コンポーネントの選択が必要です。

④ CubeMXのPinout & Configurationタブ内Software Packsをクリック
⑤ Select Components(Alt+O)を開き、Software Packs Component Selectorで追加Azure RTOSコンポーネント:RTOS ThreadX/File system FileX/USB LevelX…などを選択し、OKクリック

STM32G4評価ボード:NUCLEO-G474REを使う場合は、RTOS ThreadXを選択し、Core/Low Power supportを選択すれば十分です。但し、念のため、Performance InfoやTraceX supportも選択しておきます。

インストールしたAzure RTOS ThreadX版数が、6.1.8であることも判ります。

Software Packs Component Selector
Software Packs Component Selector

Azure RTOS ThreadXサンプルコードインポートと動作確認

インストールしたAZRTOS_G4が正常動作するかをAzure RTOS ThreadXサンプルコードと評価ボード:NUCLEO-G474REで確かめます。確認方法が下記です。

① CubeIDEのInformation CenterからImport STM32Cube exampleをクリック
② STM32 Project from STM32Cube ExamplesのExample Selectorタブで、BoardのName:NUCLEO-G474RE、Middleware:ThreadXを選択

STM32G4評価ボード:NUCLEO-G474REのAzure RTOSサンプルコード
STM32G4評価ボード:NUCLEO-G474REのAzure RTOSサンプルコード

STM32G4 Azure RTOS ThreadXサンプルコードは、現在3個です。最も基本的な、

③ Tx_Thread_Creationを選択し、Finishクリック。CubeIDEへTx_ThreadX_Creationサンプルコードがインポート。
④ CubeIDEのTx_Thread_Creation.iocをクリックし、CubeMXで、Generate Code(Alt+K)を実行
⑤ CubeIDEでTx_Thread_Creationをビルドし、評価ボードへダウンロード
⑥ 評価ボードのLED2が、500ms点滅と200ms点滅を3回繰返し、その後1秒点滅に変わる

以上で、STM32G4 Azure RTOS開発ツールのX_CUBE_AZRTOS_G4インストールを、ThreadXサンプルコードで動作確認しました。

使用したTx_ThreadX_Creationサンプルコードの説明は、次週以降に行う予定です。直ぐ知りたい方は、Tx_ThreadX_Creationフォルダ内readme.htmlを参照してください。

まとめ

STが、STM32G0やSTM32G4、STM32U5などのIoT MCUに対し、Azure RTOS開発ツール拡充を発表しました。

STM32G4を例に、CubeMXへExpansionsパッケージのX_CUBE_AZRTOS_G4でAzure RTOS機能の追加方法、Azure RTOS ThreadXサンプルコードインポート、NUCLEO-G474REでThreadXサンプルコードの動作確認をしました。

STM32G0(Cortex-M0+/64MHz)、STM32G4(Cortex-M4/170MHz)、STM32U5(Cortex-M33/160MHz)は、弊社IoT MCUテンプレートの開発対象です。

今回の発表を受け、STM32G4のRTOSを、CMSIS-RTOSからAzure RTOSへ変更し、ST版Azure RTOSアプリケーションテンプレート開発を計画中です。

好奇心とMCU開発

好奇心とMCU開発
好奇心とMCU開発

何を楽しい、面白いと感じるかは、人それぞれです。しかしながらMCU開発者の方々は、ソフトウェアやハードウエアを、自分で研究開発することに面白さや好奇心を持つ点は共通だと思います。

MCU開発は、地味です。普通の人からは、動作して当然と見られがち、しかし、その開発には努力や苦労も必要です。MCU開発者は、それら努力を他者へ説明はしません。
専門家へのキャリアアップには、避けては通れないからです。

特に日本のMCU開発者は、他者がどのように自分を見るかを気にし、しかも、同調意識も強いので、面白さを感じる感性を忘れ、自信喪失などに陥るかもしれません。

そんな時は、スマホを生んだSteve Jobs氏の、“Stay hungry, stay foolish” を思い出してください。

“Stay hungry, stay foolish”

様々な日本語訳、その意味解説があります。筆者は、Jobsは、他者の視線や動向より自分の好奇心を忘れるな、と言っているように思います。

2007年発表スマートフォン:iPhoneは、“Stay hungry, stay foolish”のJobsだから生み出せた製品です。

COVID-19、ウクライナ危機

終息が見えないCOVID-19やウクライナ危機による新しい世界秩序は、半導体製造/流通、MCU/PCセキュリティなどMCU開発者が関係する事柄にも多大な影響を与えそうです。今後数年間は、環境激変の予感がします。

既成概念やトレンド、これまでの市場予測なども大きく変わる可能性もあります。アンテナ感度を、個人レベルでも上げて対処しましょう。

MCU開発は楽しい?

行動の源は好奇心です。“Stay hungry, stay foolish”、 自分の好奇心は自ら満たし、MCU開発を楽しみましょう。

本稿の目的は、新年度:4月からMCU開発を新に始める方々へのアドバイスと、好奇心に逆らえず、Windows 11要件を満たさないPCをアップグレードした顛末を次週投稿予定という、前振りです😅。

STM32 Innovation Day 2021の歩き方

メタバース会場Mapとメニュー
メタバース会場Mapとメニュー

11月10日(水)から本投稿日12日(金)17時まで開催中のSTマイクロエレクトロニクス主催、オンライン・コンファレンスとAI、Security&Cloud、Ecosystem展示会場の歩き方を説明します。インターネット仮想空間:メタバースの移動方法です。

メタバース会場Mapと移動方法

ログインし会場入り口はこちらをクリックすると、表示されるのが最初の図、左下が会場Map、右上がメニューです。

Map内●が、現在位置:会場入り口、が、移動可能な6位置を示します。図中央の位置の移動や視点を変える方法は、Google Mapと同じ要領です。左下の+-△▽などでも移動可能です。メニューは、移動ショートカットです。

つまり、STM32 Innovation Day 2021会場が、インターネット上の仮想空間(メタバース:後述)で実現され、このメタバース内をGoogle Mapの方法を使って自由に移動するしくみです。

コンファレンスとバーチャル展示会

メタバース内は、ライブ配信のコンファレンスと、期間中いつでも入れる5か所のバーチャル展示会の2つから構成されます。

毎日13:00から17:00までのライブ配信コンファレンスは、日程の時のみコンファレンス内容が視聴可能です。一方、バーチャル展示会は、開催期間中は、24時間いつでも視聴ができます。

追記:各種資料(※基調講演および一部セッションを除く)は、11月30日(火)17:00までダウンロード可能なので、イベント開催期間中に参加できなかった方や、もう一度ご覧になりたい方は、利用できるそうです!

バーチャル展示会内操作

Product展示会の操作
Product展示会の操作

Product位置へ移動した例が上図です。「製品・デモ」をクリックすると、パネル内容に関する日本語説明員による動画、開発ボード説明やダウンロード資料などが入手できます。

つまり、現実の展示会と同じです。残り4か所の展示会へのGoogle Map移動が少し面倒ですが、各展示会とも同じ構成ですので楽しめます。位置移動は、ブラウザの戻る(履歴)や「MAP」クリックの方が簡単です。

アンケート回答でボードが当たるかも?

右下「退出する」クリックで示されるアンケートに答えると、大量370名に当たる開発ボードプレゼントキャンペーンが実施中です。もちろん、これら開発ボードは、前章の5展示会でその詳細が確認できます。ブラウザ履歴で展示会へ戻り、応募ボード内容を再確認するのも良いでしょう。

メタバース

メタバースとは、メタ (meta-) とユニバース (universe) の合成語です(Wikipediaより)。今回のSTM32 Innovation Day 2021では、アバターは使いませんが、今後は、自分のアバターと会場説明員アバターが登場し、技術解説や質問・回答を行うなど、現実世界をより仮想化した展示会やコンファレンスへ発展するかもしれません。

COVID-19の影響で、人の密集を避ける会議やイベントは、メタバースやアバター活用がトレンドです。一部ゲーマー向けだった高性能GPU搭載PCが、ビジネス分野へも普及するきっかけになります。PCやスマホ超高性能化が、MicrosoftやMeta(旧Facebook)の狙いでしょう。

クラウドベースMCU開発(個人編)

クラウドベースMCU開発お役立ちリンク
クラウドベースMCU開発お役立ちリンク

ARMが、2021年10月19日、IoT関連製品の開発期間を平均5年から最大2年間短縮できるクラウドベース開発環境「Arm Total Solution for IoT」発表という記事(EE Times Japan)は、以下の点で興味深いです。

・IoT製品化に平均5年もかかるのか?

・ハードウェア完成を待ちソフトウェア開発着手するのか?

但し、クラウドがMCU開発に効果的で、GitHubなどのクラウドリンクが今後増えることは、疑う余地がありません。そこで、すきま時間に個人レベルで役立つクラウドMCUリンクを3点示します。

すきま時間お役立ちクラウドMCU開発リンク

クリエイティブなMCUハードウェア/ソフトウェア開発中は、集中時間と空間が必要です。COVID-19の影響で、開発場所や通勤環境に変化はあるものの、ちょっとした待ち時間や出先での2~3分程度のすきま時間は相変わらず存在します。

個人レベルのIoT MCU開発支援が目的の弊社は、このような短いすきま時間にスマホやタブレットを使って、MCU情報を収集、閲覧するのに便利なリンクを紹介します。

すきま時間にMCU関連情報を閲覧することにより、集中時間に凝り固まった開発視点を新たな視点に変える、最新情報を収集するなどが目的です。

STマイクロMCU技術ノート

STマイクロMCU技術ノートの一部(PDF内容は濃く全てのMCU開発で役立つTips満載)
STマイクロMCU技術ノートの一部(PDF内容は濃く全てのMCU開発で役立つTips満載)

STマイクロのSTM32/STM8シリーズ別に検索できる日本語MCU開発Tips満載リンクです。ログインが必須ですが、わずか数ページで説明されたダウンロードPDF内容は濃く、STユーザに限らず全てのMCU開発者に役立つTipsが得られます。

EDN Japan Q&Aで学ぶマイコン講座

EDN Japan Q&Aで学ぶマイコン講座の一部
EDN Japan Q&Aで学ぶマイコン講座の一部

EDN JapanのMCU情報リンクです。Q&Aで学ぶマイコン講座は、最初の1ページでMCU初心者、中級者からの質問に対する回答要点が示されています。2ページ以降で回答詳細を説明するスタイルですので、短時間での内容把握に適しています。

Digi-Keyブログ

Digi-Keyブログの一部(日本語タイトルは翻訳された記事を示す)
Digi-Keyブログの一部(日本語タイトルは翻訳された記事を示す)

日本語タイトルで日本語へ翻訳されたブログ記事が判るリンクです。大手サプライヤーの英語ブログですのでMCUだけでなく、幅広いデバイス情報が得られます。すきま時間でも読めるように記事は短く纏まっています。最新MCU情報やハードウェア開発者向け情報が多いのも特徴です。

IoT製品とプロトタイプ開発

EE Timesの2021年10月8日、半導体製品ライフサイクルの長さと製造中止対策の記事に、20年前、1990年代の事業分野別の製品開発リードタイムとライフサイクル変化が示されています。

事業分野別の開発リードタイムと製品のライフサイクル変化(出展:記事)
事業分野別の開発リードタイムと製品のライフサイクル変化(出展:記事)

1998年の値ですが、重電機器を除く製品開発時間(リードタイム)が2.3年以内という数値は、現在でも納得できます(0.5年程度のプロトタイプ開発時間は含んでいない実開発時間だと思います)。

MCUベンダ各社は、10年間のMCU供給保証を毎年更新します。つまり、2021年更新ならば、2031年迄の10年間は販売MCUの供給を保証するということです。

但し、セキュリティが重視されるIoT製品では、最新セキュリティハード/ソフト内蔵IoT MCUによる製品化をエンドユーザは望みます。SoC:System on a Chipによる製造プロセス進化により、IoT関連製品の開発期間は、再開発も含めると1998年よりも更に短くなる可能性もあります。

前章リンク情報を活用し、最新セキュリティ内蔵MCU状況、セキュリティ機能のOTA更新可能性、開発製品がエンドユーザのセキュリティニーズと開発コストを満たすか、などを個人でも常時把握・評価し、万一、開発製品の成功見込みが少なくなった場合には、MCU見直しなども必要でしょう。

IoTセキュリティのライフサイクルは変動的で、かつ、IoT製品の市場獲得に支配的です。短い開発時間中であっても、状況に応じてMCUを変更することは、製品の成功と失敗に直結します。

弊社MCUテンプレートを使ったプロトタイプ開発は、このような激変IoT製品開発のMCU評価に適しています。制御系MCUと被制御系を分離、低コスト、少ない手間でプロトタイプを早期に開発し、プロトタイプ実機によりIoT製品のMCU評価、適正判断ができるからです。

もちろん、最初に示したバーチャルなArm Total Solution for IoTとの併用も有効です。セキュリティ重視IoT製品開発の成功には、IoT MCU選択と開発期間の短さがポイントです。

AI、Security&Cloud、Ecosystem オンライン・コンファレンス

AI、Security&Cloud、Ecosystem(=開発環境)の3日間オンライン・コンファレンスと展示会が、STマイクロ主催でライブ配信されます。STM32ユーザは勿論、他社ユーザでも組込みシステム開発ヒントの可能性があります。

STM32 Innovation Day 2021 11月10日~12日(オンライン)
STM32 Innovation Day 2021 11月10日~12日(オンライン)

AI、Security&Cloud、Ecosystemプログラム概要

11月10日(水)~12日(金)の毎日13時~17時間のライブ配信で、登録すればお好きな内容のみ視聴も可能です。登録方法は、後で示します。

AI、Security&Cloud、Ecosystemのプログラム概要
AI、Security&Cloud、Ecosystemのプログラム概要

詳細プログラムは、コチラからダウンロードできます。

見どころ

10日(水)AI:STM32MCUでの組込みエッジAIデモ。

11日(木)Security&Cloud:Cortex-M33コアSTM32U5、セキュリティ・フレームワークSTM32Trust、AWSクラウド。

12日(金)Ecosystem:STM32MCU機能安全ソフトウェア・パッケージ、Azureクラウド。

13:30~14:00の各分野エキスパートによる基調講演、バーチャル・イベント会場の最新製品紹介やデモなども面白そうです。

他社ユーザの方は、利用中MCUとの差分が明確に判る絶好のチャンスです。

登録方法

事前に、コチラで仮登録し、折返しメールで10分以内に本登録します。

コンファレンス後、アンケートに回答するとMCU評価ボードなどが当選するかもしれません。

Cortex-M4評価ボードRTOSまとめ

低価格(4000円以下)、個人での入手性も良い32ビットARM Cortex-M4コア評価ボードのRTOS状況を示します。超低価格で最近話題の32ビット独自Xtensa LX6ディアルコアESP32も加えました。

Vendor NXP STマイクロ Cypress Espressif Systems
RTOS FreeRTOS
Azure RTOS
CMSIS-RTOS FreeRTOS
Mbed OS
FreeRTOS
Eva. Board LPCXpresso54114 NUCLEO-G474RE CY8CPROTO-063-BLE ESP32-DevKitC
Series LPC54110 STM32G4 PSoC 6 ESP32
Core Cortex-M4/150MHz Cortex-M4/170MHz Cortex-M4/150MHz
Cortex-M0+/100MHz
Xtensa LX6/240MHz
Xtensa LX6/240MHz
Flash 256KB 512KB 1024KB 480KB
RAM 192KB 96KB 288KB 520KB
弊社対応 テンプレート販売中 テンプレート開発中 テンプレート検討中 未着手

※8月31日、Cypress PSoC 6のRTOSへ、MbedOSを追加しました。

主流FreeRTOS

どのベンダも、FreeRTOSが使えます。NXPは、Azure接続用のAzure RTOSも選択できますが、現状はCortex-M33コアが対応します。ディアルコア採用CypressのRTOS動作はM4側で、M0+は、ベアメタル動作のBLE通信を担います。STマイクロのCMSIS-RTOSは、現状FreeRTOSをラップ関数で変換したもので実質は、FreeRTOSです(コチラの関連投稿3章を参照してください)。

同じくディアルコアのEspressifは、どちらもRTOS動作可能ですが、片方がメインアプリケーション、もう片方が通信処理を担当するのが標準的な使い方です。

価格が上がりますがルネサス独自32ビットコアRX65N Cloud Kitは、FreeRTOSとAzure RTOSの選択が可能です。但し、無償版コンパイラは容量制限があり、高価な有償版を使わなければ開発できないため、個人向けとは言えません。

※無償版でも容量分割と書込みエリア指定など無理やり開発するトリッキーな方法があるそうです。

クラウドサービスシェア1位のAWS(Amazon Web Services)接続用FreeRTOSが主流であること、通信関連は、ディアルコア化し分離処理する傾向があることが解ります。

ディアルコア

ディアルコアで通信関連を分離する方式は、接続クラウドや接続規格に応じて通信ライブラリやプロトコルを変えれば、メイン処理側へ影響を及ぼさないメリットがあります。

例えば、STマイクロのCortex-M4/M0+ディアルコアMCU:STM32WBは、通信処理を担うM0+コアにBLEやZigBee、OpenThreadのバイナリコードをSTが無償提供し、これらを入れ替えることでマルチプロトコルの無線通信に対応するMCUです。

メイン処理を担うM4コアは、ユーザインタフェースやセンサ対応の処理に加え、セキュティ機能、上位通信アプリケーション処理を行います。

通信処理は、クラウド接続用とセンサや末端デバイス接続用に大別できます。

STM32WBやCY8CPROTO-063-BLEが採用した末端接続用のBLE通信処理を担うディアルコアのCortex-M0+には、敢えてRTOSを使う必要は無く、むしろベアメタル動作の方が応答性や低消費電力性も良さそうです。

一方、クラウド接続用の通信処理は、暗号化処理などの高度なセキュティ実装や、アプリケーションの移植性・生産性を上げるため、Cortex-M4クラスのコア能力とRTOSが必要です。

デュアルコアPSoC 6のFreeRTOS LED点滅

デュアルコアPSoC 6対応FreeRTOSテンプレートは、現在検討中です。手始めに表中のCY8CPROTO-063-BLEのメイン処理Cortex-M4コアへ、FreeRTOSを使ってLED点滅を行います。

と言っても、少し高価なCY8CKIT-062-BLEを使ったFreeRTOS LED点滅プログラムは、コチラの動画で紹介済みですので、詳細は動画をご覧ください。本稿は、CY8CPROTO-063-BLEと動画の差分を示します。

CY8CPROTO-063-BLE のCortex-M4とM0+のmain_cm4.c、main_cm0p.cとFreeRTOSConfig.hが下図です。

PSoC 6 CY8CPROTO-063-BLE FreeRTOS LED点滅のmain_cm4.cとmain_cm0.c
PSoC 6 CY8CPROTO-063-BLE FreeRTOS LED点滅のmain_cm4.cとmain_cm0.c
PSoC 6 CY8CPROTO-063-BLEのFreeRTOSConfig.h
PSoC 6 CY8CPROTO-063-BLEのFreeRTOSConfig.h

日本語コメント追記部分が、オリジナル動画と異なる箇所です。

RED LEDは、P6[3]ポートへ割付けました。M0+が起動後、main_cm0p.cのL18でM4システムを起動していることが判ります。これらの変更を加えると、動画利用時のワーニングが消えCY8CPROTO-063-BLE でFreeRTOS LED点滅動作を確認できます。

PSoCの優れた点は、コンポーネント単位でプログラミングができることです(コチラの関連投稿:PSoCプログラミング要点章を参照してください)。

PSoCコンポーネント単位プログラミング特徴を示すCreator起動時の図
PSoCコンポーネント単位プログラミング特徴を示すCreator起動時の図

PSoC Creator起動時の上図が示すように、Cypressが想定したアプリケーション開発に必要なコンポーネントの集合体が、MCUデバイスと言い換えれば解り易いでしょう。つまり、評価ボードやMCUデバイスが異なっても、使用コンポーネントが同じなら、本稿のように殆ど同じ制御プログラムが使えます。

PSoC 6 FreeRTOSテンプレートも、単に設定はこうです…ではなく、様々な情報のCY8CPROTO-063-BLE利用時ポイントを中心に、開発・資料化したいと考えています。PSoCプログラミングの特徴やノウハウを説明することで、ご購入者様がテンプレートの応用範囲を広げることができるからです。

STM版CMSIS-RTOSアプリケーションテンプレート構想

販売中のNXP版FreeRTOSアプリケーションテンプレートに続いて、STマイクロエレクトロニクス版CMSIS-RTOSアプリケーションテンプレート構想を示します。

IoT MCU開発者にRTOS開発経験とスキルが必須であること、短期で効率的にRTOSスキルを磨けるSTマイクロエレクトロニクス版CMSIS-RTOSアプリケーションテンプレート構想を示し、汎用性、セキュリティ、広い流用性を持つSTM32G4をターゲットMCUにした理由を示します。

IoT MCU開発者スキル

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

IoT MCU開発者は、ベアメタルMCU開発スキルの上に、FreeRTOSやAzure RTOSなど接続するクラウドに応じたRTOSスキルが必要です。クラウド接続後、顧客要求のIoTサービスを実装しますが、実装時には、競合他社より早い開発スピードなどの差別化スキルも要求されます。

更に、IoTセキュリティや、より高性能なデュアルコアMCUへの流用、顧客横展開など、発展性への配慮も必要です。これらは、図示したようにベアメタルMCU開発スキルを基礎とする階層構造です。
※スキルとは、開発経験に基づいた手腕、技量のことです。

RTOS開発経験とスキル

全てのモノをネットワークへ繋ぐ時代は、従来のMCUからIoT MCUへの変革が必要です。IoT MCU開発者にとってRTOS開発経験とスキルは、近い将来必須になります。理由が下記です。

・RTOSライブラリ利用がクラウド接続に必須  👉①IoT MCU急増への備え
・大規模MCU開発にRTOSが便利(≒必須)   👉②開発規模拡大への備え
・ベアメタル開発よりもRTOS開発が効率的   👉③ソフトウェア資産への備え(補足参照)

つまり、過去何度も提言されたMCUソフトウェア資産化・部品化を、RTOSが実現するからです。逆に、IoT MCU開発では、このソフトウェア資産化・部品化(ライブラリ活用)無しには、実現できない規模・技術背景になります。
※例えば、IoTセキュリティだけでも専門家が対応すべき領域・規模・技術背景になりそうです。

IoT MCU開発の成功には、様々な専門家技術が活用できる土台のRTOSは必須です。IoT MCU開発専門家の一員となるには、RTOS開発経験とスキルは必須と言えるでしょう。

効率的RTOSスキル習得

ベアメタル開発経験者の効率的なRTOS基礎固め、スキル取得を弊社STM版CMSIS-RTOSアプリケーションテンプレートの目的とします。

この目的は、NXP版FreeRTOSアプリケーションテンプレートと同じです。違いは、NXP版がFreeRTOSを用い、STM版は、コード生成ツール:STM32CubeMXが出力するCMSIS-RTOSを用いる点です。

現時点のSTM版CMSIS-RTOS APIは、FreeRTOS APIをラップ(wrapper)したもので、中身はFreeRTOSそのものです。※CMSIS-RTOS詳細は、コチラの関連投稿を参照してください。

ベアメタル開発経験者のRTOS基礎固め・スキル獲得を、短期・効果的に達成するには、

・基本的RTOS待ち手段(タスク同期:セマフォとタスク間通信:Queue)理解
・RTOSプロトタイプ開発にも使える弊社テンプレートプロジェクト活用

が適しています。

既に持っているベアメタル開発経験を活かし、例えば、単独RTOSサンプルプロジェクトでは得られない複数タスク優先順位を変えた時の各タスク挙動や、RTOSセマフォ送受失敗時の挙動などスキルアップに役立つ事柄を、自ら評価・判断できるからです。この評価を助けるために、同じ動作のベアメタルプロジェクトもテンプレートに添付します。

効率的にRTOS開発スキルを習得する方法として、自己のベアメタル開発経験を使ってRTOS習得・スキルアップする本手法は、Betterな方法だと思います。

コチラにFreeRTOS習得に役立つ情報をまとめています。ポイントとなる点をざっと掴んで、実際の開発環境で試し、参考書やマニュアルなどの内容を開発者自ら考える、これにより新技術やスキルを、身に付けることができると思います。

STM版CMSIS-RTOSアプリケーションテンプレート構想

STM版CMSIS-RTOSアプリケーションテンプレートも、NXP版同様、同一動作のベアメタルプロジェクトを添付します。

RTOS/ベアメタルどちらのプロジェクトも、ADC入力、LCD出力、SWチャタリング対策入力、LED出力、VCOM入出力の動作確認済みで、プロトタイプ開発着手時のスタートプロジェクトとしても利用可能です。

付属説明資料には、ベアメタル視点からのCMSIS-RTOS説明を加えます。また、テンプレート利用CMSIS-RTOS APIとFreeRTOS APIの対応表も添付する予定です。

CMSIS-RTOSアプリケーションテンプレートをご購入後、ベアメタル開発経験者が、RTOSプロジェクトとベアメタルプロジェクトの比較・評価がスグに始められる構成です。※比較・評価は、ご購入者ご自身で行ってください。

STM32メインストリームMCU比較(出展:STマイクロエレクトロニクスに加筆)
STM32メインストリームMCU比較(出展:STマイクロエレクトロニクスに加筆)

CMSIS-RTOSアプリケーションテンプレート動作環境は、メインストリームMCUのSTM32G4評価ボード:NUCLEO-G474RE(Cortex-M4/170MHz、Flash/512KB、RAM/96KB)とHAL APIを用います。

STM32G4は、高性能で汎用性とIoT MCU基本的セキュティ機能を備え、RTOSテンプレートのターゲットIoT MCUとして最適です。

STM32G4のセキュリティ機能を示したのが下図です。

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

また、STM32G4の汎用性、他MCUへの開発ソフトウェア流用性の広さを示したのが下図です(詳細は、コチラの関連投稿3章を参照してください)。

NUCLEO-G474RE搭載のSTM32G474RETx Compatible MCU List。2021年8月時点で98MCU!
NUCLEO-G474RE搭載のSTM32G474RETx Compatible MCU List。2021年8月時点で98MCU!

NUCLEO-G474RE評価ボードの他には、ArduinoプロトタイプシールドとBaseboardを用います。

つまり、販売中のNXP版FreeRTOSアプリケーションテンプレート評価ボード:LPCXpresso54114が、STマイクロエレクトロニクスNUCLEO-G474REにのみ変化した構成です。

CMSIS-RTOS動作もNXP版と同様、Hardware Independent FreeRTOS Exampleを基としますので、(両テンプレートをご購入頂ければ)STMとNXPのRTOSアプリケーション開発の直接比較なども可能です。

STM版CMSIS-RTOSアプリケーションテンプレートのリリースは、今秋のWindows 10 21H2更新後(Windows 11リリース後かも?)を予定しております。時間的に少し余裕がありますので、Cypress版PSoC 6ディアルコア対応FreeRTOSアプリケーションテンプレートも同時リリースできればBestだと考えています。

補足:③ソフトウェア資産への備え

ベアメタル開発でもソフトウェア規模が大きくなると、開発者が悩む点は、複数処理の待ち合わせ/制御順序です。対策は、処理を細かく分割し、優先度を考慮しつつ順次処理を行うのが常套手段です。

ところが、RTOSを使うと、この面倒な待ち処理や制御順序を、RTOSがタスク優先順位に応じて処理します。しかも、処理分割も、RTOSがTICK_RATE_HZ単位で勝手(!?)に行ってくれます😀。

RTOSにより、タスク数やTICK_RATE_HZ、最大優先順位に応じたスタックを大量に利用しますのでRAM使用量の増加、RTOS自身のオーバーヘッドなど副作用も生じますが、「タスク記述は、超簡単」になります。

初期設定と無限ループ、ループ内のRTOS待ち手段、優先順位を検討すれば、文字通り単一処理タスクを開発し、マルチタスク化はRTOSに任せます。

※ベアメタル開発経験者は、セマフォ、Queue、Mutex、イベントグループなどのRTOS待ち手段を、上記実現のためのAPIと捉えると、RTOS理解が早くなります。
※上記手法を使うと、ベアメタルサンプルプログラムもそのままRTOSへ組込めます。
※最も難しそうなのが優先順位検討ですが、ソース上で簡単に変更できます。
※RTOSマルチタスク処理を100%信頼した上での筆者感想です。

Cortex-M4コアでRTOSが使えMCUのFlash/RAMに余裕があれば、ベアメタル開発よりもRTOS開発の方が効率的に開発できると思います。また、この環境で開発したソフトウェアは、資産として別のRTOS開発へも使えるので個人ソフトウェア資産化も可能です。

上記は、RTOSの筆者感想です。弊社RTOSアプリケーションテンプレートをご購入頂き、各開発者でRTOSに対する独自感想を抱き、短期で効率的にRTOS開発経験とスキルを磨いて頂ければ幸いです。