ESP32-P4 做 LVGL HMI：先算清帧缓冲，再决定刷新与防撕裂

一块 800 × 480 的 RGB565 屏，完整一帧就要 768,000 字节。换成双帧，仅面板帧缓冲便接近 1.5 MiB；这还没有算 LVGL 的绘图缓冲、字体、图标、旋转中间图和其他任务。ESP32-P4 能把 Demo 点亮，不等于这些内存在产品配置里都有位置。先把每一块 buffer 的所有者、大小和读写时机列清楚，再谈“开双缓冲”或“交给 PPA 加速”，返工会少得多。Espressif 的 LVGL Adapter 文档明确把接口类型、帧缓冲数量、撕裂规避模式和绘图缓冲高度作为独立决策。

这里讨论的是 ESP-IDF 的公开接口及其工程推算，不是某块目标板的性能报告。究竟能否持续达到目标帧率、在网络或相机并发时是否撕裂，仍要用指定面板、PSRAM、固件版本和实际界面测量。

先在内存图上标出谁在读、谁在写

图：生成的硬件场景示意，不代表特定 ESP32-P4 板卡或测试结果。

产品设计里常把三种东西统称“显存”，于是一个配置改动可能意外多占一整帧。第一种是面板帧缓冲：LCD 驱动或扫描链路持续读取它，MIPI-DSI Video 模式的像素从主机侧帧缓冲输出；RGB 驱动也按配置从内部内存或 PSRAM 读取。第二种是 LVGL 绘图缓冲：LVGL 把需要更新的区域画在这里，容量取决于绘图模式与区域高度，并非必然等于整屏。第三种是旋转、缩放、混合或格式转换用的中间缓冲；引入 PPA 时尤其要确认输入输出是否可共用。三者可能在某个适配模式中共享地址，也可能各占一块，不能按名称相似就合并预算。MIPI-DSI LCD 驱动、RGB LCD 驱动、PPA 驱动

画出一次刷新，才能决定缓冲归属

以局部更新为例，LVGL 先把失效区域渲染到绘图缓冲，适配层再把这块像素送进当前可写的面板帧缓冲；显示外设则持续扫描另一块或同一块面板缓冲。若扫描与写入撞在同一帧、没有同步或区域所有权不清，用户看到的可能是上下部分来自不同更新周期。增加缓冲数量可以给读写分离创造条件，却不会自动完成区域复制、帧切换和触控坐标的同步。Espressif 的 RGB 双缓冲说明特别指出了避免读写同一帧与维护两帧同步这两个不同问题。RGB 双帧模式

若使用 esp_lvgl_adapter，先选 RGB 还是 MIPI-DSI，再选择适配器明确支持的 tearing mode，并用 esp_lv_adapter_get_required_frame_buffer_count() 得到所需帧数，传给面板配置。文档的 DOUBLE_DIRECT、DOUBLE_FULL、TRIPLE_PARTIAL、TRIPLE_FULL 各有更新面积、旋转与内存侧重；不要把三个帧缓冲当作“画面一定更流畅”的开关。适配器还限制了 RGB/DSI 的 NONE 模式下非零旋转。

若项目不用此适配器，而是自行组合 LVGL、esp_lcd 与 PPA，就应显式设计同等的回调、所有权和同步，不能把适配器的保证自动移植过去。ESP LVGL Adapter 模式说明

把分辨率变成可核对的内存预算

完整面板帧缓冲的原始像素量可以先用 水平像素 × 垂直像素 × 每像素字节数 计算。RGB565 按 2 字节，RGB888 按 3 字节；单位换算用 1 MiB = 1,048,576 字节。下表只是原始像素的算术结果，不包含行步长对齐、缓存、堆碎片、颜色转换、字体、解码工作区或驱动额外分配。

这张表首先是一个否决工具。例如，1024 × 600 RGB888 双帧的原始总量是 3,686,400 字节，约 3.52 MiB；扣除相机、网络和图像资源后，若 PSRAM 总可分配容量仍低于这个数值，就不能靠改一个配置开关解决，应重审颜色格式、分辨率、帧数或并发需求。两帧若分别分配，每次还需能取得至少 1,843,200 字节的连续块，并留出实际对齐开销；不能把 3.52 MiB 错当作每次分配的连续块下限。即便容量表显示“放得下”，也不能推出带宽够用：扫描、CPU 绘图、PPA 读写与其他任务可能争用 PSRAM。Espressif 的 RGB 驱动文档说明，PSRAM 帧缓冲减轻内部内存压力，但 EDMA 与 CPU 访问会共享外部内存带宽；MIPI-DSI 文档同样要求按面板时序与像素格式配置，而非只看容量。RGB LCD 缓冲模式、MIPI-DSI LCD 配置

绘图缓冲另算。假定局部绘图缓冲覆盖 800 像素宽、50 行、RGB565，一块的原始像素量是 80,000 字节，约 78 KiB；若配置两块则再乘二。这里的 50 行只是 Espressif Adapter 文档给 RGB/DSI 的默认 buffer_height 示例，不是推荐给所有产品的固定值。

把三类缓冲放进同一张所有权表

以下是用于填写预算的假设配置，不对应已验证的 Adapter 模式或目标板实测：800 × 480 RGB565、两块独立面板帧、一块 50 行局部绘图缓冲、无旋转且不调用 PPA。两块面板帧按 2 × 800 × 480 × 2 = 1,536,000 字节计算，绘图缓冲 800 × 50 × 2 = 80,000 字节，原始像素合计 1,616,000 字节，约 1.54 MiB。这是逐块相加的示例，不包含驱动实际分配、对齐、资源和并发峰值；具体适配模式可能让绘图缓冲与面板帧共用地址，也可能另分配，不能照此数值直接订 PSRAM。

如果设计后来增加一块同格式整帧大小的独立 SRM 输出工作区，只作为保守预算情景，原始合计变为 1,616,000 + 768,000 = 2,384,000 字节，约 2.27 MiB；不能据此断言实际适配层一定额外分配一整帧。把实际分配地址、最大连续块、对齐开销和共享关系填进这张表后，再决定哪些对象应该相加。即使两块缓冲物理共址，也要写清不同阶段由谁占用，不能只在总数上做减法。

增大高度通常减少 flush 次数，却会占用更多 RAM；缩小高度节省空间，却可能增加刷新调用与复制成本。实际还要看 LVGL 所用颜色格式、适配层分配位置以及绘图缓冲与面板帧缓冲是否复用。先以运行时的分配结果核对这笔预算，不能把表格数字直接写成 heap_caps_get_free_size() 的预期值。Adapter buffer_height 说明

PSRAM 不是“放进去就不用管”的存储层

面板以 DMA 读像素、CPU 或 PPA 写像素时，地址可达性、对齐和缓存一致性都会进入正确性问题。ESP32-P4 的内存同步文档明确解释：CPU 可能先改了 cache 中的数据，DMA 却从外部内存读到旧像素；反方向也可能读到陈旧缓存。若应用绕过适配层自行管理缓冲，应核对分配能力、每种 DMA 路径的对齐要求，以及写入后由谁做同步。可用的官方接口包括 esp_cache_msync()，但具体调用位置和方向取决于实际读写路径，不能无差别在每次 flush 前后“各刷一次”来掩盖所有权错误。ESP32-P4 Memory Synchronization

还要核对“最大连续可分配块”，而不只是 PSRAM 总容量。图标解码、字体缓存、网络栈和其他组件可能先占用并碎片化内存。能够启动一帧，不证明切换界面、弹出键盘或播放动画时仍能分配。评审时把启动峰值、运行稳定值、界面切换峰值分别留出记录栏；如果目标设备还带摄像头，应将其帧缓冲另列，不要复用屏幕预算。ESP32-P4 摄像头到屏幕的数据链路讨论的是图像链路，这里的重点是 HMI 绘图与面板帧所有权。

RGB 与 MIPI-DSI，刷新链路不要混写

RGB LCD 可以使用内部内存单帧、PSRAM 单帧、PSRAM 双帧或 bounce buffer 等模式。单帧最省容量，但更新过程中扫描仍在持续；双帧把当前显示帧和写入帧分开，代价是多占一帧并维护两帧内容一致。bounce buffer 不是“免费的双帧”：Espressif 描述的是 PSRAM 主帧加两块内部小缓冲，DMA 与 CPU 在行级搬运上交替，能应对某些短时带宽峰值，却增加 CPU 工作，并对外部内存缓存状态敏感。不能因为某个 RGB 示例在目标板可用，就把相同配置照搬到 DSI 面板。RGB LCD 操作模式

MIPI-DSI Video 模式则由主机侧帧缓冲持续输出像素。面板初始化的 DBI 命令路径、DPI 视频路径、lane 数与速率、像素格式、时序以及 DPHY 供电都需要与具体面板资料匹配；esp_lcd_dpi_panel_get_frame_buffer() 可取得驱动分配的帧缓冲地址。若计划让 LVGL 或 PPA 直接操作这些地址，先写清何时可写、何时换帧，以及适配器是否已经管理了这些动作。DSI 驱动文档还给出了 DMA2D draw bitmap hook 与自定义 PPA hook 的入口，但“存在 hook”不等于旋转或贴图已经自动走上加速路径。MIPI-DSI LCD 驱动

把错误按层定位会比一上来调整时钟快：完全无画面先核对面板供电、初始化命令、时序与连接；画面能出来却错行、偏移，核对 stride、区域坐标、颜色格式、字节顺序和 DMA 对齐；动画期间才发生闪烁或撕裂，追查刷新区域、写入帧、扫描帧及 VSYNC/传输完成回调。对 DSI 的像素时钟或 lane 速率作出调整之前，应先有面板手册和实际日志，不能把“蓝屏”一概解释为 LVGL 绘图太慢。Espressif 的 LCD FAQ列有 PSRAM underrun、lane 速率与时序不匹配等不同症状。

PPA 应用在明确的像素工作上

ESP32-P4 的 PPA 支持缩放、旋转、镜像、混合和填充等操作。它可以把特定像素变换从软件路径移走，却不能代替 LVGL 决定哪些对象要重绘，也不能替面板链路增加带宽或自动补齐缓存同步。PPA 的 SRM 操作要求输入图片缓冲和输出图片缓冲指向不同位置；如果在预算表里只留“旋转前一帧”而没有输出空间，方案在调用前就已经不成立。混合操作的缓冲复用条件与 SRM 不同，必须按对应 API 的限制检查，不能以“PPA 都一样”概括。PPA 驱动功能与约束

90° 或 270° 旋转还会改变宽高、触控映射、失效区域和中间缓冲的计算方式。Espressif Adapter 对某些旋转或三缓冲模式要求三块帧缓冲；这是一种已实现适配模式的容量要求，不表示所有自研驱动都只要三块，也不表示对每一种屏幕都有收益。启用旋转之前，应先用最终方向的分辨率和色深重算内存，再确认面板扫描方向能否由控制器本身完成；能在面板侧处理时，就不应无理由增加整帧像素搬运。Adapter 旋转与帧数规则

从 Demo 迁移到产品配置的顺序

固定板级输入与内存所有权

第一步固定输入条件：面板分辨率、物理方向、颜色格式、接口类型、刷新需求、触控控制器、PSRAM 型号与容量，以及是否会同时运行网络、摄像头、音视频或日志任务。没有这些数据时，任何“最佳 buffer 数量”都缺少约束。先把目标固件中的 ESP-IDF、LVGL、适配器版本锁定；不同版本的配置宏和模式行为可能变化，本文不把某一版宏写成跨版本承诺。

若无线联网由 ESP32-C6 伴随控制器承担，还要把 P4 与 C6 的数据交换及并发负载列入配置输入；ESP32-P4 + C6 双芯片架构讨论这一职责边界，不能用它代替本机的 PSRAM 峰值记录。

第二步画出缓冲所有权表：每块内存的分配者、字节数、内外存位置、CPU/PPA/DMA 的读写权限、交换时机、缓存同步责任以及异常时释放者。将 num_fbs、buffer_height 和颜色格式代入上面的容量公式，再加上字体、纹理、临时转换和并发业务的实测峰值。若分配失败，不要立刻打开 PSRAM 的“更大”配置；先确认是谁占用了整帧、哪一块能够改用区域缓冲、是否因对齐多占了空间。

比较两种配置并保留回退

第三步在同一块目标板上比较至少两种合法配置，例如相同像素格式下的单帧局部刷新与双帧 DOUBLE_DIRECT，或者双帧与旋转所需的三帧。每次只改一个变量，并记录峰值可用内存、最大连续块、LVGL 渲染耗时、flush/传输耗时、实际显示帧率、CPU 负载、触控到画面变化的时间以及明显撕裂的场景。仅测空白桌面没有代表性；应用最重的图表、弹窗、动画、语言切换和网络并发都要进同一矩阵。公开文档给出了可选模式，不能替团队交出这些目标板数值。

第四步给失败留回退路径。若启用 PPA 后出现颜色错位，先回退到未经变换的显示路径，比较输入输出 buffer、颜色格式、步长与对齐；若双缓冲后帧率下降，先检查额外的整帧复制及 PSRAM 争用，不要默认第三帧就能修复；若 OTA 或写 flash 时 RGB bounce-buffer 模式显示异常，要回查该模式对外部缓存的依赖。产品版本应保留一个已经验证的低复杂度显示配置，避免“优化”失败时只能停机分析。RGB bounce buffer 的缓存限制

最后的放行判断不应是一句“画面很顺”。它应写成可复核条件：哪块板、哪块屏、哪个固件和适配器版本、哪组界面与并发负载、连续多久、采样方法是什么，哪些失败属于阻断。内存不越界、交互可接受、画面没有可复现撕裂，以及失效时能降级，缺一项都可能让 Demo 到量产之间出现新的问题。本文提供的是把测试做对的规划框架；在这些记录出现之前，不能为任何具体产品声明目标 FPS、延迟或长期稳定性。

这套预算不覆盖哪些屏幕

本文的预算方法针对 ESP32-P4 上 RGB 或 MIPI-DSI 的 LVGL HMI，不应直接套到 SPI、QSPI 或 I80 屏。Espressif Adapter 把这些接口归为 OTHER，所列 tearing mode 只支持 NONE，刷新传输方式与面板自身缓冲条件也不同。即使同为 RGB/DSI，最终方案仍受具体面板时序、PSRAM 型号、板级供电与任务负载限制。把“适配器列出该模式”误读成“项目已经验证该模式”，正是 Demo 迁移时最危险的捷径。ESP LVGL Adapter 接口支持表

参考资料

• Espressif ESP LVGL Adapter：接口、帧数、撕裂模式与绘图缓冲
• ESP-IDF：ESP32-P4 MIPI-DSI LCD
• ESP-IDF：ESP32-P4 RGB LCD
• ESP-IDF：ESP32-P4 PPA
• ESP-IDF：ESP32-P4 Memory Synchronization