コア間通信について

Armadillo-900はLinuxからCortex-M33の周辺デバイスを使うために、コア間通信を利用しています。分かりやすいデバイス例を挙げると、前回も使用したGPIO PTC5のSYS LEDです。このLEDはLinuxのデバイスファイル「/sys/class/leds/sys/brightness」に登録されており、以下のLinuxコマンドでON/OFFできます。

armadillo:~# echo 1 > /sys/class/leds/sys/brightness
armadillo:~# echo 0 > /sys/class/leds/sys/brightness

このコマンドを実行すると、Cortex-A35からコア間通信APIのRPMsg-Liteを使ってCortex-M33にデータを送信します。ただし、Cortex-M33は前回のままだとLチカ状態にあるので、Linuxからコマンドを実行しても変化はありません。

コア間通信のデバッグ

実際のRPMsg-LiteはSRTMというラッパーAPIで使用されます。Linuxからのデータ受信は「SRTM_RPMsgEndpoint_RxHandler」という関数となっていますので、ここにブレークポイントを設定して、デバッグができることを確認してみましょう。

PALMiCE4を再度使用して、コードウィンドウに「SRTM_RPM」と入力し、Ctrl+Spaceキーを押します。

そうすると、一致するシンボル名がリスト表示されますので、その中から「SRTM_RPMsgEndpoint_RxHandler」を選択し、関数の先頭にブレークポイントを設定します。

実行ボタンをクリックして、Armadillo-900のLinuxのコンソールから以下のコマンドを入力します。

armadillo:~# echo 1 > /sys/class/leds/sys/brightness

こちらの思惑どおり、停止しました。Linuxのコンソールにはタイムアウトのメッセージが表示されますが、これはCortex-M33からのレスポンスがないためです。

このようにして、LinuxからCortex-M33のファンクションをデバッグする方法が確立しました。では、ついでに実際にGPIOを制御しているところまで見てみましょう。

GPIO出力はどこで？

現在、SRTM_RPMsgEndpoint_RxHandler関数で停止していますが、ここからステップ実行でGPIOの出力にはたどり着きません。処理的には受け取ったデータをキューに格納して終わりとなります。キューからデータを取り出すのは別のタスクで処理されます。以下はPALMiCE4のRTOSデバッグ機能でタスクの実行状態を表示しています。RTOSデバッグ機能については今回は有効にしていませんので、詳しい設定方法はPALMiCE4の動作確認済みボード「Armadillo-900セットアップ説明書」をご覧ください。

さて、SRTMのタスクにはモニタタスクと、ディスパッチャタスクが動いており、ディスパッチャタスクはキューから取り出したデータを解析して、各サービスを実行します。GPIOの処理は最終的に「SRTM_IoService_Request」という関数で処理されます。この関数はさらにコマンド別に振り分けられて、case文の GPIO_RPMSG_OUTPUT_SETの「handle->outputSet」で実際のポート出力が実行されます。

さらに進むと...

base->PSORへのビット書き込みで、ポート出力のコードにたどり着きました。

まとめ

Armadillo-900でのアプリ開発はLinuxがメインとなりますが、リアルタイム処理にはCortex-M33の活用が必須となります。Cortex-M33はFreeRTOSで動作していますが、ユーザはこれにタスクやタイマ処理を追加していく形で開発していくことになります。しかし、実際に開発する段階で、開発環境やコードの追加方法など、グレーな領域が存在します。本稿ではこれらのグレーな領域をなるべく省略せず記載し、解釈が明確になるようにしました。この記事を読んで、グレーな領域が少しでもクリアになれば幸いです。