STM32MCUでRTOS開発を行う時の3注意点、前編のSTM32CubeMX、HALに続き、本稿後編でCMSIS-RTOS関連を示します。
※木曜からの東京オリンピック4連休のため、通常金曜を本日水曜日に先行して投稿します。
前編は、STM32RTOS開発実例として、NUCLEO-G474RE FreeRTOS_QueuesサンプルプロジェクトのSTM32CubeMX（以下CubeMX）コード出力を使い、HALタイムベース変更の必要性を示しました。後編は、前編と同じ実例を使ってCMSIS-RTOSの注意点を示します。
FreeRTOS_Queues STM32CubeMXファイルのTasks and Queues
NUCLEO-G474RE FreeRTOS_QueuesサンプルプロジェクトのCubeMX構成ファイル：FreeRTOS_Queues.icoを開き、Middleware>FREERTOSのTasks and Queuesタブをクリックしたのが下図です。
2つのタスク：MessageQueuePro（Ｑプロデューサ：送信タスク）とMessageQueueCon（Ｑコンシューマ：受信タスク）と、1つのQ：osQueue（深さ1：ワード）を、CubeMXで自動生成するパラメタが設定済みです。関連投稿：NXP版FreeRTOSのQueueデータ送受信と同じです。
全て黒文字パラメタですので、変更も可能ですが、このままソースコードを自動生成（Alt＋K）してください。
CMSIS-RTOS APIからFreeRTOS API変換（wrapper）
main.cのL125に、osQueueを生成するAPI：osMessageCreateが自動生成済みです。また、L134とL138に、MessageQueueProとMessageQueueConのタスク（Thread）を生成するAPI:osThreadCreateも自動生成済みなのが判ります。
ここで、API先頭にosが付くのは、CMSIS-RTOSのAPIだからです（L145のosKernelStartも同様）。詳細は、次章で説明します。
さて、L125のosMessageCreateへカーソル移動し、F3をクリックすると、cmsis-os.cのL1040へジャンプし、CMSIS-RTOS APIのosMessageCreateの中身が見えます。その中身が、L1055のxQueueCreateで、これはFreeRTOSのAPIです。
つまり、CubeMXが自動生成したのは、CMSIS-RTOS APIですが、その実体は、FreeRTOS APIであることが判ります。
この例のように、CubeMXが生成したCMSIS-RTOS APIは、cmsis_os.cで全てFreeRTOS APIへ変換されます。
CMSIS-RTOS
CMSIS-RTOSは、Cortex-Mコア開発元ARM社が定めたRTOS APIの規格です。
※CMSIS：Cortex Microcontroller Software Interface Standard
Cortex-Mコアには、FreeRTOS/Azure RTOS/mbed OSなど様々なRTOSが使えます。下層のRTOSが変わるとAPIも変わりますが、そのAPIを変換し、上層アプリケーションへ共通なRTOS APIを提供する、これにより、
- RTOSが異なっても、同じ開発アプリケーションが使えること
- Cortex-Mコアが異なっても、開発アプリケーション移植を容易にすること
これらがCMSIS-RTOSの目的です。
これをラップ（wrap＝…を包む）と呼ぶことがあります。ラップ関数（wrapper）とは、下層API差を隠蔽し、上層アプリケーションへ同一APIを提供する関数のことです。STM32RTOS開発でのCubeMXの役目の1つは、使用するRTOSに応じたwrapperを提供することです。
現在、STM32RTOS開発のCubeMXがラップしているのは、FreeRTOSだけです。今後、FreeRTOSがAzure RTOSなどへ変わっても、開発アプリケーションをそのまま活用するために、今の時点からCMSIS-RTOS APIを使っている訳です。
Cortex-M0/M0+/M3/M4/M7コア向けの共通RTOS APIがCMSIS V1、Cortex-A5/A7/A9と全Cortex-Mコア向けの共通RTOS APIがCMSIS V2です。STM32RTOS開発では、CMSIS V1を用います。
CMSIS-RTOS とFreeRTOSのAPI
UM1722にCMSIS-RTOS APIとFreeRTOS APIの一覧が示されています。抜粋したのが下表です。
接頭語にx/vなどが付くのがFreeRTOS API、osが付くのがCMSIS-RTOS APIです。
CubeMXが生成するコードは、常にCMSIS-RTOS APIですが、実体はFreeRTOS APIです。FreeRTOSが別のRTOSへ変わっても、CMSIS-RTOS APIは同じです。CMSIS-RTOS APIとFreeRTOS APIのwrapper分のオーバーヘッドは生じますが、下層RTOSに依存しない点は、先進的で優れています。
なおUM1722 Rev3には、単にAPI列記とwrapper、RTOSサンプルプロジェクトの簡単な説明が記載されているだけです。
まとめ
STM32MCUでRTOS開発を行う時の3注意点（前編：STM32CubeMX、HAL）に続き、本稿後編で3つ目のCMSIS-RTOSを示しました。
STM32RTOS開発のSTM32CubeMXが扱うRTOSは、現在FreeRTOSだけです。FreeRTOSが別のRTOSへ変わっても、CubeMXは、開発アプリケーション流用性を高めるためにFreeRTOS APIの代わりにRTOS共通CMSIS-RTOS APIを出力します。
CMSIS-RTOS APIには、Cortex-M0/M0+/M3/M4/M7コア間で開発アプリケーション移植性が高いCMSIS V1を使います。
CMSIS-RTOS API変換オーバーヘッドがありますが、流用性、移植性に優れたRTOSアプリケーション開発ができる点は、優れています。
あとがき
残念ながらCMSIS-RTOS情報は、シェア1位AWSのFreeRTOSに比べ少なく、この少ない情報を使ってSTM32RTOS開発を行うのは、大変です。
※2位がAzureのAzure RTOS、3位がGCP（Google Cloud Platform）のmbed OS。関連投稿はコチラ。
例えば、最初の図：CubeMXのTasks and QueuesのGUI設定パラメタが多いにもかかわらず、UM1722サンプルプロジェクト説明が少ない点などです。
RTOSは、複数タスク（CMSIS-RTOSではThread）間の優先順位差とRTOS自身の動作により、開発タスク処理状態が変わります。ベアメタル視点に加え、RTOS視点でのタスク開発と経験が求められます。QueueなどRTOS単独手段理解が目的のサンプルプロジェクトだけでは、RTOS開発経験は積めません。
弊社はこれらの対策として、効率的なRTOS基礎固め、STM32RTOSアプリケーションのプロトタイプ開発早期着手を目的としたSTM版RTOSアプリケーションテンプレート（仮名）を検討中です。その構想は、固まり次第、別稿にて示す予定です。
なお、NXP版FreeRTOSアプリケーションテンプレートは、コチラで販売中です。
