STM32U5并口屏驱动实战：FMC与GPDMA 2D寻址方案解析

这块屏让我折腾了整整三天。别人听到"STM32U5 驱动 ILI9488"时，第一反应基本都是"为什么不用 SPI 屏？"——但真正做过嵌入式 GUI 的人会明白，当分辨率来到 480×320、刷新率要求超过 20 帧、CPU 还得同时跑触摸与动画逻辑时，SPI 这条路的尽头就是瓶颈。这个项目就是把 FMC 16 位并口、ILI9488 面板和 GPDMA 的 2D 搬运能力串成一条完整链路，让屏幕刷新几乎不占 CPU。即便你没用过 STM32U5，这篇文章里的总线时序剖析、DMA 二维寻址思路和踩坑清单，也能直接迁移到 STM32H7、F4 甚至其他带并行总线的 MCU 上。

1. 整体设计思路：为什么偏偏是 FMC + GPDMA 的组合拳

1.1 FMC 在 STM32U5 上的真实定位

先说个容易混淆的点：很多人搜"FMC"会搜到 FPGA 行业里的 FMC 连接器标准，那是一种高速子卡接口，尺寸和引脚定义都有规范。但 STM32 里的 FMC 完全是另一个东西，全称 Flexible Memory Controller，灵活存储控制器。它的本职工作是让 MCU 像访问内部 SRAM 一样，通过并行总线直接读写外部存储器芯片，比如 NOR Flash、SRAM、SDRAM。而很多 TFT 液晶屏恰恰提供 8080/6800 并行接口，本质上就是一个"只写存储器"，所以把 FMC 接到并口屏上，是成本最低、最稳定的高速驱动方案。

STM32U5 这一代 Cortex-M33 内核，主频能跑到 160MHz，Flash 又带加速器，算力其实相当充裕。但再充裕的 CPU，做逐像素搬运也是浪费。一块 480×320 的 ILI9488，RGB565 格式一帧就 300KB 数据，假设用 GPIO 模拟时序，哪怕每条数据线都有现成的寄存器操作，也得几百万次循环才能刷完一帧，CPU 直接打满。FMC 的价值在于，地址写一次、数据总线自动完成握手，MCU 核心只需要执行一条普通的写指令，剩下的时序全由硬件完成。

另外 STM32U5 还有 LTDC 和 GFXMMU，理论上可以接 RGB 接口屏。但 RGB 接口屏需要 24 根数据线加同步信号线，引脚压力大，而且面板普遍比 MCU 并口屏贵。项目里选 ILI9488 而不是 RGB 屏，核心原因就是手头这批 3.5 寸模块成本低、货源足、只需要一个 FMC 就能搞定，PCB 走线压力也小很多。所以这个方案的定位不是"最先进"，而是"最划算的高速屏驱方案"。

1.2 16 位并口的硬件连接与存储映射原理

ILI9488 本身支持 SPI、8 位并口、16 位并口三种模式，由 IM[3:0] 引脚的电平组合决定。项目里要发挥 FMC 的最大带宽，必然选择 16 位并口模式，也就是 8080 时序。硬件连接看起来直白，但里面藏着两个关键点。

第一，数据线 D[15:0] 和 FMC 的数据总线一一对接，这是最直接的。第二，命令/数据选择线 RS（也叫 D/CX）要接到 FMC 的地址线，比如 A0 或者 A1。这一步是整个映射关系的枢纽。FMC 访问外部存储器的地址是连续的：当 CPU 向某个基地址写入时，地址线的 A0 会被自动置高或置低。把 RS 接到 A0 上，就相当于让"命令和数据"自动分布在两个相邻的地址上。

以经典配置为例，FMC Bank1 的起始地址是 0x60000000，片选用 NE1。如果 RS 接 A0，那么：

#define LCD_BASE 0x60000000UL #define LCD_REG (LCD_BASE) // A0 = 0，写命令 #define LCD_RAM (LCD_BASE | 1) // A0 = 1，写数据

写命令时用*(volatile uint16_t *)LCD_REG = cmd;，写数据时用*(volatile uint16_t *)LCD_RAM = data;。CPU 视角下这就是两个普通内存地址，编译器毫无感知，但对 LCD 来说，低电平的 RS 意味着"这是命令周期"，高电平意味着"这是数据周期"。所以表面上看是地址跳变，实际上是 FMC 协议转换。这个映射关系几乎适用于所有 8080 接口屏，非常通用。

再说回 16 位数据传输。ILI9488 的 RGB 是三通道 18bit 色彩，一帧要 18 位数据，但 16 位并口传输时一般用 RGB565 格式，也就是每像素 2 字节，颜色深度 16bit（5bit 红、6bit 绿、5bit 蓝）。人眼对 16bit 色阶的观感通常在可接受范围内，除非做高精度图像显示，否则性能优先选 RGB565 完全合理。FMC 单次写 16bit，正好一个像素一个周期，效率最高。

1.3 为什么 GPDMA 是这套方案的灵魂

FMC 解决了"快"的问题，但如果没有 DMA，CPU 依然要执行 15 万次写操作才能刷完一帧——每次循环都在等总线。STM32U5 上的 GPDMA 相比传统 DMA，最大的升级就是支持 2D 寻址和链表模式。2D 寻址意味着 DMA 不是只能搬运一段连续内存，而是可以按"行"搬运，每一行搬运完成后，源地址和目标地址分别按预设的偏移量跳变。

这个能力放在屏幕刷新上简直是为图形而生的。一份图像缓冲在内存里通常是连续的逐行存储，但 LCD 端的目标地址，也就是 FMC 数据寄存器地址，永远固定在一个地址上。用传统 DMA 搬运连续数据会把图像"摊平"成一行写进屏幕，屏幕内容会变成一条线状错乱图。而 GPDMA 2D 模式可以设置目标地址每行偏移为零，每次写完一行后，地址仍然回到同一个数据寄存器，这样屏幕才能正确地按行刷新。

所以整套方案的精髓是：FMC 负责把写入操作变成并口时序，GPDMA 2D 负责把"连续内存中的二维图像数据"转换成"对同一外设地址的连续写入流"，CPU 自始至终只需要发起一次传输请求。

2. FMC 时序配置实战：异步 SRAM 模式的关键参数

2.1 从屏幕手册到 FMC 寄存器的参数换算

FMC 总线配置不是随便填几个数字就行，必须回到屏幕数据手册的读写时序图。ILI9488 的 8080 接口写周期包含三段时间：地址建立时间（从 CS/RS 有效到 WR 下降沿）、数据建立时间（WR 低电平脉宽，或从 WR 下降到数据稳定）、数据保持时间。FMC 的异步 SRAM 模式可以独立配置这些时间。

STM32U5CubeMX 中 FMC 的 NOR/SRAM 配置页面里，关键参数是：

• ADDSET：地址建立时间，单位是 FMC 时钟周期数
• DATAST：数据建立时间，单位是 FMC 时钟周期数
• ADDHLD：地址保持时间（很多总线不启用）
• BUSTURN：总线转换时间，两次访问之间的最小间隔

FMC 的时钟一般直接取 HCLK。以 160MHz HCLK 为例，一个周期是 6.25ns。ILI9488 手册一般会给出 WR 低电平最小脉宽，通常要求几十到上百 ns。我手里这块 3.5 寸 IPS 模组，实测写周期至少给到 100ns 以上才稳定，也就是 DATAST 至少 16 个周期。

不过项目里我并没按极限值去压，而是给了相对宽裕的参数：ADDSET=10，DATAST=20，BUSTURN=1。换算下来，单个写周期大约 (10+20+1) × 6.25 ≈ 194ns，理论吞吐约 5MB/s，一帧 300KB 也就 60ms 左右，对 30fps 的需求来说刚好在边缘，但稳定压倒一切。如果后续要提帧率，可以先把 DATAST 压到 12，写周期约 143ns，一帧 43ms，就能跑到 23fps。这里要注意，不同批次的屏幕模组对时序的敏感度不一样，量产场合最好留 1.5 倍以上余量。

2.2 CubeMX 中的实际配置步骤

CubeMX 里启用 FMC 后，选择 NOR Flash/PSRAM/SRAM 类型，对应 Bank1 NE1。我在实际项目里一般这样配：

• Memory type：SRAM
• Data bus width：16 bit
• Write operation：Enable
• Extended mode：Disable
• Asynchronous timing：
  • Address setup time (ADDSET)：10
  • Data setup time (DATAST)：20
  • Bus turn around time (BUSTURN)：1

页面下方的 Read timing 和 Write timing 通常保持相同即可。注意，如果开了 Extended mode，读写时序可以分别配置，但并口屏没必要，反而让 CubeMX 生成的代码更复杂。

生成代码后，HAL 库会调用HAL_SRAM_Init()初始化 FMC，底层把参数写入FSMC_Bank1->BTCR[0]寄存器，位域映射和 CubeMX 界面参数一一对应。我把生成后的 MX_FMC_Init() 里几个关键变量打出来观察过，确认写时序参数正确落在高 16 位（DATAST）和低 16 位（ADDSET）上。调试时如果发现屏幕无响应，第一个要查的就是这里的参数有没有被 HAL 代码正确写入。

2.3 硬件走线对时序的影响

很多人软件配好了还是花屏，问题出在硬件走线。FMC 12 根数据线如果从 MCU 到屏幕模块距离过长且没有等长处理，高速翻转时信号偏斜会直接吃掉时序余量。我打样时把 FMC 总线全部走在同一层，总长控制在 6cm 内，地平面完整铺底，实测用默认时序参数就能开机显示，后期把 ADDSET/DATAST 再调小也不会花。如果你的板子走线绕了很远，建议宁可把 DATAST 调大一点，也别强行压时序。

3. GPDMA 2D 模式原理细拆：不只是"带偏移的 DMA"

3.1 STM32U5 GPDMA 的寄存器级结构

STM32U5 的 GPDMA 和传统 STM32 DMA 相比，最明显的不同是每个通道有独立的传输配置寄存器，而且可以配置链表（Linked List）。传统 DMA 描述符通常就是一个结构体，而 GPDMA 的链表机制允许把多次传输串成一串，硬件自动按顺序执行，传输完成再触发中断，这对连续刷新屏幕特别合适。

GPDMA 通道初始化需要设置源地址寄存器 DMA_CxSAR、目标地址寄存器 DMA_CxDAR、块传输长度寄存器 DMA_CxBR1、传输配置寄存器 DMA_CxTR1/TR2 以及控制寄存器 DMA_CxCR。其中传输配置寄存器里最有价值的是 DTYPE 字段，用于选择传输数据宽度（byte/half-word/word）和交换模式。屏幕数据用 RGB565，源缓冲是 uint16_t 数组，FMC 数据总线 16 位，所以 DTYPE 选半字传输，一次搬运一个像素，完美对齐。

传统 DMA 的搬运是线性扫描，从起始地址一路读到结束地址。GPDMA 增加了二维配置：源地址每行搬运完以后，加上一个行偏移量；目标地址同理。行长度和偏移量分别在寄存器中独立设置，这就是 2D mode 的核心。听起来抽象，但实际就是在描述一个矩形块扫描：比如源缓冲是 320 宽、480 高的图像，每一行有 320 个半字，行间偏移为 0（连续存储），扫描完一行跳到下一行；而目标地址每行偏移为 0（始终写同一个外部地址），也就实现了"把矩形图像逐行灌进同一数据端口"。

3.2 2D 寻址的具体配置方式

这里以本项目为例列出 GPDMA 通道初始化的关键配置，写代码时我一般直接操作寄存器，CubeMX 生成的 GPDMA 初始化代码也可以做同样的事：

DMA_Channel->CCR = 0; // 先关通道 // 传输配置寄存器 TR1 // DTYPE = half-word (01)，方向 = memory-to-memory DMA_Channel->CTR1 = (1 << DMA_CTR1_DTYPE_Pos) | DMA_CTR1_SINC | DMA_CTR1_DINC | DMA_CTR1_SBURST_1 | DMA_CTR1_DBURST_1; // 传输配置寄存器 TR2：2D 模式相关 DMA_Channel->CTR2 = ...; // 配置 2D 使能、源/目标地址偏移

不过 HAL 库提供了更高的抽象，HAL_GPDMA_Init()会填充一个DMA_InitTypeDef，其中有两个字段特别关键：SrcAddressOffset和DstAddressOffset，对应源地址和目标地址的二维偏移量。我在使用 HAL 时是这样配的：

DMA_InitStruct.Request = DMA_REQUEST_MEM2MEM; DMA_InitStruct.BlockHWRequest = DMA_BREQ_SINGLE_BURST; DMA_InitStruct.Direction = DMA_MEMORY_TO_MEMORY; DMA_InitStruct.SrcInc = DMA_SINC_INCREMENTED; DMA_InitStruct.DestInc = DMA_DINC_FIXED; DMA_InitStruct.SrcDataWidth = DMA_SRC_DATAWIDTH_HALFWORD; DMA_InitStruct.DestDataWidth = DMA_DEST_DATAWIDTH_HALFWORD; DMA_InitStruct.SrcAddressOffset = 0; DMA_InitStruct.DstAddressOffset = 0; DMA_InitStruct.TransferLength = 153600; // 480 * 320 像素

注意源地址每行偏移为 0 是很特殊的情况：因为图像数据在内存中是连续排列的，DMA 本身在每行搬运结束后会自动把源地址增加"当前行长度 × 数据宽度"，并不需要额外的行偏移。目标地址则必须固定，所以 DestInc 设为 FIXED，每写完一个全字后目标寄存器地址不递增，继续写同一个 FMC 数据寄存器。很多初学者在 2D 模式里给源地址加偏移，反而把图像搬运成了锯齿状。

3.3 2D 模式相比普通 DMA 的优势到底在哪

用普通 DMA 也可以刷屏，前提是源数据在内存中必须"每一行后面补足够多的空字节"来伪造成连续排列，或者目标端使用 FIFO 加外部逻辑。这两种方式要么浪费内存，要么增加硬件成本。GPDMA 的 2D 模式直接把"按行扫描"做进硬件，使得源缓冲可以采用任意排列，甚至可以直接把屏幕上一块小窗口的区域作为 DMA 源传输出去，这在上层 GUI 做局部刷新时特别有用。

比如做时钟界面时，只有秒针区域在动，传统方式要么全屏重刷，要么手动拷贝小窗口数据到连续缓冲再开启 DMA。有了 GPDMA 2D，可以设置源地址为秒针所在矩形区域的左上角像素地址，源行地址偏移设为目标图像总行宽和矩形宽度的差值，这样一次搬运只刷新指定矩形区域，带宽消耗大幅下降。我把一分钟刷新策略从全屏改为局部刷新后，CPU 占用率直接降了 40%，屏幕功耗也明显降低。

4. 完整刷屏实现：从初始化到 GPDMA 传输

4.1 ILI9488 的初始化序列

屏幕驱动不能绕过初始化序列。ILI9488 上电后需要软件复位、退出睡眠模式、设置像素格式、关闭/开启显示等一系列命令。网上流传的初始化数组很多，但最好先在厂家提供的代码或者屏幕模块商给的例程基础上整理。我在项目里用的初始化序列包含以下关键步骤：

1. 硬件复位：RESET 引脚拉低 10ms，再拉高，等待 120ms
2. 软件复位命令 0x01，等待 120ms
3. 退出睡眠命令 0x11，等待 120ms
4. 像素格式命令 0x3A，参数设为 0x55 即 RGB565，16bit 格式
5. 设置显示方向命令 0x36，根据 PCB 安装方向调整扫描顺序
6. 开启显示命令 0x29

这里有个常见坑：初始化时必须等待硬件复位和软件复位的延时，否则后续命令被屏幕忽略，表现为白屏或者显示异常。很多模块商例程里延时很短，量产环境必须测试上电时序。

初始化序列的每个命令发送都走前面提到的LCD_REG和LCD_RAM地址。命令参数格式上，ILI9488 通常要求先发命令字节，再发参数，但由于我们选了 16bit 模式，命令和参数都可以用半字传输。有些命令是 8bit 参数，这时候往数据地址写一个 uint8_t 值，但要确保系统内存里高位字节不会干扰，我一般用(volatile uint16_t *)类型强制转换。

4.2 真正的刷屏流程：GPDMA 一启动，CPU 就解放

屏幕初始化完成并清屏后，接下来就是刷帧。GPDMA 启动刷屏的完整流程如下：

第一步，准备一帧图像缓冲。图像源可以是摄像头采集到的 RGB565 数据、UI 引擎渲染的 buff，或者直接用数组定义的静态图片。注意内存要 2 字节对齐，我在工程里用__attribute__((aligned(32)))确保缓冲区起始地址不会让 DMA 半字传输错位。

第二步，计算帧大小。480×320=153600 个像素，半字传输模式下 TransferLength 就是 153600，传输的总字节数 = 153600 × 2 = 307200 字节。

第三步，启动 GPDMA 通道。HAL 库调用方式：

HAL_GPDMA_Start(&hdma, (uint32_t)pFrameBuffer, (uint32_t)&LCD_RAM, 153600);

这个调用是异步的，函数返回后 GPDMA 已经接管总线，CPU 可以继续做其他任务。我一般在启动后立刻使能 DMA 传输完成中断，在中断回调里置一个标志位。触摸轮询、UI 事件处理、传感器采集都可以在这段时间里跑。

第四步，等待一帧传输完成。如果是连续刷视频，可以在完成回调里直接再次启动下一次传输，形成乒乓缓冲。用两帧缓冲交替：一帧在 GPDMA 传输，另一帧被 GUI 渲染，等传输完成信号后再交换指针。这样能把渲染时间和传输时间完全重叠，帧率可以稳在 25fps 左右。

4.3 代码级避坑：地址映射和 DMA 宽度

我之前踩过一个典型坑：往 LCD_RAM 写数据时，地址定义成了0x60000001，但volatile uint16_t *和 FMC 16 位宽度的组合下，编译器会生成 LDRH/STRH 半字指令，没问题；可如果地址定义成 uint32_t 指针，编译器会生成 LDR/STR 字指令，一次写入 32bit，ILI9488 的数据线只有 16 根，导致高 16bit 数据丢失、屏幕出现错乱颜色。解决方案就是明确用volatile uint16_t *类型强制所有命令和数据的操作宽度为 16bit。

另一个细节：GPDMA 开启前，FMC 要确保已经初始化完成。有些代码在系统时钟初始化后立即调用屏幕初始化函数，但 FMC GPIO 配置还没生效，总线处于高阻态，写命令自然失败。我习惯在 main 函数最前面先做 FMC GPIO 和 FMC 控制器初始化，再跑屏幕初始化。

5. 实测性能与调优：数字背后是真实体验

5.1 帧率与总线占用的量化测试

刷屏性能不能靠感觉，得量化。我用 GPIO 翻转配合逻辑分析仪测过：从 GPDMA 启动到传输完成中断触发，用 DATAST=12 的时序配置，完整刷一帧耗时约 42ms，也就是约 23fps。这个帧率在普通 GUI 界面中完全可接受，滑动列表时有轻微拖影但不至于难受，加上局部刷新策略后，动态区域刷新时间只有 4ms 左右，体感很顺滑。

把 DATAST 压到 8 再测，一帧降到 35ms，接近 28fps，但偶发出现屏闪。分析原因，可能是数据建立时间太短，ILI9488 内部控制逻辑来不及锁存，也可能是屏幕模块 PCB 上的走线分布电容偏大。最终我放弃了极限压时序，选择 20fps + 局部刷新的组合，稳定性和体验都更好。

性能对比放到表格里更清楚：

FMC+GPDMA 的优势其实不在拉开帧率差距，而是把 CPU 释放出来。SPI 方案刷屏时中断频繁，CPU 几乎每 KB 数据就要处理一次；GPDMA 方案一帧只产生两次中断，主循环可以专心处理业务逻辑。这个差别在高负载场景下非常明显。

5.2 降低功耗与提升流畅度的组合技巧

STM32U5 主打低功耗，但推着大屏跑起来的功耗并不低。我实测整机在 23fps 刷新时电流约 40mA（不含屏幕背光），背光 20% 亮度时整机 70mA。为了延长电池续航，我做了三件事：一是按需刷新，只在内容变化时发起传输，静止画面下停止 GPDMA；二是利用屏幕自带的休眠命令 0x10，在长期无操作时让屏幕进入低功耗模式；三是降低 FMC 总线时钟频率，从 160MHz 降到 16MHz，虽然刷屏变慢，但待机电流明显下降。STM32U5 的WFI指令配合 GPDMA 完成中断唤醒，能进一步降低非刷新期间的功耗。

帧率调优方面，GPDMA 2D 模式还支持突发传输（burst），可以一次从内存里拿多个半字再写入 FMC。我试过把突发长度调到 4，发现只要 FMC 时序足够宽松，几乎感受不到差别；但突发长度过大时，DMA 从内存连续读取的 burst 会占总线时间过长，反而阻碍 CPU 访问 Flash。最后还是保持单次突发，让总线访问更均衡。

6. 常见问题排查实录：花屏、卡顿、DMA 异常一次说清

6.1 花屏与颜色错位

花屏是这类方案的"第一座山"。我总结的经验是，先区分硬件花屏还是软件花屏。软件花屏常见原因有四个：

• FMC 数据宽度配置错误，16bit 屏幕配成 8bit，造成的现象是颜色错乱、像素横向拉伸
• RGB565 与 RGB888 格式不匹配，现象是颜色偏紫偏绿
• FMC 时序参数过激，花屏是随机的，偶发性强，时好时坏
• GPDMA 传输长度不对，比如把像素数传成了字节数，导致画面出现多余内容或断层

排查步骤一般这样走：先用最简单的循环写屏函数测试单色刷屏，如果单色都花，基本是 FMC 配置问题；单色正常但显示图像花，检查 GPDMA 的传输长度和数据宽度。我写了个测试函数，把一帧数据全填成 0xF800（红色），如果没有异常，再换成 0x07E0（绿色），单色测试能快速定位总线问题。

6.2 刷新卡顿与掉帧

刷新卡顿，优先看两个地方：GPDMA 是否在传输完成前又被重复启动，以及是否有优先级反转。我在用双缓冲时，如果完成中断回调里直接调用HAL_GPDMA_Start启动下一帧，而主循环同时也在渲染缓冲，就会出现 DMA 读取正在被 CPU 修改的缓冲区，画面撕裂。解决方法是加一个volatile uint8_t dma_busy标志，只有 DMA 完成后才允许交换缓冲。

另一种卡顿来自 FMC 和 DMA 的总线仲裁。STM32U5 的总线矩阵中，CPU 访问 Flash 和 GPDMA 访问内存同时发生时，如果 GPDMA 的优先级高于 CPU，CPU 的取指会被延迟，表现为 UI 动画掉帧。我把 GPDMA 通道优先级设置为中等，CPU 对应的 AHB 优先级为高，卡顿感明显减轻。

6.3 GPDMA 传输不完成或超时

GPDMA 传输超时，10 次里有 9 次是配置的传输长度太大或目标地址非法。我踩过一次：把传输长度设成了 460800，这是 RGB888 格式的字节数，但 DTYPE 设为 half-word，实际硬件按半字计数，传输量翻倍，导致 DMA 访问到未映射区域而挂死。检查时先看中断标志寄存器，如果是 FIFO 错误或总线错误，多半是地址访问越界。

还有一次 GPDMA 启动后不传输，原因是DMA_InitTypeDef.Request没有配置，GPDMA 不知道用哪个请求信号。memory-to-memory 传输也需要明确指定请求类型，我用DMA_REQUEST_MEM2MEM解决。每条通道的可用请求列表可以在参考手册的 DMA request mapping 表里查到，配错不会报错，但就是不动，非常隐蔽。

6.4 引脚冲突与复用难题

FMC 总线占用大量引脚，STM32U5 的封装如果不够大，FMC 和 ADC、UART、SPI 等功能容易冲突。我的板子上 FMC 占用了 PD0-PD15，手指触摸屏的 I2C 用 PB8/PB9，刚好错开。如果遇到冲突，优先考虑用 FMC 的地址线复用方案：部分功能复用 A0-A7 和 D0-D7，用 AF 映射把不冲突的引脚配置成复用功能。实在不行，就只能改选更小的封装或用 SPI 屏降级方案——这不是认输，而是产品定义里的妥协。

调 FMC 的引脚一定要看 CubeMX 的引脚分配图，软件上没有任何冲突提示不代表硬件就适合，因为高速信号互相干扰在布线阶段就会要命。

7. 写在最后的一点实际感受

这套方案折腾下来，最大的感触是：FMC + GPDMA 2D 的组合，本质上是一种"用硬件设计情怀换 CPU 时间"的思路。STM32U5 的低功耗定位配上 480×320 大屏，很多人觉得不搭，但从项目结果看，只要控制好刷新策略、合理规划局部刷新区域，这套组合完全可以在便携设备上跑出可用的流畅度。如果你也打算这么干，我的建议是：屏幕初始化序列一定先用模块商例程跑通再改，FMC 时序参数不要上来就压最低值，GPDMA 的 2D 模式先从全屏刷新开始验证再去做局部窗口。踩完这些坑，后面再切到更复杂的 GUI 框架，你会发现底层这套总线驱动已经稳得不像话。哪天真把屏幕刷到瓶颈，再回来看看 GPDMA 的链表模式，那又是另一片天地。