显示驱动与帧缓冲：从像素到屏幕的最后一公里
做嵌入式GUI，说白了就是跟像素打交道。你写的每一个按钮、每一帧动画，最终都要变成屏幕上的一串亮光。这中间发生了什么？今天我们就来拆开看看。
FrameBuffer：你的画板在哪里？
FrameBuffer，中文叫帧缓冲。你可以把它想象成一块内存区域，里面存着屏幕上每个像素的颜色值。CPU往这块内存里写数据，显示控制器就自动把这些数据刷到屏幕上。
我刚开始做GUI时，总觉得FrameBuffer就是个数组。后来踩了坑才明白——它的组织方式直接决定了你的渲染效率。
常见的像素格式有这么几种：
| 格式 | 每像素位数 | 颜色深度 | 典型场景 |
|---|---|---|---|
| RGB565 | 16位 | 65K色 | 小屏、低端MCU |
| RGB888 | 24位 | 16.7M色 | 中高端屏、HMI |
| ARGB8888 | 32位 | 16.7M色+Alpha | 带透明效果的UI |
举个例子，一块320×240的屏幕，用RGB565格式，FrameBuffer大小就是：
320 × 240 × 2 = 153,600 字节 ≈ 150KB换成ARGB8888呢？直接翻倍到300KB。嗯，这里要注意——MCU的RAM通常很金贵，选格式时得精打细算。
双缓冲机制：告别撕裂和闪烁
单缓冲有个致命问题——你正在往FrameBuffer里写数据时，屏幕控制器也在读它。结果就是：上半屏显示新画面，下半屏还是旧的。这就是撕裂(tearing)。
双缓冲怎么解决？很简单：准备两个缓冲区。
- 前端缓冲(Front Buffer)：当前正在显示的内容
- 后端缓冲(Back Buffer)：你正在绘制的内容
绘制完成后，交换指针。屏幕控制器从新的前端缓冲读取，整个过程无缝切换。
我曾经在一个工业HMI项目里，客户投诉屏幕闪烁。查了半天，发现是单缓冲+直接写显存导致的。改成双缓冲后，问题立刻消失。你想想看，用户盯着闪烁的屏幕操作，体验能好吗？
核心要点： 双缓冲不是"画两遍"，而是"画在后台，前台只负责显示"。交换动作要快，最好在垂直消隐期(VBlank)内完成。
DMA加速传输：让CPU喘口气
双缓冲解决了撕裂，但还有个问题——把后端缓冲的数据拷贝到前端缓冲，或者直接刷到LCD接口，这个操作很费CPU。
假设你有一块480×272的屏幕，RGB565格式，每次刷新需要拷贝：
480 × 272 × 2 = 261,120 字节 ≈ 255KB用CPU逐字节拷贝？以72MHz的Cortex-M3为例，大概要花3-5ms。这期间CPU啥也干不了，动画帧率直接掉到200fps以下。
DMA(Direct Memory Access)就是干这个的。它是个硬件搬运工，你告诉它"从哪搬到哪、搬多少"，它就自己干完了，搬完再通知你。
我建议的流程是这样的：
- CPU在后端缓冲里绘制UI
- 配置DMA：源地址=后端缓冲，目标地址=前端缓冲/LCD控制器，长度=255KB
- 启动DMA传输，CPU立刻去干别的事（比如处理触摸事件）
- DMA传输完成，触发中断，通知CPU可以开始画下一帧
屏幕刷新流程：一帧画面的完整旅程
把上面几个知识点串起来，一帧画面的完整流程是这样的：
你看，从应用层到屏幕显示，中间经过了四个关键环节。每个环节都有它的瓶颈：
- 绘制阶段：CPU性能决定你能画多复杂的UI
- 传输阶段：DMA带宽决定数据搬运速度
- 扫描阶段：屏幕刷新率是硬上限，60Hz就是16.7ms一帧
实战建议： 我习惯在项目初期就画一张这样的流程图，标出每个环节的预估耗时。这样后期优化时，一眼就能看出瓶颈在哪——是CPU画太慢，还是DMA带宽不够，还是屏幕刷新率拖了后腿。
总结一下
FrameBuffer是你的画板，双缓冲是防撕裂的利器，DMA是解放CPU的搬运工。这三样东西配合好了，你的GUI动画才能流畅跑起来。