显示驱动移植：framebuffer原理、注册flush_callback、双缓冲机制、分辨率与色深配置
好，咱们进入第二章。显示驱动移植，说白了就是让LVGL能跟你的屏幕“对上话”。很多初学者一上来就急着画界面，结果屏幕黑着，或者花屏、撕裂，折腾半天找不到原因。我当年第一次移植LVGL时也踩过这个坑——屏幕亮了，但刷新慢得像PPT，后来才发现是flush_callback没写好。
这一章，咱们把显示驱动的几个核心点拆开揉碎。你搞懂了这些，后面移植任何屏幕都不会慌。
2.1 framebuffer是什么？
framebuffer，帧缓冲区。你可以把它想象成一块“画布”——内存里的一块连续区域，每个像素点对应一个或几个字节。CPU或GPU往这块画布上画图，显示控制器再定时把画布内容推给屏幕。
在Linux系统里，/dev/fb0就是framebuffer设备。你往这个文件里写像素数据，屏幕就会显示。但在裸机或RTOS环境下，我们通常自己分配一块内存当framebuffer。
核心概念： framebuffer的大小 = 分辨率宽度 × 高度 × 每个像素字节数。比如800×480的RGB565屏幕，就是800×480×2 = 768,000字节，约750KB。
我个人习惯把framebuffer叫做“显存”。LVGL不直接操作硬件，它把绘制结果放到这块显存里，然后由你写的flush函数把显存内容刷到屏幕。
2.2 注册flush_callback
flush_callback是LVGL和屏幕驱动之间的“桥梁”。LVGL每画完一个脏区域，就会调用你注册的这个回调函数，把绘制好的像素数据交给你，你再通过SPI、I2C、RGB接口或MIPI DSI把数据发给屏幕。
注册方式很简单：
static void my_flush_callback(lv_disp_drv_t * disp_drv,
const lv_area_t * area,
lv_color_t * color_p)
{
// 获取脏区域坐标
int32_t x1 = area->x1;
int32_t y1 = area->y1;
int32_t x2 = area->x2;
int32_t y2 = area->y2;
// 把color_p指向的像素数据刷到屏幕
// 这里调用你的底层驱动函数
screen_draw_region(x1, y1, x2, y2, color_p);
// 通知LVGL刷新完成
lv_disp_flush_ready(disp_drv);
}
// 在初始化时注册
lv_disp_drv_t disp_drv;
lv_disp_drv_init(&disp_drv);
disp_drv.flush_cb = my_flush_callback;
disp_drv.draw_buf = &draw_buf;
disp_drv.hor_res = 800;
disp_drv.ver_res = 480;
lv_disp_drv_register(&disp_drv);
注意： 一定要在flush完成后调用lv_disp_flush_ready()。我曾经见过有人忘了这行，结果LVGL以为还没刷完，一直卡着不画下一帧，整个界面像死机一样。
这里有个小技巧：如果你的屏幕驱动支持DMA或硬件自动刷新，可以在DMA传输完成中断里调用lv_disp_flush_ready()，这样CPU不用傻等，能继续干别的事。
2.3 双缓冲机制
单缓冲有个致命问题——屏幕在刷新时，LVGL同时在画下一帧，你会看到屏幕上半截是新画面，下半截还是旧画面，这就是“撕裂”。
双缓冲怎么解决？两个缓冲区：一个叫“前台缓冲”，正在被屏幕读取显示；另一个叫“后台缓冲”，LVGL正在往里画。画完后，交换指针，屏幕读新的前台，LVGL画新的后台。
LVGL支持三种缓冲模式：
| 模式 | 缓冲区大小 | 特点 | 适用场景 |
|---|---|---|---|
| 单缓冲 | 1/10屏幕或更小 | 内存占用小，可能有撕裂 | 低端MCU，内存紧张 |
| 部分双缓冲 | 1/2屏幕 | 减少撕裂，内存适中 | 大多数嵌入式设备 |
| 全双缓冲 | 完整两帧 | 无撕裂，流畅度最高 | 高性能平台，内存充足 |
配置双缓冲的代码：
// 分配两个缓冲区
static lv_color_t buf1[MY_DISP_HOR_RES * MY_DISP_VER_RES];
static lv_color_t buf2[MY_DISP_HOR_RES * MY_DISP_VER_RES];
lv_disp_draw_buf_t draw_buf;
lv_disp_draw_buf_init(&draw_buf, buf1, buf2, MY_DISP_HOR_RES * MY_DISP_VER_RES);
我的经验： 在STM32F429这类带LTDC控制器的芯片上，我习惯用全双缓冲。LTDC直接读取一个framebuffer显示，LVGL画另一个，画完通过VSYNC中断交换。这样帧率稳定在60fps，界面丝滑。
但如果你用的是ESP32+SPI屏幕，内存只有几百KB，全双缓冲不现实。那就用部分双缓冲，配合DMA传输，也能做到不错的体验。
2.4 分辨率与色深配置
这两个参数直接影响内存占用和显示效果。配置不对，要么画面颜色不对，要么内存爆了。
分辨率： 水平像素和垂直像素。LVGL里通过hor_res和ver_res设置。注意，分辨率必须和屏幕物理分辨率一致，否则画面会拉伸或偏移。
色深： LVGL支持多种颜色格式：
| 色深 | 宏定义 | 每像素字节 | 颜色数 | 典型场景 |
|---|---|---|---|---|
| 1-bit | LV_COLOR_DEPTH_1 | 1/8 | 2 | 单色OLED |
| 8-bit | LV_COLOR_DEPTH_8 | 1 | 256 | 低端彩屏 |
| 16-bit | LV_COLOR_DEPTH_16 | 2 | 65536 | 大多数嵌入式彩屏 |
| 32-bit | LV_COLOR_DEPTH_32 | 4 | 16.7M | 高性能平台 |
配置方法：在lv_conf.h里修改：
/* 颜色深度：1, 8, 16, 32 */
#define LV_COLOR_DEPTH 16
/* 是否启用LV_COLOR_16_SWAP，用于RGB565字节序交换 */
#define LV_COLOR_16_SWAP 0
避坑指南： 我曾经在ILI9341屏幕上用RGB565，但屏幕驱动要求字节序是BGR而不是RGB。结果红色显示成蓝色，找了半天才发现是LV_COLOR_16_SWAP没开。如果你的屏幕颜色不对，先检查字节序。
另外，色深越高，内存占用越大。一个800×480的屏幕：
- 16-bit：800×480×2 = 768KB
- 32-bit：800×480×4 = 1.5MB
如果你的MCU只有512KB RAM，强行用32-bit色深，系统直接崩。所以，选色深时要算好内存账。
2.5 整体流程框架
说了这么多，咱们用一张图把整个显示驱动移植的流程串起来：
嗯，这张图把整个流程和关键决策点都标出来了。你照着这个顺序走，基本不会出大问题。
2.6 实战建议
最后，给几个实战中的建议：
- 先点亮屏幕，再移植LVGL。 我见过太多人一上来就搞LVGL，结果屏幕驱动本身就有问题，排查起来很痛苦。先用裸机代码把屏幕点亮，能显示颜色块，再接入LVGL。
- flush_callback里不要做复杂计算。 这个函数会被频繁调用，里面只做数据搬运。颜色转换、图像处理这些事，放在LVGL的draw阶段做。
- 善用DMA。 如果你的芯片支持DMA，把flush_callback里的数据传输交给DMA，CPU可以继续处理LVGL的绘制任务。我曾在STM32上把帧率从15fps提升到45fps，就靠这一招。
- 调试时先降低分辨率。 比如你的屏幕是800×480，调试阶段可以先改成320×240，这样缓冲区小，刷新快，问题定位也快。调通了再改回真实分辨率。
一个小技巧： 在flush_callback里加个GPIO翻转，用示波器看波形，就能知道实际刷新率。我经常用这招验证优化效果，比软件计时靠谱多了。
显示驱动移植是LVGL性能优化的第一道关卡。这一步做好了，后面UI再复杂，帧率也能稳住。如果这一步有瑕疵，后面再怎么优化代码都是白搭。