残念ながら、このLCDにはmipi出力を直接接続できないのでLT8918が追加されていますが、問題は起きていないようです。テストパターンはそのデバイス上で正常に実行され、デバッグログにも同期と基本設定の合格が示されています。
しかし、出力に問題が生じます。現在私が持っているコードは、800x1280の画面の中央にある非常にシンプルな小さなメモリバッファ（128x256）のためのものです。実際の出力画面を見る必要はないが、非常に歪んでいるように見える。また、印刷された診断情報には、DMAが1行分の書き込みに必要なデータを十分な速さで取得できていないかのように、アンダーランエラーが多数表示されます。
私はLCDやNXPレジスタの専門家ではありません。どこかで何か愚かな間違いを犯しているのだろうか？不確実な要素は山ほどある。SRAM_OC1は実際にはかなり遅いのでしょうか？タイミングを正しく調整するために、AXIまたはDMAの設定があるのかもしれません。MPUコードでキャッシュしないように設定を変更しましたが、それも間違いかもしれません。残念ながら、デフォルト領域とncache領域の違いは分かりません。他にも考慮すべき点はたくさんあります。例えば、ストライド長を、より小さい128ピクセルのレイヤー0サイズではなく、800ピクセルの行全体に変更してみました。RGBピクセルクロックはMIPIバイトクロックよりも遅いが、MIPIはRGBの24本の並列接続ではなく2本のラインを使用しているため、いずれにしてもMIPIの方がはるかに高速であると予想される。
また、レイヤー0領域をこれほど小さくしている理由は、SDRAMにエラーが発生する可能性があるからです。この不確実性を避けるために、これをより小さなコントロールされた部分に縮小していますが、ここでも何が問題なのか正確には見つけられません。
ここまで来られたのは素晴らしいことだが、これ以上進歩するために何をすればいいのか分からないのは非常に歯がゆい。背景の単色表示はすべて問題なく動作し、テストパターンはきれいな形のバーの領域を作るので、本当の"LCD"の問題ではないと思います。むしろRAMバッファの読み取りやLCDIFv2がパラレル出力に割り当てているのがタイミングの問題のように見えます。
これをどうやってデバッグすればいいですか?ありがとう。
いくつか試してみたところ、少なくとも印刷された診断結果を見る限り、アンダーランエラーのない安定した出力が得られているようです。主な変更点は最初のものだと思いますが、その他の変更点は実際にはもう少し複雑です。しかし、分かりやすくするために列挙しておきます。この設定はまだRGB888のままで、アルファレイヤー描画の実験のために変更したくありません。というのも、まだそれほど良い状態ではないからです。
1. ピクセルクロックを大幅に遅くし、リフレッシュレートを15Hzに近い値にする。DMAには作業のための余分な時間があるのかもしれない？でも、おっしゃる通り、OCRAMは高速なはずです。MPUの設定で、その領域もNCACHE領域として設定しています。
2. 使用されている色は黒と白のみです。緑色の背景を試すと、緑色がRGBパターンにシフトされて毎行(1バイトずれ?)という問題が発生します。
3. RAMレイヤー0の幅を高さ256に合わせるために256に変更します。実際、128の高さでも問題ありませんが、この丸太は256で、ストライドも768に変わるのがわかります。
4. 玄関ポーチと裏庭のビデオ設定がかなり大きくなっています。これが主な原因ではないと思います。もっと速い速度でこれらの設定も試してみましたが、あまり効果はありませんでした。データシートによると、Hfp + Hbp + Hs の最大値は任意の値に設定できますが、ここで合計200を超える値を設定する理由はあるのでしょうか？縦位置設定は、合計で250に制限されています。
とにかく、面白い話です!技術的には、LCDのデータシートには最低22Hzで動作させる必要があると記載されていますが、白い部分にちらつきは見られません。もっと速く走らせたいです。
RT1172のDMAについては全く気にしていなかったのですが、動作速度を上げたり、優先度を上げたりするために何かできることはありますか？LCDIFv2には、これに関する他の設定はありますか？特にOCRAMは本来とても速いはずなのに、こんなに遅くしたのにこんな効果が出たのは驚きです。
右。本当にありがとうございました！もっと色々なことを試してみましょう。こちらが別のログです。
私はRGB888にこだわりたかったのです。ARGB8888の方がこの用途に適している理由は何かありますか？いつかアルファ版を試してみようかな。
CTRLDESCL5: 0xD8000260
リファレンスマニュアルで確認したところ、BPP設定はビット27〜24で、その「8」はRGB888にうまく入力したことを示しています。最後のバイトは無関係に見え、アルファ設定は無害にずれているように見える。
画面出力は異なって見えるが、修正されていない。もしかしたら改善されたのかも？包み込むようなデザインは健在だが、以前ほど攻撃的な印象ではない。
ピクセルクロックの速度を上げる実験もしてみましたが、効果があるのか悪いのかは分かりません。
もっと動画設定を変えてみることはできますか?25%のHsync設定はここではかなり強力だと思っていたのですが、考えてみれば、これまでこのような設定をしたことがなかったのです。どのような要素が、その場所を特に優れたものにするのでしょうか？Vsyncも関係ありますか？LT8918ブリッジもこれらの設定入力が必要ですが、それも管理できます。入力する数字は推測するしかないのでしょうか？
ドライバーはJD9365DA-H3です。参考になれば。タッチスクリーンが付いているという奇妙なパッケージもありますが、私は特に問題ありません。
こんにちは、 @davidpspeedtech さん。
最新情報ありがとうございます！しかし、問題は、設定の一部に一貫性がないことです。
- 0xD9000260 → ハードウェアにラッチされたフォーマットはARGB8888（32ビット/ピクセル）です。
- したがって、stride = 384(=128×3, RGB888)を設定しても、ハードウェアは1行あたり128×4 = 512バイト/行→ずれを取り出し、バッファを越えて読み込み、アンダーランします。
毎回ストライドまたはBPPマクロのみを変更しましたが、ハードウェアは実際には.pixelFormatに従い、ARGB8888のままでした。4つの値は決して一貫していませんでした。
それらをすべて32ビットARGB8888またはRGB888として一度に統一してください。
CTRLDESCL3 は現在 0x200 (512) を読み取っているはずです。32ビットフレームバッファと24ピンRGB888出力は独立しているため、24ピンリンクに3バイトバッファは必要ありません。
また、これら3回線はeLCDIFビット定義を使用しています。LCDIFv2にはRUNビットがなく、これが制御状態を乱すことがあります。
Gavin_Jia_0-1788249587860.pngGavin_Jia_0-1788249587860.pngGavin_Jia_0-1788249587860.png
標準APIのみを使用して操作してください。
その他の点について確認させてください。
- ストライドは画面幅ではなく、RAMバッファ幅に基づいて計算されます。これは正しいです。
- 背景色はレジスタ生成（メモリフェッチなし）であるため安定しており、出力パスが正常であることが証明され、障害がレイヤーフェッチパスにあることが特定されます。
- 原色と二次色の間でカラーバッファがちらつく現象（「まるでバイトが失われたかのよう」）は、まさにアンダーランによってバイトが失われていることが原因です。フォーマットが統一されれば、この現象は解消されるはずです。
- 帯域幅はボトルネックではない（OCRAM、128幅）。それでもアンダーランが解消されない場合は、ピクセルクロックを下げるか、HBP/HFPを上げて確認してください。
いや、それでは解決しない。実際、ストライドがRGB888の場合は128*3でも、ARGB8888の場合は800*4に設定して画面全体をRAMに収めようとしても、出力は画面の端で歪みが生じる点でかなり似ており、アンダーランエラーが発生します。ファイル内のテキストだけでなく、さまざまな設定を試してみました！
#define SMALL_LAYER_0_HEIGHT 256U
#define SMALL_LAYER_0_WIDTH 128U
#define SMALL_LAYER_0_BPP 3U /* RGB888 */
#define SMALL_LAYER_0_STRIDE (SMALL_LAYER_0_WIDTH*SMALL_LAYER_0_BPP) /*384*/
~デバッグ出力~ CTRLDESCL3: 0x 180 (ピッチ/ストライド = 384バイト)
これもまたうまくいかない。
でも、レイヤー0のストライド設定はRAMバッファ幅に基づいて本来ならLCD画面幅ではなく、右？
LT8918へのインターフェースは24ピンのパラレル接続なので、本来RGB888であるべきです。DMAか何かが処理速度に追いついていないのではないかと心配になることもありますが、これはバッファサイズが小さいためSRAM_OC1が不足している状態です。おそらくRGB565も、最上位ビットがRGBピンで正しく出力できるので、似たような出力を持つかもしれません。モノクローム作品にも挑戦してみようかな。
サンプルコードを見ると、RGB888のBPPを3ではなく4に設定している箇所があり、他にも間違いを犯している可能性があります。
「背景領域」を別のレイヤーに配置し、別のメモリにバッファリングする必要があるのでしょうか？背景設定が正しく機能し、設定した単色で出力色が安定している点が気に入っています。白色以外のRAMバッファを使った実験では、画面が原色（RGB）と二次色の間でちらつくことがあり、まるで個々のバイトが失われたかのような現象が見られる。
こんにちは、 @davidpspeedtech さん。
NXP MIMXRTシリーズにご関心をお寄せいただきありがとうございます！
ご提供いただいた添付ファイルを確認しましたが、一部の設定を調整する必要があるかもしれません。
CTRLDESCL3: 0x00000C80 (ピッチ/ストライド = 3200バイト)
- CTRLDESCL3 (PITCH) = 384 (0x180)、つまりSMALL_LAYER_0_STRIDE = 128 * 3。
- バッファのベースアドレスは64バイト境界にアラインされます。キャッシュ不可のままにするか（現在の設定は正しいです）、表示前にDキャッシュをクリアしてください。
よろしくお願いします、
ギャビン
こんにちは、 @davidpspeedtech さん。
記述子は自己整合的になりました: CTRLDESCL5=0xD8000260 (BPP=8=RGB888)、CTRLDESCL3=0x300=768=256×3。おっしゃる通りです。
しかし、根本的な不一致は依然として存在しており、低いクロック周波数によって覆い隠されているだけである。「行ごとに色が変わる、まるで1バイトが失われたかのようだ」という証拠は、メモリダンプがすべて0xFFFFFFFFであり、センターピクセルが1ピクセルを単一の32ビットワードとして読み取っていることです。つまり、ハードウェアが3バイトをフェッチしている間も、コンテンツは依然として32ビット/ピクセルです。白は各バイトに0xFFされるため隠れています。緑は1行あたりにドリフトします。
ピクセルクロックを下げるとアンダーランは解消されますが、それはOCRAMが遅いからではありません（OCRAMは高速であり、オンチップメモリがボトルネックではありません）。アンダーランは、AXIマスターとしてのLCDIFv2のフェッチスループットに依存します。リフレッシュを~13.5 Hz(18.85 MHz÷ 1000×1400)に下げ、取っ取り要求を3〜4×減らしたので止まりますが、これはパネルの最低限値より低いです。
アンダーランせずに速く走るには、以下の方法が役立つかもしれません。
- エンドツーエンドに切り替えARGB8888:
.pixelFormat=ARGB8888、BPP=4、stride=256×4=1024、バッファは4バイト/ピクセルで、ピクセル書き込みコードが32ビットワードを書き込むことを確認してください。理由は2つあります。(a)既存の32ビットコンテンツと一致するため、緑色の問題を修正できます。(b)RMノートに記載されているRGB888はバス上で長さ15のバーストを発行しますが（効率が悪く、アンダーランが発生しやすい）、ARGB8888は32ビットにアラインされ、長さ16のクリーンなバーストを使用します。緑色のダンプで確認してください。行ごとにずれがなく、きれいな繰り返しになっているはずです。 - LCDIFv2のb_clk（クロックのルート）を上げて、ピクセルクロックを22Hz以上に復元してください。これが速度を上げるための正しい方法であり、クロックを下げることではありません。LCDIFv2はeDMAを使用しないため、「DMA優先度の上昇」は適用されません。利用可能なレバーはb_clk、バースト長、未処理リクエスト数、そしてTHRES動的優先度閾値です。
- JD9365DA-H3パネルのデータシートに記載されているタイミング値を使用し（推測しないでください）、LT8918の入力タイミングをそれに合わせてください。~200の水平ブランキングでも問題ありません。ブランキングが大きいとアンダーランが緩和されますが、htotalが上がり(より高いピクセルクロックが必要)、トレードオフとなります。ルート修正は高いb_clkです。Vsync/垂直ポーチはパネルと一致させる必要がありますが、ラインごとのアンダーランにはほとんど影響しません。
よろしくお願いします、
ギャビン