FreeRTOS/Azure RTOSソフトウェア開発手法

ルネサス公式センササンプルコードを使って、ベアメタル処理を起点とするRTOS(FreeRTOS/Azure RTOS)ソフトウェア開発手法を説明します。

筆者にしては、長い投稿です。要旨は、「ベアメタル処理+RTOS処理待ち=RTOS処理」です。

ベアメタル処理とFreeRTOSタスク処理並列多重
ベアメタル処理とFreeRTOSタスク処理並列多重

センササンプルコード

  1. FS2012 Sample application – Sample Code
  2. HS300x Sample application – Sample Code
  3. ZMOD4xxx Sample application – Sample Code

説明に用いたセンササンプルコードが、上記3種類です。ダウンロードには、ルネサスのログインが必要です。同一動作のベアメタル/FreeRTOS/Azure RTOS、3個のe2studioプロジェクトが同胞されています。動作MCUは、ルネサス)RA/RX/RE/RL78ファミリです。

サンプルコードマニュアルだけは、下記からログイン不要でダウンロードできます。本稿は、これらマニュアル情報だけで読める工夫をしました。

  1. FS2012 Sample application
  2. HS300x Sample application
  3. ZMOD4xxx Sample application

FS2012がガスフローセンサ、HS300xが湿度・温度センサ、ZMOD4xxxが高性能ガスセンサです。この順番で、サンプルコードが複雑になります。

そこで、焦点を、一番簡単なFS2012サンプルコード、動作MCUをRA6M4(Cortex-M33/200MHz/1MB Flash/256KB RAM)に絞って説明します。他サンプル/MCUでも同様の結果が得られます。

なお、3サンプルコードは、ベアメタルからRTOS開発へステップアップする時にも適したコードです。

センサとMCU間接続:I2C

PMODインタフェースによるセンサボードとMCU接続
PMODインタフェースによるセンサボードとMCU接続

センサとMCU間は、サンプルコード全てPMOD経由のI2C接続です。従って、I2C接続センサのIoT MCU制御例としても応用可能です。FreeRTOSとAzure RTOS、両方に対応した点が便利です。

PMODとは、米Digilent社規定のオープンインタフェース規格です。図示のように、複数センサボードを、レゴブロックのようにMCUへ追加接続できる特徴があります。

ベアメタルとFreeRTOS/Azure RTOSメモリ量

FS2012サンプルコードマニュアルより抜粋した使用メモリ量比較です。

ベアメタル FreeRTOS Azure RTOS
Flash 1065 bytes 1374 bytes 1342 bytes
RAM 73 bytes 249 bytes 246 bytes

RTOSは、ベアメタル比1.3倍のFlash使用量、3.4倍のRAM使用量です。但し、上表にRTOSタスク/スレッドのスタックメモリ量は含みません。

Flash/RAM使用量が増加しますが、RTOS開発ソフトウェア流用性が高まるメリットがあります。これら増加分は、ベアメタル単体処理からRTOSマルチタスク/スレッド処理のオーバーヘッドに相当すると考えて良いでしょう。

マルチタスク/スレッド以外にも、RTOS開発には、クラウド接続/セキュリティ/OTA(Over The Air)処理などのオーバーヘッドが別途必要です。

これら処理のため、IoT MCUは、ベアメタル比、Flash/RAM量の十分な余裕と高速動作が必要になります。

FS2012センサAPI使用方法

FS2012フローセンサの使用APIとその利用手順です。一般的なセンサでも同様で、特に変わった点はありません。

FS2012 APIと利用手順
FS2012 APIと利用手順

ベアメタル処理フロー

RTOS開発の起点となるベアメタル開発の処理フローです。

FS2012のベアメタル処理フロー
FS2012のベアメタル処理フロー

初期設定で、I2Cとセンサを初期化し、無限ループ内で、センサデータ取得と取得データの演算を繰返します。センサデータの連続取得に409.6ms遅延時間が必要であることも判ります。センサデータ取得完了は、センサ割込みを使って検出しています。

このベアメタル処理フローも、特に変わった点はありません。

RTOS処理フロー

ベアメタルと異なる処理だけを橙色抜粋したFreeRTOS処理フローです。

ベアメタル処理とRTOS処理のフロー差分
ベアメタル処理とRTOS処理のフロー差分

差分は、RTOS遅延:vTaskDealy()/tx_thread_sleep()で409.6msと1msが加わる点、vTaskDelete()/tx_thread_delete()でタスク削除する点です。

また、センサ制御本体は、タスク/スレッド記述へ変更し、セマフォにより別タスク/スレッドとの排他制御を行います。

1ms遅延は、別タスク/スレッド切替えに必要です(関連投稿のコチラ、6章コンテキストスイッチ参照)。FS2012サンプルは、タスク/スレッド数が1個なので切替え不要です。

しかし、例えば、HS300xセンサボードを、FS2012センサボードへレゴブロック様式で追加した時は、FS2012センサとHS300xセンサの2タスク/スレッドを、この1msスリープでRTOSが切替えます。

FS2012センサは、ベアメタル処理フローで示したデータ取得間隔に409.6ms遅延処理が必要です。この遅延中に、HS300xセンサのデータ取得を行えば、両タスク/スレッドの効率的な並列多重ができ、これにセマフォ排他制御を用います。

※RTOS遅延処理は、本稿最後の補足説明参照。RTOSメリットが具体的に判ります。

この切替え処理が、本稿最初の図で示したRTOS処理待ちに相当します。その他のRTOS処理フローは、ベアメタル処理と同じです。

つまり、RTOS処理とは、単体のベアメタル処理へ、RTOS処理待ちを加え、複数のベアメタル処理を並列処理化したものです。

数式的に表すと、「ベアメタル処理+RTOS処理待ち=RTOS処理」です。

RTOS(FreeRTOS/Azure RTOS)ソフトウェア開発手法

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

ベアメタル処理を、効率的に複数並列動作させるのがRTOSの目的です。

この目的のため、優先制御や排他、同期制御などの多くの機能がRTOSに備わっています。RTOSの対象は、個々のベアメタル処理です。つまり、ベアメタル開発スキルを起点・基盤としてその上層にRTOS機能がある訳です。

RTOS習得時、多くの機能に目移りします。しかし、本稿最初の図に示したように、RTOSは、複数ベアメタル処理(タスク/スレッド)を、優先度や排他・同期条件に応じて切替え並列多重化します。

逆に、ベアメタル側からRTOSを観ると、セマフォ/Queueなど「RTOSによる処理待ち」がベアメタル無限ループ内に入っただけに見えます。「待ち/解除の制御は、RTOS」が行います。待ち処理の種類が、セマフォ/Queue/イベントフラグ……など様々でも、「ベアメタル側からは単なる待ち」です。

筆者が、RTOS開発の起点はベアメタル処理、とした理由が上記です。

つまり、ベアメタル起点RTOSソフトウェア開発手順は、

1:単体ベアメタル処理開発。単体デバッグ後、タスク/スレッド化。
2:タスク/スレッド無限ループ内へ、RTOS処理待ち挿入。
3:複数タスク/スレッド優先度を検討し、RTOS結合デバッグ。

以上で、RTOSソフトウェア開発ができます。

処理自体は、1でデバッグ済みです。2以降は、効率的RTOS処理待ち挿入と、複数タスク/スレッド間の優先度検討が、主なデバッグ内容です。複数タスク/スレッドが想定通り並列動作すれば、第1段階のRTOSソフトウェア開発は完了です。

スタックメモリ調整やより効率的な待ち処理などのチューニングは、3以降で行います。

RTOS待ち処理は、セマフォやQueueの利用頻度が高いため、RTOS習得もセマフォ/Queueを手始めに、より高度な待ち処理機能(イベントフラグなど)へと順次ステップアップしていけば良いでしょう。

ベアメタル開発経験者が感じるRTOS障壁

ベアメタルは、開発者自身が全ての制御を行います。ところが、RTOS開発では、ソースコード内に、自分以外の第3者:RTOSが制御する部分が混在します。ここが、ベアメタル開発経験者の最初のRTOS違和感、RTOS障壁です。

前章の手法は、1でベアメタル処理を完成すれば、2以降は、RTOS処理のデバッグに集中できます。つまり、既に持っているベアメタルスキルと新しいRTOSスキルを分離できます。これで、最初に感じたRTOS障壁は小さくなります。

また、RTOS障壁は、IoT MCUクラウド接続時の通信処理やセキュリティ処理時に、MCUベアメタル開発経験者に大きく見えます。しかし、これらの処理は、決まった手順で当該ライブラリやAPIを順番に利用すれば良く、一度手順を理解すれば、本当のRTOS障壁にはなりません。

クラウド接続やセキュリティ処理サンプルコードを入手し、各API利用手順の理解後は、これら該当処理の丸ごと流用でも十分に役立ちます。

まとめ:RTOSソフトウェア開発手法

IoT MCU RTOSソフトウェア開発の3分野
IoT MCU RTOSソフトウェア開発の3分野

IoT MCUは、クラウド接続のためRTOS開発になります。IoT MCU RTOS開発は、データ収集、クラウド接続、エッジAIやIoTセキュリティなど、大別すると3分野に及びます(関連投稿:世界最大情報通信技術(ICT)サービス輸出国、アイルランドIoT事情)。

本稿は、センササンプルコードを使い、ベアメタルスキル起点・基盤としたデータ収集分野のRTOSソフトウェア開発手法を説明しました。

1:単体ベアメタル処理開発。単体デバッグ後、タスク/スレッド化。
2:タスク/スレッド無限ループ内へ、RTOS処理待ち挿入。
3:複数タスク/スレッド優先度を検討し、RTOS結合デバッグ。

数式的に示すと、「ベアメタル処理+RTOS処理待ち=RTOS処理」です。

クラウド接続とエッジAI/IoTセキュリティ分野は、決まった手順のRTOSライブラリ活用などが主な開発内容です。従って、この分野は、差別化の努力は不要です。

IoT MCU RTOS開発で、他社差別化できるデータ収集RTOSソフトウェア開発の手法を説明しました。

RAベアメタルテンプレート発売中

RAベアメタルテンプレート概要
RAベアメタルテンプレート概要

2022年5月にRAベアメタルテンプレート(1000円税込)を発売しました。本稿説明のRTOS(FreeRTOS/Azure RTOS)ソフトウェア開発には、ベアメタルスキルが必須です。

RAベアメタルテンプレートにより、開発ツール:FSP(Flexible Software Package)やe2studioの使い方、豊富なベアメタルサンプルコードを活用したベアメタル開発スキルが効率的に得られます。ご購入は、コチラから。

RA版RTOSテンプレート(仮名)は、検討中です。

NXP版FreeRTOSテンプレート発売中

NXP版FreeRTOSテンプレートも発売中です。また、本年度中には、ST版Azure RTOSテンプレートも、開発・発売予定です。

弊社ブログは、RTOS関連も多数掲載済みです。ブログ検索窓に、FreeRTOSやAzure RTOSなどのキーワードを入力すると、関連投稿がピックアップされます。

補足説明:RTOS遅延処理

RTOS遅延処理のvTaskDealy(409.6ms)/tx_thread_sleep(409.6ms)は、他タスク/スレッドの処理有無に関わらず409.6msの遅延時間を生成します。これは、ベアメタル開発者にとっては、夢のようなRTOS APIです。

このようにRTOSは、開発ソフトウェアの独立性・流用性を高めるマルチタスク/スレッド動作を実現し、ベアメタルの補完機能を提供します。

つまり、ベアメタル開発中に、他処理の影響を受けるので開発が難しいと思う部分(例えば、上記遅延処理など)があれば、RTOSのAPI中に解が見つかる可能性があります。

あとがき

長い投稿にお付き合いいただき、ありがとうございました。

ベアメタル開発経験者がRTOS習得・開発を目指す時、サンプルコード以外の情報が多すぎ、途中でくじけそうになります。本稿は、サンプルコードとベアメタルスキルを活かしRTOS開発へステップアップする手法を示しました。RTOSでも、基本はベアメタルスキルです。

RTOSサンプルコードが豊富にあれば、必要情報の絞り込み、RTOSスキル向上も容易です。掲載RTOSサンプルコードは、非常に貴重だと思いましたので、RTOSソフトウェア開発手法としてまとめました。

1GHz 64ビットMPU量産開始

1GHz/64ビットMPU:RZ/A3UL評価ボード構成
1GHz/64ビットMPU:RZ/A3UL評価ボード構成

2022年8月ルネサスは、最大動作周波数1GHz 64ビットMPU、RZ/A3ULの量産を始めました。本プログメインカテゴリのMCU(マイコン)では無く、比較対称のMPU(マイクロプロセッサ)のことです。

より高度なHMI(Human Machine Interface)を実現するためRTOS(FreeRTOS/Azure RTOS)採用、RISC-Vコア搭載機RZ/Fiveとも互換性を持たせる作りです。肥大化するソフトウェア資産流用、活用に重点を置いています。

ところで、2022年8月9日ITmediaのPCとは何だったのか記事の最初のページには、PC(CPU)が16→32→64ビットへと変わった41年の歴史が、23回連載記事タイトルからも判ります(詳細は、連載記事参照)。

本稿で言いたいのは、MCU(マイコン)も近い将来GHzクラス高速化へ向かうだろうと言うことです。

MCU → IoT MCU

未だに8/16ビット機も現役のMCUは、CPU程の紆余曲折や派手さはありませんが、着実に高速・大容量化が進行中です。制御規模が小さく、スタンドアロン処理も可能なMCUなので8/16ビット機でも現役です。

しかし、時代はIoT、全ての制御対象がネットワークに繋がります。OTA(Over The Air)によりセキュリティ更新や、制御ソフトウェア変更もIoT MCUでは可能です。これら処理は、セキュリティライブラリや決まった更新手順で実施されます。

つまり、プリミティブなMCU制御から、よりアプリケーション寄り、場合によってはRTOS前提のIoT MCU制御へ変わらざるを得ない状況になりつつあります。自力でこれらを開発する猛者もいるでしょう。しかし、これらは、本来注力すべき開発差別化部分ではありません。

MCUハードウェア/ソフトウェアともに、市場獲得に向けて他社差別化を狙う部分と、IoTクラウド接続達成部分を、コストパフォーマンス高く共立する、これがIoT MCUの要件です。

CPU/MPU製造技術やソフトウェアのMCU転用は、過去、上記要件の解となってきました。大容量Flash内蔵が前提MCUと、外付けRAM前提CPU/MPUのハードウェア差はありますが、その転用速度は、今後更に早まると思います。

高度なHMIを体験すると元に戻れないように、MCU+クラウド→IoT MCUを顧客が体験すると、元のスタンドアロンMCUには戻れません。

ドライバ → 個別API → HAL API → マルチタスク

IoT MCUソフトウェア開発の変遷
IoT MCUソフトウェア開発の変遷

MCUソフトウェアも、40年前のドライバ開発、20年前のMCU個別API開発、10年前からはMCU共通HAL(Hardware Abstraction Layer) API開発へと変わりました。MCUソフトウェア資産化も、もはや夢ではありません。

開発部分がアプリケーション層に近づけば近づくほど、オーバーヘッドは増えます。オーバーヘッド増大や各種セキュリティライブラリなどの有効活用、RTOS利用によるマルチタスク開発には、IoT MCUの64ビット化、GHzクラス高速化も必然だと思います。

ビット幅増大は、各種巨大ライブラリ流用のためです。ここは32ビットでも十分かもしれません。しかし、高速化は、オーバーヘッド対策や、場合によってはMPU同程度の高度HMI処理、クラウドエッジでのAI処理など、IoT MCU機能実現には必須です。

製造業経済規模 → 縮小中の日本

我々開発者は、前章のIoT MCUソフトウェア開発の変遷を見ただけでもかなりの大変さ、自助努力が開発に必要であることを実感できます。

しかし、日本は、世界の先進国とは異なります。大変さや努力に対し報われることが期待できません。

日本が先進国で唯一、製造業の経済規模が縮小している国という記事や、労働者不足が、COVID-19のせいではないという記事を読むと、その理由と現状が判ります。

世界第2位から降下中の日本
世界第2位から降下中の日本

諸外国の真似をせよという気はありません。が、このままでは気が付けば、後進国になりかねないのが、今の日本です。

今こそ、日本開発者「個人」で変化に対応すべきです。少しずつでも、IoT MCUへ準備を始めませんか?

弊社NXP版FreeRTOSテンプレートは、FreeRTOSプロジェクトと同じ動作のベアメタルプロジェクトも添付済みです。アプリケーションレベルでRTOSとベアメタルを比較しながら技術習得が可能です。是非、ご活用ください。また、ST版Azure RTOSテンプレートも本年度中には開発予定です。

最後は、宣伝となってしまいました。すいません。

Azure RTOS習得(6):低電力動作

STM32G4評価ボードのAzure RTOS低電力動作サンプルコード:Tx_LowPowerは、現在正常に動作しません。原因は、Stop1モード開始/Run復帰処理であることは判りました(下表の青部分)。

そこで、この低電力モード開始/復帰処理を、VCPメッセージ出力へ変更、低電力動作は保留し、Azure RTOS低電力動作プロジェクト作成方法と低電力動作の流れを説明します。

処理名 処理内容:低電力動作

(LD2:評価ボード単体)

優先度 プリエンプション閾値
メインスレッド 1) セマフォ取得を永遠に待つ
2) 取得時LD1 500ms点滅を10回実施
10 10
S1プッシュ割込み セマフォカウンタ=0時、セマフォ放出
Enter_LowPower_Mode Stop1モード開始処理 ➡ VCPメッセージ出力
Exit_LowPower_Mode Runモード復帰処理 ➡ VCPメッセージ出力

まとめ

STM32G4評価ボードのAzure RTOS低電力動作サンプルコード:Tx_LowPowerは、Stop1モード開始/Run復帰に問題があり正常動作しません。

そこで、Stop1モード開始/復帰処理を保留にし、Azure RTOS低電力動作プロジェクト作成方法と低電力動作の流れを説明しました。

Azure RTOSプロジェクトで低電力動作させるには、STM32CubeMXのConfiguration ThreadXタブLow PowerのEnter LowPower SupportとTX_LOW_POWER_TICKNESSをEnableにするだけです。

Enable後、CubeMX生成のApp_ThreadX_LowPower_Enter/Exitの中身:Enter/Exit_LowPower_Modeへ、STM32G4低電力動作7モードの設定/Run復帰処理を記述すれば、Azure RTOS低電力動作ができます。

Tx_LowPower動作

サンプルコード:Tx_LowPower の正常な動作が下記です。

1) S1プッシュでLD1が10回点滅後、Enter_LowPower_Mode実行しStop1停止
2) S1プッシュ割込処理でExit_LowPower_Mode実行しRun復帰

つまり、S1プッシュ毎にLD1が10回点滅し、その後、低電力Stop1モードで待機します。Stop1状態表示はありません。

Stop1モード動作の代わりにVCPメッセージ出力が下記です。S1プッシュでLD1が10回点滅、点滅中はVCPメッセージ出力無しです。違いは、Stop1モード動作有無です。

Stop1モード動作の代わりのVCP出力
Stop1モード動作の代わりのVCP出力

「非」動作対策の保留(NOP)

STM32CubeMXは、プログラムフレームワーク生成に優れています。Enter/Exit_LowPower_Mode内容のみを変更すれば、Stop1以外のStop2モードやSleepモードへの低電力動作変更が簡単にできます。

ちなみに、筆者は、Sleepモードへも挑戦しましたが、正常動作はしませんでした。
※Enter/Exit_LowPower_Mode正常化をご教授頂ける方は、メールを頂けると助かります。

そこで、このEnter/Exit_LowPower_Mode処理は、一旦、保留(NOP)とします。

Tx_LowPowerが正常化した後、改めて保留にしたEnter/Exit_LowPower_Mode処理を入れ替えれば済むからです。現状は、NOPの代わりにVCPメッセージ出力処理を選びました。

この保留対策で、Azure RTOS低電力動作プロジェクト作成方法と低電力動作の流れ理解の段階へ進めます。

Azure RTOS低電力動作プロジェクト作成方法

Azure RTOS Low Powerプロジェクト作成
Azure RTOS Low Powerプロジェクト作成

低電力動作有りと無しのプロジェクト作成差は、CubeMXのConfiguration ThreadXタブのLow Powerを開き、Enter LowPower SupportとTX_LOW_POWER_TICKNESSをEnableにするだけです。

App_ThreadX_LowPower_EnterとApp_ThreadX_LowPower_Exitは、CubeMXが生成する関数名です。この両関数の中身が、我々が開発するEnter/Exit_LowPower_Mode関数です。

つまり、Enter/Exit_LowPower_Mode中身を変えれば、その他の部分はそのままで、様々な低電力動作、例えばSleepやStop2へ対応できる作りになっています。フレームワーク生成に優れるSTM32CubeMXの利点です。

低電力動作の流れ

全てのスレッドが、待機状態になると、App_ThreadX_LowPower_Enterとその中身Enter_LowPower_Modeが実行されます。その結果、例えば、Sleepが低電力動作の場合には、MCUコアSleep+周辺回路動作になります。

割込み発生でApp_TreadX_LowPowerとその中身Exit_LowPower_Modeが実行されRun復帰、最優先スレッドが実行されます。

この低電力動作に関して、公式Azure RTOSサイトに記述は有りません。低電力動作は、個別MCU依存のためでしょう。

STM32G4低電力動作モード

STM32G4の7つの主要低電力モード(出典:STM32G4 - PWR)
STM32G4の7つの主要低電力モード(出典:STM32G4 – PWR)

そこで、STM32G4の低電力動作をまとめました。元資料は、STM32G4 – PWRLPTIMです。

STM32G4は、7種の低電力動作モードをサポートしています。Runウエイクアップ時間が11サイクルと短く、電力低減効果も高いSleepが筆者のお勧めです。

サンプルコードのEnter/Exit_LowPower_Mode処理が複雑なのは、更に効果の高いStop1だからです。

サンプルコード対応

・サンプルコードが無い時は、他の評価ボードから流用。
・サンプルコードに問題ありの時は、当該処理をNOP化、サンプルが示す内容取得。

サンプルコードは、開発TipsやKnow Howの宝庫です。しかし、残念ながら付属説明は、最低限です。説明するとキリが無いからです。そこで、弊社は、ベアメタル開発経験がある方を対象に、少し丁寧に説明を追加したつもりです。

サンプルコードと評価ボードさえあれば、実際にMCU動作が確認ができ、1から10まで記載の分厚いユーザマニュアルを読むよりも、手軽で効率的にMCU開発ができます。

サンプルコードにも、トラブルがあります。STM32G4評価ボード:NUCLEO-G474REを使ったAzure RTOS習得(2)~(5)用のサンプルコード対応をまとめたのが、本章最初の2行です。また、(2)~(5)で使ったサンプルコード名と内容が下表です。

サンプルコード名 サンプル内容(詳細リンク先参照) 備考
AzureRtos0 汎用Azure RTOSプロジェクト作成 NUCLEO-G474RE+Arduinoプロトタイプシールド動作
AzureRtosEventFlag スレッド間イベントフラグ同期 STM32G4サンプル流用動作
AzureRtosQueue スレッド間キューメッセージ送受信 NUCLEO-G0B1RE流用動作
AzureRtosMutexSema ミューティックス/バイナリセマフォ排他制御 STM32G0C1E-EV流用動作
AzureRtosLowPower 低電力動作プロジェクト作成(本稿) STM32G4サンプル非動作

最近のMCU開発は、HAL(Hardware Abstruction Layer)API利用のため、サンプルコード流用が簡単です。個別MCUハードウェアに依存しないためです。

便利なサンプルコードを活用すれば、効率的なMCU開発ができます。更に、複数サンプルコードを流用し、プロトタイプの早期開発が容易な弊社MCUテンプレートを使えば、開発効率は上がります。

STM32G4評価ボードとArduinoプロトタイプシールド、LCDやADC動作のBaseboardを使ったST版Azure RTOSテンプレート(仮名)は、年内開発予定です。NXP版FreeRTOSテンプレートは、コチラで販売中です。

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

Azure RTOSやFreeRTOSは、IoT MCU開発に必要です。ベアメタルLチカ理解に相当するRTOS機能コンポーネントの習得、個人レベルで初めてはいかがでしょう。

Azure RTOS習得(5):Mutexとセマフォ

Azure RTOSミューテックスとバイナリセマフォを使ったプロジェクトを作成し、スレッド間の排他制御方法を説明します。Azure RTOSでは、ミューテックスとバイナリセマフォが、同じ機能であることも判ります。

先にまとめ、次に詳細の順で説明します。

ミューテックスとバイナリセマフォは同じ動作結果
ミューテックスとバイナリセマフォは同じ動作結果

まとめ

Azure RTOS排他制御には、ミューテックスやリソースアクセス数1のバリナリセマフォが使われます。

STM32G4評価ボードにミューテックスとバリナリセマフォサンプルコードが無いため、STM32G0C1E-EVのTx_Thread_Syncサンプルコードを流用し、AzureRtosMutexSemaプロジェクトを作成しました。

作成したAzureRtosMutexSema プロジェクトを使い、Azure RTOS排他制御を、STM32G4評価ボードにArduinoプロトタイプシールドを追加し、ミューテックスは、バイナリセマフォと同じ動作結果をもたらすことを示しました。

リソースアクセス数2以上のカウントセマフォは、排他制御だけでなくイベント通知にも使えますが、優先度逆転など注意事項もあります。

本稿説明のAzure RTOS APIは、下記です。

・ミューテックス/セマフォ取得:tx_mutex / semaphore_getと、TX_NO_WAIT
・ミューテックス/セマフォ開放:tx_mutex / semaphore_put
・スレッド処理中断:tx_thread_sleepと、コンテキストスイッチ
・セマフォ優先度の逆転、ミューテックス優先度の継承と、TX_INHERIT / TX_NO_INHERIT

単純なAzure RTOS排他制御は、ミューテックス利用が良さそうです。

STM32G4 Azure RTOSサンプルコード探し

STM32G4(Cortex-M4/170MHz)評価ボード:NUCLEO-G474REへのAzure RTOSサンプルコードは、現在3個、この中にミューテックスやセマフォを使うサンプルコードはありません。

対策は、キューサンプルコードの前稿と同じです。CubeIDEのInformation Centerℹ️でImport STM32CubeMX exampleをクリックし、Example SelectorタブでThreadXにチェックを入れて流用できるサンプルコードを選定します。

選定したSTM32G0C1E-EVのTx_Thread_Suncコードを、STM32G4へ流用します。

STM32G4 Azure RTOSミューテックスとバイナリセマフォサンプルコードの探し方
STM32G4 Azure RTOSミューテックスとバイナリセマフォサンプルコードの探し方

Tx_Thread_Syncプロジェクト

ミューテックスやセマフォは、スレッド間の排他制御に用います。しかし、サンプルプロジェクト名は、“Sync”:同期となっていて違和感があります。

サンプルプロジェクトのreadme.htmlを読むとミューテックスとバリナリセマフォを使っていますので、ミューテックスとバイナリセマフォの排他制御利用例であることは、間違いありません。

サンプルの2つのスレッドは、それぞれLED点灯の独立した制御です。プロジェクトが示したいのは、LED点灯の直列制御、この直列化のため、ミューテックス、または、バイナリセマフォを同期手段として用いたからと筆者は、解釈しました。

つまり、手段のミューテックスやバイナリセマフォよりも、制御結果からプロジェクト名を付けたのだと思います。

面白いのは、このTx_Thread_Syncは、1プロジェクト内で、ミューテックスとバイナリセマフォをマクロで切替え、両者が同じ結果をもたらすことを示している点です(最初のVCP出力参照)。

しかしながら弊社は、Azure RTOSの排他制御手段でのプロジェクト名や日本語コメントを付けます。

AzureRtosMutexSemaプロジェクト

下表が、Tx_Thread_Syncの処理内容です。STM32G4評価ボード:NUCLEO-G474REとArduinoプロトタイプシールド用に、赤の工夫を加えました。

スレッド名 処理内容:スレッド1/2のLED点灯排他制御

(LD2:評価ボード単体+
Arduinoプロトタイプシールド

優先度 プリエンプション閾値
スレッド1 1) 排他オブジェクト取得確認
2) 成功時LED1 500ms/5秒トグル後、オブジェクト開放
3) 失敗時排他オブジェクト取得待ち
10 10
スレッド2 1) 排他オブジェクト取得確認
2) 成功時LED2 500ms /5秒トグル後、オブジェクト開放
3) 失敗時排他オブジェクト取得待ち
10 10

排他オブジェクトは、マクロでTX_MUTEX定義済みならミューテックス、未定義ならバイナリセマフォ利用に変更できます。

AzureRtosMutexSemaプロジェクト作成

AzureRtosMutexSemaプロジェクト作成方法も、AzureRtosEventFlagの時と同じです。

汎用テンプレートAzureRtos0をコピー&別名AzureRtosMutexSemaでペーストし、AzureRtosMutexSemaプロジェクトを作成します。ペースト先のAzureRtos0.icoは、AzureRtosMutexSema.icoへRenameします。

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

STM32G0C1E-EV のTx_Thread_Syncコードapp_threadx.c/hを流用し、AzureRtosQueueプロジェクトの、app_threadx.cとapp_threadx.h へ追記します。追記コードの一部抜粋が下記です。

app_threadx.c追記例

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

app_threadx.h追記例

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

Azure RTOSミューテックスとバイナリセマフォ

サンプルコードは、ミューテックスがデフォルト利用ですので、Azure RTOSミューテックスで説明します。

スレッド1/2は、優先度、プリエンプション閾値ともに同じです。

しかし、スレッド1を先に生成し即実行(TX_AUTO_START)しますので、常にスレッド1が排他オブジェクト:ミューテックスを先に取得(tx_mutex_get)し、LED1トグル点灯を5秒間続けます。5秒経過後、ミューテックスを開放(tx_mutex_put)し、1ティックの10msスリープ(tx_thread_sleep)します。この処理を繰返します。

スレッド2は、開始後オブジェクト:ミューテックス取得を狙いますが、スレッド1取得済みのため待ち無し(TX_NO_WAIT)で取得狙いを繰返します。スレッド1のミューテックス解放で、ミューテックスを取得し、LED2トグル点灯を5秒間続けます。5秒経過後、ミューテックスを開放し、10msスリープするのは、スレッド1と同じです。

ミューテックスオブジェクトにより、スレッド1/2が排他動作します。

ここで、ミューテックス解放後の1ティックスリープは重要です。このスリープが、スレッド1/2のコンテキストスイッチを行います。試しにスリープをコメントアウトすると、排他制御が働きません。

app_thread.x.h L60のマクロUSE_TX_MUTEXをコメントアウトすると、バイナリセマフォ(tx_semaphore_get/tx_semaphore_put)を使ってミューテックスと同じ動作結果が確認できます。

Azure RTOSサイトのカウントセマフォを読むと、カウントセマフォは、排他制御だけでなくイベント通知にも使用可能です(前稿キュー イベント チェーンがその利用例)。また、デットロックやスレッド優先度の落とし穴、“優先度の逆転”(Priority Inversion)などの利用時注意事項もあります。

排他制御だけなら、ミューテックス利用がシンプルで良さそうです。但し、“優先度の逆転”対策の“優先度の継承”(Priority Inheritance)オプション:TX_INHERITが必要です。サンプルコードは、TX_NO_INHERITです。

※優先度の逆転、優先度の継承を試すには、スレッド1/2以外の第3のスレッドが必要です。第3スレッドは、スレッド1/2の中間の優先度と、1/2排他制御とは無関係なことも必要です。この逆転、継承もRTOSらしい機能ですが、サンプルコード実装は無く、各自でお試しください、ということでしょう。

ミューテックス/バイナリセマフォ排他制御の結果、ArduinoプロトタイプシールドのLED1とLED2が、交互に点滅を繰返すことが確認できます。

オリジナルプロジェクト名:“Sync”が示すようにLED1/2は同期して交互点滅している、と記述することも可能です。

RTOS文章直列記述→並列動作マッピング

本サンプルコードは、わずか2個スレッドです。それでも、RTOS処理を文章で記述する難しさを感じます。文章は、動作を「直列」で記述することが得意だからです。

RTOS処理は、複数のスレッドが「並列」に動作します。勿論、シングルコアで時分割動作なので、実際に動作しているのは、RTOSを含め1個です。ですが、これを判り易く文章化するのは、結構難しいことです。

例えば、本稿スレッド1/2のtx_thread_sleepです。開発者同士なら、ソースコードを見せれば、それで事足ります。しかし、そもそもRTOS理解レベルが不明の顧客へ、スリープの目的や意味を説明しても、判ってもらえるでしょうか?

RTOS開発は、開発アプリの顧客向け資料作成でも苦労しそうです😭。

RTOS習得には、公式サイト文章記述の各種RTOS機能を、サンプルコードへ変換後、さらに、個々の開発者が、サンプルコードと評価ボードを使って「納得するまで色々変えてみること」が必要だと思います。

この試行で、直列記述の文章で表現されたRTOS動作が、開発者の中でRTOS並列動作へマッピングされます。RTOS習得・開発には、並列動作マッピングの過程が最重要だと思います。

Azure RTOS習得(4):メッセージキュー

Azure RTOSのキューを使ったプロジェクトを作成し、スレッド間のメッセージ送受信方法を説明します。メッセージキューは、比較的判り易い機能です。先にまとめ、次に詳細の順に説明します。

まとめ

Azure RTOSメッセージキュー送受信
Azure RTOSメッセージキュー送受信

Azure RTOSのスレッド間メッセージ送受信には、キューが用いられます。

STM32G4評価ボードのAzure RTOSメッセージキューサンプルコードが無いため、NUCLEO-G0B1REのTx_Thread_MsgQueueサンプルコードを流用し、AzureRtosQueueプロジェクトを作成しました。

作成したAzureRtosQueueプロジェクトを使い、基本的なAzure RTOSメッセージキュー機能を、STM32G4評価ボードにArduinoプロトタイプシールドを追加し説明、動作確認しました。

本稿説明のAzure RTOS APIは、下記です。

・メッセージキュー作成:tx_queue_create
・メッセージキュー送信:tx_queue_send
・メッセージキュー受信:tx_queue_receiveと、TX_NO_WAIT / TX_WAIT_FOREVER
・メッセージキュー送信時通知:tx_queue_send_notifyと、キュー イベント チェーン

複数のQメッセージを受信スレッドで処理し、かつ、メッセージ無しの時、受信処理を中断する場合は、Azure RTOSキュー イベント チェーン(Queue Event chaining)機能が効果的です。

STM32G4 Azure RTOSサンプルコード探し

現在、STM32G4(Cortex-M4/170MHz)評価ボード:NUCLEO-G474REへのAzure RTOSサンプルコードは、3個、この中にキューサンプルコードはありません。

そこで、逆にExample Selectorから流用できるキューサンプルコード:Tx_Thread_MsgQueueを探します。選定条件は、利用中のCubeIDE版数(v1.9.0)、評価ボード(Nucle-64)に近いものが良いでしょう。

CubeIDEのInformation Centerℹ️でImport STM32CubeMX exampleをクリックし、Example SelectorタブでThreadXにチェックを入れて選定します。

選定したNUCLEO-G0B1REのTx_Thread_MsgQueueコードを、STM32G4へ流用します。

STM32G4 Azure RTOSキューサンプルコードの探し方
STM32G4 Azure RTOSキューサンプルコードの探し方

AzureRtosQueueプロジェクト

下表が、Tx_Thread_MsgQueueの処理内容です。STM32G4評価ボード:NUCLEO-G474REとArduinoプロトタイプシールド用に、赤の工夫を加えました。評価ボード+Arduinoプロトタイプシールドの目的は、Azure RTOS習得(2)を参照してください。

スレッド名 処理内容:Q1/Q2によるメッセージ送受信

(LD2:評価ボード単体+
Arduinoプロトタイプシールド

優先度 プリエンプション閾値
送信スレッド1 500ms毎にSET_GRN_LEDメッセージをQ1へ送信
Q送信失敗時、LD2点灯+停止
5 5
送信スレッド2 1s毎にRESET_GRN_LEDメッセージをQ2へ送信
Q送信失敗時、LD2点灯+停止
5 5
受信スレッド Q1とQ2、両方からメッセージ受信
Q1受信成功時、LED1トグル点灯+VCP出力
Q2受信成功時、LED2トグル点灯+VCP出力
受信失敗時、LD2点灯+停止
10 10

AzureRtosQueueプロジェクト作成

AzureRtosQueueプロジェクト作成方法は、前稿のAzureRtosEventFlagと同じです。汎用テンプレートAzureRtos0をコピー&別名AzureRtosQueueでペーストし、AzureRtosQueueプロジェクトを作成します。ペースト先のAzureRtos0.icoも、AzureRtosQueue.icoへRenameします。

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

NUCLEO-G0B1REのTx_Thread_MsgQueueコードapp_threadx.c/hを流用し、AzureRtosQueueプロジェクトの、app_threadx.cとapp_threadx.h へ追記します。追記コードの一部抜粋が下記です。

app_threadx.c追記例

app_threadx.c追記ソースコード抜粋(橙色は注意箇所)
app_threadx.c追記ソースコード抜粋(橙色は注意箇所)

app_threadx.h追記例

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

Azure RTOSメッセージキュー

Azure RTOSのスレッド間メッセージ送受信には、メッセージキューが用いられます。

送信スレッド1/2のtx_queue_sendで、Q1/2へメッセージ送信、受信スレッドのtx_queue_receiveで、Q1/2からメッセージ受信、メッセージ内容を確認し、受信成功ならLED1/2をトグル点灯させます。

送信スレッド1/2は、同じ優先度とプリエンプション閾値です。送信間隔が同じ500msだと煩雑ですので、スレッド2は、1秒送信間隔へ変更しました。

Azure RTOSメッセージキューの送受信は、比較的判り易い機能です。メッセージキューを作り(tx_queue_create)、そのQへの送受、STのKnowledge Baseに判り易いアニメもあります。

しかしながら、受信スレッドが、複数Qからのメッセージ処理を行い、かつ、メッセージ無しの時に無限待ち(TX_WAIT_FOREVER)の場合には、キュー イベント チェーン(Event chaining)が効果的です。

本サンプルは、複数Qからの受信処理を行いますが、待ち無し(TX_NO_WAIT)の例です。

AzureRtosQueueプロジェクトVCP出力
AzureRtosQueueプロジェクトVCP出力

キュー イベント チェーン

Azure RTOS ThreadX 機能第 3 章の中程に、“キュー イベント チェーン”の説明があります。簡単に抜粋すると、

本受信スレッドのようにQ1とQ2の両方からメッセージを受信し、メッセージ無しの時、受信中断もある場合は、Q1/Q2に通知関数を登録(tx_queue_send_notify)し、カウントセマフォを使うキュー イベント チェーンが有効。キュー イベント チェーンなしでの実現は“非常に困難”。

流用サンプルコードのreadme.htmlにもキーワード:Event chainingがあります。しかし、このキュー イベント チェーンは未実装です。

カウントセマフォなしでは非常に困難でRTOSらしい機能ですが、各自でお試しください、ということでしょう😢。本ブログもこの方針に従いました。

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アプリケーションテンプレート開発を計画中です。

組込み開発 基本のキ: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セキュリティ