FREQMを使ってCPU使用率を調べる

ABDACBの44.1KHzクロック用にクリスタルを交換するつもりでいましたが、数字を読み間違えていたことに気付いて挫折感に浸っています。しばらくは、交換しないでこのまま作業を続けることにします。

さて、先週の記事で示したように、現在のクロック系統ではPLL出力の192MHzを8分周した24MHzをmain clockとして選択し、これをCPUクロックとしています。

SAM4Lは48MHzでの動作が可能なのですが、36MHzを超える場合にはPower Scalingの機能を使ってPS2のモードに遷移する必要があります。また、フラッシュの読み出しにもウェイトを加えねばなりません。こんな理由で、いまのところはCPUクロックを24MHzとしています。FREQMでのクロック測定の結果も次のようになっていました。

この出力は、JTAGを使ってファームを書き込み/実行した際に取得したものです。ところが、いったんボードをリセットしたり、JTAG無しで動作させると、次のような出力になってしまいました。

CPUクロックの数値が激減してしまいました。それどころか、ゼロになってしまうことすらあります。FREQMの使い方をどこか間違っているのかとも思いましたが、他のクロックの数値は問題なく出ているので、FREQMの使い方に問題があるわけではありません。しばらく考えてみて、これはちゃんと正しくCPUクロック数を計測した結果なのだということに気がつきしまた。

以前の記事にも書いたように、FREQMによる周波数の計測には32KHzクリスタルを参照基準クロックとしてつかっています。今回の計測では、この参照基準クロックが250回カウントする間に、測定対象クロックが何回刻まれたかを数えることにより、測定対象クロックの周波数を算出しています。上記の出力とクロック系統図を見るとわかるように、GCLK0の出力は参照基準クロックの32KHzそのものです。そのため、GCLK0の測定クロック数も250となり、算出した周波数が32768Hzとなっているわけです。ちなみに、250クロックは7.62msに相当します。

続いて、CPUクロックの測定結果の意味を考えてみます。2回の測定結果は、7.62msの間にCPUクロックがそれぞれ285回と0回しか入らなかったことを意味します。CPUクロックが入らなければ、当然CPUは動いていないことになります。つまり、スリープしているということです。

FREQMによる周波数計測では、割り込みにより計測終了待ちをしており、割り込みが入るまではWFI命令を使ってスリープする作りになっています。そのため、計測が終わるまではCPUクロックが止まっていると考えることができます。1回目の計測のように０ではない計測結果が得られることもあります。これはどういうことかというと、7.62msの計測期間の間に、タスク制御に使用している10msに１回のsystick割り込みが発生した場合であると考えることができます。JTAGを使っていた時にはクロック源の周波数が出ていましたが、これはJTAGデバック時にはCPUのデバック機能を動かすためにCPUクロックが供給され続けるためのようです。

このようにCPUクロックの計測結果は、クロック生成部の出力を計っているのではなく、省電力機能によるクロック・ゲーティングが働いて実際にCPUに入っているクロック数を数えているのだと推測すると、つじつまが合うのです。試しに、割り込み待ちではなくポーリングにより計測終了待ちをしてみると....

ちゃんと24MHz相当の値になりました。CPUクロックは、実際にCPUが動いた割合を反映することが確認できました。したがって、実行すべきタスクが無い場合にはちゃんとスリープするようにソフトウェアが組まれていれば、この値からCPU使用率を導出できることになります。今度は、IISCとABDACBを動かして受信した音楽データの再生処理をしてみましょう。

再生処理が動いていない期間では、実効クロック速度が37KHz程度であったのが、再生中は146KHz程度に増えていますが、それでも24MHzの0.6%程度に過ぎません。再生処理といっても、その実態はDMA割り込み処理にしか過ぎないので、CPUの負荷は小さいことが良くわかります。