STM32+SSD1306：从零搭建可复用的OLED显示子系统

说句实在话，我一开始做OLED显示的时候，脑子里根本没有“子系统”这个概念。当时觉得这就是一个驱动文件的事：把初始化序列抄过来，画点函数抄过来，屏幕上能出字就算完事。直到后来项目里要接菜单、要调亮度、要在低功耗和流畅刷新之间来回折腾，我才发现，一个屏幕上要承载的东西远比“点亮”两个字复杂得多。

这篇博客我想聊聊怎么从零搭一个真正能用的微型OLED显示子系统。以STM32和0.96寸SSD1306为例，从硬件接口、HAL库驱动、渲染层到上层应用接口，每一层该怎么拆、怎么设计、怎么避免翻车。适合刚接触单片机显示的同学，也适合想把零散OLED代码整理成可复用模块的工程师。核心思路一句话：先把屏幕当作一个外设子系统去设计，而不是把屏幕当作一堆寄存器调用。

1. 先想清楚再画屏：OLED子系统到底“子”在哪

1.1 驱动文件不是子系统

如果你去GitHub随便搜一个OLED驱动，你大概率会看到这种组织方式：一个oled.c，里面从上到下堆着初始化、清屏、显示字符串、画点、画线、画圆，甚至还有几个汉字索引表。代码能跑，但这不叫子系统，这叫“一个很长很长的C文件”。

子系统的核心特征是边界。它要对外暴露稳定的接口，对内屏蔽硬件的细节。你上层代码需要做的事情只是：“把这张1KB的图片画到屏幕的(10, 20)位置”，而不是“把列地址设为10，把页地址设为2，然后发一串0x40开头的数据”。当你的主逻辑不用关心这些底层细节时，这个显示系统才真正独立出来了。

我见过不少项目，前期图省事直接在主循环里调清屏函数和显示函数，结果做到后面菜单逻辑越来越复杂，屏幕刷新和业务逻辑互相干扰，改个字体大小要翻半天代码。真到那时候再回头做抽象，成本比一开始就分层高得多。

1.2 我把这个子系统划成了四层

按照我自己习惯的做法，一个微型OLED子系统至少要有四层：

• 硬件抽象层：负责I2C或SPI的读写，封装成oled_write_cmd、oled_write_data这样的底层函数。上层完全不感知用的是STM32的硬件I2C还是GPIO模拟的软件I2C。
• 驱动层：负责初始化序列、显存缓冲、刷新、清屏、开关显示。这一层跟具体的屏幕控制器打交道。
• 渲染层：负责画点、画线、画矩形、显示字符、显示图片。这层只操作显存缓冲区，不直接操作硬件。
• 应用接口层：给业务代码提供高层次的接口，比如ui_draw_menu()、ui_show_value()、ui_update_progress()。业务代码根本不需要知道屏幕是OLED还是LCD。

四层划分听着可能有点“软件工程”，但在单片机上实现起来并不重。代码量不会多多少，结构却清晰得多。后面移植到别的屏幕，或者从单色屏换成灰度屏，只需要换驱动层，渲染层改动量很小。

1.3 小系统里做抽象，会不会过度设计？

我知道肯定会有人问：一个128x64的单色屏，RAM才几十KB的MCU，搞这么分层是不是小题大做？我的答案是：抽象要服务于收益。

如果这个OLED屏只是上电显示一行“Hello World”，那确实不需要分层，直接拿现成驱动改就行。但如果你要在这个屏幕上做菜单、做动态仪表盘、做多语言字库切换，或者要同时接多个传感器显示数据，那分层带来的收益很快就超过那点代码量成本。

从我的实践来看，真正重要的不是多复杂的设计模式，而是定义好接口之后不要随便破坏它。比如驱动层跟渲染层之间定好oled_fill_buffer()这个函数，那渲染层就永远通过它把缓冲区同步到屏幕，不做越层操作。这个纪律比任何架构理论都有用。

2. 面板与总线：SSD1306里藏着的那些讲究

2.1 显存、页与行：128x64为什么是1024字节

先搞明白单色OLED的存储结构。SSD1306内部有一块被称为GDDRAM的显存，128x64个像素点，每个点对应1 bit，所以总大小是128 * 64 / 8 = 1024字节。关键是你不能像写LCD那样按像素横着写，它是按“页”来组织的。

所谓“页”，就是把纵向的64行分成8页，每页8行。0到7行是Page0，8到15行是Page1，以此类推。每一页里有128个字节，一个字节的8个bit正好对应这一页里的8个像素点。也就是说，屏幕在SSD1306眼里不是横着的坐标纸，而是一块8页x128列的显存块。画点的时候，要把y坐标先换算到页号，再用位运算找到对应bit，这就是为什么几乎每个OLED驱动里都会有一个framebuffer[page * 128 + x]的数组。

这个结构直接决定了刷新策略。如果你只改了一个像素点，按最省事的方式全屏刷新，那就要把1024字节全部重发到屏幕上。如果你改了一个8x8的字符，其实只需要刷新那一页的8个字节。理解了这个页结构，后面优化刷新速度才有基础。

2.2 I2C和SPI：带宽、引脚和可靠性取舍

0.96寸OLED屏常见的接口有I2C和SPI两种，市面上还有4针I2C版本、6针SPI版本和7针带复位版本。选哪种，取决于你对刷新速度和引脚余量的需求。

I2C模式只需要SCL、SDA两根线，加上电源一共4根线，接线非常省。但I2C常见速率400kHz，发一个字节还得带一个控制字节，全屏刷新1024字节差不多要20毫秒以上。如果你只是显示静态数据，完全没问题；如果要做动画或者动态波形，这个速度会让你明显感觉到闪烁和延迟。

SPI模式要用SCL、MOSI、CS、DC四根线，有的还带RES。好处是速度可以推到几十MHz级别，同样刷新一屏数据时间可以缩短到十分之一甚至更低。代价就是多占两个IO，而且软件逻辑比I2C稍微复杂一点，因为要额外控制数据/命令选择脚（DC）。

我自己的选型经验是这样的：日常信息显示、菜单交互，I2C够用；要做绘图、波形、动画，优先上SPI。别指望在I2C上靠优化把刷新速度翻好几倍，那纯粹是自己给自己挖坑。

2.3 0.96寸和1.3寸之间的兼容差异

很多人会拿0.96寸128x64的驱动去点1.3寸的屏，结果发现底部或者边缘显示不正常。原因很简单：0.96寸的控制器通常是SSD1306，1.3寸的屏幕很多用的是SH1106。

SH1106的内部显存其实是132x64，但可显示的窗口只有128x64。有些SH1106在初始化之后，列地址偏移需要额外设置，如果不做偏移修正，显示内容可能整体往右偏几个像素。另外这两个控制器的部分命令虽然兼容，但初始化序列里的某些寄存器设置不能用同一个序列直接跑。

所以拿到一个新屏幕，第一件事是确认控制器型号，然后对照它的数据手册核对初始化序列，不要上来就用通用的初始化代码。这个排查成本比后续在渲染层反复调坐标小得多。

3. 驱动层实现：从初始化序列到显存搬运

3.1 HAL库底层的I2C读写封装

STM32上用HAL库操作OLED其实不复杂。SSD1306的I2C通信有一个基本约定：在发送命令或数据之前，要先发一个控制字节。控制字节为0x00时，后面的字节按命令处理；控制字节为0x40时，后面的字节按显存数据处理。

先封装两个基础操作：

void oled_write_cmd(uint8_t cmd) { uint8_t buf[2]; buf[0] = 0x00; buf[1] = cmd; HAL_I2C_Master_Transmit(&hi2c1, OLED_I2C_ADDR, buf, 2, 100); } void oled_write_data(uint8_t *data, uint16_t len) { uint8_t prefix = 0x40; HAL_I2C_Master_Transmit(&hi2c1, OLED_I2C_ADDR, &prefix, 1, 100); HAL_I2C_Master_Transmit(&hi2c1, OLED_I2C_ADDR, data, len, 100); }

要注意，OLED_I2C_ADDR是左移一位后的地址，0x3C对应左移后是0x78，0x3D对应0x7A。很多驱动里直接写死0x3C或0x78，都是同一个硬件地址的两种写法，只是有的HAL函数要求7位地址，有的要求8位地址，坑就出在这里。

上面这个oled_write_data写法有点浪费，因为每次传数据都发了两次I2C起始条件。更高效的做法是把控制字节和显存数据拼到一个字节数组里连续发。后面在刷屏函数里我会用这种方式，一次传输搞定。

3.2 初始化顺序为什么不能乱改

SSD1306的初始化序列一般有几十条命令，看起来都像天书，实际上它是严格按照控制器内部状态机设计的：先关闭显示、设置时钟分频、设置复用比、设置显示偏移、设置起始行、设置地址模式、设置对比度，最后才打开显示。

这些命令之间是有依赖关系的。比如你先把显示打开，再去改对比度，屏幕可能会闪一下；你先设置了列地址范围，再去改显存起始地址，那数据写入的位置可能就乱了。所以我的建议是：初始化序列以原厂或成熟驱动为准，不要自己“精简”掉任何一条看起来没用的命令。有些命令在0.96寸上确实不生效，但在同控制器的其他型号上可能就变得很关键。

实际的初始化流程在HAL库环境下是这样调用的：

void oled_init(void) { GPIO_InitTypeDef gpio = {0}; __HAL_RCC_GPIOC_CLK_ENABLE(); /* 如果RES引脚单独接了GPIO，需要先拉低再拉高 */ HAL_GPIO_WritePin(GPIOC, GPIO_PIN_0, GPIO_PIN_RESET); HAL_Delay(10); HAL_GPIO_WritePin(GPIOC, GPIO_PIN_0, GPIO_PIN_SET); HAL_Delay(10); oled_write_cmd(0xAE); /* 关闭显示 */ oled_write_cmd(0xD5); /* 设置时钟分频因子 */ oled_write_cmd(0x80); oled_write_cmd(0xA8); /* 设置多路复用比 */ oled_write_cmd(0x3F); /* 64行 */ oled_write_cmd(0xD3); /* 设置显示偏移 */ oled_write_cmd(0x00); oled_write_cmd(0x40); /* 设置显示起始行 */ oled_write_cmd(0x8D); /* 电荷泵设置 */ oled_write_cmd(0x14); /* 开启电荷泵 */ oled_write_cmd(0x20); /* 设置内存寻址模式 */ oled_write_cmd(0x00); /* 水平寻址模式 */ oled_write_cmd(0xA1); /* 列地址段重映射 */ oled_write_cmd(0xC8); /* 行扫描方向重映射 */ oled_write_cmd(0xDA); /* COM引脚硬件配置 */ oled_write_cmd(0x12); oled_write_cmd(0x81); /* 设置对比度 */ oled_write_cmd(0xCF); oled_write_cmd(0xD9); /* 设置预充电周期 */ oled_write_cmd(0xF1); oled_write_cmd(0xDB); /* 设置VCOMH取消选择电平 */ oled_write_cmd(0x40); oled_write_cmd(0xA4); /* 从GDDRAM显示 */ oled_write_cmd(0xA6); /* 正常显示，不反色 */ oled_write_cmd(0xAF); /* 打开显示 */ }

调试的时候如果把某条命令删掉，屏幕可能照样亮，但显示可能偏暗、偏移或者有残影。所以初始化序列我当黑盒对待，能用就不动。

3.3 坐标到GDDRAM的映射公式

有了前面的页结构，画点的逻辑就很直白了。在STM32里维护一个镜像显存g_oled_fb[1024]，先在数组里改数据，再一次性刷到屏幕：

void oled_draw_pixel(uint8_t x, uint8_t y, uint8_t color) { if (x >= OLED_WIDTH || y >= OLED_HEIGHT) { return; } uint16_t page = y >> 3; uint8_t bit = 1 << (y & 0x07); uint16_t index = page * OLED_WIDTH + x; if (color) { g_oled_fb[index] |= bit; } else { g_oled_fb[index] &= ~bit; } }

这里y >> 3就是除以8，算出所在的页；y & 0x07取余数，算出在这个页里的第几行。整个映射关系只要把屏幕想象成8张并排放置的页就很好理解。

3.4 双缓冲与全量刷新代价

双缓冲这个词在嵌入式里听起来高大上，但在单色OLED上其实很朴素：MCU里留一份显存镜像，渲染层只往镜像里绘图，需要显示的时候把镜像整体同步到控制器。好处是渲染和显示在时间上解耦，不会出现你画了一半、屏幕刷新到一半的撕裂效果。

全量刷新的代价是带宽和时间。实测下来，在400kHz的I2C下，刷一屏1024字节大约要30毫秒左右，一秒钟只能刷30多帧，肉眼能感觉到明显的刷新过程。但SPI模式就快得多，8MHz速率下一屏只有几毫秒。

如果要压缩刷新时间，可以用“增量刷新”思路：重画菜单只更新菜单区域，重画数值只更新数值区域。但是增量刷新会带来残影和脏标记管理，代码复杂度高不少。我的建议是，先把全量刷新跑通，再去考虑增量优化。能用DMA的尽量用DMA，把HAL_I2C_Master_Transmit这种阻塞式调用放进定时器或任务里，别让刷新阻塞主循环。

4. 渲染层与应用接口：字体、图形和抗锯齿思维

4.1 中英文字模的取法与存储

单色OLED本身没有字库，所有字符都要预先取模。英文字母常见的是6x8或者8x16点阵，一个字符占用6字节或16字节存储。汉字至少要12x12、16x16，一个16x16汉字要32字节。如果不做字库管理，在Flash有限的情况下，放几百个汉字很快就吃满空间了。

取模工具有很多，常见的像PCtoLCD2002、FontCreator、点阵字模软件，核心设置是：阴码、逐行式、列行式或行列式要跟渲染函数对应上。这里最容易踩的坑就是取模时选了一种扫描方式，驱动函数却按另一种方式解析，结果字是花的或者颠倒的。

我习惯用逐列式扫描，把字模数据按16列存放，每列对应16个bit的两个字节。显示的时候读取两个字节，按位写入显存。一个字模的显示函数大概长这样：

void oled_draw_char_16x16(uint8_t x, uint8_t y, const uint8_t *ch) { for (uint8_t col = 0; col < 16; col++) { for (uint8_t row = 0; row < 16; row++) { uint8_t byte = (row < 8) ? ch[col * 2] : ch[col * 2 + 1]; if (byte & (1 << (row % 8))) { oled_draw_pixel(x + col, y + row, 1); } } } }

这种实现最直观，但效率不高，因为每个像素都调用一次oled_draw_pixel。实际项目里可以优化成把16x16字模按页写入缓冲区，一次循环填充32字节，速度快得多。不过对初学者来说，先把显示效果搞对，再优化性能，顺序不能反过来。

4.2 我的绘图API集合

一个显示子系统如果只能显示字符，很多场景是不够用的。我整理的渲染层最少要包含这些绘图函数：

• oled_draw_pixel(x, y, color)：画点，是整个几何绘图的基础
• oled_draw_line(x0, y0, x1, y1, color)：画线，用Bresenham算法
• oled_draw_rect(x, y, w, h, color)：空心矩形
• oled_fill_rect(x, y, w, h, color)：实心矩形，进度条必备
• oled_draw_circle(cx, cy, r, color)：画圆，画仪表盘会用到
• oled_draw_bitmap(x, y, w, h, *data)：图片或图标显示

这些函数的实现都不复杂，但要注意处理边界裁剪。比如要画一个20x20的图标，起点在(110, 60)，那有一部分会超出屏幕边界。如果绘图函数不做边界判断，直接写g_oled_fb[page * 128 + x]就可能越界，把缓冲区旁边的内存写坏，表现出来就是诡异的乱码和死机。我在oled_draw_pixel里加了边界判断，所有高级绘图函数最终都调用它，这是一种很简单的“接口兜底”。

4.3 小OLED上的“清晰”与字体彩边

聊到文本清晰度，很多人会联想到Windows桌面上的字体彩边问题。这其实是子像素渲染技术引起的：为了让文字边缘看起来更平滑，系统会把一个字拆解到RGB三个子像素上，在个别OLED屏幕上就会出现彩色边缘和发虚现象。解决思路通常是关掉ClearType或者改用灰度抗锯齿。

单色OLED没有RGB子像素，不存在彩色边缘的问题，但它同样有“清晰度”问题。纯黑白两色下，一个点要么亮要么不亮，曲线边缘会出现明显的锯齿。要让小屏上的文字和图形看起来更舒服，可以用半色调思路：在边缘像素上不给满亮度，而是通过控制亮暗模式形成视觉上的灰度过渡。

SSD1306有0x81命令可以设置对比度，但这只能整体调亮度，做不到局部像素的灰度渐变。所以真正的抗锯齿还是得靠抖动算法，把边缘像素打散成规则的点阵图案。不过单色屏本身分辨率只有128x64，过度抗锯齿反而会让小字糊成一团。我的实际感受是：对于8x16以下的像素字体，别搞灰度渐变，保持锐利的黑白边界，观感反而更通透。

另外MacType那种配置思路提供了另一个启发：高DPI OLED设备上，字体的渲染策略应该以清晰优先，而不是平滑优先。在嵌入式小屏上同理，笔画能对齐到像素格就直接对齐，不要为了平滑牺牲锐利度。

4.4 用一个“脏矩形”机制降低刷新压力

我前面说先做全量刷新，但真到做界面的时候，全量刷新在I2C下还是有点吃亏。一个折中的优化方案是维护“脏矩形”：记录所有发生变化的区域，刷新时只把这些区域传到屏幕。

做法也不复杂。在绘图函数里，当往缓冲区写入数据时，同时更新一个全局的矩形范围，比如dirty_min_x、dirty_max_x、dirty_min_y、dirty_max_y。刷新函数只需要把这些坐标内部的页数据发送给SSD1306。

这个方案对菜单、数值更新这类局部变化场景效果非常明显。比如一个仪表盘，一秒刷新一次数字区间，脏矩形可能只有几十个字节，刷新时间从30毫秒降到3毫秒以内。不过要注意，如果矩形区域越来越大，最终会退化成全量刷新，所以这个机制适合界面元素相对分散的场景，不适合整屏动画。

5. 子系统落地：菜单、任务调度与低功耗流程

5.1 这样组织代码，移植时不用推倒重来

具体到目录结构，我的代码一般长这样：

app/ ui/ ui_menu.c ui_dashboard.c display/ display_driver.c display_render.c display_fonts.c hal/ hal_oled_i2c.c hal_oled_spi.c

hal_oled_i2c.c里只放跟I2C读写相关的函数，比如封装HAL库的HAL_I2C_Master_Transmit；display_driver.c放初始化、刷新、开关显示这些跟SSD1306寄存器直接相关的函数；display_render.c放画点、画线、显示字符等纯内存操作；ui_menu.c放菜单逻辑和页面渲染。

这样分完之后，如果你的板子从I2C换成SPI，只需要换hal_oled_i2c.c为hal_oled_spi.c，并把驱动层的底层调用切过去，渲染层和应用层一行都不用改。我自己就在同一个项目里做过一次这样的切换，从I2C改成SPI只花了一个晚上，而且中间的坑基本都被分层挡住了。

5.2 把刷新交给谁：主循环、定时器还是RTOS任务

显示刷新不能想起来就刷，要按一个固定的节奏。在没有RTOS的裸机项目里，我建议用定时器中断里置一个刷新标志，主循环检测到标志后再做刷新。这样即使主循环里跑了一些阻塞式延时，显示刷新依然能稳定按周期发生。

如果用RTOS，就更简单了，开一个显示任务，vTaskDelay或者消息队列触发刷新。注意不要在中断服务函数里直接做HAL_I2C_Master_Transmit，HAL库本身就不是中断安全的，而且阻塞式传输会拖死中断响应。正确做法是中断里只做“通知”，真正的事务放到任务上下文去执行。

刷新机制定了以后，整个子系统的时序大概是这样：渲染层在任意时刻往缓冲区里画，主循环或显示任务每次被触发时把缓冲区同步到屏幕。只要保证“画”和“显示”别在同一个函数里纠缠，就不会出现闪烁和撕裂。

5.3 睡眠唤醒与掉电保持

OLED自己会发光，长时间显示静态内容不仅耗电，还可能加速像素老化。所以低功耗场景下，必须支持睡眠和唤醒。

SSD1306的睡眠指令是0xAE，唤醒是0xAF。睡眠状态下功耗可以降到很低，但要注意一个问题——睡眠会关掉显示驱动，但不会清掉显存。唤醒之后，之前画的内容还在。这意味着你可以在睡眠前保留界面，唤醒后直接恢复显示，不用重新绘制一遍。

从应用层的角度，我把它封装成两个接口：

void oled_display_on(void) { oled_write_cmd(0x8D); /* 打开电荷泵 */ oled_write_cmd(0x14); oled_write_cmd(0xAF); /* 打开显示 */ } void oled_display_off(void) { oled_write_cmd(0xAE); /* 关闭显示 */ oled_write_cmd(0x8D); /* 关闭电荷泵，进一步省电 */ oled_write_cmd(0x10); }

注意关闭电荷泵之后，屏幕会彻底不工作，唤醒时要先开电荷泵再开显示，顺序不能反。MCU进入低功耗模式之前，先把I2C引脚释放或者配置成合适的电平，避免漏电。这个地方如果电压不对，睡眠电流可能比正常显示还高，那低功耗方案就白做了。

5.4 方向、镜像和对比度调节

不同产品的安装方向不同，屏幕显示也经常需要旋转。SSD1306提供了几条关键命令：0xA1是列地址重映射，0xC8是行扫描方向重映射。组合起来可以实现180度旋转，但做不到90度旋转。90度旋转必须靠渲染层重排坐标，这是单色屏控制器的硬限制。

对比度通过0x81命令设置，范围是0x00到0xFF。OLED用久了亮度会下降一些，这时候适当提高对比度数值可以补偿。但不要一上来就调到最高值，长期高亮度会加速老化，我一般默认用0xCF，视觉上已经足够亮了。

6. 移植与故障排查：黑屏、花屏和残影究竟是谁的锅

6.1 上电黑屏：先查复位和地址，再怀疑代码

OLED最常见的故障就是上电之后屏幕毫无反应。很多人的第一反应是去调初始化代码，实际上一大半问题出在更基础的地方。

第一步查供电，OLED模块的VCC要确认是3.3V还是5V，很多市售模块板上自己带了稳压，但供电电压接错照样不亮。第二步查I2C地址，0x3C和0x3D之间的选择通常靠模块背面的电阻跳线，有的模块还有SA0引脚，接地是0x3C，接VCC是0x3D。第三步查复位，如果RES引脚悬空，很多模块上电后一直处于复位态，那自然怎么初始化都没用。我用逻辑分析仪看I2C波形，发现地址一直显示为0x78，就是因为那个SA0引脚默认拉到了高电平，而不是我以为的低电平。

排查顺序我总结成一句话：先测电压，再查地址，然后看波形，最后才怀疑初始化代码。这个顺序能帮你省下一大半的调试时间。

6.2 花屏、残影与随机点：电源、总线和初始化状态机

花屏的成因比黑屏复杂很多，常见的有这么几种。

如果屏幕上出现随机的小点，或者某些行显示不稳定，大概率是电源纹波太大或者I2C总线信号质量不好。SDA和SCL上有没有上拉电阻很关键，硬件I2C一般要求上拉到VCC，有的模块板上已经带了，有的不带。没有上拉或者上拉电阻太大，高速通信时边沿就会变得很平缓，数据传错，表现出来就是随机花点。

还有一种花屏很有意思：界面切换的时候，新画面出来之前能看到上一帧的残影。这不是SSD1306的响应速度问题，而是你只更新了新区域，旧区域的数据没有清掉。特别是用脏矩形机制的时候，如果某个区域从“有内容”变成“空白”，但没有触发刷新，残影就会一直留在那里。解决办法是改数据前先对目标区域做oled_fill_rect(..., 0)清底，再做图形绘制。

另外，如果显示内容上下颠倒或者镜像，不要改渲染层的坐标公式，直接在初始化里调0xC0/0xC8和0xA0/0xA1，方向问题用命令解决是最干净的方式。

6.3 刷新慢到肉眼可见：DMA与分块刷新的取舍

I2C模式下全屏刷新慢是常态，但如果你发现刷新一屏卡顿到肉眼可见的画面撕裂，就得考虑DMA了。先把I2C外设配置成DMA模式，发送时构造好数据，再用HAL_I2C_Master_Transmit_DMA异步发送，发送完成之后在回调里释放信号量。这样主循环不会被阻塞，屏幕刷新期间CPU还能继续跑业务逻辑。

但DMA模式有个坑：DMA是异步的，如果你在发送过程中又去修改了发送缓冲区，发出去的数据就可能半新半旧。要么用双缓冲交替发送，要么在发送期间禁止对目标缓冲区写入。我在实际项目里是用一个简单信号量，发送完成之前oled_write_data会直接拒绝新的刷新请求，宁可丢一帧也不要发出错乱的半帧画面。

至于到底用SPI还是I2C上加DMA，我的建议是：如果项目里动画场景多，直接从SPI起步，不要在I2C上死磕性能；如果只是静态显示加菜单，I2C加DMA已经完全够用。

6.4 从MCU到Linux：同一套逻辑如何搬家

最后说个延伸话题。当你把MCU上的OLED代码整理成一个清晰的四层结构之后，会发现这套设计思想其实不止适用于单片机。如果你在Linux环境下驱动小型SPI屏，常见路径是借助fbtft框架或者DRM显示子系统，它们同样遵循“底层驱动程序、中间层显存缓冲、上层应用接口”的模型。

fbtft里注册一个fb_info，负责把写入framebuffer的数据转发给SPI设备；用户空间的程序只要往/dev/fb0里写入像素数据，屏幕就能显示，不需要关心SPI时序和控制命令。而嵌入式项目里的g_oled_fb[1024]缓冲区，本质上就是一个迷你的framebuffer。理解了单色屏的分层设计，再看Linux的display子系统，很多概念都是相通的。

当然这不是说要在单片机上复刻整个Linux内核架构，而是说分层的边界感是通用的。你手里的OLED屏再小，它也是一个独立的显示外设；把外设和业务逻辑之间的那条线划清楚，屏幕就再也不会成为你项目里的祸害。

我自己在好几个项目里反复踩过这些坑之后，最大的体会是：OLED显示系统真正的复杂度不在初始化序列里，而在缓冲区管理、刷新策略和接口设计上。那些网上流传的驱动代码能点亮屏幕，但如果你要的是稳定、可维护、可以不断加功能的上层界面，那就值得多花一点时间把底层好好收拾干净。最后再分享一个小技巧：给oled_draw_pixel加边界判断，给所有绘图API一个共同的入口，这个小习惯能让你在屏幕上做各种奇奇怪怪的效果时，少死机无数次。