如何用几KB内存流畅驱动ST7789彩屏？STM32帧缓冲优化实战
你有没有遇到过这样的尴尬：想在STM32上加个彩色屏幕，结果发现光是一帧RGB565图像就要112.5KB——比某些芯片的总RAM还大？这正是我们在开发智能手环、工业HMI或IoT面板时最常踩的坑。
而主角ST7789，这块如今几乎统治了240×240圆形/方形彩屏市场的驱动IC，恰恰就站在这个矛盾的中心。它性能不错、价格便宜、接口灵活，但和资源有限的MCU搭配时，如何让它“吃得少、跑得快”，就成了关键问题。
别急着外挂PSRAM或者换高端芯片。本文要讲的，是一套不依赖全帧缓存的轻量级刷新策略，教你用不到10KB内存，照样实现顺滑的UI动画与区域更新。
为什么传统方案走不通？
先算一笔账：一块240×240分辨率的TFT屏，每个像素用RGB565格式存储（即2字节），一帧就是：
240 × 240 × 2 = 115,200 字节 ≈ 112.5 KB对于STM32F103C8T6（20KB RAM）或是G070RB（32KB RAM）这类常见型号，这意味着你连一个完整的帧缓冲都放不下。更别说双缓冲翻页了——那得225KB以上！
可如果我们放弃“必须有完整画面副本”的执念呢？
好消息是：ST7789本身自带GRAM显存，所有像素数据都存在它自己内部。我们MCU的任务，并不是维持整幅画，而是按需送图进去。这就为内存优化打开了突破口。
ST7789能做什么？别把它当“ dumb display”
很多人把ST7789当成一个被动接收数据的“哑巴设备”，其实不然。它的硬件设计本身就支持高效局部更新，关键在于你会不会用。
核心能力一览
| 特性 | 实际意义 |
|---|---|
支持CASET/RASET地址窗口设置 | 只刷某一块区域，不用动全屏 |
| 内置DC-DC升压电路 | 省去外部电源模块，简化BOM |
| 软件复位指令（0x01） | 减少硬件引脚依赖 |
| 多种扫描方向控制寄存器 | 屏幕旋转无需重绘，直接改配置 |
| 支持SPI最高15MHz时钟 | 在合理布线下可达~2MB/s传输速率 |
尤其是那个地址窗口机制，是我们做帧管理优化的核心武器。
比如你想只刷新屏幕上半部分的一个按钮状态，完全可以这样做：
1. 发送CASET设置列范围为[50, 90]
2. 发送RASET设置行范围为[60, 80]
3. 发0x2C开始写数据
4. 后续发进去的数据自动填入指定矩形区
整个过程不需要碰其他区域，也不会清空已有内容。
这就像你在纸上画画，不是每次都要重新涂满整张纸，而是拿支笔精准地改几个字。
真正实用的帧缓冲策略：从“全存”到“按需生成”
既然不能全存，那就换个思路：不提前缓存图像，而在需要刷新时动态生成像素流。
根据系统资源和应用需求，常见的几种策略如下：
1.无缓冲直写模式（Direct Write）
- 内存占用：极低（<1KB）
- 适用场景：静态界面、低频更新
- 原理：每次刷新都实时调用绘图函数，边画边传
- 缺点：重复计算，CPU负载高
适合只显示时间、温度等简单信息的小工具。
2.行缓冲 + DMA 传输（Recommended）
这才是大多数项目的黄金选择。
假设你的屏幕宽240像素，RGB565格式下每行占480字节。如果分配一个“行缓冲区”：
uint8_t line_buffer[240 * 2]; // 一行像素，仅480字节然后逐行填充并发送：
for (int y = y_start; y <= y_end; y++) { render_line_to_buffer(y); // 把第y行渲染进buffer st7789_set_window(x_start, y, x_end, y); st7789_send_dma(line_buffer, w * 2); // 使用DMA异步发送 }这样只需要几百到几千字节内存，就能完成任意矩形区域的更新。
更重要的是：DMA一启动，CPU就可以去干别的事了——采集传感器、处理通信协议、响应按键……真正实现并发。
3.Tile分块缓存（高级玩法）
将屏幕划分为若干瓦片（如80×60的小块），只缓存最近修改过的tile。配合脏矩形合并算法，可以进一步减少冗余绘制。
不过实现复杂度较高，一般用于LVGL等图形库底层优化，不适合裸机小项目。
4.双缓冲乒乓机制（外扩SRAM才考虑）
如果你用了带FSMC/FMC接口的STM32（如F4系列），并且外接了32MB SDRAM，那当然可以搞真·双缓冲。但成本和功耗也上去了，不在本文讨论范围内。
关键代码实战：基于HAL库的非阻塞刷新
下面这段代码，展示了如何结合窗口设置 + 行缓冲 + DMA传输，实现高效的区域刷新。
头文件定义
// st7789_fb.h #ifndef ST7789_FB_H #define ST7789_FB_H #include "stm32f4xx_hal.h" #include <stdint.h> #define FB_WIDTH 240 #define FB_HEIGHT 240 // 单行缓冲（RGB565） extern uint8_t line_buffer[FB_WIDTH * 2]; void st7789_init(void); void st7789_set_window(uint16_t xs, uint16_t ys, uint16_t xe, uint16_t ye); void st7789_update_area(uint16_t x, uint16_t y, uint16_t w, uint16_t h); void draw_line_to_buffer(uint16_t row); // 用户自定义渲染函数 #endif驱动实现（重点看DMA）
// st7789_fb.c #include "st7789_fb.h" uint8_t line_buffer[FB_WIDTH * 2]; extern SPI_HandleTypeDef hspi2; // 假设使用SPI2 static void cs_select() { HAL_GPIO_WritePin(CS_GPIO_Port, CS_Pin, GPIO_PIN_RESET); } static void cs_deselect() { HAL_GPIO_WritePin(CS_GPIO_Port, CS_Pin, GPIO_PIN_SET); } void st7789_set_window(uint16_t xs, uint16_t ys, uint16_t xe, uint16_t ye) { uint8_t cmd; uint8_t data[4]; cs_select(); // 设置列地址：CASET (0x2A) cmd = 0x2A; HAL_SPI_Transmit(&hspi2, &cmd, 1, HAL_MAX_DELAY); data[0] = xs >> 8; data[1] = xs & 0xFF; data[2] = xe >> 8; data[3] = xe & 0xFF; HAL_SPI_Transmit(&hspi2, data, 4, HAL_MAX_DELAY); // 设置行地址：RASET (0x2B) cmd = 0x2B; HAL_SPI_Transmit(&hspi2, &cmd, 1, HAL_MAX_DELAY); data[0] = ys >> 8; data[1] = ys & 0xFF; data[2] = ye >> 8; data[3] = ye & 0xFF; HAL_SPI_Transmit(&hspi2, data, 4, HAL_MAX_DELAY); cs_deselect(); } void st7789_write_data_start(void) { uint8_t cmd = 0x2C; cs_select(); HAL_SPI_Transmit(&hspi2, &cmd, 1, HAL_MAX_DELAY); } // 区域刷新函数（非阻塞版本） void st7789_update_area(uint16_t x, uint16_t y, uint16_t w, uint16_t h) { uint16_t xe = x + w - 1; uint16_t ye = y + h - 1; st7789_set_window(x, y, xe, ye); st7789_write_data_start(); for (uint16_t row = y; row <= ye; row++) { draw_line_to_buffer(row); // 由上层提供渲染逻辑 // 使用DMA发送（非阻塞） HAL_SPI_Transmit_DMA(&hspi2, line_buffer, w * 2); // 等待本次DMA完成（也可改为中断回调处理） while (HAL_SPI_GetState(&hspi2) != HAL_SPI_STATE_READY) { // 可在此插入低优先级任务调度 } } cs_deselect(); }⚠️ 注意：这里的
while(wait)是为了演示清晰。实际项目中应使用DMA传输完成中断来触发下一行或通知刷新结束，避免阻塞。
性能实测：到底有多快？
以STM32F407ZGT6 + ST7789为例，在不同SPI频率下的理论吞吐量：
| SPI时钟 | 数据速率 | 刷新240×240全屏耗时 |
|---|---|---|
| 8 MHz | ~800 KB/s | ~144 ms (~7fps) |
| 10 MHz | ~1.0 MB/s | ~115 ms (~8.7fps) |
| 12 MHz | ~1.2 MB/s | ~96 ms (~10.4fps) |
虽然达不到手机级别的流畅度，但对于菜单切换、进度条、图表更新等场景已经足够。
而且别忘了：我们很少需要“全屏刷新”。一次按钮按下可能只影响几十×几十像素的区域，耗时仅几毫秒，用户完全感知不到延迟。
工程技巧：避开这些坑，让你的屏幕更稳
我在多个量产项目中总结出以下几点经验，能显著提升稳定性和用户体验：
✅ 必做项清单
电源去耦一定要到位
在ST7789的VDD引脚旁放置0.1μF陶瓷电容，最好再并联一个10μF钽电容。电压波动会导致花屏甚至死机。背光独立控制
用MOSFET或专用驱动IC控制LED背光，配合PWM调光。夜间自动降亮度，节能又护眼。严格遵守初始化时序
特别是复位后要延时至少120ms，否则可能出现白屏或乱码。Datasheet里的 delay 不是开玩笑的。启用看门狗防锁死
如果SPI总线卡住导致屏幕黑屏，WDT能帮你重启恢复，避免设备变砖。保留SWD调试口
图形问题最难查。留个调试接口，方便在线观察变量、断点跟踪刷新流程。
🔧 提升体验的小技巧
合并脏区域
当多个控件同时变化时，把它们的矩形框合并成一个更大的更新区域，减少命令开销。延迟刷新机制
对连续快速变化的值（如滚动数字），不要每次都刷屏，而是定时批量更新，降低平均功耗。利用寄存器旋转屏幕
想要竖屏显示？别用软件转置图像（太费CPU），直接改MADCTL寄存器即可。
实际应用场景举例
场景1：智能手表界面
- 分辨率：240×240 圆形屏
- MCU：STM32L432KC（64KB Flash / 16KB RAM）
- 更新内容：时间、步数、电量图标
- 方案：行缓冲 + 定时局部刷新
- 效果：每秒仅刷新时间区域（约40×30像素），其余静态内容不动，平均功耗<5mA
场景2：POS终端菜单
- 分辨率：240×320
- MCU：STM32F401RE
- UI框架：LVGL
- 方案：LVGL自带脏矩形管理，配合本驱动的DMA刷新
- 效果：触摸响应灵敏，列表滑动无撕裂
结语：小资源也能做出好交互
嵌入式图形开发的魅力，就在于在限制中创造可能。
ST7789 + STM32 的组合，看似受限于内存，实则通过合理的帧缓冲管理策略，完全可以胜任大多数中低端显示需求。关键是转变思维——不再追求“完整帧缓存”，而是构建“按需刷新”的流水线。
记住这几个关键词：
-局部更新
-地址窗口
-行缓冲
-DMA异步传输
-脏区域合并
掌握它们，你就能用最少的资源，做出最流畅的交互体验。
如果你正在做一个带屏的项目，不妨试试这套方案。哪怕只有几KB可用内存，也能点亮一块绚丽的彩屏。
你用过哪些巧妙的帧优化方法？欢迎在评论区分享你的实战经验！
