← ニュース&インサイトに戻る
知識7分で読める

STM32 LTDCフレームバッファ帯域幅:トラフィックとFIFOアンダーラン

FIFOアンダーランを調査する際は、STM32 LTDCのフレームバッファ容量、平均スキャンアウトトラフィック、アクティブピクセル需要、およびサービスギャップを分離して検討すること。.

STM32 LTDC Framebuffer Bandwidth: Traffic and FIFO Underrun

フレームバッファはRAMに収まっても、STM32 LTDCディスプレイがピクセルデータ不足に陥ることがある。容量は何バイト保存できるかに答える。帯域幅は繰り返し発生するトラフィックを表す。FIFOアンダーランは、コントローラが現在の予備が空になる前にデータを受け取れるかに関わる。設計はこれら三つすべてに対処しなければならない。.

本分析は、リニアで非圧縮のフレームバッファからの連続スキャンアウトを対象とする。その数値は教育用の仮定であり、パネルのタイミングやSTM32の性能保証ではない。目的は、メモリインターフェースが十分であると判断する前に、トラフィックの勘定とサービスレイテンシの調査を構築することである。.

容量から始め、次に時間を計算に組み込む

800 x 480のアクティブ画像がRGB565でピクセルあたり2バイトで保存されていると仮定する。厳密に割り当てられたフレームには800 x 480 x 2 = 768,000バイトが必要である。そのようなフレームバッファ2つには1,536,000バイトが必要である。実際の割り当てはそのレイアウトとメモリ要件も満たさなければならない。.

Close view of unmarked memory packages on a controller board
概念図:割り当てられたメモリ容量と繰り返し発生するディスプレイトラフィックは異なる問いに答える。.

これらの数値はストレージを確立するものであり、転送レートではない。同じ保存済みフレームは変更なしに繰り返し読み出せる。逆に、置換フレームをレンダリングすると、ディスプレイエンジンがそれを読み出す前であってもトラフィックが追加される。.

TouchGFX 4.27は、ダブルバッファリングのストレージコストとライフサイクルを説明している。一方のバッファが連続的なディスプレイ読み出しを供給し、もう一方がレンダリングされ、制御されたスワップが行われる。.[2] 2つのバッファが割り当てられていても、LTDCがリフレッシュごとに2つの完全な画像を読み出すわけではない。.

バッファは画像を保存し、レイヤーは設定された合成入力である。複数のアクティブレイヤーは個別の読み出しを必要とする場合がある。1つのレイヤーのダブルバッファリングは、連続するフレームの場所を変えるものであり、同時に読み出されるレイヤー数を変えるものではない。.

フレーム平均トラフィックとアクティブ消費を区別する

教育用画像を800 x 480のままとし、60 Hzのリフレッシュを仮定する。1秒全体にわたって読み出される有用なアクティブピクセルペイロードは:

800 x 480 x 60 x 2 = 46,080,000バイト/秒

これは10進メガバイトで46.08 MB/sである。フレーム間隔の平均であり、その間隔内でメモリがサービスを任意に遅延してよいという保証ではない。.

次に、ブランキングを含む総タイミング寸法を1056 x 525と仮定する。対応するピクセルクロックは1056 x 525 x 60 = 33.264 MHzである。そのクロックに2バイトを掛けると、ピクセルクロックベースのアクティブ消費スクリーニングレートとして66.528 MB/sが得られる。.

ST AN4861 リビジョン7は、ピクセルクロックを総タイミング寸法とリフレッシュに関連付け、ピクセルクロックとレイヤーあたりのピクセルあたりストレージバイト数に基づく帯域幅スクリーニングを提示している。また、競合するバスマスタについて論じ、FIFOスタベーションと転送エラーを区別している。.[1]

教育用数量 RGB565、2バイト/ピクセル ARGB8888、4バイト/ピクセル
フレーム間隔で平均したアクティブペイロード 46.08 MB/s 92.16 MB/s
ピクセルクロックベースのスクリーニングレート 66.528 MB/s 133.056 MB/s

このスクリーニングレートはアクティブピクセルのケイデンスを表すものであり、ポーチ用の追加RAMピクセルやブランキング期間中の一定RAMレートではない。バッファ付きフェッチはブランキング中に発生する場合がある。このレートをフレーム平均に加算してはならない。.

実際のメモリフェッチはバースト的でバッファ付きであり得る。これらの計算は、正確なリフィルパターン、トランザクションオーバーヘッド、保証されたメモリサービスを記述するものではない。これらは有用なペイロードの量を、それを供給するレートとタイミング制約から区別するのに役立つ。.

プロデューサトラフィックは、評価対象のメモリにおいて一度だけ加算する

ディスプレイリーダーは参加者の一つに過ぎない。CPUレンダリング、画像デコード、DMA2D操作、バッファコピーは追加の読み出しと書き込みを生み出す可能性がある。明示された境界でそれらを数える。例えば、コピー元とコピー先の両方を保持する外部メモリなどである。.

完全なRGB565フレームが毎秒30回コピーされると仮定する。両側がそのカウント対象メモリを使用し、各ペイロードが境界を一度だけ通過すると仮定する。各コピーは768,000バイトを読み出し、さらに768,000バイトを書き込む:

(768,000読み出し + 768,000書き込み) x 30 = 46,080,000バイト/秒

そのコピーを1レイヤーのフレーム平均スキャンアウトに加算すると、46.08 + 46.08 = 92.16 MB/sとなる。これは理想的なペイロード小計である。他の作業やトランザクションコストは除外されている。キャッシングや中間ステージングは選択された境界でのトラフィックを変え得る。各読み出しと書き込みを一度だけ数え、同じコピーをフラッシュトラフィックなどの第二のラベルの下で再び加算してはならない。.

教育用勘定におけるワークロード 明示されたメモリにおける平均トラフィック
60 Hzでの1つのRGB565スキャンアウト 46.08 MB/s読み出し
毎秒30更新でのフルフレームコピー 23.04 MB/s読み出し + 23.04 MB/s書き込み
小計 92.16 MB/s

配置が勘定を変える。コピー元が別の場所にある場合、その読み出しはコピー先の書き込みと同じメモリ境界を通過しない場合がある。逆に、コピー先ピクセルを読み出してから書き込むレンダリングは、単純な書き込み専用モデルを超えるトラフィックを追加する。すべてのGUI更新に一つの汎用コストを割り当てるのではなく、操作を定義せよ。.

GUIレンダリングモードはプロデューサ側を変える

LVGL 9.5はPARTIAL、DIRECT、FULLレンダリングを区別している。PARTIALは変更された領域に対してより小さな描画バッファを使用する。DIRECTはフルスクリーンサイズのバッファを使用し、2つのバッファがある場合はフラッシュ後にレンダリングされた領域を他方のバッファにコピーする。FULLは画面全体を再描画する。.[3]

これらの区別はワークロード勘定に属する。モード名だけでは結果として生じる外部メモリトラフィックを確立できない。レンダリングがどこで発生するか、フラッシュ操作が何をコピーするか、どの割り当てがレビュー対象のメモリを共有するかを追跡せよ。.

部分レンダリングは連続的なLTDCスキャンアウトを停止させない。小さなボタンの更新はプロデューサの作業を減らすかもしれないが、コントローラは表示中のフレームを読み出し続ける。アーキテクチャが代わりにディスプレイローカル画像メモリや別のリフレッシュモデルを使用する場合、ここで使用したものとは異なる勘定が必要である。.

同様に、ダブルバッファリングはプロデューサとリーダーの所有権を分離できるが、リフレッシュで消費されるバイト数を減らすものではない。フレームワークによっては同期コピーを導入する場合もある。追加バッファが帯域幅の最適化であると仮定するのではなく、実際の操作を比較せよ。.

平均帯域幅はすべてのサービスギャップに対して保護できない

FIFOは有限の予備を保持する。メモリが長い間隔で十分なバイトを供給しても、サービスがない期間がアクティブ消費中にその予備を枯渇させ得る。これが平均帯域幅の結果ではアンダーランに対する免疫を確立できない理由である。.

Abstract teal blocks held in a small open tray with a gap before additional blocks
有限の予備と供給の中断の視覚的メタファー。FIFOサイズとタイミングはテキストでのみ規定される。.

意図的に理想化されたモデルを考える:256バイトのFIFOが満杯で開始し、一定の96 MB/sで排出され、4マイクロ秒間リフィルがない。これらは独立した例のための架空のパラメータであり、STM32のFIFO仕様や先のRGB565ワークロードから導出された値ではない。.

ギャップ中に要求されるバイト数 = 96,000,000 x 0.000004 = 384

ギャップは想定される満杯の予備が保持する以上のデータを要求する。その後のより高速なサービスは、デッドラインがすでに過ぎたピクセルを供給できない。したがって、十分な長期スループットはサービスにおけるすべての中断を補償できない。この例はレイテンシ制約を示すものであり、実際のLTDCに対するスケジューリング制限を規定するものではない。.

実際の評価には、対象FIFOの構成、ギャップ開始時の占有量、フェッチ動作、メモリサービス時間が必要である。部分的に満杯の状態で開始するFIFOは、このモデルよりも余裕が少ない。消費中のリフィルは軌道を再び変化させる。算術が有用であり続けるのは、その前提が可視化されている場合のみである。.

代表的なワークロードで競合を調査する

ピークインターフェースレートは、LTDCへの持続的な有効配信とは異なる。対象のメモリタイミング、トランザクションパターン、リフレッシュ動作、アービトレーション、競合アクセスが、受けるサービスを決定する。想定効率のパーセンテージを挿入し、その結果を検証済みの限界として扱ってはならない。.

Embedded display integration setup on a clean laboratory workbench
統合ワークベンチの概念図。代表的な並行ワークロードは、実際のハードウェアでの測定が依然として必要である。.

静的スキャンアウトと、追加のレンダリング、コピー、その他のメモリユーザーを分離したワークロード記録を構築する。次に、作業のバーストを生み出す遷移を含む、現実的な組み合わせを実行する。静かな静的画面は、画像をデコードし更新領域をコピーするシステムを代表できない。.

記録すべき証拠 対処する問い
アクティブレイヤー、フォーマット、タイミングの合計 ディスプレイ消費はどのように構成されているか?
メモリ位置を含むコピーおよびレンダリングスケジュール どのプロデューサートランザクションが同じ境界で競合するか?
対象が文書化したアンダーランおよび転送エラー記録 観測された障害はスターべーションを示すのか、それとも別の故障か?
並行ワークロードと観測期間 結果はどのような条件下で得られたか?

すべてのデバイスが同じカウンタを公開するとは仮定せず、対象が文書化したステータスまたはドライバ記録を収集する。モニタリングが有効であり、対象イベントを記録していることを確認する。文書化された処理セマンティクスに従う。アンダーランが記録されなかった期間は、それらの条件に対する有用な証拠であるが、完全なパネル互換性を証明するものではなく、将来のすべてのワークロードをカバーするものでもない。.

可能な変更には、不要なコピーの削減、アクティブレイヤーの再検討、メモリ配置とスケジューリングの改訂が含まれる。それぞれがアカウントの特定部分を変更するため、対象上で確認する必要がある。リフレッシュの変更はパネルがサポートするタイミング内に留めなければならない。普遍的に安全な削減は存在しない。.

帯域幅を他の統合障害から分離する

不正確なピクセルレイアウトと古いCPU書き込みデータには、それぞれ独自の証拠が必要である。帯域幅の計算では、正しいキャッシュパブリケーションやバッファ所有権を証明できない。逆に、メモリ可視性の修正は、ビジーなメモリシステムがスキャンアウトのデッドラインを満たすことを保証できない。.

以下を使用すること LCDピクセルクロックとタイミングガイド タイミングコンテキストおよび LCDディスプレイモジュールインターフェース インターフェースコンテキストのガイド。トラフィックアカウントを実際の連続スキャンアウトパスに結び付けて維持する。.

プロジェクト固有のレビューのために、, RJY Displayにお問い合わせください。 パネルデータシートとタイミング、MCU、メモリトポロジとクロック、バス幅、レイヤーとフォーマット、レンダリング/コピースケジュール、障害記録、代表的な並行ワークロードとともに。これらの詳細はスコープ付きの統合議論を支えるものであり、計算例は互換ボードや保証された修正を確立するものではない。.

参考文献

  1. ST AN4861、リビジョン7:LTDCを使用したグラフィカルアプリケーションの作成; 同じアプリケーションノート内のレイヤーの議論. 2026年2月。.
  2. TouchGFX 4.27:フレームバッファ, 2026年10月22日閲覧。.
  3. LVGL 9.5:ディスプレイセットアップと描画バッファ.

この記事を共有する。.

チームまたはネットワークに転送する。.

LinkedIn フェイスブック X WhatsApp

RJY Displayにより公開。.

すべての記事に戻る

さらに探索する

RJYからのその他の記事。.