Skip to main content

2. CPU動作

動機#

このセクションでは、マイクロコントローラ・コア、内蔵RAM、Flashが目的とするクロック速度で動作していることを確認します。

TouchGFXは、どのようなマイクロコントローラ速度でも動作可能ですが、クロック設定を誤ると、必要な性能を満たせない可能性があります。 この後のボードの立ち上げでは、タッチ・コントローラのI2Cクロックなど、特定のタイミング・パラメータを設定する必要があります。 そのような設定は、マイクロコントローラが正しい速度で動作していることが保証されない限り、行えません。

STM32マイクロコントローラではシステム・クロックを設定します。 このクロックは分周されて、FCLKコア・クロックや、APB1などの各種ペリフェラル・クロックを生成します。

目標#

このセクションの目標は、クロックが適切に設定されるようにプロジェクトを変更することです。 さらに、内蔵RAMおよびFlashが期待通りの速度で動作していることも確認します。

検証#

次の表に、このセクションの検証ポイントを示します。

検証ポイント検証内容
SystemCoreClock変数の値が正しいマイクロコントローラが、目的の周波数で動作するように設定されていること。
内蔵RAMを読み出せるマイクロコントローラが期待される容量の内蔵RAMを備え、これが読出し可能で、その速度を測定できること。
内蔵Flashを読み出せるマイクロコントローラが期待される容量の内蔵Flashを備え、これが読出し可能で、その速度を測定できること。
キャッシュが無効化されているキャッシュを無効にして実行すると、システムの複雑さが抑えられ、動作がわかりやすくなること。

Prerequisites#

以下に、このステップの前提条件を示します。:

  • ハードウェアのクロック・ソースに関する情報。 クリスタルを使用するのが一般的ですが、その他の方法も可能です。

作業内容#

ここからは、必要なマイクロコントローラ周波数を得るために、プロジェクトのクロック設定を調整するステップを進めていきます。 その後、内蔵Flashの読出し速度の測定方法を説明します。

システム・クロック#

In STM32CubeMX click on the "Clock Configuration" tab. 使用する特定マイクロコントローラのクロック・ツリーの概要が表示されます。

クロック設定

この例では、クロック・ソースとしてHSIが選択されています。 多くのプロジェクトで外部クリスタルを使用しますが、その場合はHSEを適切な分周回路(/M) や逓倍回路(/N) とともに使用する必要があります。 クロック設定に関するアドバイスは、本ガイドの対象外です。 After you have changed the clock configuration you must regenerate the project in STM32CubeMX (click Generate Code in upper right corner).

コア・クロック(HCLK) は、生成されるコードにより、実行時に計算され、変数に保存されます。 この変数をアプリケーション・コードで使用すれば、クロック・サイクル数と秒数や起動タイマなどの間の正確な変換が可能になります。 変数を再計算するには、SystemCoreClockUpdate()関数を呼び出す必要があります。 Call文は、main.c(ユーザ・コード・セクション)に挿入します。

SystemCoreClockUpdate

その関数の最後にブレークポイントを設定しておけば、コア・クロックを確認(設定に応じて) できます。

SystemCoreClock

もう一つの重要なテスト・ポイントはシステム・タイマです。 このタイマは、HCLKで動作し、1msごとに割込みを発生するように分周されています。 This timer is used by the STM32Cube Firmware to implement millisecond delays.

タイマの動作は、mainにたとえば5秒の遅延を挿入することでテストできます。 遅延時間はストップ・ウォッチなどで検証します。

遅延の測定

FlashとRAMのサイズおよび速度#

システム・タイマを使用すれば、メモリの読出し速度の確認は簡単です。 システム・タイマの割込みにより、1ミリ秒ごとに変数がインクリメントされます。 コードの前後でこの変数を読み出すことで、コードの実行時間を(1ms単位で) 測定できます。 この方法を使用して、アプリケーションの各所で時間を測定できます。 精度は、それほど高くありませんが、オシロスコープなどの外部デバイスなしで測定することが可能です。

このためには、まず結果を保存するための2つのvolatile変数が必要です。 ここで結果を保存しないと、最適化コンパイラで測定用のコードが削除される場合があります。

測定結果を保持するグローバルなvolatile変数

以下に、Flashの0x08000000から0x08020000まで(128Kb) を読み出し、そのコードの時間を測定する例を示します。

読出しループの時間測定

このようなコードは、各種メモリの速度の検証に使用できます。 Once you have created a setup in STM32CubeMX you can measure the read speed and make a note of the result. この測定は、後で繰り返し検証できます。 メモリバンド幅(kb/s単位での読出し速度) を測定する場合は、データ量と測定された時間を比較します。

16MHzのSTM32F429では、コードは12msで実行されます。したがって、(この方法による) 内蔵Flashの読出し速度は、128kb / 0.012s = 10,666kb/sになります。

上記のループを変更することで、内蔵Flashの全領域が有効化され読出し可能であることを簡単に検証できます。 変更するのは、開始アドレスと終了アドレスだけです。

このコードで内蔵RAMも確認できます。 F429の場合、RAMはアドレス0x20000000から始まります。 コア直結メモリは0x10000000です。 使用する特定のマイクロコントローラのデータシートで、これらに該当するメモリ・アドレスを確認してください。

さまざまなメモリについて、何度か測定を行い、結果を記録してください。 RAMについては読出しと書込みの両方の速度をテストします。

リンカ・スクリプト#

もう一つの注目すべきものとしてリンカ・スクリプトがあります。 この設定ファイルは、システム上のRAMとFlashのアドレスをリンカに伝えます。 リンカ・スクリプトは、プロジェクトとともにCubeMXによって生成されますが、内容を確認しておくことを推奨します。 多くの場合、今後、プロジェクトのニーズに合わせて変更する必要が生じます

F7およびH7のキャッシュ#

Arm Cortex-M7ベースのSTM32F7とSTM32H7マイクロコントローラには、データおよび命令のキャッシュが含まれています。 安定したプラットフォームが得られるまで、少なくともデータ・キャッシュは無効化しておくことを推奨します。 データ・キャッシュは多くの場合、性能を大幅に向上させますが、テストを複雑にする要因にもなります。

プラットフォームが安定したら、データ・キャッシュを有効化して構いません。 その段階になれば、問題の原因がデータ・キャッシュ管理であることを容易に特定できます。そうでなければ、プラットフォームは正常に機能するからです。

データ・キャッシュの複雑さは、マイクロコントローラ・コアがキャッシュに対して読み書きを行うのに対し、DMA2やLTDCなどのペリフェラルは(キャッシュではなく) メモリから直接読み出すことに起因します。 そのため、たとえばフレームバッファにデータを書き込んでも、そのデータの一部はディスプレイに表示されないような状況が発生します。 これは、その時点で新しいデータがまだキャッシュにしか書き込まれていないため、LTDCがRAMからそのデータを見つけられなかったためです。 解決策は、プロジェクトの特定の時点でキャッシュをフラッシュすることですが、そのような処理はもっと後で行うことを推奨します。

Caching can be disabled/enabled in STM32CubeMX in the System Core section.

TouchGFX内部のDCacheステート・マシン#

TouchGFXエンジンは、現在および直近のレンダリング動作を記録します。HARDWARESOFTWAREの2つの状態があります。 描画動作の大部分がハードウェアによって実行されるため、初期状態はHARDWARE に設定されます。 状態遷移が発生すると、ステート・マシンが適切な仮想関数を呼び出し、キャッシュの無効化を処理します。 状態がHARDWAREからSOFTWAREに遷移する場合は、仮想メソッド void touchgfx::HAL::InvalidateCache()を呼び出し、SOFTWAREからHARDWAREへの遷移の場合は仮想メソッドvoid touchgfx::HAL::FlushCache()を呼び出します。 これら2つの関数の機能の派生HALクラスへの実装はユーザに委ねられています。

TouchGFXエンジンの内蔵DCacheのステート・マシン

TouchGFX Generatorを使用する場合は、これらの派生メソッドがDCache無効化の関数呼び出しとともにTouchGFXGeneratedHALクラス内に実装されるため、特段の作業は不要です。

参考資料#

The documents linked here contains more information about STM32CubeMX and the STM32 caches: