ルネサス公式センササンプルコードを使って、ベアメタル処理を起点とするRTOS（FreeRTOS/Azure RTOS）ソフトウェア開発手法を説明します。
筆者にしては、長い投稿です。要旨は、「ベアメタル処理＋RTOS処理待ち＝RTOS処理」です。
ベアメタル処理とFreeRTOSタスク処理並列多重
センササンプルコード
- FS2012 Sample application – Sample Code
- HS300x Sample application – Sample Code
- ZMOD4xxx Sample application – Sample Code
説明に用いたセンササンプルコードが、上記3種類です。ダウンロードには、ルネサスのログインが必要です。同一動作のベアメタル/FreeRTOS/Azure RTOS、3個のe2studioプロジェクトが同胞されています。動作MCUは、ルネサス）RA/RX/RE/RL78ファミリです。
サンプルコードマニュアルだけは、下記からログイン不要でダウンロードできます。本稿は、これらマニュアル情報だけで読める工夫をしました。
- FS2012 Sample application
- HS300x Sample application
- ZMOD4xxx Sample application
FS2012がガスフローセンサ、HS300xが湿度・温度センサ、ZMOD4xxxが高性能ガスセンサです。この順番で、サンプルコードが複雑になります。
そこで、焦点を、一番簡単なFS2012サンプルコード、動作MCUをRA6M4（Cortex-M33/200MHz/1MB Flash/256KB RAM）に絞って説明します。他サンプル/MCUでも同様の結果が得られます。
なお、3サンプルコードは、ベアメタルからRTOS開発へステップアップする時にも適したコードです。
センサとMCU間接続：I2C
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と利用手順
ベアメタル処理フロー
RTOS開発の起点となるベアメタル開発の処理フローです。
FS2012のベアメタル処理フロー
初期設定で、I2Cとセンサを初期化し、無限ループ内で、センサデータ取得と取得データの演算を繰返します。センサデータの連続取得に409.6ms遅延時間が必要であることも判ります。センサデータ取得完了は、センサ割込みを使って検出しています。
このベアメタル処理フローも、特に変わった点はありません。
RTOS処理フロー
ベアメタルと異なる処理だけを橙色抜粋したFreeRTOS処理フローです。
ベアメタル処理と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開発者スキルの階層構造
ベアメタル処理を、効率的に複数並列動作させるのが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開発になります。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ベアメタルテンプレート概要
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ソフトウェア開発手法としてまとめました。
