前回FSP利用FreeRTOSアプリの作り方で、ルネサス公式サンプルコードを流用・活用した実践的RTOSアプリ開発方法を示しました。今回は、前回開発したアプリを使ってFSPの役目、RTOSアプリがどのように動作開始するかを説明します。
これからRTOS開発を始めるベアメタル開発経験者に役立つと思います。
前回のおさらい
FPB-RA6E1評価ボードのLED1点滅速度を、SW1プッシュ割込みで変える1スレッドのみを持つRTOSアプリの開発方法を、新規FreeRTOS Blinkyプロジェクトへ評価ボード実装済みベアメタルサンプルコードを移植することで説明したのが、前回のfreertos_blinkyプロジェクトでした。
※12月9日投稿時、FSP Importした割込みコントローラ初期化の記述を忘れていました。翌日10日に追記済みです。お詫びします<(_ _)>。
本稿の目的
ルネサスFSP（Flexible Software Package）は、ベアメタル、FreeRTOSとAzure RTOS、これら3者に対応した周辺回路API とMCU起動ファイルを自動生成するツールです。
※MCU起動ファイルは本稿ではstartup.c、main.c、ユーザファイルの3つを指します。
従って、初めてFSPを利用する時は、戸惑う部分もあります。例えば、ベアメタル開発には無関係のスレッドやオブジェクト設定エリアがあること、FreeRTOS開発時でもタスクではなくスレッドへ統一された説明やパラメタ設定があるなどです。
つまり、１つのFSPでベアメタル、FreeRTOS、Azure RTOSの3者に同時対応したため、FSPパラメタ設定や説明に解りにくい点があります。
※本稿も、FSPに習ってタスクではなくスレッドを用います。
また、当然ですが、ベアメタルとRTOSでは、FSP生成のMCU起動コードも異なります。何度か開発すれば、ベアメタルとRTOSでどこが違うかが判ります。しかし、初めからハッキリ区別した説明があるとFSPとRTOS理解が早くなります。
そこで本稿は、FSP生成MCU起動ファイルとベアメタル/RTOSユーザファイルまでの動作差を説明します。
FSP自動生成MCU起動ファイル（startup.cとmain.c）
startup.c：リセット後のMCU動作開始には、動作クロック設定やRAMゼロクリアなど、様々な前処理が必要です。これら前処理を行うのが、startup.cです。startup.cは、ベアメタル/RTOSともに同じ処理です。
main.c：ベアメタルでは、startup.c→main.c→user_main.cと処理が進みます。RTOSは、startup.c→main.cだけです。main.cの処理内容がベアメタルとRTOSで異なります（次章の図参）。
ベアメタルのmain.cは、実質のメイン関数であるuser_main.cへの橋渡しファイルで処理はありません。なぜ橋渡しファイルを使うかは、後で説明します。
RTOSのmain.cには、ユーザがFSP Configurationで追加したスレッドやオブジェクトの生成関数が、FSPにより自動追加されます。例えば、前回のfreertos_blinkyプロジェクトのmain.cなら、下線部分です。
FSP生成のmain.cは、スレッドやオブジェクトを生成し、最後に橙色で囲ったRTOSタスクスケジューラを起動してリターン（終了）します。
つまり、RTOSのmain.cは、「全てのRTOS処理を開始するための前処理、準備」を行います。
因みに、FSP生成startup.cやmain.cは、ユーザが勝手に変更を加えにくいようプロジェクトファイル階層の深い部分や、ユーザフォルダ：srcとは別フォルダ内にあります。
FSP生成ベアメタルまたはRTOSユーザファイル（user_main.cまたはuser_thread_entry.c）
逆にユーザファイルは、変更を加え易いよう最上位のユーザフォルダ：srcの中にFSPが生成します。ベアメタルならuser_main.c、RTOSならuser_thread_entry.cです。
ベアメタルでは、実質のメイン関数：user_main.cがmain.cから起動します。user_main.cは、周辺回路の初期設定と、無限ループの2構成から成るごく普通のメイン関数です（関連投稿：組込み開発 基本のキ 組込み処理）。
一方、RTOSは、main.c内でFSPが追加した生成関数user_thread_createによりuser_thread_entry.cが起動します。前章のfreertos_blinkyプロジェクトで示すと、blinky_thread_createとblinky_thread_entry.cです。
ユーザが複数スレッドを追加した場合は、各スレッドが下図のようにmain.c内で生成され、RTOSによる複数スレッド並列動作となります。
それぞれのスレッドは、優先度やセマフォなどのRTOSオブジェクトに従って、つまりRTOS環境で制御されます。
FSP利用のRTOS開発は、main.cまでがベアメタル動作、これ以降はRTOS動作環境になります。
ベアメタルのmain.cがuser_main.cへの橋渡しファイルなのは、右側のRTOS動作環境の形に無理やり(?)合わせたためだと思います。FSPは、Azure RTOS＞FreeRTOS＞ベアメタルの順位で設計されたからでしょう。
まとめ：FSP利用FreeRTOSアプリ起動動作
ユーザ設定のFSP Configurationを基にFSPは、周辺回路APIを生成し、同時に、MCU起動ファイル（startup.cとmain.c）とユーザファイルを分離して生成します。
FSP自動生成ファイルやAPIには、ユーザが手動変更しないようわざわざ下記注意コメントが先頭に付いています。
/* generated XYZ source file – do not edit */
また、FSP生成ユーザファイルにも下記コメントが付いています。
/* TODO: add your own code here */
これらFSPコメントに従って、ユーザがコメントの後へユーザコードを追加すればアプリが開発できます。ただ、開発にはFSPが生成するファイル内容や、FSPが想定しているベアメタル/RTOSアプリ動作の理解が必須です。
そこで本稿は、FPB-RA6E1 FreeRTOSアプリ（freertos_blinky）を使ってFSPが生成したMCU起動ファイルとRTOSユーザファイル動作を説明しました。
その結果、ベアメタルでは橋渡し役のmain.cが、RTOSでは全てのRTOS動作開始の前処理、準備を行うことを示しました。
ルネサスMCU開発は、FSP理解が鍵です。FSPが自動生成するベアメタルとRTOSユーザファイルまでの起動動作が判ると、FSP理解とベアメタル開発経験者のRTOS開発が容易になります。