Azure RTOS アーカイブ - IoT MCUのHappyTech

Azure RTOSはEclipse ThreadXへ

2024年1月19日 WithHappy

Microsoftが、Azure RTOSをEclipse Foundationへ提供しました。Azure RTOSからEclipse ThreadXへ名前を変え、ベンダーニュートラルなオープンソースRTOSへ変わりました（2024年1月9日、MONOist）。

上記記事に筆者は驚きました。Microsoft発表は、昨年11月21日です。発表から約2か月たった現在の業界動向をまとめました。

Microsoft動向

MicrosoftがAzure RTOSを手放した経緯は、前述MONOist記事が詳しく説明しています。ごく簡単にまとめます。

Microsoftは、2019年ExpressLogic社買収で入手したThreadXを、自社クラウドサービス接続用RTOS、Azure RTOSとして育ててきた。しかし、2022年Azure RTOS開発責任者がMicrosoftを退社。結局、2023年Microsoftは、Azure RTOSをEclipse Foundationへ提供。今後、Microsoftは機能安全コストも負担しない。

※機能安全コストとは、厳格な安全やセキュリティ規格を満たすソフトウェアのメンテやサポートコスト。

Eclipse財団動向

MCU統合開発環境のデファクトスタンダード：Eclipse IDEの非営利運営団体がEclipse Foundation。

Eclipse財団は、提供Azure RTOSをEclipse ThreadXと改名。ベンダーニュートラルなオープンソースRTOSとし、一般的に有償の機能安全版も、2024年1月末目途にMIT Licenseで提供準備中。

Eclipse財団は現在Eclipse ThreadX開発者募集中で、Eclipse ThreadXの全コンポーネント（IoT MCUベンダ動向図のTCP/IPスタック等）無償配布になる可能性あり。

MCU RTOS動向

Eclipse ThreadX競合ライバルのFreeRTOS、 μT-Kernel状況が下記。特段の対応は現在無し。

FreeRTOS：機能安全版は商用ライセンスSAFERTOSで提供中。FreeRTOSは無償提供中。
μT-Kernel： IEEE標準規格：IEEE2050-2018完全準拠版μT-Kernel 3.0を無償提供中。

IoT MCUベンダ動向

本ブログ掲載IoT MCUベンダで言えば、STマイクロ＞ルネサス＞NXPの順に、Azure RTOSに積極的でした（FreeRTOSなら真逆）。

そのSTマイクロが、Eclipse ThreadXは、重要な開発環境の一部、とMicrosoft発表内でコメントしています。つまり、STマイクロは、これまでのAzure RTOS同様、Eclipse ThreadXをミドルウェアとして提供すると思います。

米市場動向

MicrosoftがAzure RTOSを手放したのは、育成済みAzure RTOSを、今さら保守・運用しなくても、自社クラウドサービスへの影響は少ない、と判断したからかもしれません。

一方、一般向けAI PCに関しては、Windows 11シェア伸び悩む、Windows 12方向性などの記事から、Microsoftは次期Windows＋Copilotに注力すると思います。AI Copilotキー追加やモバイルCopilotなど、最近は生成AI関連のCopilot発表一色です。

これらCopilot群は、次期AI Windows（Afterword2参照）で使い易く統合されるでしょう。

2024年1月12日、米株式市場も⽣成AI⾰命からより多くの恩恵を受けるMicrosoft時価総額を、アップルを抜き首位復活させました。

Summary：IoT MCU開発者対応

Microsoftが、Azure RTOSを手放し、Eclipse財団が、Eclipse ThreadXと改名、ベンダーニュートラルオープンソースRTOSとしたことを、業界は、冷静かつ好意的に受け止めているようです。

むしろ、AWSならFreeRTOS、AzureならAzure RTOSと2本立てIoT MCU RTOS開発が、Eclipse ThreadXで一本化、機能安全パッケージも無償提供期待の方が大きいのかもしれません。

IoT MCU開発者は、Eclipse ThreadXを含むRTOS動向に注意する必要があります。

Afterword：RTOSチェックポイント

MCUにRTOSを使う理由は、クラウド接続ライブラリが必要だからです。

しかし、ライブラリは関数の集合に過ぎないので、ライブラリ利用例、つまりサンプルコードが無いと使えません。ベンダーニュートラルEclipse ThreadXが、AzureとAWS両方の接続サンプルコードを提供するかがチェックポイントです。

また、サンプルコードがあっても、接続の容易さや安定性も確認したいです。評価ボードでのテストやクラウド接続ユーザ数変化、SNSなどで判るでしょう。

Eclipse ThreadXが他RTOSへ与える影響は、少なくないと思います。この辺りは、調査を続けます。

Afterword2：AI Windows12決め手

Win11敗因の1つは、TPM 2.0などのPCハードウェアとWin11アップグレード条件を、100%結び付けたことだと思います。条件を満たさないPCは、Win11アップグレートができずWin10のままです。Win10でも、PC生産性に大差はありませんが…😓。

ハードウェアとアップグレート条件の結び付きを緩くし、例えば、NPU（Neural Processing Unit）搭載最新Core Ultraプロセッサなら、自然言語入力にも対応するAI機能満載Win12、古いCPUなら、従来CUI/GUI 入力のAI Win12など、アップグレード機能/能力差を付けます。

これに近いことは、既に昨年のWin11 23H2アップデートの段階的機能ロールアウト（Controlled Feature Rollout、CFR）で実施中です。

AI機能は、PC生産性に直結します。PC買換え需要も喚起できるでしょう。不振Win11と2025年秋Win10サポート終了前に、AI Win12リリースをMicrosoftが急ぐ理由です。

つまり、2024年内にPCハードウェアに応じたAI Win12アップグレートをMicrosoftが提供することが、低下しつつあるWindowsシェア復活の決め手になると思います。

FSPベアメタルサンプルのRTOSスレッド化

2023年1月27日 WithHappy

前投稿FSPベアメタルサンプルコード：sci_uart_fpb_ra6e1_epを、RTOSスレッド化する方法を示します。

多くのルネサスRA公式サンプルコードを活用した効率的なRTOSスレッド開発が本方法で可能です。FreeRTOS、Azure RTOS両方に使えます。

サンプルコードベースRTOSスレッド開発

RTOS開発は、複数スレッドを組合せ全体を動作させます。ベアメタルコードに比べ、個々のスレッドは、独立性や移植性が高い特徴があります。スレッド優先度やセマフォなどのRTOSオブジェクトを適切に設定すると、複数スレッド全体処理としてユーザ所望のシステム動作をします。

スレッドは、勝手に回る歯車、優先度やRTOSオブジェクトは、各歯車をシステム全体で上手く動作させる手段と考えると解りやすいと思います。

スレッド設計法は、機能別や処理手順別など様々あり、唯一の方法は無さそうです。しかし、先ずは、歯車となるスレッドを開発し、次に、開発スレッド優先度やRTOSオブジェクトを調整しながら、システム全体動作を仕上げるのがRTOS開発の方法です。

本稿は、スレッド単体開発の１方法として、ルネサスRAファミリ公式FSPベアメタルサンプルコードを活用したサンプルコードベースのRTOSスレッド開発法を示します。複数スレッドを組合せたRTOSオブジェクトの適切な調整や設定に関する内容は、含みません。

公式ベアメタルサンプルコードは、各ベンダエキスパートが開発し、評価ボードで動作確認済みの高信頼ソフトウェアです。また、MCU周辺機能毎に多くのサンプルコードが提供中です。

これらベアメタルコードを活用する本方法は、FreeRTOS/Azure RTOSどちらのRTOSスレッド開発へも使えます。

RTOSスレッド化方法

詳細は、後で説明しますが、先ず、ベアメタルサンプルをスレッド化する手順を簡単に示します。方法全体像が判っていると把握しやすいからです。

スレッド無しで空の新規RTOSプロジェクト作成
g_ioport以外のベアメタルサンプルFSPスタックを、RTOS FSPスタックへImport
hal_entry.c以外のベアメタルサンプルsrcファイルを、RTOSプロジェクトsrcフォルダへコピー
新しいスレッド：MyThreadをRTOSプロジェクトへ追加後、Gegerare Project Contentクリック
MyThread_entry.cへ、初期設定と無限ループ処理を追記

1で新規作成した空のRTOSプロジェクトへ、2と3で対象ベアメタルサンプルから内容を追加、4でベアメタルmain()相当の新しいMyThreadを追加後、FSPを使ってRTOSプロジェクトを自動生成します。

生成後、5でRTOSプロジェクトのMyThread_entry.c初期設定と無限ループを追記します。追記内容は、ベアメタルサンプルの初期設定と無限ループ処理です。

つまり、1～5手順全てFSPベアメタルサンプルからの単純コピーでRTOSスレッド化が可能です。

次章から、前投稿で用いたベアメタルサンプルコード：sci_uart_fpb_ra6e1_epを、FreeRTOSスレッド化する具体例を使って、各詳細手順を示します。

1. 空の新規FSP freertos_uartプロジェクト作成

スレッド無し空FreeRTOSプロジェクトを新規作成します。新規RTOSプロジェクト名は、freertos_uartとでもしてください。

2. sci_uart_fpb_ra6e1_epのFSPスタックImport

freertos_uartプロジェクトのFSPスタックへ、sci_uart_fpb_ra6e1_epのg_ioport以外のFSPスタックを全てImportします。Importした各スタックプロパティは、オリジナルプロパティと同じに手動で設定してください。

3. sci_uart_fpb_ra6e1_epのsrcファイルコピー

sci_uart_fpb_ra6e1_epのhal_entry.c以外のsrcファイルを全て、freertos_uartのsrcへコピーします。

4. freertos_uartプロジェクトへ新しいUart Thread追加後、Generate Project

新しいスレッドのSymbolは、Uart_threadとしてください。先頭を大文字にする目的は、FSPが自動生成したファイルやスレッドが使う全小文字表記とユーザ追加のそれらを、大小文字で区別するためです。

Tips：大文字利用は、好みの問題です。RTOS開発は、多数のスレッドやオブジェクトソースが、プロジェクト・エクスプローラのsrcフォルダに表示されます。自分が追加したソース（バグ有り?）と純FSP生成ソースを、一目で区別できるメリットがあります。

最後にGenerate Project Contentをクリックし、FSPによりRTOSプロジェクトを自動生成します。

5. Uart_Thread_entry.cへ初期設定と無限ループ処理追記

RTOSプロジェクトのsrcフォルダ内に、Uart_thread_entry.cが生成されます。

先頭の#include “Uart_thread.h”に、sci_uart_fpb_ra6e1_epのsrcファイルにある#include “common_utils.h”、 #include “uart_ep.h”、 #include “timer_pwm.h”を追記します。
これら4個の#include文は、freertos_uartの全srcファイルに手動で追記します。

RTOS初期設定は、Uart_thread_entry.c のTODO: add your own code here以下へ、sci_uart_fpb_ra6e1_epの初期設定：hal_entry.cのL41からL93までをコピーします。

sci_uart_fpb_ra6e1_epの無限ループ処理は、コピーした初期設定の後方にあるuart_ep_demo()です。

RTOS無限ループ内には、上図でコメントアウトしたコンテキストスイッチが必要です。そこで今回は、RTOSプロジェクトuart_ep.cのuart_ep_demo()内へ、直接コメントアウトしたFreeRTOSコンテキストスイッチ：vTaskDeley(1)を追記します。

Tips：#include “Uart_thread.h”が、FreeRTOS関連API：コンテキストスイッチ追記を可能にします。

sci_uart_fpb_ra6e1_epとfreertos_uartスレッド同一動作確認

RTOSプロジェクトをビルドし、評価ボードへダウンロード後、実行してください。前稿のベアメタルサンプルコードと全く同じ処理が、開発したfreertos_uartスレッドで確認できます。

FreeRTOS/Azure RTOSスレッド化差

本稿で示したFreeRTOSスレッド化とAzure RTOSスレッド化の差は、コンテキストスイッチのみです。FreeRTOSならvTaskDelay(1)、Azure RTOSならtx_thread_sleep(1)が、コンテキストスイッチです。

Tips：コンテキストスイッチは、FreeRTOS/Azure RTOS開発手法のRTOS処理フローなどを参照してください。

ベアメタルサンプルコードをAzure RTOSスレッド化する時は、手順1で、新規Azure RTOSプロジェクトを作成し、手順5のvTaskDelay(1)の代わりに、tx_thread_sleep(1)を使えばOKです。

Tips：FSP生成スレッドMyThread_entry.cの無限ループ内には、作成RTOSプロジェクトに応じて初めからvTaskDelay(1)、またはtx_thread_sleep(1)が実装済みです。

本方法が、FreeRTOS/Azure RTOSどちらのRTOSスレッド開発へも使えることが分かります。

補足

2023年1月16日、e2 stidioは2022-10のまま、RAファミリFSPがv4.2.0へ更新されました。本稿は、FSP v4.2.0/4.1.0両方で動作確認済みです。

FSP利用FreeRTOSアプリの作り方

2022年12月9日2022年12月10日 WithHappy

ルネサスFSP（Flexible Software Package）とサンプルコード利用の「実践的FreeRTOSアプリの作り方」を示します。下記の最新開発環境を用いました。古い環境や別評価ボードでも同じ結果が得られると思います。

RAファミリ評価ボード：FPB-RA6E1（Cortex-M33/200MHz、Flash:1MB、RAM:256KB）
FSP 4.1.0 (e2 studio 2022-10含む)
サンプルコード：r20an0651eu0111-fpb-ra6e1-exampleprojects.zip
サンプルコード説明書：FPB-RA6E1 Example Project Bundle
Windows 11 22H2 (22621.900)

全体流れ説明

先ず本FreeRTOSアプリ開発の全体の流れを説明します。というのは、組込み開発で良くあるサンプルコード付属説明：readme.txtとソースコード動作が不一致など、少々込み入った内容を含むからです。

FPB-RA6E1購入時インストール済みサンプルコード：qiuckstart_fpb_ra6e1_epは、ベアメタルソフト。readme.txt記載のSW1プッシュでLED1/2点滅速度変化とは不一致。
SW1プッシュでLED1/2点滅速度変化へFSP改造（1と2は、ベアメタル開発）。
FPB-RA6E1で、新規LED1/2点滅FreeRTOSアプリ作成（3以降は、FreeRTOS開発）。
作成FreeRTOSアプリのLEDスレッドへ、2.のベアメタルのSW1プッシュLED1/2点滅速度変化改造FSPと、ソースコード移植。
LED2は、FreeRTOSアプリエラー表示用とするため、点滅処理から削除。

本稿の背景

ベアメタル開発者は1と２、RTOS開発者は3以降が実行できれば、SW1プッシュでLED1点滅速度変更の1スレッドのみを持つFreeRTOSアプリを開発できます。

「実践的FreeRTOSアプリ開発」としたのは、0からアプリを開発するのではなく、豊富に提供される公式サンプルコードを流用・活用し、所望アプリを早く効果的に開発する例を示したかったからです。

RTOSのメリットを説明した資料は多く見かけます。しかし、具体的なRTOSアプリ開発方法を示す資料が少ないことも背景にあります。

以下、1～5の説明を加えます。細かい説明は後回しにし、まとめ章を先に読むとより全体が解り易いと思います。従って、まとめ章を先に記述します。また、最後の章に、RTOS開発の基盤となるRAベアメタルテンプレート宣伝（?）もあります。

まとめ：実践的RTOSアプリ開発方法

評価ボード実装済みLED1とSW1は、いわば開発アプリ正常動作中を示すインジケータです。開発したFreeRTOSアプリをテンプレートとし、所望機能のスレッドを追加していけば、最終的に様々なFreeRTOSアプリを早期に開発できます。

FreeRTOSをRAファミリFSP利用例としましたが、Azure RTOSでも同様です。

つまり、本稿のアプリは、RTOSテンプレート骨格で説明した内容を、より具体化したものです。

もちろん複数スレッド追加時は、スレッド優先度やスレッド間制御（セマフォ/キュー/ミューティックスなど）の検討も必要になります。これらは、追加スレッドがほぼ完成した後の検討項目です。

先ずは、必要な個々のスレッドを単体・単独で開発し、その後、複数スレッド結合へと段階的に進める方法がRTOS開発には適していると考えます（関連投稿：FreeRTOS/Azure RTOSソフトウェア開発手法）。

複数スレッドの検討方法は、文章量が増えるため割愛しました。別途改めて、投稿する予定です。

1：qiuckstart_fpb_ra6e1_ep動作とreadme.txt

評価ボードに初めからインストール済みのサンプルコードが、quickstart_fpb_ra6e1_epです。zip内に収められています。e2 studioは、zip内にあるサンプルコード説明書：readme.txtをIDE内にインポートしません。

Tips：zip解凍後のreadme.txtを、サンプルコードプロジェクト内へ手動でコピーしておくと、いろいろ便利。
Tips：quickstart _fpb_ra6e1_epのfpb_ra6e1が評価ボード名、epはexample projectの略。別評価ボード利用時は、fpb_ra6e1部分が異なる。

quickstart_fpb_ra6e1_epのreadme.txtが下記です。

下線部：評価ボードSW1でユーザLED1/2点滅制御とありますが、この動作はFPB-RA6E1にはありません。しかし、quickstart_fpb_ra6e1_epソースコードには、SW1割込み処理：callback_irq1ds_buttonでLED1/2点滅delay変更処理が記述済みです。

これは、RAファミリのソースコードがHAL（Hardware Abstraction Layer）記述で、MCUが変わっても同じソースコードを使えるからです。別評価ボードのソースコードとreadme.txtを、そのままFPB-RA6E1へコピー流用している訳です。

組込み開発ではMCUの種類が多いため、このように既存資産をコピーして当該MCUコードや資料を作ることは良くあります。その結果、今回のようにreadme記述内容とサンプルコード動作が不一致なことも多々あります。

Tips：逆に上記は、MCUソフトウェア開発の本質が「サンプルコードやFSPなどの既存資産を上手くコピー活用すること」を示しているとも言えます！

2：SW1プッシュ割込みでLED1/2点滅速度変化へFSP改造

readme.txt記述とサンプルコード動作不一致の原因が、FSPです。

そのままコピーできるreadmeやサンプルコードと異なり、FSPは、当該MCU毎に設定が必要です。不一致の原因は、FPB-RA6E1のFSP設定にミス（忘れ）があるからです。

動作一致のためには、外部割込みコントローラ（External IRQ）とFPB-RA6E1のSW1（P205）の接続が必要です。下記のようにP205ピン設定を変更後、Generate Project Contentをクリックします。

quickstart_fpb_ra6e1_epを再ビルドし、評価ボードへダウンロードすれば、readme内容と同じSW1プッシュでLED1/2点滅速度が変わります。

外部割込みコントローラ（External IRQ）とS1（P205）を接続するピン設定

3：LED1/2点滅新規FreeRTOSアプリ作成

新規FreeRTOSアプリ作成は、ベアメタルアプリ作成と同じ方法です。そこで、本稿は、ベアメタル作成との差分のみを示します。

新規作成FreeRTOSプロジェクト名は、freertos_blinkyとでもしてください。FSP Summaryが下記です。

このfreertos_blinkyを評価ボードへダウンロードすると、LED1/2が1秒毎に点滅します。生成したLEDスレッド：blinky_thread_entry.cのvTaskDelay(configTICK_RATE_HZ)が、1秒点滅の仕組みです。

4：LEDスレッドへ、2:SW1プッシュLED1/2点滅速度変化改造FSP移植

2：で改造したSW1割込みでLED1/2点滅速度を変える機能を、3の新規FreeRTOSアプリへ移植します。

freertos_blinkyのFSP Stacksタブを選び、画面上で左クリックしImportを選択します。From fileにquickstart_fpb_ra6e1_epを選び、configuration.xmlを開きます。Stack ImportでExternal IRQを選ぶとquickstart_fpb_ra6e1_epの割込みコントローラ設定がfreertos_blinkyへ移植できます。

Tips：移植するFSPスタック数が多い時は、Import機能が便利。

しかし、割込みコントローラとSW1（P205）間の接続はImportできません。そこで、1：と同様にP205ピン設定を割込みコントローラと接続し、Generate Project ContentクリックでFSP移植は完了です。

Tips：FSP Importは簡単便利だが、上記のように同一MCUであっても、ピン設定はImportされない。また、ピン設定が無くてもエラー表示もない。代替方法に、New Stackクリックでスタック群から追加機能を選ぶ方が、ピン設定忘れが少ないかもしれない。

次に、SW1割込み処理：callback_irq1ds_buttonを移植します。

callback_irq1ds_button処理は、e2studioのDeveloper Assistanceを開き、callback_function_definitionをクリックし、blinky_thread_entryの後へペーストで追記します。今回は、TODO:add your own code hereコメント後へ、quickstart_fpb_ra6e1_epのSW1割込み処理をコピー＆ペーストし移植します。

コピー後エラーが表示される箇所は、全て定数未定義部分ですので、quickstart_fpb_ra6e1_ep定数部分もコピー&ペーストします。

Tips：e2 studioは、デフォルトではソースコード変更後、このように即コンパイルエラーを表示。

最後に、vTaskDelay(configTICK_RATE_HZ)のconfigTICK_RATE_HZ を、割込み処理で作成したg_delayへ変更します。

以上で、割込み処理の移植完了です。ビルドし、SW1でLED1/2点滅速度が変わることが確認できます。

※12月10日追記：FSP Importした割込みコントローラ初期化の移植記述を忘れていました。追記します。

Importした割込みコントローラの初期化：icu_initializeも、下図のようにblinky_thread_entry.cへ移植します。

5：LED2点滅処理削除

LED2は、FreeRTOSアプリのエラー表示に使います。例えば、追加したスレッド初期設定に失敗した時のインジケータなどです。そこで、下記のようにLED2をLEDスレッドの点滅処理から外します。

以上で、SW1プッシュでLED1点滅速度変更の1スレッドのみを持つFreeRTOSアプリ完成です。

このFreeRTOSアプリへRTOSテンプレート骨格で投稿した７メニュー形式表示、LED2エラー表示などの機能を更に追加しFreeRTOSテンプレートとします。

FreeRTOSテンプレートは、全てのFreeRTOSアプリ開発の出発点となり、所望スレッド機能を追加していけば、効率的に様々なRTOSアプリ開発が可能です。

Tips：本稿はFreeRTOSテンプレート開発方法に重点を置き投稿。実FreeRTOSテンプレートは、もっと解り易い構造とソースコードで提供。

RTOS開発はベアメタル開発スキル必須

前章1～5から「RTOS開発には、ベアメタル開発スキルが必須」であることがお解り頂けたと思います。

組込み開発は、説明不足の事柄が非常に多いです。また、サンプルソフトとreadme.txtなどの説明不一致も多々あります。説明対象を初心者/中級者の誰にするか、どこまで説明するか、などなど読者を絞り難いこと、説明側にとっては、自明の理の内容が多いことがその理由です。

本稿で追記したTipsや背景となる技術スキルが無いと効率的に先へ進めないと思います。ベアメタルを補う目的のRTOS開発ではなおさらです。

RAファミリで、FSP利用の効率的なベアメタル開発スキルを身に付けるには、弊社RAベアメタルテンプレートがお勧めです。ソースコードに豊富な日本語コメントを付加し、付属説明資料にはTipsやFSPノウハウなども記載しています。RAベアメタルテンプレート説明サイトは、コチラをご覧ください。

ルネサス以外のベアメタル用テンプレートも多数ご用意しております。また、NXPのFreeRTOSアプリケーションテンプレートも販売中です。

RTOSテンプレートの骨格

2022年10月21日2022年11月18日 WithHappy

IoT MCU RTOSは、FreeRTOSとAzure RTOSの2種類。接続クラウドAmazon AWSやMicrosoft Azureに応じて選択する必要があります。各RTOSそれぞれにRTOSアプリケーションを開発するのは非効率です。

そこで、アプリケーション開発の基になるRTOSテンプレートの骨格を検討しました。APIはFreeRTOSとAzure RTOSで異なるものの、同一の骨格から開発するとメリットがあるからです。

結論は、単体タスク/スレッド試験も容易なメニュー表示形式RTOSテンプレート骨格とします。

RTOSアプリケーション例

Data flow diagram for a smart thermostat（出展：JACOB’S Blogに加筆）

RTOSアプリケーション例が上図です。複数のタスク/スレッドと各タスク/スレッドを制御するアプリケーション本体から構成されます。

アプリケーション本体とタスク間は、同期（S：セマフォ）/排他（M：ミューテッスク）/メッセージキュー（Q）などのRTOS処理待ちに応じたRTOS APIが用いられます。

FreeRTOSとAzure RTOSで処理待ちRTOS API記述が異なるものの、どちらも機能的には同じです。

また、センサやタッチスクリーン、Wi-FiなどMCU内蔵/外部回路間の制御API、いわゆるドライバ部分は、各MCUベンダ提供のAPI生成ツールで開発します。このAPI生成ツールは、ベアメタル開発で使うものと同じです。RTOS開発だからと言って別のドライバAPI生成ツールがある訳ではありません。

ベアメタル開発とRTOSとの差分は、灰色部分です。1無限ループ内で全ての処理を行うのがベアメタル、RTOSアプリケーション本体と複数のRTOS処理待ちタスク/スレッドで並列多重を行うのがRTOS、ここだけです。

メニュー形式アプリケーション特徴

メニュー 1-5 を選択してください。
(1) Process Input処理
(2) Network Manager処理
(3) 出力処理
(4) メモリ処理
(5) 印刷
(6) 処理自動実行

最初の図のような複雑な処理をベアメタル開発する時は、例えば上のようなメニュー表示形式アプリケーションがしばしば用いられます。メニューの表示は、USART接続のPC、Tera Term利用が一般的です。

このメニュー表示形式アプリの特徴は、(1)から(5)の各処理を単体デバッグできることです。

また、単体デバッグ後、(1)から(5)の処理を自動で結合する処理(6)を開発すれば、開発が完成する点も優れています。

(6)完成後は、メニュー表示をスキップし、PCを使わずにMCU単体で(6)を実行すれば、ベアメタル組込み完了です。

メニュー形式RTOSテンプレート骨格と開発手順

RTOSアプリケーション開発でもメニュー表示形式を採用します。

メリットは、単体タスク/スレッド開発、デバッグが容易な点です。RTOS開発は、タスク/スレッドの独立性がベアメタルよりも高いため、メニュー形式で開発したタスク/スレッド流用性も高く、開発ソフトウェア資産化も可能です。

弊社RTOSテンプレートは、FreeRTOSでもAzure RTOSでもメニュー形式のテンプレート骨格とします。テンプレートが用意するデフォルトメニュー数は7個、タスク/スレッド優先度もデフォルト7レベル（1から7）設定とします。優先度初期値は、どれも同一優先度（真ん中の4）とします。

※FreeRTOSは値が大きいと高優先、Azure RTOSは値が小さいと高優先で真逆に注意

RTOSテンプレートを使って、単体のタスク/スレッドを開発し、単体タスク/スレッド完成後、並列多重の結合動作へステップアップします。多重時、各タスク/スレッドの高/低優先度変更や、タスク合併などを検討します。

もちろん、メニュー数や優先度数の増加も容易です。しかし、弊社がお勧めするIoT MCUは、低価格評価ボード搭載の汎用IoT MCUです。RTOSオーバーヘッドが少ない7程度が適当だと思います。

RTOSテンプレートを使って、第1段階ではタスク/スレッド分割と単体タスク/スレッド開発に集中し、第2段階でタスク/スレッド並列多重に関連する優先度などのRTOSパラメタ調整に集中します。段階を踏んだ集中開発ができるため、複雑なRTOSアプリケーションの早期開発に役立ちます。

弊社RTOSテンプレートは、FreeRTOSまたはAzure RTOS個別対応済みのバージョンを販売予定です。但し、RTOSテンプレートの骨格がFreeRTOS/Azure RTOSで同じことをご購入者がご理解済みなら、FreeRTOS APIとAzure RTOS API変換も、比較的容易だと思います。

ベアメタルテンプレートとの違い

弊社ベアメタルテンプレートは、主に開発初心者から中級者が対象です。メニュー表示形式など、複雑な構成のテンプレートを提供するよりも、シンプルで解り易いソースコードの方が適しています。

一方、RTOSテンプレートは、ベアメタル開発経験者、つまり中級以上の開発者が対象です。

テンプレート付属説明資料も異なります。ベアメタルテンプレート付属説明資料は、各ベンダのIDEやAPI開発ツールの基本的使い方、開発つまずき回避のTipsなどを記述しています。具体例は、RAベアメタルテンプレート説明資料をご覧ください。

RTOSテンプレート付属説明資料は、既知のベアメタル関連説明は省き、ベアメタルとRTOSの差分や、実践的なRTOS Tipsの説明を加えます。具体例は、NXP版FreeRTOSテンプレート説明資料をご覧ください。

まとめ

FreeRTOSとAzure RTOS同一のメニュー形式RTOSテンプレート骨格構想を示しました。

弊社RTOSテンプレートを使えば、単体タスク/スレッド開発に集中でき、効率的、段階的なRTOSアプリケーション開発が可能です。開発単体タスク/スレッドは、独立性が高いので、ソフトウェア資産化も容易です。

また、接続クラウド変更に伴うFreeRTOSとAzure RTOSのAPI変更も、同じテンプレート骨格利用のため容易です。

本構想に基づいたAzure RTOSテンプレート、FreeRTOSテンプレートは、本年度末発売予定です。現在販売中のNXP版FreeRTOSテンプレートも、本構想用に改版を予定しております。

弊社RTOSテンプレート骨格について、皆様のご意見などを現在募集中です。お気軽にinfo@happytech.jpへお寄せください。

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

2022年9月9日2022年9月22日 WithHappy

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

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

センササンプルコード

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

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

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

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

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

センサとMCU間接続：I2C

センサと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とその利用手順です。一般的なセンサでも同様で、特に変わった点はありません。

ベアメタル処理フロー

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

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

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

RTOS処理フロー

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

差分は、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）ソフトウェア開発手法

ベアメタル処理を、効率的に複数並列動作させるのが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開発になります。IoT MCU RTOS開発は、データ収集、クラウド接続、エッジAIやIoTセキュリティなど、大別すると3分野に及びます（関連投稿：世界最大情報通信技術（ICT）サービス輸出国、アイルランドIoT事情）。

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

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

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

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

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量産開始

2022年8月19日2022年9月20日 WithHappy

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 → マルチタスク

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のせいではないという記事を読むと、その理由と現状が判ります。

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

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

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

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

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

2022年7月8日2022年7月15日 WithHappy

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モード動作有無です。

「非」動作対策の保留（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低電力動作プロジェクト作成方法

低電力動作有りと無しのプロジェクト作成差は、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 – PWRとLPTIMです。

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テンプレートは、コチラで販売中です。

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

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

2022年6月24日2022年7月1日 WithHappy

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ミューテックスとバイナリセマフォサンプルコードの探し方

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) 失敗時排他オブジェクト取得待ち

スレッド2

1) 排他オブジェクト取得確認
2) 成功時LED2 500ms /5秒トグル後、オブジェクト開放
3) 失敗時排他オブジェクト取得待ち

排他オブジェクトは、マクロで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.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)：メッセージキュー

2022年6月17日2022年6月24日 WithHappy

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）機能が効果的です。