简介：这份资源面向嵌入式开发学习者与STM32驱动工程师，聚焦TFT液晶屏高速刷新的实现方案，解决SPI传输占用CPU、刷屏帧率偏低的问题。内容以STM32F767的Cortex-M7平台为核心，通过SPI结合DMA驱动9341显示控制器，涉及54MHz SPI时钟配置、DMA传输方向与缓冲区设定、9341初始化序列及20Hz整屏刷新等关键环节，适合已具备HAL库基础、希望深入掌握显示驱动优化的中高级开发者参考。压缩包共1099个文件，约54.23MB，以591个c源文件与275个h头文件为主体，辅以51个汇编文件、42个链接脚本及Keil、IAR工程配置，完整保留驱动库与工程结构，便于直接编译验证与二次移植。目前已有2123人学习下载，可从中获取SPI DMA刷屏的配置思路、DMA中断处理流程与性能调优参考，是排查显示卡顿、提升刷新率的实用工程样本。
1. 屏幕刷新率卡在 30 帧，问题往往不在 CPU
很多人第一次用 STM32F767 驱动 9341 这类 TFT 屏，都会遇到一个反直觉的现象：主频拉到 216MHz，CPU 空转时间一大把，可整屏刷新还是慢得像幻灯片。直觉会让人去优化绘图算法、减少浮点运算，但真正卡住帧率的，是那条把像素从内存搬到屏幕的 SPI 总线。9341 的显存写入本质是串行搬运，一帧 320×240×16bit 就是 1.2Mbit 的数据量，靠 CPU 逐字节写寄存器，光总线占用就能把帧率压到个位数。所谓「SPI 高速 9341 刷屏」，核心不是让 CPU 算得更快，而是让 DMA 接管搬运、让 SPI 时钟逼近器件上限、让 CPU 在搬运期间去干别的事。这套机制搞懂了，你才知道为什么同样是 F767，有人刷屏 60 帧，有人只有 20 帧。
2. SPI 与 DMA 的协作机制：为什么搬运能脱离 CPU
2.1 9341 的写时序决定了瓶颈在哪
9341 这类控制器接收像素数据的方式很朴素：拉低片选、发命令 0x2C 进入显存写入模式，然后连续送 16bit 颜色值，每个字节在 SCLK 上升沿被采样。也就是说，屏幕本身不关心数据从哪来，它只认 SCLK 上的节拍。CPU 写 SPI 数据寄存器（DR）时，硬件把数据挪进移位寄存器再逐位打出去，CPU 必须等 TXE 标志再写下一个字节。这个「写一个、等一个」的循环，就是纯 CPU 刷屏慢的根源——总线速度再高，CPU 也被标志位轮询拖住了。
DMA 的价值在于把这个循环从 CPU 手里拿走。SPI 外设的 TXE 或 TXDMA 请求可以直连 DMA 控制器，DMA 每搬一个字节到 DR，硬件自动清请求、继续搬下一个，CPU 完全不参与。F767 的 DMA 控制器支持外设到存储器、存储器到外设的双向传输，SPI 发送走的是存储器到外设方向。理解这一点很关键：DMA 不是「加速 SPI」，SPI 时钟频率没变，它只是把 CPU 从搬运工的角色里解放出来，让总线在 DMA 驱动下满速跑，不再有空等标志的间隙。
2.2 数据流：从帧缓冲到移位寄存器的完整链路
一条完整的刷屏链路是这样的：帧缓冲区在 SRAM 或 SDRAM 里，DMA 通道配置源地址为缓冲区、目的地址为 SPI 的 DR 寄存器，传输宽度按字节或半字设置，传输数量等于像素字节数。使能 DMA 后，SPI 每发完一个数据就向 DMA 发请求，DMA 从源地址取下一个数据写进 DR。整个过程里 CPU 只在开头配置一次，结尾等一个传输完成中断。
这里有个容易被忽略的细节：SPI 的 DMA 请求是「发送缓冲空」触发的，也就是说 DMA 写 DR 的速度必须跟得上 SPI 移位寄存器的消耗速度。如果 DMA 通道优先级太低、被其他外设抢占，就会出现 SPI 等数据、SCLK 出现间隙的情况，屏幕上看不出错，但实际吞吐掉了。常见的实现思路是把 SPI 的 DMA 通道设成较高优先级，并确保源缓冲区所在的总线（比如 AXI 或 AHB）带宽足够，别让 DMA 在总线上排长队。
2.3 双缓冲与传输完成中断的配合
单缓冲刷屏有个隐患：DMA 还在搬上一帧，CPU 已经往同一块缓冲区写下一帧，画面就会撕裂。解决办法是双缓冲——准备两块帧缓冲，DMA 搬 A 块时 CPU 渲染 B 块，传输完成中断里切换指针。F767 的 DMA 支持传输完成中断，中断里做指针交换和下一帧启动，CPU 和 DMA 就形成了流水线。
/* 双缓冲切换的简化逻辑，传输完成中断里调用 */ volatile uint8_t buf_index = 0; uint16_t *frame_buf[2]; /* 两块帧缓冲，由初始化阶段分配 */ void DMA_TransferComplete_IRQHandler(void) { /* 清传输完成标志，具体寄存器名依 DMA 控制器而定 */ DMA_ClearFlag(DMA_STREAM, DMA_FLAG_TCIF); /* 当前这块搬完了，切到另一块准备下一帧 */ buf_index ^= 1; /* 若还有待刷新的帧，立即启动下一次 DMA 搬运 */ if (frame_pending) { LCD_SetWindow(0, 0, 319, 239); /* 重设显存写入窗口 */ LCD_WriteCmd(0x2C); /* 进入显存写入模式 */ DMA_Start(frame_buf[buf_index], LCD_PIXEL_BYTES); frame_pending = 0; } }这段代码的关键不在语法，而在时序：LCD_SetWindow和0x2C命令必须在 DMA 启动前用 CPU 发完，因为命令阶段数据量小、且需要严格顺序，交给 DMA 反而增加复杂度。DMA 只负责像素洪流，命令和窗口设置仍走 CPU 直写。frame_pending是个软件标志，渲染完成时置位，中断里消费它，避免在中断里做重活。参数LCD_PIXEL_BYTES是一帧的字节数，320×240×2 等于 153600，这个值直接决定单次 DMA 传输的长度，超过 DMA 单次传输上限时要拆成多次。
3. SPI 时钟与 9341 时序的边界：高速到底能多高
3.1 9341 的写周期上限不是玄学
9341 数据手册给出的写周期最小时间约为 100ns 量级，换算成 SPI 时钟，理论上限在 10MHz 附近，但实际工程里很多人跑到 40MHz 甚至更高也能点亮。这不是手册写错了，而是写周期约束主要针对连续写同一类寄存器的场景，显存写入（0x2C 之后）的像素流对时序容忍度更高。真正限制速度的是信号完整性和 9341 内部显存写入的建立保持时间。常见的血泪经验是：杜邦线飞线接屏，20MHz 就开始花屏；换成短排线、加地线回流，40MHz 稳定。所以「高速」不是一个固定数字，而是你的布线和屏幕模组共同决定的边界。
F767 的 SPI 时钟来自 APB 总线分频，配置时要算清楚分频系数。比如 APB2 跑 108MHz，SPI 分频 2 得到 54MHz，分频 4 得到 27MHz。分频寄存器写错一位，实际时钟可能差一倍，调试时用逻辑分析仪抓 SCLK 是最直接的办法，别靠猜。
3.2 时钟极性与相位必须和屏幕对齐
SPI 的 CPOL 和 CPHA 决定数据在哪个边沿采样。9341 通常工作在模式 0（CPOL=0，CPHA=0）或模式 3，具体看模组。配错模式的表现很典型：屏幕能亮但颜色错乱、或者干脆白屏。这不是 DMA 的问题，是采样边沿错了，数据位整体偏移。排查时先把 SPI 降到低速、关掉 DMA，用 CPU 单步写几个像素验证模式，确认颜色正确后再提速、再开 DMA。这个顺序能帮你把「时序问题」和「DMA 问题」分开，不然两个变量搅在一起，翻车了都不知道从哪查。
3.3 DMA 传输宽度与字节序的坑
9341 接收的是 16bit 颜色，但 SPI 数据寄存器在 8bit 模式下按字节发送。用 DMA 时如果传输宽度配成半字（16bit），DMA 会把一个 16bit 值拆成两个字节依次写 DR，字节序取决于 SPI 的 MSB/LSB 配置和 DMA 的端序处理。配错的表现是颜色红蓝互换或者高低字节颠倒。稳妥的做法是 DMA 传输宽度设成字节，源缓冲区按字节数组组织，颜色值在写入缓冲区时就按屏幕期望的字节序排好。这样 DMA 只管搬字节，不涉及任何端序转换，逻辑最干净。
4. 帧缓冲布局与显存窗口：搬运效率的隐藏变量
4.1 窗口设置决定了能不能连续搬
9341 的显存写入是带窗口的：先发 0x2A 设列地址范围、0x2B 设行地址范围，再发 0x2C 开始写。窗口设成整屏，之后送的数据就按行优先连续填满整个显存，DMA 可以一口气搬完，不需要中途干预。如果窗口设小了或者每次只刷局部区域，DMA 传输就被切成很多段，每段之间都要 CPU 重新设窗口、发命令，流水线断掉，效率大打折扣。所以整屏刷新时窗口一次设满，局部刷新时才按区域切分，这是布局层面的取舍。
4.2 帧缓冲放在哪块内存影响很大
F767 有内部 SRAM、也有外部 SDRAM 接口。帧缓冲放内部 SRAM，DMA 访问延迟低，但 320×240×2 约 150KB，双缓冲就是 300KB，内部 SRAM 未必够。放外部 SDRAM，容量不是问题，但 SDRAM 的访问延迟和刷新开销会让 DMA 搬运出现等待，尤其 SDRAM 控制器和 DMA 抢总线时。常见的做法是单缓冲放 SDRAM、配合局部刷新减少搬运量，或者用内部 SRAM 做小块行缓冲、DMA 按行搬运。这里没有标准答案，取决于你的内存预算和刷新策略，但一定要意识到：DMA 的吞吐不只由 SPI 时钟决定，源端内存的带宽同样是瓶颈。
4.3 局部刷新与脏矩形
整屏 60 帧对 SPI 带宽要求很高，很多场景其实只需要局部更新。维护一个脏矩形列表，只把变化的区域通过窗口设置加 DMA 搬过去，能大幅降低总线占用。实现上要注意脏矩形合并——多个小区域重叠或相邻时合并成一个大矩形，减少窗口切换次数。这个策略的代价是 CPU 要维护区域信息，但换来的是 DMA 传输段数减少、命令开销摊薄。对于 UI 类应用，局部刷新往往比盲目堆 SPI 时钟更有效。
5. 避坑与排查：那些让刷屏翻车的细节
5.1 现象：开了 DMA 反而比 CPU 刷得慢
原因通常是 DMA 通道优先级配置过低，或者 DMA 请求映射到了错误的 SPI 实例。F767 的 DMA 请求靠 DMAMUX 路由，SPI1_TX 和 SPI2_TX 对应的请求号不同，配错请求号 DMA 根本不会触发，程序卡在等传输完成。解决方法是查参考手册的 DMA 请求映射表，确认请求号，并把通道优先级提到 high 以上，同时检查是否有其他高优先级外设长期占用总线。
5.2 现象：刷几帧后画面卡死或花屏
多半是 DMA 传输完成中断里没有正确清标志，导致中断反复触发、或者下一次传输没启动。另一个常见原因是双缓冲指针在中断和主循环之间竞争，没加保护。解决方法是中断里只做标志清除和指针切换这类短操作，用 volatile 修饰共享变量，必要时关中断保护临界区。花屏则要怀疑源缓冲区在 DMA 搬运期间被改写，确认双缓冲确实隔离了读写。
5.3 现象：颜色整体偏色或红蓝互换
这是字节序或 SPI 模式问题，不是 DMA 的锅。先确认 SPI 的 CPOL/CPHA 与屏幕匹配，再检查 DMA 传输宽度和源数据的字节排列。RGB565 的高字节是红绿、低字节是绿蓝，如果高低字节颠倒，红色会跑到蓝色通道。解决方法是统一在缓冲区写入阶段按屏幕期望顺序排字节，DMA 只做字节搬运，不在传输路径上做任何转换。
5.4 现象：提高 SPI 时钟后偶发数据错位
信号完整性问题。飞线长、没有地线回流、屏幕模组排线质量差，都会在高速下出现采样错误。表现是偶发、不固定位置的花点。解决方法是缩短走线、增加地线、必要时在 SCLK 上串小电阻抑制振铃，然后把时钟降一档验证。别迷信「别人能跑 50MHz 我也能」，布线和模组差异决定了每块板子的实际上限。
5.5 现象：DMA 传输长度超过限制导致后半屏不刷新
DMA 单次传输的计数器有位数上限，一帧字节数超过上限时，超出的部分不会搬。解决方法是把一帧拆成多次 DMA 传输，每次传输完成中断里启动下一段，或者用 DMA 的链表模式。拆分时注意每段之间不需要重设窗口，因为显存写入是连续的，只要 0x2C 之后数据流不断，地址会自动递增。
6. 设计取舍：高速刷屏的本质是让对的单元干对的活
把整件事拆开看，高速刷屏的取舍集中在三个地方。第一是 CPU 与 DMA 的分工边界：命令、窗口设置这类带严格顺序的小数据走 CPU，像素洪流走 DMA，边界划清了，两边都不互相拖累。第二是时钟与可靠性的平衡：SPI 时钟不是越高越好，它受布线和模组约束，找到你板子上的稳定上限比追求纸面数字更有意义。第三是整屏与局部的策略选择：整屏刷新简单但吃带宽，局部刷新省带宽但要维护脏矩形，选哪个取决于你的应用是视频流还是 UI 交互。
| 取舍点 | 偏性能的选择 | 偏稳妥的选择 | 适用场景 |
|---|---|---|---|
| 搬运方式 | DMA 全接管像素 | CPU 写命令 + DMA 写像素 | 大多数刷屏场景 |
| SPI 时钟 | 逼近模组上限 | 留一档余量 | 量产 vs 调试 |
| 缓冲策略 | 双缓冲防撕裂 | 单缓冲省内存 | 动画 vs 静态界面 |
| 刷新范围 | 整屏连续搬 | 脏矩形局部刷 | 视频 vs UI |
验证这套机制是否真的生效，最直接的办法是测单帧搬运时间：用定时器在 DMA 启动和完成中断之间打点，算出实际吞吐，再和理论值（像素字节数除以 SPI 时钟）对比。差距大就说明有等待或断流，顺着 DMA 优先级、内存带宽、窗口设置逐项排查。我自己的习惯是每次改 SPI 分频或换屏幕模组，都先用逻辑分析仪抓一段 SCLK 和片选，确认没有间隙再上整屏测试，这个动作帮我省过好几次「以为是代码问题、其实是硬件边界」的冤枉路。希望帮到你。
本文还有配套的精品资源，点击获取
