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 は、ソースコードへひな型をコピー＆ペーストできる形で表現されています。
スレッド1/2
以下、説明が簡単になるので、オリジナル評価ボードソースにコメント追記したコードで説明します。
スレッド1/2は、初期設定＋無限ループの簡単で単純な構成です。
スレッド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へ入れると他へ影響を与えないメリットがあります。
RTOS習得とArduinoプロトタイプシールド追加
ベアメタル開発のLチカ理解に相当するのが、本稿説明のスレッド間同期イベントフラグをはじめとする多様なRTOS機能理解です。
本稿サンプルコード動作程度であれば、ベアメタルで開発する方が簡単です。但し、ベアメタルでは、動作に必要な機能を全てユーザが開発します。
一方、RTOS開発では、RTOSが提供する機能を活用し、残りの差分をユーザ開発しさえすればアプリが完成します。下図のようにベンダー提供資産（RTOS、セキュリティなどのミドルウェアやドライバ）有効活用が、現代的MCUユーザアプリケーション開発の肝です。RTOS機能が多すぎるのが、玉に瑕ですが…😂。
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機能プロジェクト作成方法は、次回投稿予定です。
まとめ
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プロトタイプシールドをお勧めします。
