说句实在话我一开始做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行是Page08到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寸的控制器通常是SSD13061.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对应左移后是0x780x3D对应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.chal_oled_i2c.c里只放跟I2C读写相关的函数比如封装HAL库的HAL_I2C_Master_Transmitdisplay_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_TransmitHAL库本身就不是中断安全的而且阻塞式传输会拖死中断响应。正确做法是中断里只做“通知”真正的事务放到任务上下文去执行。刷新机制定了以后整个子系统的时序大概是这样渲染层在任意时刻往缓冲区里画主循环或显示任务每次被触发时把缓冲区同步到屏幕。只要保证“画”和“显示”别在同一个函数里纠缠就不会出现闪烁和撕裂。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一个共同的入口这个小习惯能让你在屏幕上做各种奇奇怪怪的效果时少死机无数次。