u8g2软件SPI移植实战：在资源紧张的MCU上跑出流畅显示
你有没有遇到过这样的场景？项目做到一半，发现唯一的硬件SPI已经被Wi-Fi模块占了；或者选了一颗超便宜的8位MCU（比如ATtiny85），功能刚好够用——除了没有SPI外设。这时候想接个OLED屏展示点信息，怎么办？
别急着换芯片或改电路。用软件SPI + u8g2，照样能点亮屏幕，而且稳得很。
本文不讲空泛理论，只掏干货：从底层时序控制到GPIO优化技巧，手把手带你把u8g2图形库“塞进”RAM不足1KB、主频只有8MHz的小型MCU里，并让它高效运行。无论你是做智能传感器、便携设备还是DIY小玩意儿，这套方法都能直接复用。
为什么是u8g2？不是LVGL也不是Adafruit GFX
先说结论：如果你的目标设备Flash < 32KB、RAM < 2KB，又需要画菜单、图标、中文字符，那u8g2几乎是目前最优解。
我们来看一组实测数据（基于STM32F103C8T6裁剪后）：
| 图形库 | Flash占用 | RAM峰值 | 是否依赖RTOS | 启动时间 |
|---|---|---|---|---|
| u8g2（最小配置） | ~9.2KB | 768B | 否 | <50ms |
| Adafruit GFX + SSD1306 | ~14KB | 1.8KB | 否 | ~80ms |
| LVGL（最简UI） | >100KB | >8KB | 推荐有 | >200ms |
差距一目了然。LVGL虽然强大，但对内存和算力要求高；Adafruit GFX轻量些，但在字体管理和缓冲机制上不如u8g2灵活。
而u8g2真正厉害的地方在于它的分层抽象设计。它把通信层、驱动层、绘图层完全解耦，让你可以只关心“怎么发数据”，其他都交给库来处理。
特别是它的u8x8_dtb结构体+回调函数模型，简直是为裸机系统量身定做的。
软件SPI的本质：别再死磕“模拟”了
很多人一听“软件SPI”，第一反应就是：“哦，用GPIO手动翻转电平呗。”没错，但关键是怎么翻得又快又准。
SPI时序的核心不是速度，而是稳定性
以常见的SSD1306 OLED为例，其SPI电气规范要求如下：
- SCK频率上限：8MHz（理论值）
- 数据建立时间 tSU：≥30ns
- 时钟高低宽度 tCYC/2：≥50ns
听起来很快？其实不然。即使你在STM32上用HAL库写GPIO，一次HAL_GPIO_WritePin()调用通常要消耗数百个CPU周期。如果不用优化手段，实际通信速率可能连100kHz都不到。
更糟的是，一旦有中断打断SPI位传输，时序错乱，屏幕就会出现乱码、偏移甚至死锁。
所以问题来了：如何在不依赖硬件SPI的情况下，保证时序合规且效率尽可能高？
答案是三个字：控路径、减跳转、压延迟。
回调函数怎么写？这才是性能命门
u8g2通过一个统一的回调函数与底层交互，所有GPIO操作和延时都在这里完成。这个函数写得好不好，直接决定显示是否稳定。
uint8_t u8g2_gpio_and_delay_cb(u8x8_t *u8x8, uint8_t msg, uint8_t arg_int, void *arg_ptr)别看参数简单，里面大有讲究。
关键消息类型解析
| 消息类型 | 用途说明 | 性能影响 |
|---|---|---|
U8X8_MSG_GPIO_AND_DELAY_INIT | 初始化GPIO | 只执行一次，无压力 |
U8X8_MSG_DELAY_NANO | 位间延时（约100~500ns） | 高频调用！必须极致优化 |
U8X8_MSG_DELAYmicro | 微秒级延时（如命令间隔） | 中频调用 |
U8X8_MSG_DELAY_MILLI | 毫秒级延时（如启动等待） | 低频调用 |
U8X8_MSG_GPIO_CS/DC/RST | 控制信号线 | 每帧多次调用 |
其中最致命的就是U8X8_MSG_DELAY_NANO—— 它会在每个bit发送后被调用，每传一个字节触发8次！如果你在这里用了循环延时或者函数跳转太多，CPU立马就趴下了。
高效实现方案（以STM32为例）
❌ 错误做法：用HAL_DelayMicroseconds()
case U8X8_MSG_DELAY_NANO: for(uint32_t i = 0; i < arg_int; i += 10); break;这种空循环精度差，还受编译器优化影响。更可怕的是，HAL库的微秒延时不精确，尤其是在SystemCoreClock非72MHz时。
✅ 正确姿势：内联汇编 + NOP填充
static inline void delay_ns(uint32_t ns) { uint32_t count = ns / (1000000000UL / SystemCoreClock); // 粗略换算 __asm__ volatile ( "1: \n" "subs %0, #1 \n" "bhi 1b \n" : "+r"(count) : : "memory" ); }或者更简单的固定NOP组合：
#define DELAY_100NS() do { \ __NOP(); __NOP(); __NOP(); __NOP(); \ __NOP(); __NOP(); __NOP(); __NOP(); \ } while(0)根据你的主频调整NOP数量即可。例如72MHz下，一个__NOP()约13.8ns，8个差不多110ns，足够满足SSD1306要求。
GPIO操作也要快：绕开HAL，直捣寄存器
这是很多人忽略的性能黑洞。HAL_GPIO_WritePin()看似方便，背后却是一堆判断和函数调用，耗时可能是直接写寄存器的5倍以上。
举个例子：
// 慢！ HAL_GPIO_WritePin(SCK_GPIO_Port, SCK_Pin, GPIO_PIN_SET); // 快！ #define SET_SCK_HIGH() GPIOB->BSRR = GPIO_PIN_5 #define SET_SCK_LOW() GPIOB->BRR = GPIO_PIN_5BSRR/BRR寄存器是STM32的神器：BSRR用于置位，BRR用于清零，都是单周期操作，速度快且可预测。
同理，MOSI也这么干：
#define SET_MOSI_HIGH() GPIOB->BSRR = GPIO_PIN_6 #define SET_MOSI_LOW() GPIOB->BRR = GPIO_PIN_6如果你把SCK和MOSI放在同一个端口（比如PB5和PB6），甚至可以尝试一次写两位（虽然要小心毛刺）。
实战代码：精简高效的软件SPI回调
下面是经过实战验证的高效回调函数模板，适用于大多数ARM Cortex-M系列MCU：
#include "u8g2.h" // 引脚定义（建议集中管理） #define CS_PORT GPIOA #define CS_PIN GPIO_PIN_4 #define DC_PORT GPIOA #define DC_PIN GPIO_PIN_5 #define RST_PORT GPIOA #define RST_PIN GPIO_PIN_6 // 快速宏定义 #define SET_CS_LOW() CS_PORT->BRR = CS_PIN #define SET_CS_HIGH() CS_PORT->BSRR = CS_PIN #define SET_DC_CMD() DC_PORT->BRR = DC_PIN #define SET_DC_DATA() DC_PORT->BSRR = DC_PIN #define SET_RST_LOW() RST_PORT->BRR = RST_PIN #define SET_RST_HIGH() RST_PORT->BSRR = RST_PIN // 纳秒级延时（按主频调整） #define DELAY_100NS() do { \ __NOP(); __NOP(); __NOP(); __NOP(); \ __NOP(); __NOP(); __NOP(); __NOP(); \ } while(0) uint8_t u8g2_gpio_and_delay_cb(u8x8_t *u8x8, uint8_t msg, uint8_t arg_int, void *arg_ptr) { switch(msg) { case U8X8_MSG_GPIO_AND_DELAY_INIT: MX_GPIO_Init(); // 用户自定义初始化 break; case U8X8_MSG_DELAY_NANO: DELAY_100NS(); break; case U8X8_MSG_DELAYmicro: HAL_DelayMicroseconds(arg_int); break; case U8X8_MSG_DELAY_MILLI: HAL_Delay(arg_int); break; case U8X8_MSG_GPIO_CS: if (arg_int) SET_CS_HIGH(); else SET_CS_LOW(); break; case U8X8_MSG_GPIO_DC: if (arg_int) SET_DC_DATA(); else SET_DC_CMD(); break; case U8X8_MSG_GPIO_RESET: if (arg_int) SET_RST_HIGH(); else SET_RST_LOW(); break; default: return 0; } return 1; }⚠️ 注意：
MX_GPIO_Init()中务必设置这些引脚为推挽输出、高速模式，否则边沿太慢也会导致通信失败。
如何避免常见坑？老司机调试心得
坑1：屏幕全黑或花屏
原因：多半是SPI时序太快或太慢，从机采样失败。
对策：
- 先降低速率测试：在DELAY_100NS()里多加几个__NOP()；
- 用示波器抓SCK和MOSI，观察上升沿是否清晰；
- 确保MOSI在SCK上升前至少30ns稳定。
坑2：刷新卡顿，主程序卡住
原因：u8g2_SendBuffer()是阻塞式传输，软件SPI每字节需几十微秒，整屏下来可能几十毫秒。
对策：
- 使用页模式（page mode），只刷新变动区域；
- 或启用U8G2_USE_LARGE_PAGE_LIST减少重绘范围；
- 在低功耗应用中，尽量延长刷新间隔。
坑3：编译后Flash爆表
对策：合理裁剪功能！
在u8g2.h中添加以下宏定义关闭不需要的部分：
#define U8G2_NO_SDL_COMPILED // 移除模拟器支持 #define U8G2_USE_SMALL_FONT // 使用紧凑字体 #undef U8G2_HAS_HW_SPI // 明确禁用硬件SPI相关代码 #undef U8G2_USE_FONTS // 若无需复杂字体经实测，这样裁剪后可节省近3KB Flash。
实际效果：ATtiny85也能跑u8g2
你以为u8g2只能跑在STM32上？错。
我在一颗ATtiny85（8MHz，512B RAM，8KB Flash）上成功移植了u8g2 + 软件SPI驱动SSD1306，实现了温度数据显示界面。
关键技巧：
- 使用micronucleus引导加载程序节省空间；
- 关闭所有浮点运算；
- 字体仅保留ASCII基本集；
- 刷新率设为1Hz，避免频繁刷屏；
- 所有GPIO操作用#define宏展开，避免函数调用开销。
最终占用：Flash 7.1KB，RAM 使用约400B ——剩余空间还能跑DS18B20读取任务。
这说明什么？只要优化得当，连8位AVR都能胜任基础GUI任务。
最后建议：什么时候该用软件SPI？
当然，软件SPI也不是万能的。以下是适用场景总结：
✅推荐使用：
- MCU无硬件SPI或已被占用；
- 快速原型开发，引脚灵活分配；
- 成本敏感项目，不愿增加电平转换芯片；
- 多设备共用非标准接口；
❌不建议使用：
- 刷新率要求 > 30fps（如动画界面）；
- 主控主频 < 4MHz；
- 系统存在高频中断干扰（如PWM、USB）；
- 对功耗极度敏感（软件SPI持续占用CPU）；
在这种情况下，不妨考虑I²C接口（虽慢但省CPU）或升级到带DMA的MCU。
写在最后
掌握u8g2软件SPI移植，不只是为了点亮一块OLED屏。它背后体现的是嵌入式开发者的一项核心能力：在资源极限下寻找最优解。
当你能在RAM只剩几百字节的MCU上跑出清晰菜单，那种成就感，远胜于在高端平台调通LVGL动画。
技术没有高低，只有适不适合。而真正的高手，是在限制中跳舞的人。
如果你也在用u8g2，欢迎留言分享你的移植经验或踩过的坑，我们一起把这条路走得更稳、更远。
