カテゴリー: MCU：マイコン

マイコンやIoT関連の情報、Tipsなどを記載します。

FSP利用FreeRTOSアプリの作り方

WithHappy

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

 全体流れ説明

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

  1. FPB-RA6E1購入時インストール済みサンプルコード：qiuckstart_fpb_ra6e1_epは、ベアメタルソフト。readme.txt記載のSW1プッシュでLED1/2点滅速度変化とは不一致。
  2. SW1プッシュでLED1/2点滅速度変化へFSP改造（1と2は、ベアメタル開発）。
  3. FPB-RA6E1で、新規LED1/2点滅FreeRTOSアプリ作成（3以降は、FreeRTOS開発）。
  4. 作成FreeRTOSアプリのLEDスレッドへ、2.のベアメタルのSW1プッシュLED1/2点滅速度変化改造FSPと、ソースコード移植。
  5. 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

サンプルコードzip内のqiuckstart_fpb_ra6e1_ep
サンプルコードzip内のqiuckstart_fpb_ra6e1_ep

評価ボードに初めからインストール済みのサンプルコードが、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が下記です。

quickstart動作とreadme.txtの不一致箇所
quickstart動作と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）を接続するピン設定
外部割込みコントローラ（External IRQ）とS1（P205）を接続するピン設定

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

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

LED点滅の新規FreeRTOSアプリ作成（ベアメタル作成との差分）
LED点滅の新規FreeRTOSアプリ作成（ベアメタル作成との差分）

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

FSP Summary
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機能が便利。

FSP Import
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点滅速度が変わることが確認できます。

SW1割込み処理：callback_irq1ds_buttonの移植
SW1割込み処理：callback_irq1ds_buttonの移植

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

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

割込みコントローラの初期化処理の移植
割込みコントローラの初期化処理の移植

5：LED2点滅処理削除

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

LED2点滅処理削除
LED2点滅処理削除

以上で、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アプリケーションテンプレートも販売中です。



次世代ネットワークIOWN（アイオン）

WithHappy
What's IWON（出展：NTTサイト）
What’s IOWN（出展：NTTサイト）

IOWN（Innovative Optical and Wireless Network）は、2030年実現を目指すNTTの次世代ネットワークです。

IOWN技術

大容量、低遅延の光伝送路。ネットワーク遅延や揺らぎ無し。データドリブン将来社会のデータ量や消費電力増加を解決。キーテクノロジが「光電融合デバイス」、などなど実現技術に興味がある方は、コチラの記事で解ります。

IOWNサービス

IOWNが提供するサービスの一例が、コチラの遠隔医療記事です。IOWNは、ネットワーク本来の目的、離れた場所との距離を感じさせない通信を提供します。

既存ネットワークで遅延や揺らぎが生じるのは、電気信号と光信号の変換回数が多いためです。電気に比べ減衰が少ない光伝送と、光と電気を融合した光電融合デバイス、これらにより電気と光の変換回数を減らし、IOWNのオールフォトニックス・ネットワーク（APN）を実現します。

APNは、低消費電力で大容量、高品質、低遅延で揺らぎの無い理想的な伝送サービスを提供します。

さらに、WirelessのIOWNは、宇宙空間や海中でも接続します。低軌道人工衛星を用いた宇宙RAN（Radio Access Network）や、地上IoT端末と衛星を接続する宇宙センシング、さらに、海中での高速無線通信による水中ドローンなども2030年頃のIOWN 4.0で可能になります。

早くもAMDは、宇宙空間でAI処理ができる宇宙グレードSoCの信頼性評価を完了しました。

宇宙統合コンピューティング・ネットワーク（出展：SKY Perfect JSATサイト）
宇宙統合コンピューティング・ネットワーク（出展：SKY Perfect JSATサイト）

TRONプロジェクトリーダ：坂村健氏も注目

2022年11月25日の記事では、TRONプロジェクトリーダ：坂村健氏が、多くのIoTセンサを組込んだスマートホームなどのICTインフラに、電力効率100倍、伝送容量125倍、レイテンシ200分の1のIOWNが大きなインパクトを与えると語ったことが記載されています。

スマートホームでこれほど高速、大容量の公衆ネットワークが安価に使えると、個人のPCストレージは、もはや全てクラウド上に置くことも可能な気もします。

IWON特徴（出展：NTTサイト）
IOWN特徴（出展：NTTサイト）

IOWNと2030年

2030年まであと8年。リモートワークや移動時、遠距離でも低電力、大容量、低遅延、遅延揺らぎ無しの通信ニーズは、今後益々高まります。

IOWNが、これらニーズを満たし現状ネットワークの様々なボトルネックを解消した新たなサービスの実現、開発インフラになりそうです。IoT MCU開発者もまた、IOWNと2030年に向けた進化が必要です。

関連投稿：2030年のエンジニア



Rapidus（ラピダス）

WithHappy

Rapidusロゴ2022年11月11日、経産省キモ入りの日本国内8社（キオクシア、ソニー、ソフトバンク、デンソー、トヨタ自動車、NEC、NTT、三菱UFJ銀行）から成る次世代半導体（Beyond 2nm）製造会社：Rapidus設立（ITmedia）の記事は、世界と国内の半導体製造「10年遅れ、先端ロジック分野後進国」を取り戻すには、「異次元の取組みが必要」と報じています。

RapidusとLSTC体制で2030年までに市場規模100兆円目指す

次世代半導体プロジェクトはRapidusとLSTCの2本立て（出展：経産省サイト）
次世代半導体プロジェクトはRapidusとLSTCの2本立て（出展：経産省サイト）

年内に半導体技術の研究開発拠点：LSTC（Leading-edge Semiconductor Technology Center）も立上げ、研究開発はLSTC、製造はRapidusの2社体制で2030年までに市場規模100兆円を目指すそうです。

過去との差分

Rapidusが過去の半導体ファウンドリー設立と異なる点は、半導体ユーザ企業（ソフトバンク、デンソー、トヨタ自動車、NTT）が各10億円出資して参加している点と、Rapidus経営陣メンバーの本気度が高いことだそうです（2022年11月11日、日経xTECH）。

上記記事は、新会社への期待と不安も示しています。弊社も、RapidusとLSTCに注目していきたいと思います。

周回遅れの日本国内ワクチン産業との類似性

変異型COVID19と対応ワクチン
変異型COVID19と対応ワクチン

世界と国内の「10年遅れ」と類似する事象に、COVID-19国内ワクチン開発が「周回以上の遅れ」と指摘している記事があります。この記事も、対策には「抜本改革が必要」としています。

先端半導体研究開発とCOVID-19国内ワクチン開発、全く別分野ですが、両者の日本状況は良く似ています。

ワクチン不足から類推する先端半導体不足

ワクチン接種は、現在無料です。これは、政府が海外メーカからワクチンを買上げ、無料で国民に接種しているからです。

仮に、変異型ウイルス対応ワクチンが不足し、入手困難ならどうなるでしょう？ 旧型ワクチンでは変異型に対して効果が期待できない場合などは、国内パニックになるでしょう。

これと同じことが、先端半導体不足でも生じます。多くの製品や車は、半導体が性能、製品差の決め手です。先端半導体を使えないことは、日本製の新製品や新車の魅力が無いのと同等になるでしょう。

この事態を避けるためRapidusとLSTCの異次元取組みに期待し、日本の10年遅れを挽回してほしいです。

海外最新半導体製造ニュース

  • TSMC米国アリゾナ工場、3nm製造の可能性（2022年11月15日、EE Times）
  • 独）Infineon、アナログ/ミックスドシグナル/パワー半導体を新工場で製造計画（2022年11月15日、EE Times）

海外半導体製造の最新ニュースを2件示します。この分野は、Rapidusの強力ライバルが着実に進出中です。

先端IoT MCUはRTOS開発

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

個人レベル開発スキルもまた、Rapidusや国内ワクチン産業と同様、異次元の取組みや抜本改革無しの方法では、海外との開発競争にすらなりません。

景気後退が懸念される今、個人の開発スキルを磨き、先端技術人材になりましょう！

IoT MCU分野では、RTOS開発が先端技術だと筆者は思います。JACOB’S BLOGの5 RTOS Design Best Practicesが、とても参考になります。

関連投稿：RTOSテンプレート骨格、クリエイタ的エンジニア

本稿主旨は、「危機感は大切だが、あせりは禁物。お互い切磋琢磨しましょう」です。



64ビットMCU得失

WithHappy
RZファミリ位置付け（出展：ルネサスサイト）
RZファミリ位置付け（出展：ルネサスサイト）

今年春の3月2日、ルネサスが64ビットRISC-Vコア搭載の汎用MPU：RZ-Fiveを発表しました（!=MCU）。

本稿は、RISC-Vの簡単な紹介と、MCUの64ビット化得失についてまとめました。

RISC-V

リスク ファイブ（RISC-V）は、2010年にカルフォルニア大学バークレイ校（2022年世界大学ランキング第4位）で開始されたプロジェクト。オープン標準命令セットアーキテクチャ（ISA）でオープンソースライセンス。使用料無料。用途に応じた32/64/128ビット対応アーキテクチャで、RISC-Vチップや派生成果物の作成も許可。（Wikipediaより）。

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

ルネサスなどのMPU/MCUチップ製造側にとっては、ARMコアベースに比べ、ライセンス料が無く競合他社差別化や独自性も出し易いのがRISC-Vコアと言えそうです。※RZファミリには、ARMコア（Cortex-A55とCortex-M33ディアルコア）のRZ/G2ULもあるため、ArmベースMPUが最初の右グラフに記載。

日経xTECH記事（2022-09-13）によると、ルネサス以外にも、既に多くのRISC-V利用MPUや32ビットMCUが発表されています。RISC-V CPU搭載ノートPCも販売中です。

関連投稿：Cortex-MとRISC-V、1GHz 64ビットMPUのRZ/A3UL

IoT MCU要件

CPUやMPUは、64ビット化が進んでいます。Windows 11は、32ビット対応版がありません。また、ルネサスRZ-Five同様、NXPやSTマイクロでもMPUは全て64ビットです。

これは、CPU/MPUに要求されるセキュリティ機能や性能を満たすには、先行するサーバやデータセンタで開発したソフトウェア資産の移植が、64ビットの方が容易だからです。

一方、MCUは、性能・機能の向上と消費電力増加のバランスが、MPUに比べ重視されます。MCU設置個数は、MPUよりも桁違いに多いため既存MCU資産を活かすバイアスが働くためです。最初の右側グラフで、16ビットRL78が低消費電力の代表として表示されていることからも解ります。

このバランスのため現状のIoT MCU主流は、32ビットMCUです。

しかし、MCU製造プロセス改良や、電力供給の世界情勢、自動車ADASと半導体供給状況などにより、IoTセキュリティ機能への要求や、低消費電力への要求バランスは大きく変わる可能性もあります。場合よっては、CPU/MPU同様、64ビットMCUがIoTに適すかもしれません。

アクティブ消費電力とスリープ消費電力両方を減らせるSOTBプロセス（出典：ルネサスサイト）
アクティブ消費電力とスリープ消費電力両方を減らせるSOTBプロセス（出典：ルネサスサイト）

関連投稿：ルネサスのMCU新製造プロセス SOTB

また、IoT必須のRTOSをMCUへ適用する場合には、32ビットカウンタでは、タイマー満了周期が短い問題も指摘されています。

結論：64ビットMCU見通し

既存MCU資産（特にソフトウェア）をそのまま活かしMCU性能を上げるには、同一コア高速化が適します。一方、サーバやデータセンタのセキュリティ機能移植を考えると、64ビットMCUも有力です。また、IoT MCUのRTOS開発時は、32ビットカウンタの短さに注意が必要かもしれません。

ビット幅を意識することは、Cなどの高級言語でMCU開発する限り稀です。しかし、RTOS開発時や更なる性能・機能向上（例えばエッジAI）、効率的セキュリティ導入を求める時は、32ビットMCU限界が現れることもあり得ます。

アーキテクチャ変更で得るものと失うものバランス、トータル開発コスト、これらが次世代IoT MCUを決めます。今後主流のIoT MCUが32/64ビットいずれになるかは、流動的です。だからこそ、最新IoT MCUやMPU、RISC-V動向を注意深く観察する必要があるというのが結論です。



クリエイタ的エンジニア

WithHappy

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

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

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

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

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

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

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

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

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

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

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

自分事、主体的に考える

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

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

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

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

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

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

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

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

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

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

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

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



RTOSテンプレートの骨格

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に加筆）
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、ここだけです。

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

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

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

メニュー形式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へお寄せください。

関連投稿リンク

効率的MCU開発ディスプレイサイズ

WithHappy

MCU開発Eclipse IDE画面の表示情報量は多く、ディスプレイサイズや解像度が小さいと非効率です。効率的MCU開発ディスプレイサイズと解像度を検討し、Windows 11ノートPCに適したディスプレイサイズと要件を考察しました。

Eclipse IDE表示情報

Eclipse IDEとしてNXP社のMCUXpresso IDE 11.6.0を例にします。IoT MCU開発時は、どのViewにも重要な情報が表示されます。

例えば、上から解像度（1920×1080）、（1920×1200）、（2560×1440）、（3840×2160、150%テキスト表示）4つの表示例です。どれも筆者が頻繁に利用するネットカフェの同じ31.5型4Kディスプレイを用いました。

ちなみに、（1920×1080）が弊社所有14型ノートPC、（1920×1200）が24型デスクPCの表示サイズです。

解像度が大きくなると、各Viewへ一度に表示できる情報量が増えることが判ります。

1920x1080_100%のIDE View表示例
1920x1080_100%のIDE View表示例
1920x1200_100％のIDE View表示例
1920x1200_100％のIDE View表示例
2560x1440 100％のIDE View表示例
2560×1440 100％のIDE View表示例
3840ｘ2160_150％のIDE View表示例
3840ｘ2160_150％のIDE View表示例

ディスプレイサイズとテキスト表示サイズ

各Viewのタブをクリックすれば、そのViewだけを表示できます。ソースコード記述時など1点だけに集中する時は、この方法も使います。

しかし、多くの場合、複数Viewを参照しながら作業を行います。大きいディスプレイへ複数Viewを表示しながら作業する方が、効率的に開発が進むのは明らかです。

その結果、弊社は、14型ノートPCは主に確認用、24型デスクPCが開発用となります（ノートPCのマルチディスプレイ利用は次章説明）。

では、ディスプレイサイズが大きければ大きい程効率的かというと、そうでもありません。筆者の場合は、24型～27型位に最適値があります。

ディスプレイと目の距離を40cmとすると、27型よりも大きい31.5型ディスプレイは、圧迫感があるためです。また、テキスト表示サイズも150%へ変更しないと、小さすぎます。

100%テキスト表示で、A4用紙が実物と同じ大きさに表示されるのは、24型です。

つまり、24型～27型で40cm配置に、MCU開発効率が良いディスプレイ選択肢がありそうです。この時は、テキスト表示サイズは、100%でOKです。

ディスプレイと目の距離は、ノートPC、デスクPCどちらも同じ40cm以上（出展：富士通パソコンを使う時の姿勢）
ディスプレイと目の距離は、ノートPC、デスクPCどちらも同じ40cm以上（出展：富士通パソコンを使う時の姿勢）

効率的MCU開発のWindows 11ノートPC要件

ノートPCには、可搬性が求められます。ノートPCディスプレイに、14型や15.6型を用いるのは可搬性実現のためです。

しかし、ディスプレイ外枠を極力少なくし、16型や17型でも従来ノートPCに近い筐体を実現するノートPCも最近発売中です。

また、ノートPCは、マルチディスプレイでの使い方が前提です。Windows 11では、このマルチディスプレイ操作性が改善されました。

外付けマルチディスプレイの左右上下物理配置に応じた本体ディスプレイ１との再配置が可能です。ディスプレイ間のマウス移動時、違和感が旧Windowsに比べ無くなりました。さらに、外付けディスプレイの大きさを自動認識し、大きいディスプレイをメインとするタスクバー配置も行います。

Windows 11は、マルチディスプレイ上下左右配置に応じ再配置可能
Windows 11は、マルチディスプレイ上下左右配置に応じ再配置可能

従って、効率的MCU開発のWindows 11ノートPC要件は、

(1) 可搬性を犠牲にしない範囲で、できるだけ大きい本体ディスプレイ
(2) MCU開発効率の良い100%テキスト表示24型～27型マルチディスプレイ出力インタフェース

これら2つになります。

また、ノートPC本体ディスプレイと、外付けマルチディスプレイとの目の距離は同じ方が良いはずです。もし、外付けディスプレイとの距離が40cmよりも遠い場合には、27型よりも大型のディスプレイと100%よりも大きなテキスト表示が必要になります。

つまり、4K大型高解像度ディスプレイは、この外付けディスプレイの配置が、40cm以上遠くに設置した時の対応策が予め機能として備わっていると考えられます。

まとめ

効率的なMCU開発に適したWindows 11ノートPCディスプレイサイズを検討し、16型ディスプレイ、マルチディスプレイ出力インタフェース1本、の必須要件を示しました。

具体的な製品例を示すと、DELL)Inspiron 16 Intel（1920×1200、Core i7-1255U）、余裕があれば高性能CPU搭載のDELL）Inspiron 16 Plus プラチナ（3072×1920、Core i7-12700H）などです。

DELL）Inspiron 16 Plus プラチナ（3072x1920、Core i7-12700H）
DELL）Inspiron 16 Plus プラチナ（3072×1920、Core i7-12700H）

あとがき

本稿は、MCU開発ノートPCに焦点を絞っています。また、マルチディスプレイと言っても、外付けは1台だけです。このサイズが大きい外付けがメインディスプレイで、ノートPC本体は、補佐的な表示になります。やはり、大きなディスプレイは、開発効率化に直結します。

その結果、外付けディスプレイ2を、目から40cm距離の最適正面へ配置、ノートPC本体ディスプレイ1は、ディスプレイ2の左右、つまり脇役配置になります。

最近、低価格化が進む4K大型ディスプレイやノートPC（円安で価格上昇中）に、どの程度コストをかけるべきか、これは筆者個人の問題です。その問題解決・整理のために、本稿を作成しました。

もちろん、解像度が上がれば表示文字も綺麗に見易くなります。しかし、ネットカフェで31.5型3840×2160 150%テキスト表示ディスプレイを40cm位置で利用しMCU開発を何回か行った結果、4K大型ディスプレイ追加コストに見合うMCU開発効率化は得にくいと現状は思いました。

メタバース空間でWordやExcelが使え、MCU開発業務もVR空間でできることも、そう先の未来ではないかもしれません。それでも、ここ数年は、本稿結果が活きるはずです。

RAファミリprintfデバッグ3方法

WithHappy

ルネサス公式RAファミリ開発お役立ち情報ページがあります。本稿は、このページの中から、ソースコードを変更せずにprintfデバッグができるDymanic Printfを説明し、他の2方法と比較します。

Dynamic Printfの設定方法
Dynamic Printfの設定方法

printfデバッグ2方法

ソースコード変数値を出力し、デバッグする方法をprintfデバッグと呼びます。RAファミリ評価ボードにも、printfデバッグを容易にするツールや、外部ハードウェア（USART-USB変換）が実装済みのものもあります。

例えば、RAファミリのPFB-RA6E1（Cortex-M33/200MHz）、FPB-RA4E1（Cortex-M33/100MHz）の場合は、SEGGER J-Linkエミュレータサーキット経由でprintfデバッグできる無償J-Link RTT ViewerをPCへ追加すると、変数やユーザへの説明がPCへ出力できます。

競合他社の例では、STM32G071RBやLPCXpresso54114などは、評価ボードプログラミングとUSART-USBレベル変換機能を兼ねたハードウェアが実装済みのため、これを利用してVirtual COM経由でprintfデバッグが可能です。この場合も、Tera TermなどのPCコンソール表示フリーウェアが追加で必要になります。

Dynamic Printf

Dynamic Printfの特徴は、J-Link RTT ViewerやTera TermなどのPC追加ソフトウェア不要、e2studioなどEclipse IDEのDebug Console Viewへ、printfフォーマット変数数値を直接出力できることです。

Debug Console Viewへの出力設定は別途必要（Dynamic Printf動画30秒付近）ですが、前述のデバッグ2方法と比べると、ソースコードの記述変更も不要です。

Dynamic Printfは、ブレークポイントの一種です。一旦プログラムを停止し、設定変数をDebug Consoleへ出力後、自動的にプログラムを再開します。

例えば、センサAD変換値をDebug Consoleへ連続出力し、正常動作を確認する時などに重宝します。

RAファミリprintf 3方法まとめ

printf方法 J-Link RTT Viewer Virtual COM Dynamic Printf
ソースコード
記述例		 APP_PRINT(“\r\n> Current FSP version is v%d.%d.%d.”, version.major, version.minor, version.patch); VcomSndMsg(uint8_t *String, uint32_t Size); 不要
(Debug Console設定要)
追加ソフトウェア J-Link RTT Viewer
SEGGER_RTT
common_utlils.h		 Tera Term 不要
追加ハードウェア 不要 TTL-USBレベル変換要 不要
特徴 手軽にPC出力可能
色付き出力不可		 競合他社標準PC出力
色付き出力可能		 ソースコード不変
変数連続出力容易
出力例 J-Link RTT Viewer出力例 Virtual COM出力例 Dynamic Printf出力例

RAファミリ評価ボードのprintfデバッグに使える3方法を説明、特徴などをまとめました。

printfデバッグは、デバッグの最も基本テクニックです。確認したい変数出力だけでなく、プログラムや操作方法の説明出力などにも使います。

Virtual COMの方法は、Tera Term追加が必要ですが一般的なMCU開発でよく用います。

J-Link RTT Viewerの方法は、TTL-USBレベル変換非搭載の低価格RAファミリ評価ボードで使います。

Dynamic Printfは、Eclipse IDE搭載機能です。ブレークポイントを設定し、変数のprintfフォーマット出力後、自動的に再実行します。センサAD変換値を連続表示する時など、ソースコード変更なしに手軽に変数出力とセンサ動作確認できるので便利です。

最初に示したルネサス公式RAファミリ情報ページには、本稿printf以外にも多くのTipsが掲載中です。説明や動画が短く纏まっているので、隙間時間のチェックに都合が良く、開発ヒントも得られます。

RA用e2studio 2022-07リリース

WithHappy

2022年8月31日より、FSP v4.0.0同梱RAファミリ最新開発環境e2studio 2022-07が、ダウンロード可能です。

FSP for RA MCU Family, version 4.0.0. (2022/08/31)

FSP同梱インストーラ利用指示

RAファミリはFSP同胞インストーラ利用指示
RAファミリはFSP同梱インストーラ利用指示

RAファミリ以外の単体e2studioバージョンアップは、7月20日でした。

RAファミリのアップデートは、上記リリースノートのようにFSP（Flexible Software Package）同梱インストーラ利用指示があるため、RA用のe2studio 2022-07リリースは、単体から1.5ヶ月遅れの8月31日になりました。同梱インストール理由は、不明です（単体e2studio+単体FSPインストールも可能ですが、指示に従う方がBetter）。

また、e2studio 2022-04以降、Windows 11-64bitに正式対応しました。弊社の先行Win11 21H2も、最新FSP同梱RA用e2studio 2022-07の正常動作確認済みです。

但し、ルネサス半導体セミナーやリリースノート、サンプルコードの説明書きなどは、未だWin10です。

Win11への移設は、今秋予定の22H2発表後でも良いと思います。Win11 22H2は、9月20日リリース情報があります。仮に9月20日なら、次回投稿は、弊社Win11 21H2の22H2大型更新レポートになるでしょう。

Example Project Bundle

RA6E1（左）とRA4E1（右）サンプルコード一覧
RA6E1（左）とRA4E1（右）サンプルコード一覧

弊社推薦RA6/4ファミリ評価ボード：FPB-RA6E1、FPB-RA4E1サンプルコード：FPB-RA6E1/FPB-RA4E1 Example Project Bundleも、最新版がリリースされました（2022/08/11）。

最新Example Project Bundleでも、多くのベアメタルサンプル、FreeRTOSサンプルは1個（下線）、Azure RTOSサンプルは0個です。

Cortex-M33コア採用のRA6/4は、IoT MCUでFSPもRTOS対応済みです。先ずは、ベアメタル開発でFSPに慣れてもらうという意図でしょうか？

RA開発環境まとめ

9月16日時点の最新RA開発環境バージョンアップ状況をまとめたのが下図です。

RA用開発環境のバージョンアップ状況
RA用開発環境のバージョンアップ状況

RA用の開発環境は、FSPバージョン版数が不揃いです。例えば、FSP同梱e2studioのFSP版数は、v4.0.0なのに、最新Example Project BundleのFSP版数は、v3.8.0で1世代前です。

しかし、v3.8.0のExample Project Bundleは、下図のようにFSP ConfigurationのBSPタブで最新FSP version 4.0.0へ変更が可能です。変更後、Generate Project Contentをクリックすれば、FSP v4.0.0でのAPIコードやひな型コードが生成されます。

FSPバージョン変更方法
FSPバージョン変更方法

また、直にIoT MCU RTOS開発を始めたいベアメタル開発経験者には、FreeRTOSやAzure RTOSサンプルコード数が少ないことも問題です。

対策案として、前投稿説明のベアメタルサンプルコードからRTOSコードを自作する方法をお勧めします。

RTOSの目的や機能を教科書から学ぶよりも、自作サンプルコードから理解していくベアメタル起点のRTOS習得方法は、RTOSスキルを磨きベアメタル補完RTOS開発の面白さを知る良い方法だと思います。

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

WithHappy

ルネサス公式センササンプルコードを使って、ベアメタル処理を起点とする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ソフトウェア開発手法としてまとめました。