STM32驱动SSD1322 OLED屏：SPI与DMA刷屏优化

简介：面向嵌入式开发者，提供STM32基于SSD1322驱动芯片控制OLED屏的完整C/C++源码工程，覆盖初始化配置、SPI及8080接口通信、命令发送、数据写入、灰度显示与图形文本绘制等核心环节，适合正在调试OLED显示或学习STM32外设驱动的读者参考。压缩包共76个文件，以31个c源程序和32个h头文件为主，辅以系统启动汇编、工程配置文件及批量清理脚本，整体仅285KB，模块划分清晰，便于对照阅读。已有1080人进行学习下载。资料特点在于从底层寄存器到应用层绘制均有覆盖：包含头文件模块划分、FWLIB/CMSIS库文件、系统延迟与初始化实现，可直接导入MDK5工程编译使用；描述中还给出了常见显示异常排查思路，如通信时序、引脚配置等注意事项，能帮助开发者理解SSD1322的驱动流程并快速定位问题。

1. SSD1322驱动的OLED屏，为什么值得用STM32重写一遍驱动

SSD1322和大多数开发者熟悉的SSD1306不是一回事：SSD1306是单色（1位色深），而SSD1322是4位灰阶（16级灰度，部分模式支持8位），分辨率最高能做到480×128，常见面板尺寸在2.7英寸到3.12英寸之间。这意味着它一次能显示的像素信息量是SSD1306的4到8倍，视觉效果也从“点灯”变成真正的“灰度屏”。但代价是命令集完全不同，寄存器配置更复杂，显存占用更高——很多固件工程师第一反应是“照搬SSD1306的代码”，结果屏幕要么白屏，要么只有黑白两级，问题多半出在灰度映射和写显存方式上。

用STM32驱动SSD1322的典型场景是工业仪表、便携医疗设备、离线编程器和一些需要灰度波形显示的仪器面板。这类产品对刷新率要求不高，但需要稳定、可控的灰度输出，且MCU资源不能全耗在刷屏上。本文会从通信接口、初始化序列、显存组织和DMA传输四个层面把这条路走通，最后给一个C++驱动封装思路和灰阶验证方法，适合正在移植驱动或在SSD1306工程上升级屏幕的开发者参考。

2. SSD1322的接口选择与STM32引脚分配

2.1 为什么SPI是STM32上最务实的接法

SSD1322硬件上支持6800/8080并行接口和SPI串行接口。并行接口16根数据线 + 控制线，在F103这类LQFP48封装上几乎占满全部GPIO；SPI只要4根线（SCLK、SDIN、CS、DC），加一条RESET，5个引脚就能点亮。并行接口的优势是写入速度快，但SSD1322的SPI最高时钟能跑到50MHz左右（具体以手头面板的手册为准），STM32F103的SPI最高18MHz（PCLK1=36MHz时二分频），F4系列能到42MHz，对大部分灰度仪表界面完全够用。

我一般建议选SPI而不是并行接口，还有一个理由是引脚可复用性：SPI2的SCK/MOSI可以和I2C、定时器通道错开，DC和CS任意接普通GPIO，画PCB时走线容易得多。

2.1.1 SPI引脚分配表与GPIO初始化

按STM32F103C8T6 + SPI1的常用分配方式，引脚规划如下：

注意一个细节：SSD1322的SPI只支持Mode 0和Mode 3，没有硬件地址位，也不需要MISO，所以STM32的SPI配置成仅发送模式（HAL_SPI_Init中Mode = SPI_MODE_MASTER，Direction = SPI_DIRECTION_1LINE）即可。MISO引脚可以空着，不用配置。

void OLED_GPIO_Init(void) { GPIO_InitTypeDef gpio = {0}; __HAL_RCC_GPIOA_CLK_ENABLE(); __HAL_RCC_SPI1_CLK_ENABLE(); gpio.Pin = GPIO_PIN_5 | GPIO_PIN_7; gpio.Mode = GPIO_MODE_AF_PP; gpio.Speed = GPIO_SPEED_FREQ_HIGH; HAL_GPIO_Init(GPIOA, &gpio); gpio.Pin = GPIO_PIN_2 | GPIO_PIN_3 | GPIO_PIN_4; gpio.Mode = GPIO_MODE_OUTPUT_PP; gpio.Speed = GPIO_SPEED_FREQ_HIGH; HAL_GPIO_Init(GPIOA, &gpio); }

这段代码把SCK和MOSI设为复用推挽，CS/DC/RESET设为普通推挽输出。SSD1322对SPI时钟极性的容忍度比SSD1306高，但模式必须和STM32匹配：HAL库中SPI_POLARITY_LOW+SPI_PHASE_1EDGE对应Mode 0，SSD1322数据手册推荐的就是这个组合，读写时序最顺。

提示：如果把SCK接到逻辑分析仪上看到波形有毛刺，先查GPIO速度配置，不要急着改SPI分频。

3. SSD1322初始化时序与寄存器配置

3.1 SSD1322和SSD1306的命令集差异

SSD1322的命令集和SSD1306几乎不重叠。比如SSD1306用0xAF开启显示，SSD1322也是0xAF，但地址设置命令完全不同：SSD1306用0x21/0x22设置列和页地址，SSD1322用0x15/0x75设置列地址范围和行地址范围。灰度相关命令更是SSD1306没有的——0xB8设置灰度查找表（Gray Scale Lookup Table），0xC7设置默认灰度表。

如果之前写过SSD1306驱动，对着初始化序列会下意识想跳过一些命令，这在SSD1322上特别危险。SSD1322有5组内部寄存器和2个运算放大器（DAC）偏置，漏掉任何一组都会导致显示错位或灰度非线性。

3.1.1 最小可用初始化序列

下面这段初始化序列基于128×128分辨率的SSD1322面板（如UG-2828系列）编写，SPI方式驱动：

static void OLED_WriteCmd(uint8_t cmd) { OLED_DC_LOW(); OLED_CS_LOW(); HAL_SPI_Transmit(&hspi1, &cmd, 1, HAL_MAX_DELAY); OLED_CS_HIGH(); } static void OLED_WriteData(uint8_t data) { OLED_DC_HIGH(); OLED_CS_LOW(); HAL_SPI_Transmit(&hspi1, &data, 1, HAL_MAX_DELAY); OLED_CS_HIGH(); } void OLED_Init(void) { OLED_RESET_HIGH(); HAL_Delay(10); OLED_RESET_LOW(); HAL_Delay(100); OLED_RESET_HIGH(); HAL_Delay(50); OLED_WriteCmd(0xFD); OLED_WriteData(0x12); // 解锁命令 OLED_WriteCmd(0xA1); OLED_WriteData(0x00); // 显示起始行 0 OLED_WriteCmd(0xA2); OLED_WriteData(0x00); // 偏移量 0 OLED_WriteCmd(0xA8); OLED_WriteData(0x7F); // 多路复用比 1/128 OLED_WriteCmd(0xA4); // 关闭显示全亮全灭覆盖 OLED_WriteCmd(0xB3); OLED_WriteData(0xF0); // 时钟分频和频率 OLED_WriteCmd(0xCA); OLED_WriteData(0x7F); // 预充电电压 OLED_WriteCmd(0x81); OLED_WriteData(0x7F); // 对比度 128 OLED_WriteCmd(0xB1); OLED_WriteData(0x22); // 相位周期 OLED_WriteCmd(0xBC); OLED_WriteData(0x08); // 预充电电流 OLED_WriteCmd(0xB4); OLED_WriteData(0xA0); // 显示增强，灰度 OLED_WriteCmd(0xB6); OLED_WriteData(0x01); // 第二预充电周期 OLED_WriteCmd(0xBE); OLED_WriteData(0x07); // VCOMH 电压 OLED_WriteCmd(0xA6); // 正常显示，非反色 OLED_WriteCmd(0xAF); // 开启显示 }

命令逐个解释几个关键的：

• 0xFD是锁定命令入口，上电后必须先写0x12解锁，否则后面所有命令都被忽略——这是SSD1322白屏的第一大原因。
• 0xA8设置多路复用比，128像素的面板需要0x7F（即128-1），写成0x3F会导致屏幕上只有上半部分工作。
• 0xCA预充电电压决定像素亮度饱和度，设置过低会发灰，过高会烧屏，128灰阶屏推荐0x7F起步。
• 0xA4与0xA5的差别是：0xA4正常显示，0xA5强制所有像素全亮。调试时如果画面是整片亮，先查是不是这条命令写错了。

初始化完成后，应该能看到屏幕熄灭状态变成均匀的暗灰（因为还没有写显存，灰度默认是0，也就是关断状态）。如果屏幕依然全白，多半是0xBE的VCOMH电压配得过高，或者0xBC预充电电流过大。

3.1.2 分辨率与行列地址映射

void OLED_SetWindow(uint8_t col_start, uint8_t col_end, uint8_t row_start, uint8_t row_end) { OLED_WriteCmd(0x15); OLED_WriteData(col_start); OLED_WriteData(col_end); OLED_WriteCmd(0x75); OLED_WriteData(row_start); OLED_WriteData(row_end); }

SSD1322的列地址范围是0到127，行地址0到127。和SSD1306的页地址不同，这里列和行都是逐像素寻址，写数据后地址自动加1。设置显示窗口后，所有后续写入的数据都会按窗口内的行列顺序流动，不会自动循环。

这里有一个比较容易踩的坑：SSD1322的“列”方向和“行”方向与面板的物理方向可能不一致。部分厂商的128×128面板实际是128列×128行，但行列驱动方向可以通过0xA1和0xA2翻转。初始化序列里0xA1 0x00和0xA2 0x00都是正向，装到竖屏产品上如果发现字是镜像的，改这两个寄存器的值即可，不用改代码逻辑。

4. 灰度数据组织与GRAM写入优化

4.1 4位灰度模式下的像素打包

SSD1322支持1位、4位和8位灰度模式，分辨率128×128时，8位模式下显存需128×128×1 = 16KB（每像素1字节），4位模式下为8KB（每2像素1字节）。STM32F103C8T6只有20KB SRAM，选8位模式会让内存吃紧，所以工程中几乎都用4位模式。

4位模式下，一个字节的高4位表示左边像素的灰度，低4位表示右边像素的灰度，顺序是从上到下、从左到右。要显示一个灰度值为g的像素，实际上去查的是SSD1322内部的灰度查找表（GSDLUT）索引。默认查找表是线性的：0最暗，15最亮。

#define OLED_W 128 #define OLED_H 128 #define OLED_BUF_SIZE (OLED_W * OLED_H / 2) uint8_t oled_buf[OLED_BUF_SIZE]; static void OLED_SetPixel(uint8_t x, uint8_t y, uint8_t gray) { if (x >= OLED_W || y >= OLED_H) return; if (gray > 0xF) gray = 0xF; uint16_t idx = y * OLED_W + x; if (x % 2 == 0) { oled_buf[idx / 2] = (oled_buf[idx / 2] & 0x0F) | (gray << 4); } else { oled_buf[idx / 2] = (oled_buf[idx / 2] & 0xF0) | gray; } }

这段代码把屏幕坐标映射到缓冲区字节位置，并对奇偶列分别写入高低4位。注意gray << 4没有做掩码保护——调用者传入超过15的值会覆盖低4位，所以函数开头做了clip处理。对于实时刷新的数据，我会在写入前先清空整个缓冲区，再重填，避免残影。

4.1.1 灰度像素流式写入

绘图函数填完缓冲区后，整帧搬到屏幕：

void OLED_Flush(void) { OLED_SetWindow(0, OLED_W - 1, 0, OLED_H - 1); OLED_DC_HIGH(); OLED_CS_LOW(); HAL_SPI_Transmit(&hspi1, oled_buf, OLED_BUF_SIZE, HAL_MAX_DELAY); OLED_CS_HIGH(); }

全屏刷新一次需要发送8192字节。在18MHz SPI下，理想耗时约8192×8/18MHz≈3.6ms，加上每次发送的GPIO翻转和函数调用开销，实际在5ms左右。这个数字对波形刷新、菜单切换都够用，但如果要刷动画（比如屏保、实时趋势线），就得靠DMA。

4.2 用DMA把刷屏时间从主循环里摘出去

阻塞式HAL_SPI_Transmit在发送期间会占用CPU等待SPI移位完成，8192字节在18MHz下让CPU空转3.6ms。如果主循环里有按键扫描或ADC采样，按键会迟钝，ADC会抖动。用DMA后，SPI硬件会自己搬运内存数据到移位寄存器，发送过程不占用CPU。

#define OLED_DMA_BUF_SIZE 8192 volatile uint8_t oled_dma_busy = 0; void OLED_Flush_DMA(void) { while (oled_dma_busy) { // 等待上一次传输完成，防止改缓冲区导致数据混乱 } OLED_SetWindow(0, OLED_W - 1, 0, OLED_H - 1); OLED_DC_HIGH(); OLED_CS_LOW(); oled_dma_busy = 1; HAL_SPI_Transmit_DMA(&hspi1, oled_buf, OLED_BUF_SIZE); } void HAL_SPI_TxCpltCallback(SPI_HandleTypeDef *hspi) { if (hspi->Instance == SPI1) { OLED_CS_HIGH(); oled_dma_busy = 0; } }

DMA模式下有两个必修的细节。第一，发送前必须关闭SPI中断或等待上次传输结束，否则SPI外设还在忙，发新数据会覆盖未传完的内容；第二，DMA传输的是内存到外设，oled_buf必须是全局或静态数组，不能是函数局部数组——局部变量在栈上，DMA访问栈地址在优化开启时不稳定，会花屏。

提示：DMA传输结束后再拉高CS，不是发送前拉高。CS拉太早，SSD1322会把最后一个字节的一部分当成命令解析，导致屏幕错位。

另外一个常被忽略的是DC引脚时序。DMA方式下，DC在传输开始时拉高（表示数据阶段），传输完成后保持高电平，直到下一次写命令时拉低。如果代码在传输回调里顺手把DC拉低，下一次写命令时再拉高，中间的毛刺信号会被SSD1322当成一次命令写入，破坏寄存器状态。

4.2.1 SPI分频和DMA时钟的关系

把SPI时钟从18MHz提到36MHz甚至42MHz，刷屏时间能从5ms缩短到3ms以内，但这时要注意SPI总线上所有设备的时序余量。SSD1322的SCLK最高频率是50MHz（手册典型值），36MHz足够安全。如果用的还是杜邦线和面包板，建议降到9MHz，波形质量比速度重要。

5. 用C++封装SSD1322驱动，减少重复代码

5.1 驱动类的接口划分

C语言版本用全局函数加一个缓冲区，工程里调用次序稍有差池就会出现花屏。C++封装不是必须的，但如果项目里有多个显示实例（比如两块OLED同时工作），或者后续要换MCU平台，抽象成类能省很多事。常见的做法是把平台相关的底层函数抽成虚函数，上层只操作显存和命令序列。

class SSD1322 { public: SSD1322(uint8_t w, uint8_t h) : width_(w), height_(h), buf_(new uint8_t[w * h / 2]) {} virtual ~SSD1322() { delete[] buf_; } void set_pixel(uint8_t x, uint8_t y, uint8_t gray); void clear(uint8_t gray = 0); void flush() { write_data(buf_, width_ * height_ / 2); } void init() { reset(); write_cmd_(0xFD); write_data_(0x12); // 与上文C版本初始化序列相同 write_cmd_(0xAF); } protected: virtual void write_cmd_(uint8_t cmd) = 0; virtual void write_data_(const uint8_t* data, uint16_t len) = 0; virtual void reset() = 0; uint8_t width_, height_; uint8_t* buf_; };

这套设计把write_cmd_和write_data_设为纯虚函数，具体平台上实现时可以直接调用HAL库的SPI发送函数。比如STM32上的实现类可以持有SPI_HandleTypeDef*指针，在write_data_里调用HAL_SPI_Transmit。换到GD32或者其他MCU，只需要重写这几个虚函数，上层绘图代码一行不用改。

C++封装带来的一个风险是对象构造时new可能失败。在STM32这种嵌入式环境，我倾向于不用动态内存，而是把缓冲区作为模板参数传入：

template <uint16_t W, uint16_t H> class SSD1322Fixed : public SSD1322 { public: SSD1322Fixed() : SSD1322(W, H) { // 将buf_指向静态数组，避免堆分配 } private: uint8_t static_buf_[W * H / 2]; };

这块是一个开放讨论点——C++的虚函数在构造期不能调用，所以init()不能在构造函数里执行，需要外部显式调用。如果急着在构造函数里初始化，虚函数分派会落到基类实现，然后因为没有实现而报错或什么都不做。

5.1.1 双缓冲与局部刷新

GC9A01这种TFT屏驱动经常讲双缓冲，SSD1322上其实更实用。动态波形显示时，后台缓冲绘制下一帧，绘制完成后整帧切换到前台缓冲，避免刷新过程中屏幕出现撕裂。

void update_waveform(float* samples, uint16_t len) { uint8_t* front = buf_; uint8_t* back = back_buf_; plot_wave(back, samples, len); // 在后台缓冲中画波形 swap(front, back); flush(); // 发送新缓冲 // 下一帧画到另一个缓冲 }

显存翻倍到16KB后，F103C8T6的20KB SRAM几乎耗尽，所以这个方案只在F407或者F103ZE上选。如果主控内存不够，可以不准备两个完整缓冲区，而是按行双缓冲：只缓存一行200字节的像素数据，画一行发一行，代价是绘图函数必须逐行绘制，无法随机访问——但SPI是流式的，天然适合这种模式。

5.2 灰阶条验证法

调通驱动后第一件事不是显示图片，而是跑一段灰度条验证：

void test_gray_scale(SSD1322* oled) { oled->clear(0x0A); for (uint8_t x = 0; x < 128; x++) { uint8_t gray = (x * 15) / 127; for (uint8_t y = 0; y < 128; y++) { oled->set_pixel(x, y, gray); } } oled->flush(); HAL_Delay(2000); oled->clear(0x00); oled->flush(); }

这一段是把128列像素映射到0到15的16个灰度等级，屏幕上的结果应该是16根从左到右由暗变亮的竖条。如果发现只有黑白两档，检查0xB4命令是否写错——该命令的0xA0参数启用灰度增强功能，某些面板变体需要不同的增强值。如果发现灰阶条不均匀，比如末端有跳变，尝试调节对比度寄存器0x81的值。

除了灰阶条，用手头生成一段正弦波滚动曲线，观察动态刷新是否流畅，同时也是对DMA传输稳定性最直观的验证。如果屏幕出现零星的噪点，先怀疑DMA和CPU访问SRAM的总线仲裁问题——F103的DMA1访问SRAM和CPU有调度冲突，这时候把SPI分频降一档，问题往往自动消失。

本文还有配套的精品资源，点击获取