FreeRTOSアプリケーションテンプレートのQueue利用タスク間データ送受信を説明します。これは、テンプレートのベースとしたMCUXpresso SDK付属FreeRTOSサンプルプロジェクトfreertos_generic解説の後半に相当します。
FreeRTOSアプリケーションテンプレートのベースプロジェクト（まとめ図参照）は、本稿で全て説明済みとなります。下記1～3が、関連投稿です。1～3の順にお読み頂くと、内容が解り易いと思います
- FreeRTOSアプリケーションテンプレート構想
- FreeRTOS新規プロジェクト作成からアプリケーションテンプレートまで
- テンプレートベース：freertos_generic前半（ソフトウェアタイマ関連）
freertos_genericのQueueによるデータ送受信
FreeRTOSでは、送信タスクと受信タスクの２つに分離しデータ送受信処理を開発します。
送信タスクは、自分の都合の良いタイミングで、いつでもデータ送信を始めます。受信タスクは、いつ始まるか判らないデータ送信に対し、常時受信できるように待機中です。但し、受信タスクの受信開始タイミングは、その他のタスク優先度により変動します。
この受信開始変動があっても送信データを取りこぼし無く受信するために、送受タスク間で一時データを格納するFIFOバッファが必要で、これがQueue（以下Q）です。マルチタスクによる副作用と言えます。
もちろん、データ溢れが生じないようQには複数データを蓄える深さも必要です。受信タスクは、データのQ完了イベントで、FreeRTOSが受信開始を起動します。また、送信タスクよりも、受信タスクの方が優先度が高いのは、Qデータ溢れ防止策です。
１データ長、データ送信タイミング、その他のタスク数やその優先度にも影響されるQの深さは、十分な検討が必要です。
freertos_genericでは、Qの深さを1データ、送信タスク優先度を1、受信タスク優先度を2とし、データを100固定値にして1バイトデータ長の送受信を行い、送信開始タイミングは、vTaskDelayUntil（後述）で作成しています。その他のタスクが、freertos_generic前半で説明したソフトウェアタイマタスク、この優先度が4です。
同一優先度のタスクが無く、他のタスク数もタイマタスク1個で高優先、1バイトデータ長のため、深さ１のQでも送受信データは溢れません。
少ないタスク数と同一優先度無しのシンプルなサンプルプロジェクトですが、簡単に説明しても上記のように長くなります。
ベアメタル開発経験者であれば、RTOS個々の文章説明（＝Serial or Sequential動作）は、理解できます。しかし、RTOSによりシングルコアMCUであっても各タスクが時分割Parallel動作しますので、途端に解り難くなります。
BareMetal/SerialからRTOS/Parallelへ、従来の設計手法をステップアップする必要がありそうです。
vTaskDelayUntil対vTaskDelay
freertos_genericは、データ送信タイミングの作成に、他のサンプルでよく見かける待ち処理：vTaskDelayではなく、vTaskDelayUntilを使っている点に注意が必要です。
vTaskDelayは、指定待ち「時間」後、RTOSにより優先度に応じて次処理が実行されます。ゆえに、高優先の他タスクやその状況により、次処理実行までの待ち時間が変動します。
vTaskDelayUntilは、指定待ち「周期」後、次処理が実行されます。仮に2周期よりも長い待ちが発生した時は、次処理はスキップされます。つまり、vTaskDelayよりもデータ送信の（スキップも含めると）定間隔、周期性に優れています。
サンプルプロジェクトの場合、Qの深さが最小の1のため、vTaskDelayUntilの方が、Q溢れ対策として効果があります。vTaskDelayだと、変動を考慮し、より深いQが必要になりそうです。但し、vTaskDelayUntilのRAM使用量は、vTaskDelayよりも増えます。
つまり、vTaskDelayUntil 利用か、それとも、vTaskDelayとQの深さ利用か、どちらにRAM資源を割当てる方が、よりQ溢れ対策として効果的か、これが検討ポイントの1つです。freertos_genericでは、前者を選択した、と筆者は解釈しました。
参考資料：Kernel > API Reference > Task ControlのvTaskDelayUntilとvTaskDelay
本稿まとめとFreeRTOSアプリケーションテンプレート目的
FreeRTOSアプリケーションテンプレートのQ利用タスク間データ送受信を説明しました。Qにより、送信タスクと受信タスクを分離して開発できますが、Qの深さは、送受タスク以外の他タスク優先度など多くの要因にも関係するため、設計に注意が必要です。
FreeRTOS利用メリットは、ベアメタル開発に比べ、独立性や流用性が高いタスク開発ができることです。反面、優先度に応じたマルチタスク環境では、ベアメタル開発には無かったスキルも必要になります。
本稿説明のSDK付属FreeRTOSサンプルプロジェクトfreertos_genericをベースにした、Cortex-M4コア最高速150MHz動作LPCXpresso54114対応のFreeRTOSアプリケーションテンプレートは、6E目標に開発中です。
同じ動作のアプリケーションを、FreeRTOSとベアメタル、それぞれで開発した2つのプロジェクトを添付します。
FreeRTOSアプリケーションテンプレートの目的は、FreeRTOS特有スキルを、ベアメタルと比較し、具体的に理解・習得すること、基本的なFreeRTOSアプリケーション開発テンプレート（＝スタートプロジェクト）としても使えること、の2点です。
なお現行のLPCXpresso54114開発SDKツールデフォルトコア速度100MHzを150MHz動作へ変える方法は、前稿を参照してください。