TFT LCDフレームバッファのストライドとRGB565のバイトオーダー

TFT LCDは、パネルが安定した信号を受信している場合でも、行のずれや誤った色を表示することがあります。タイミングを変更したり配線を交換したりする前に、ピクセルを書き込むコンポーネントとそれを読み取るコンポーネント間のメモリ契約を確認してください。両者はピクセルパッキング、行ピッチ、バイト順、チャネル順について合意している必要があります。.

この分析は、単一プレーン、リニア、パックドRGBバッファを対象としています。以下の数式は、タイル状、圧縮、またはマルチプレーンのレイアウトを記述するものではありません。数値例は教育用のケースであり、ハードウェアの測定値やRJYパネルの要件ではありません。.

プロデューサーとコンシューマーを別々に記述する

プロデューサーは、レンダラー、画像デコーダー、またはDMAコピー操作である場合があります。コンシューマーは、メモリをスキャンするディスプレイコントローラー、または転送用にバイトを準備するフラッシュルーチンである場合があります。フォーマット名だけでは、これらのコンポーネントが合意していることを確立できません。.

各側が期待する内容を書き留めてください：ピクセルフォーマット、ピクセルあたりのバイト数、最初のピクセルのオフセット、行ピッチとその単位、画像 dimensions、バッファの所有権。それらの間に変換ステージがある場合、それは入力契約と出力契約を持ちます。パネルがレンダラーのメモリレイアウトを変更なしに認識すると仮定するのではなく、両方に従ってください。.

Linux DRM/KMS v6.12において^[1], 、フレームバッファ記述にはフォーマット、dimensions、ピッチ、オフセット、レイアウト修飾子が含まれます。修飾子はレイアウトの解釈にとって重要であり、フォーマットサポートはドライバーとディスプレイプレーンに依存します。実際のアロケーションとドライバー情報を使用してください。幅だけではピッチを決定できません。.

実用的な結論は、画像のそばにバッファメタデータを取得することです。フォーマットとピッチなしのスクリーンショットは、症状を示しながらも、それを引き起こした不一致を隠す可能性があります。.

コンポーネントの精度とストレージサイズを分離する

RGB565は、16ビットピクセル値内で赤に5ビット、緑に6ビット、青に5ビットを割り当てます。パックドRGB888はピクセルあたり3バイトを使用します。XRGB8888は4ストレージバイトを使用します。Xフィールドはアルファチャネルを確立しません。API定義に従ってください。したがって、可視色コンポーネントを数えるだけではストレージサイズを決定するのに十分ではありません。.

LVGL 9.5のカラーフォーマットドキュメントは^[3] これらのストレージサイズをリストし、RGB565の2バイトのスワップと赤/青チャネルの交換を区別しています。そのスワップヘルパーの例はバージョン固有のガイダンスであり、すべてのフラッシュバッファを変更する要件ではありません。プロジェクト内のバージョンのドキュメントを確認してください。.

あるステージがピクセルあたり3バイト進み、別のステージが4バイト進む場合、その不一致は行全体で増大します。赤/青の設定を変更してもそのアドレス計算を修復できません。色の解釈を調整する前にストレージサイズを確認してください。.

アクティブ幅×ピクセルサイズではなく、実際の行ピッチを使用する

アクティブ行バイトは画像に属するピクセルを記述します。ピッチ（ストライドとも呼ばれる）は、ある格納行の先頭から次の行の先頭までの距離を記述します。パディングによりピッチがアクティブ行サイズより大きくなる場合があります。.

正のdimensionsと既知の正のバイトピッチを持つ単一プレーン、リニア、パックドバッファの場合、ピクセルのアドレスは：

pixel_address = base + offset + y * pitch_bytes + x * bytes_per_pixel

ここで、baseはアロケーションを識別し、offsetは最初の画像ピクセルへの非負のバイトオフセットであり、xとyは画像内の座標です。非負で境界チェックされた座標と、オーバーフローしない整数演算を使用してください。アロケーションがコンシューマーがアクセスする可能性のあるすべてのアドレスをカバーしていることを確認してください。このレイアウトでは、ピッチは少なくとも行あたりのwidth × bytes_per_pixelのアクティブバイトをカバーする必要があります。アクセスされるスパンを実際のアロケーション長で確認してください：

offset + (height - 1) * pitch_bytes + width * bytes_per_pixel <= allocation_bytes

この境界は最後の行までのアクティブピクセルをカバーします。パディングをフェッチするコンシューマーや他のアクセス要件を持つコンシューマーは、より多くのストレージを必要とする場合があります。すべての加算と乗算のオーバーフローを確認してください。これらの数式は他のレイアウトを記述するものではありません。.

意図的にパディングされたRGB565の例

2バイトピクセルの641×480画像を想定します。この教育例のみにおいて、アロケーターがすべての行を32バイトの倍数に切り上げると仮定します。その仮定は以下の値を生成します：

各新しい行を1,282バイト後に開始するコンシューマーは、このパディングされたレイアウトに従いません。逆に、パディングを期待するコンシューマーは、タイトにパックされた画像内の有用なバイトをスキップします。正しい修復は、両方のステージが同じレイアウトを使用するようにするか、明示的な行対応コピーを実行することです。.

ここに示すフルピッチアロケーションは、最後の行を含むすべての行にピッチを確保します。これは教育用のアロケーション慣例であり、すべてのAPIが受け入れる最小アロケーションについての主張ではありません。ターゲットのアロケーションとアクセス要件が引き続き権威を持ちます。.

APIがバイト数とピクセル数のどちらをカウントするかを確認する

ST AN4861、リビジョン7^[4] LTDCフレームバッファの入力フォーマットと、アクティブラインデータとピッチの区別について論じている。掲載されているHAL_LTDC_SetPitchの例ではピクセル数を使用している。対象のAPIとフォーマットを確認せずに、一般的なバイトピッチ値をそのパラメータにコピーしないこと。この注記のメモリアライメントに関するガイダンスは、記載されたSTM32のコンテキストに属するものである。.

strideという名前の変数は単位の宣言ではない。ライブラリ、レジスタ、ドライバ間で値が受け渡される境界において、単位を名前またはコメントに明記すること。.

バイトオーダーと赤/青の順序は異なる問題を解決する

Linux v6.12のDRMフォーマットヘッダーは、リトルエンディアン格納でRGB565とRGB888を定義している。.^[2] これらはAPI固有の定義である。別のAPIのRGB名が同じレイアウトを保証するものではない。.

論理的なRGB565の赤ピクセル0xF800は、リトルエンディアンメモリではバイト00 F8を占める。バイトシリアル出力パスでは、データシートとドライバがその順序を指定している場合にのみF8 00が必要となる可能性がある。バス名だけではそれを確定できない。.

追加の既知テスト値として、論理的な緑0x07E0と青0x001Fを使用すること。RGB888では、アドレス順に3バイトを指定すること。転送段階での再パッキングは別途文書化すること。.

画像全体を変更する前に、小さなメモリフィクスチャを使用する

以下は提案されたソフトウェア検証方法であり、テスト済みボードの報告ではない。8バイトピッチの3ピクセル幅、2行のRGB565フィクスチャを作成する。各行には6アクティブバイトと2パディングバイトが含まれる。パディングには識別可能なセンチネル値を設定する。.

各座標で異なる既知の色を選択する。各行の先頭と最後のアクティブピクセルのバイトを確認する。行を認識する変換では、各行の6アクティブバイトを処理し、パディングを変更しないままにする必要がある。これにより、割り当てをアクティブピクセルの連続配列として扱うコードが明らかになる。.

RGB565のバイトスワップ操作では、1回の変換後の期待出力を検証する。同じスワップを再度適用すると元のバイトオーダーに戻る。したがって、2回目の変換は結果を改善するのではなく、重複した処理パスを隠す可能性がある。.

また、変換中にバッファの所有権が誰にあるかを明確にする。別のコンシューマがまだ古い表現を読み取っている間は、インプレーススワップは不適切である。DMA完了前に戻るフラッシュコールバックには、定義されたバッファライフタイム契約が必要である。完了、再利用、および必要な同期は、プロジェクトの実際のドライバモデルに属する。.

外観だけでなく証拠から次のチェックを選択する

キャッシュの可視性、ティアリング、パネルタイミングは、調査の別々の層である。正しいメモリバイトは、コンシューマが最新の書き込みを認識していること、またはスキャン中にフレームが変化しないことを証明しない。同様に、タイミングの変更は既知のピッチ不一致を隠すべきではない。.

リンクタイミング層については、RJYの LCDピクセルクロックとタイミングガイド. を参照のこと。シリアライズされたLVDSビット配置については、別途 VESAおよびJEIDAマッピングガイド. Neither mapping nor pixel clock can be calculated from row padding alone.

Partial updates add another boundary to check. A rectangle copied from a larger framebuffer can retain the source pitch, while a temporary transfer buffer may pack only the rectangle pixels. Record the source row step and destination row step separately. The rectangle width sets the active bytes to copy; it does not automatically set either buffer pitch. Check the first and last pixel of successive rows before increasing the transfer area.

Document the contract before requesting integration support

A useful handoff identifies the exact panel and controller, host OS and GUI version, allocation layout, actual pitch with units, pixel format, and ownership rules. Include a known-pattern memory capture and the relevant datasheets. State where the first incorrect representation appears: renderer output, conversion output, transfer buffer, or displayed image.

RJY Displayに問い合わせる with that evidence for project-specific TFT module or controller-board review. Any adaptation depends on the actual panel, interface, timing, backlight, touch, firmware, and application requirements. The examples here establish a debugging method, not a universal conversion or hardware fix.

参考文献

1. Linux DRM/KMS documentation, v6.12. Framebuffer metadata and layout modifiers.
2. Linux DRM format definitions, v6.12. RGB565 and RGB888 storage conventions.
3. LVGL color-format documentation, 9.5. Storage sizes and RGB565 byte swapping.
4. ST AN4861、リビジョン7. LTDC framebuffer pitch and padding; shown HAL pitch example.