先ごろ、STM32N6の発表に伴いSTM32CubeMXのアップデートがありました。ほぼ時を同じくしてX-Cube-FreeRTOSも新しくなっていたので内容を確認してみたのですが、使用されているFreeRTOSのバージョンは10.6.2となっており、ちっとも新しい感じがしません。
LVGLPlayerではCubeMXが生成してくれるFreeRTOSを使っていたのですが、V11が使えないままなのにはがっかり。そこで方針転換して CubeMXが生成するFreeRTOSは使わないことにして、GItHubから直接V11を持ってくることにしました。ソースコードでは、RTOS APIとしてはCMSIS RTOS2を使っているのですが、その部分だけはX-Cube-FreeROTSに含まれているコードを流用しています。
さて、どうしてFreeRTOSV11が使いたかったかと言うと、それはSystemView が使いたかったからです。FreeRTOSV10でもSystemViewが使えるのですが、そのためにはFreeRTOSのソースにパッチを当てる必要がありました。それが面倒なので、SytemViewを使うのをためらっていたのですが、FreeRTOSV11ではカーネルソースへの変更が不要になり、FreeRTOSConfig.h を編集するだけで済むようになりました。
実際に使ってみるとトレース情報が多すぎてすぐにイベントバッファのオーバフローが発生してしまします。そこでSEGGER_SYSVIEW_Conf.h に
#define TRACERETURN_ENABLE ( 0 )
の一文を追加。これで細かいFreeRTOS APIのトレース情報出力を抑止することができます。
まっとうに動くようになったので、以前から気になっていたMusic PlayerでDOOM音楽を再生中の動作をキャプチャしました。
全体的に紫色で示されるguitaskの実行時間が多いことが一目瞭然です。というか、guitaskで埋め尽くされているために、Idle時間が全く生じていないことがわかります。guitaskは LVGLの処理を担当するタスクであり、画面の更新とその再描画にかなりの時間がとられていることになります。
もう少し拡大してみます。。。
中央部分に見られる緑色の flacreaderは、音楽データであるFLACファイルをSDカードから読み出して展開デコードする処理を担当しています。これにもそこそこの時間が取られていることがわかります。FLACファイルを展開して得られたPCMデータは、mixplayerによってFFT解析されて画面上に廻る放射状のバーとして表示されます。このタスクは青緑で表示されていますが、それほど時間がかかっているわけでもありません。つまり、FFTの演算処理は十分に短い時間で終了しているものの、それを画面に反映するための guitask処理に多くの時間が取られているということがわかります。
次の例は、Doom PlayerではなくBluetooth Playerを実行して音楽を再生した場合の様子。
SDカードからFLACファイルを読むわけではないのでflacreaderタスクは動いていません。A2DPで音楽データを受信してデコードしているので、btstackタスクの実行時間が増えているのがわかります。それでも、やはりguitaskの実行時間が圧倒的に支配的なのが良くわかります。うーん、これ以上高速化をはかるためには、DMA2Dを使うしかないかな。LVGLのレンダリング処理にDMA2Dを使っても効果は限定的らしいのですが。。
最後の例はOscilloscope Musicを実行した場合です。
ここではflacreaderタスクはSDカードからWAVファイルを読み込んでいますが、中身は16bit PCMですのでデコード処理は必要ありません。そのため、サンプリング速度が192Kと高速でも処理時間は短くて済んでいます。一番時間をとっているのはやはりguitaskですが、前の例と違ってしCPU Loadの表示に白い余白部分(すなわち Idleタイム)ができており余裕で処理できていることがわかります。
