企业官网建设流程全解析

我先把话放这儿：如果你现在手里有块带ST7789驱动芯片的小屏，又有一块ESP32开发板，想点亮它但心里没底——这篇文章就是给你写的。我第一次接手这个组合时，屏幕上只有一片刺眼的白，当时连DC引脚和RST引脚的作用都没完全搞清楚，折腾一下午才明白问题出在初始化序列里一个寄存器写错了。后来在几个项目里反复用它跑LVGL做卡片式UI、环境监测面板、桌面摆件，才终于把这套链路彻底摸透。

本文会覆盖从硬件选型、接线、裸机驱动ST7789、移植LVGL图形库，到DMA刷新和常见花屏白屏问题的完整排查链路。适合刚入门ESP32图形开发的初学者，也适合在Arduino-ESP32与ESP-IDF之间纠结怎么选的朋友。我会把值得记住的坑和“为什么这样写”都讲清楚，你可以当成一份完整实战记录来参考。

1. 为什么是ESP32 + ST7789？这套组合的适用边界

先说结论：ESP32加ST7789不是唯一的选择，但在“低成本、低功耗、彩色小屏、快速出原型”这个区间里，它的综合体验确实好。ST7789是当前小尺寸IPS屏幕模组上最常见的驱动芯片，ESP32则提供了足够的主频、内存和DMA通道来带动图形库。两者搭配起来，入门门槛低，社区资料也极其丰富。

1.1 ESP32在屏幕驱动上的家底

ESP32-WROOM-32这颗芯片本身跑240MHz双核，虽然比不上桌面处理器，但驱动一块240x240的屏幕绰绰有余。它内置SPI外设支持40MHz甚至更高的时钟，配合DMA可以在不占用CPU的情况下往屏幕搬数据。对于LVGL这种图形框架来说，CPU还要忙着处理渲染和事件循环，DMA把像素数据送到屏幕这一步就会省下大量阻塞等待时间。

另外ESP32的520KB SRAM在小尺寸嵌入式领域算是“大户”。LVGL渲染至少需要一个帧缓冲块，如果用240x240分辨率、RGB565格式，一个全屏缓冲区就是240×240×2=115200字节，约112.5KB，ESP32还能勉强承担。如果用更大分辨率比如240x320，全屏缓冲就到了150KB，这时候520KB内存就比较紧张了，必须用分块刷新策略，后面我会专门讲怎么配置。

ESP32还支持两种主流开发方式：Arduino-ESP32和ESP-IDF。Arduino上手快，库生态完善，PlatformIO里一键配置好板型就能编译烧录，非常适合学习阶段。ESP-IDF则更底层、更可控，内存占用更低，适合做产品化时要接OTA、蓝牙、Wi-Fi协议栈深度定制的场景。

1.2 ST7789屏幕模组的真实面貌

ST7789是一颗显示控制芯片，它并不是“一块屏幕”，而是屏幕模组上的主控IC。市面上大量1.3寸240x240、1.54寸240x240、2.0寸240x320、2.4寸240x320的IPS屏幕模组用的都是它。这些模组价格通常从十几块到三十几块不等，IPS全视角，色彩观感很好。

但有个容易被忽视的问题：同一颗ST7789芯片，不同模组厂家的初始化序列并不完全一样。有的厂家把背光串联了大电阻，有的没有；有的屏幕出厂默认需要开启颜色反转才能显示正常颜色，有的则相反；有的MADCTL默认扫描方向不同，导致图像旋转90度或镜像。你从淘宝买屏幕时，最好记下商家给的初始化代码或者驱动库出处，不要凭经验套用网上另一块屏幕的代码。

1.3 不要用这套方案硬扛重型GUI

ST7789的极限分辨率基本就是240x320，帧率受SPI带宽限制，跑个时钟界面、温湿度卡片、设置菜单完全没有问题，跑视频流或者复杂3D风格的GUI就非常吃力。如果你需要做更大型的界面，建议考虑ESP32-S3加RGB接口屏幕或者带并行接口的屏幕，那是一条更复杂的路线。

我个人的判断标准很简单：如果一个界面的重绘面积超过全屏的三分之一，且需要每秒高频刷新，ST7789加SPI的方案就不合适了。但如果你的需求只是“几秒钟跳变一次的数据展示”，那这套方案可以说是性价比天花板。

2. 硬件准备与接线：三件容易出错的事

点亮屏幕之前，先把硬件准备好。很多人包括我自己，第一次翻车就翻在接线上。ST7789屏幕模组引脚不多，但每根线的作用和接线顺序影响很大。

2.1 物料清单与选型细节

选屏幕时还有个小细节：模组PCB上是否集成电平转换芯片。很多廉价模组把IO直接引出，输入高电平范围兼容3.3V，不要用5V单片机的逻辑电平去驱动，否则可能烧坏屏幕控制IC。

2.2 SPI接口接线表与信号说明

ST7789模组常见的接口引脚为：VCC、GND、SCL/SCLK、SDA/MOSI、RES/RST、DC、CS、BLK/BL。有些模组还会引出MISO，但ST7789是单工写为主，MISO很少用到。

我用的是ESP32经典开发板，VSPI默认引脚接法如下：

GPIO编号也不是固定死的，你完全可以根据自己板子的实际引出情况更改。但注意避免使用ESP32的某些只读引脚或启动约束引脚，比如GPIO12在部分模块上影响flash电压，GPIO16/17与PSRAM冲突，选择普通输出IO更稳妥。

2.3 电源与背光的隐藏问题

屏幕供电看起来是小事，其实最容易引发“薛定谔的白屏”。很多ST7789模组的背光LED串联了限流电阻，直接把BLK接到3.3V就能亮，但背光全亮时电流可能达到几十毫安。如果开发板自带的LDO同时给ESP32射频和其他外设供电，屏幕插上后可能会出现电压跌落，轻则屏幕闪烁，重则ESP32反复重启。

我的经验是：初期调试直接用USB供电没问题，但一旦屏幕尺寸超过1.54寸或者同时外接其他传感器，最好从外部稳压源给屏幕单独供3.3V，两者共地。另外屏幕的VCC脚旁边我习惯加一颗100nF和一颗10uF电容，位置越靠近屏幕越好，对抑制SPI高速切换引起的电源噪声非常有效。

还有一点容易被忽略：DC和CS引脚在初始化前处于不确定状态，如果驱动代码里没有正确配置GPIO的模式和上拉，屏幕可能会在启动瞬间收到乱码命令。所以初始化代码的第一步，一定是先把所有控制引脚设置为输出模式并拉高，再拉低复位，再执行初始化序列。

3. 裸机驱动ST7789：把像素从芯片送到屏幕的底层原理

很多人一上来就直接跑LVGL例程，屏幕亮了就以为“会了”，一旦花了屏却不知道从哪里查起。我的建议是先抛开LVGL，花一个小时写一个裸机驱动，把屏幕点亮并显示纯色、画个简单的矩形，确认SPI链路和初始化序列没问题，再往上叠图形框架。这一步省下的时间会远超你的预期。

3.1 SPI通信与命令体系

ST7789通过SPI接收命令和数据，协议非常简单：当CS为低时，SPI开始传输字节；DC引脚决定当前字节是命令还是数据，DC拉低表示命令，DC拉高表示数据。可以这样理解：命令告诉屏幕“我要做什么”，数据告诉屏幕“具体怎么做”。

常用的SPI模式是Mode 0（CPOL=0，CPHA=0），即时钟空闲为低，在上升沿采样数据。大部分驱动库默认都使用这个模式，如果你时序不对，屏幕轻则花屏重则完全无反应。

写一个命令的基本动作是：

void lcd_write_cmd(uint8_t cmd) { gpio_set_level(DC_PIN, 0); // 命令模式 gpio_set_level(CS_PIN, 0); // 拉低片选 spi_transfer(cmd); // 发送命令字节 gpio_set_level(CS_PIN, 1); // 拉高片选 } void lcd_write_data(uint8_t data) { gpio_set_level(DC_PIN, 1); // 数据模式 gpio_set_level(CS_PIN, 0); spi_transfer(data); gpio_set_level(CS_PIN, 1); }

注意DC电平切换必须发生在CS拉低之前，否则屏幕会把第一个数据字节误判为命令。很多初次移植的人在这个顺序上栽过跟头。

3.2 初始化序列：为什么不同厂家的序列不完全一样

ST7789上电后并不能直接显示内容，需要先执行一串初始化命令，比如退出睡眠模式、设置像素格式、设置扫描方向、打开显示等。一个最小可用的初始化序列大致如下：

lcd_write_cmd(0x01); // SWRESET，软件复位 vTaskDelay(pdMS_TO_TICKS(150)); lcd_write_cmd(0x11); // SLPOUT，退出睡眠 vTaskDelay(pdMS_TO_TICKS(200)); lcd_write_cmd(0x36); // MADCTL，扫描方向 lcd_write_data(0x00); lcd_write_cmd(0x3A); // COLMOD，像素格式 lcd_write_data(0x05); // 16位RGB565 lcd_write_cmd(0x21); // INVON，开启颜色反转（部分模组需要） lcd_write_cmd(0x13); // NORON，正常显示 lcd_write_cmd(0x29); // DISPON，打开显示

有几个关键寄存器你必须理解，而不是背下来：

• 0x36 MADCTL（Memory Access Control）：控制扫描方向、RGB/BGR顺序、行/列地址自增方向。修改低6位能实现旋转和镜像。如果你发现显示方向不对、像照镜子，改这个寄存器就行。
• 0x3A COLMOD（Pixel Format）：设置为0x05表示RGB565，16位每像素；0x06是RGB666，18位每像素。LVGL的LV_COLOR_DEPTH必须和这里匹配，否则颜色会错乱。
• 0x21 INVON / 0x20 INVOFF：颜色反转。同一块屏幕上，有的模组需要打开反转才显示正常颜色，有的必须关闭。它的表现不是花屏，而是颜色像底片一样反色，非常容易误判成RGB顺序问题。

很多模组在初始化序列中还会写入伽马校正、电源控制等“私有”寄存器，由屏幕厂家提供。我的建议是：如果屏幕卖家或者驱动库作者给的序列能正常工作，就不要自行修改那些额外的寄存器。

3.3 一个最简画点函数：像素格式与显存窗口

ST7789内部有一整块显存，你需要告诉它“我要往哪个区域写像素”，然后再发像素数据。这个区域由两个命令框定：

• CASET（0x2A）：设置列地址范围（X方向）
• RASET（0x2B）：设置行地址范围（Y方向）
• RAMWR（0x2C）：写入像素数据

在240x240的屏幕上，如果CASET从0开始，RASET从0开始，坐标就是左上角为原点。但很多模组内部存在物理偏移，比如x轴从0到239显示正常，y轴却从80开始，这通常需要在窗口命令里加上偏移量。这也是花屏排查时最隐蔽的原因之一。

一个画点函数可以写成这样：

void lcd_draw_pixel(uint16_t x, uint16_t y, uint16_t color) { lcd_write_cmd(0x2A); // CASET lcd_write_data((x + offset_x) >> 8); lcd_write_data((x + offset_x) & 0xFF); lcd_write_cmd(0x2B); // RASET lcd_write_data((y + offset_y) >> 8); lcd_write_data((y + offset_y) & 0xFF); lcd_write_cmd(0x2C); // RAMWR lcd_write_data(color >> 8); lcd_write_data(color & 0xFF); }

每次画点都重新设置窗口，效率极低，但作为验证裸机驱动的工具完全够用。等你确认整个链路没问题了，再进入批量发送阶段，也就是LVGL的flush回调要做的事。

4. LVGL移植：从裸机画点跑到图形框架

裸机驱动能点亮屏幕之后，就可以把LVGL移植进来了。LVGL（LittlevGL）是一个开源嵌入式图形库，提供了控件、布局、动画、主题等一整套机制。移植的本质只有三件事：给LVGL提供“当前时间”，给LVGL提供一个把缓冲区画到屏幕的函数，然后周期性地调用它的任务处理函数。

4.1 项目形态：Arduino + LVGL 还是 IDF + LVGL

很多初学者卡在第一步：到底用哪个环境。我的建议如下：

如果你已经能写ESP-IDF的SPI驱动，我推荐直接用IDF。如果刚开始，先用Arduino跑通整个流程建立信心，再迁移到IDF也不迟。

4.2 拿到LVGL源码后要做的三件事

无论哪种环境，LVGL的目录结构都类似。拿到源码后，第一步是复制lv_conf_template.h为lv_conf.h，并在编译选项里定义LV_CONF_INCLUDE_SIMPLE。然后在lv_conf.h中重点关注几个宏：

#define LV_COLOR_DEPTH 16 #define LV_TICK_CUSTOM 1 #define LV_MEM_SIZE (32 * 1024)

LV_COLOR_DEPTH必须与屏幕的像素格式一致，ST7789初始化里设置了RGB565，这里就是16。LV_TICK_CUSTOM为1时，LVGL会使用lv_tick_get_custom函数获取系统毫秒计数，这样就不用手动调用lv_tick_inc，对FreeRTOS环境非常方便。

LVGL还需要一个周期性的心跳来驱动动画和任务调度。在Arduino里通常放在loop()中调用lv_timer_handler()，在IDF中则建议创建一个独立任务，每5毫秒或每10毫秒调用一次：

while (1) { lv_timer_handler(); vTaskDelay(pdMS_TO_TICKS(5)); }

对于UI响应，5到10毫秒的周期足够流畅。lv_timer_handler()内部会处理输入、重绘和动画，它的调度频率决定了界面的刷新上限。

4.3 显示驱动注册与flush回调函数实现

LVGL不直接操作屏幕寄存器，而是通过一个显示驱动结构体来和底层连接。在LVGL v8中，注册方式大致如下：

static lv_disp_draw_buf_t draw_buf; static lv_color_t buf_1[240 * 40]; static lv_color_t buf_2[240 * 40]; lv_disp_draw_buf_init(&draw_buf, buf_1, buf_2, 240 * 40); static lv_disp_drv_t disp_drv; lv_disp_drv_init(&disp_drv); disp_drv.hor_res = 240; disp_drv.ver_res = 240; disp_drv.flush_cb = lcd_flush_callback; disp_drv.draw_buf = &draw_buf; lv_disp_drv_register(&disp_drv);

flush回调是LVGL和屏幕之间的唯一数据通道。LVGL会把一整个矩形区域的像素打包好，通过这个回调交给你。你需要把这部分像素写入屏幕，发送完成后调用lv_disp_flush_ready()来通知LVGL缓冲区已经空闲，可以继续渲染下一块。

一个基于Arduino SPI库的flush函数长这样：

void lcd_flush_callback(lv_disp_drv_t *drv, const lv_area_t *area, lv_color_t *color_p) { lcd_set_window(area->x1, area->y1, area->x2, area->y2); for (int y = area->y1; y <= area->y2; y++) { for (int x = area->x1; x <= area->x2; x++) { uint16_t c = color_p->full; spi_write_byte(c >> 8); spi_write_byte(c & 0xFF); color_p++; } } lv_disp_flush_ready(drv); }

如果你直接把像素字节发完再调用lv_disp_flush_ready()，功能上没问题，但会阻塞CPU直到SPI发送完毕。对于240x40的缓冲区，RGB565数据就是240×40×2=19200字节，在40MHz SPI时钟下大约需要几毫秒，这个时间虽然不致命，但会卡住LVGL的渲染循环，动画一多就会觉得不跟手。后面我会讲怎么用DMA解决这个问题。

4.4 输入设备：按键和触摸的接入

屏幕只做显示不算完整产品，LVGL还支持按键、编码器、触摸屏等输入设备。如果是带触摸的ST7789模组，触摸IC通常是XPT2046或STMPE610，通过SPI读出坐标，再通过lv_indev_drv_t注册到LVGL。

如果是纯按键，那更简单。LVGL提供了一个lv_indev_drv_t类型为LV_INDEV_TYPE_ENCODER的输入方式，可以用两个GPIO模拟旋钮，一个GPIO作为确认键，然后映射到焦点控制和点击事件。对于无触摸的小屏项目，按键驱动是最常见的方案。

不过输入设备不是屏幕驱动的必需部分，我建议先把显示调通，再加输入，一步步来。

5. 跑起来之后的事：性能调优与内存优化

LVGL跑起来只是第一步。等你把几个页面和动画写上，才会真正感受到“画面流畅”和“卡成幻灯片”的差距。这一章分享我实测过的几种优化手段。

5.1 DMA刷新还是阻塞刷新？这是个关键选择

上一章的普通flush函数，每次发送都要等待SPI忙完。在LVGL中，flush回调触发频率很高，每一次等待都会拖慢渲染节奏。改进办法是用DMA启动传输后立即返回，让CPU继续处理LVGL渲染，同时SPI硬件在后台搬数据。

但DMA方案有一个经典陷阱：你必须在启动下一块数据传输之前，确认上一块已经发完。因为LVGL双缓冲机制下，虽然有两块缓冲区，但如果你提前覆盖了正在被DMA读取的缓冲区，画面就会出现撕裂。正确处理方式是维护一个“发送完成标志”，在SPI的中断服务函数里置位，flush回调里若发现上一块还没发完，就循环等待。

以ESP-IDF的SPI驱动为例，使用spi_device_queue_trans可以异步发送，然后在发送完成回调里记录当前缓冲区已经空闲。核心代码思路如下：

bool spi_sending = false; void lcd_flush_callback(lv_disp_drv_t *drv, const lv_area_t *area, lv_color_t *color_p) { while (spi_sending) { // 等待上一次DMA传输完成 } lcd_set_window(area->x1, area->y1, area->x2, area->y2); spi_transaction_t t = { .tx_buffer = color_p, .length = (area->x2 - area->x1 + 1) * (area->y2 - area->y1 + 1) * 2 * 8, }; spi_sending = true; spi_device_queue_trans(spi_handle, &t, portMAX_DELAY); } void spi_transmit_done_cb(spi_transaction_t *t) { spi_sending = false; lv_disp_flush_ready(display_drv); }

这里有一个细节：lv_disp_flush_ready()可以在DMA完成中断里调用，前提是你保存了对应的lv_disp_drv_t指针。这样做的好处是LVGL在DMA传输期间可以继续渲染下一块区域，帧率会有明显提升。

5.2 帧率实测：不同buffer配置下的表现

我分别测试了单buffer和双buffer、不同行缓存大小的情况，屏幕都是240x240的ST7789，SPI时钟40MHz，CPU 240MHz：

实测下来，40行双buffer加DMA是绝大多数项目最均衡的方案。全屏双buffer虽然最流畅，但内存占用太大，留给LVGL控件的空间就少了，界面一复杂反而容易内存不足。局部刷新适合表盘这类界面变化范围小的场景，但需要你确保LVGL的LV_COLOR_DEPTH和屏幕设置一致，否则局部刷新区域会出现残影。

5.3 内存不够的优化思路

LVGL每个控件、样式、图片解码都会占用内存。如果运行时出现花屏、重启、控件不显示，十有八九是内存分配失败。排查和优化可以从这几个方向入手：

• 调低LV_MEM_SIZE不是解决办法，而是先统计实际内存使用，再反向配置。可以在lv_conf.h中打开LV_USE_LOG和LV_LOG_LEVEL，通过串口日志查看LVGL内部内存分配失败的具体位置。
• 关闭不需要的组件宏。LVGL的每个组件都会编译进代码并占用Flash和少量RAM，用不到的组件直接关闭，例如LV_USE_BAR、LV_USE_CHART、LV_USE_MSGBOX等。
• 字体按需裁剪。用LVGL官方字体转换工具lv_font_conv生成字体时，只保留实际使用的字符和字号，不要一股脑包含全量Unicode。
• 如果你的ESP32模块带有PSRAM，可以考虑让LVGL的动态内存分配到PSRAM。但注意，DMA用的显示缓冲尽量不要放PSRAM，因为PSRAM访问延迟高，DMA传输容易出问题，显示缓冲继续放在内部RAM，只有LVGL的堆区使用PSRAM。

5.4 LVGL v8与v9版本差异

LVGL版本迭代很快，目前v8.3依然是资料最全的稳定版本，v9虽然性能更好，但API变动较大。如果你是新手，建议直接用v8.3，网上教程和社区问题基本都以这个版本为准。v9中lv_disp_drv_t的注册方式、颜色类型定义、部分内置组件API都有变化，老代码不能直接编译通过，需要迁移。等你能独立完成v8.3项目后，再考虑升级，否则会被报错淹没。

6. 踩坑实录：花屏、白屏、卡死与黑屏的完整排查链路

这一章是我最想写的部分。屏幕驱动项目90%的时间都花在调试显示异常上，所以我把常见问题整理成一条排查链路，你照着走一遍，基本能定位到根因。

6.1 白屏：先分清是背光问题还是驱动问题

白屏分两种：一种是一片亮白色，背光是好的，但屏幕没有接收到有效命令；另一种是屏幕完全不亮，看起来像白屏或暗屏，其实是背光电路的问题。

如果是背光不亮，先测量BLK引脚电压，看是否为高电平。很多模组把BLK串了电阻后直接接VCC也能亮，但如果你在初始化代码里把BLK作为普通IO输出，务必要确保输出高电平。

如果背光正常但屏幕白色无内容，原因通常出在初始化序列没有执行成功。这是我一个朋友的典型错误：他把RST引脚接到GPIO后，忘了先拉低再拉高，屏幕根本没有完成复位，后续命令全部无效。正确做法是接线配置完成后，先拉低RST至少10ms，再拉高，再延时，然后再发送初始化序列。

还有一个非常隐蔽的错误：初始化代码里把spi_device_queue_trans用错了，导致命令字节前面的DC状态没有正确更新。因为DC切换和SPI事务是分步的，必须保证DC引脚状态在片选拉低之前就绪，否则前几个字节会被当作错误类型处理。

6.2 花屏：SPI信号质量、MADCTL、像素格式三层排查

花屏是另一个重灾区。我总结了一个由简到繁的排查顺序：

第一步，先画纯色测试。如果纯色画面连同位置一起出现斜向噪点、条纹干扰，说明SPI信号质量不好。常见诱因是杜邦线太长、线材质量差、SPI时钟过高。把SPI时钟从40MHz降到10MHz或更低，如果花屏消失，问题就定位在信号完整性。我的经验是：调试阶段用10cm以内的杜邦线，跑40MHz通常问题不大；超过20cm，20MHz都有风险。

第二步，如果是全屏图像颜色不对，比如红色显示成了蓝色，说明RGB/BGR顺序反了。可以通过修改MADCTL寄存器中的RGB位（bit 3）或者LVGL对应的颜色配置来修正。屏幕模组千奇百怪，有的需要RGB，有的需要BGR，没有统一答案。

第三步，如果图像是镜像、旋转、坐标偏移，检查MADCTL的控制位。每个屏幕默认扫描方向不一样，你需要试出合适的值。常用的方法是在屏幕上画一个带方向标志的图标（比如一个左上角有红色圆点、右下角有蓝色方块的测试图像），然后根据显示的朝向去调MADCTL。

第四步，如果整个画面错位、显示区域偏移，重点检查CASET/RASET命令里的坐标偏移量。有些模组虽然分辨率是240x240，但内部DRAM行数多于240，厂商初始化序列里通过设置偏移把显示窗口“纠正”回来。你若用了其他屏幕的偏移量，就会出现画面整体偏移。这里只能靠逐项试，或者参考卖家初始化代码。

6.3 开机卡死：电源问题还是GPIO冲突

有屏幕出现“烧录完程序之后一直重启”的情况，常见原因有两个。一是ESP32的3.3V稳压器无法同时满足射频、传感器和屏幕背光的电流需求，启动瞬间电压跌落导致ESP32复位循环。解决方法是给屏幕外接稳压源，并让两块板子共地。

二是GPIO选择错误。ESP32有些引脚在启动时有特殊状态，比如GPIO12、GPIO0、GPIO2在启动时被内部上拉或影响启动模式。如果你把屏幕控制线接到这些引脚，屏幕在复位瞬间可能拉低或拉高这些关键信号，导致系统启动异常。遇到这类问题时，把屏幕引脚换成纯输出类型的普通GPIO，比如GPIO18、GPIO23、GPIO25、GPIO26、GPIO5这套常规组合，基本能排除干扰。

6.4 LVGL在OTA升级后黑屏：刷新任务与升级流程的竞争

热词里有人提到“esp32 ota升级”，我把一个真实案例分享出来。某个远程设备通过OTA升级后，屏幕彻底黑了，但设备本身正常工作。排查之后发现，OTA升级过程中Wi-Fi协议栈占用了大量CPU中断，LVGL刷新任务被抢占，flush回调长时间得不到执行，LVGL内部错误日志里的lv_disp_flush_ready没有被调用，导致渲染流程死锁。

这个问题修复起来不复杂：OTA升级期间，主动通知UI任务停止刷新，同时把显示缓冲区清零，等重启或者升级完成后重新初始化屏幕。如果你在升级过程中又需要显示进度条，建议用裸机画图函数直接写屏，不要经过LVGL的flush回调，因为LVGL的错误恢复机制在这些场景下并不完善。

6.5 用逻辑分析仪验证时序：从根上确认问题

如果上面几种排查都没解决，不要继续猜了，上逻辑分析仪。一个十几块钱的8通道逻辑分析仪，配上开源的PulseView，就能抓到完整的SPI波形。你只需要抓CS、DC、SCLK、MOSI四根线，看看初始化序列是否正确发送。

正常波形应当是：CS拉低期间，DC先拉低发送命令字节，再拉高发送数据字节，SCLK按频率翻转，MOSI上有对应的8位数据。如果你在MOSI上看到预期命令码（比如0x36），那问题就不在SPI通信层，而要进一步查初始化序列本身；如果MOSI上没有数据，那就是SPI驱动函数根本没被执行，优先级要在代码层面找。

我每次调试新屏幕的第一步，就是先抓一次SPI波形，确认字节级数据正确，再往下走。这个习惯帮我省掉了无数“改代码—编译—烧录—看屏”的死循环。

最后再分享一个个人习惯：新屏幕到手后，先写一个最简单的裸机测试程序，循环显示红、绿、蓝三色，每1秒切换一次。如果这三种颜色显示准确，说明SPI链路、像素格式、背光电源全部正常。拿到这个底气，再移植LVGL，基本上一步到位。玩屏幕就是这么个过程：慢就是快，先把底层验证扎实，上层框架才会稳。