基于wl_arm的SPI驱动编写：实战案例分享-平芜编程栈

基于 wl_arm 平台的 SPI 驱动开发实战：从寄存器到音频采集系统

在嵌入式系统的日常开发中，我们常常面临这样一个问题：芯片手册几十页，SPI 控制器寄存器密密麻麻，但真正写起驱动来却无从下手？

尤其是在像wl_arm这类基于 ARM Cortex-M 内核定制、专为无线连接与实时处理优化的平台上，外设高度集成、时钟树复杂、DMA 和中断协同紧密。一旦 SPI 驱动没写好，轻则传感器读不出数据，重则整个系统卡死、音频断续、Flash 写入失败。

今天，我就结合一个真实项目——智能语音采集终端的开发经历，带你一步步从硬件初始化走到 DMA 传输优化，彻底搞懂如何在wl_arm架构下写出稳定、高效、可复用的 SPI 驱动。

为什么是 SPI？它到底强在哪？

先别急着看代码。咱们得明白：SPI 不是唯一的通信方式，但它往往是性能和控制力的最佳平衡点。

相比 I²C 的地址仲裁与低速瓶颈，SPI 没有协议开销；相比 UART 的异步限制，SPI 是同步全双工。它的四大信号线（SCLK、MOSI、MISO、CS）构成了嵌入式世界里最直接的数据通道。

更重要的是，在 wl_arm 这种强调实时性的平台中，SPI 能做到：

微秒级响应：配合 NVIC 中断控制器，可在数据到达瞬间触发处理；
高吞吐能力：支持高达数 MHz 的速率，满足音频流、图像帧等大数据量需求；
灵活拓扑：单主多从结构清晰，每个设备独立片选，便于模块化设计。

当然，代价也很明显：没有标准帧格式，一切靠自己定义。命令怎么发？状态怎么查？超时怎么处理？这些都得由驱动层一肩扛起。

wl_arm 上的 SPI 控制器长什么样？

wl_arm 并不是一个公开架构名称，而是指代某类基于 Cortex-M3/M4 定制的高性能 MCU，常见于 Wi-Fi+MCU 二合一或边缘 AI 场景。这类芯片通常具备增强型外设，其中 SPI 模块尤为关键。

以我们使用的型号为例，其 SPI1 控制器具有以下特性：

特性	说明
工作模式	主/从可配（本文聚焦主机）
数据宽度	支持 8 位 / 16 位传输
时钟极性与相位	CPOL/CPHA 可编程，兼容 Mode 0~3
波特率分频	最高支持 PCLK / 256，72MHz 下可达 ~2.8MHz
FIFO 缓冲区	发送和接收各 8 字节深度
传输方式	支持轮询、中断、DMA 三种模式
DMA 支持	TX/RX 双通道 DMA 请求，支持循环模式

这些参数不是随便看看就算了的——它们决定了你能不能把 W25Q64 Flash 的写速度拉满，也关系到 I²S 音频桥接是否会出现丢包。

第一步：让 SPI “活”起来 —— 初始化全流程拆解

任何驱动的第一步都是初始化。但在 wl_arm 上，这不仅仅是设置几个寄存器那么简单。你需要协调RCC、GPIO、SPI 本体、NVIC四大模块。

下面这段SPI1_Init()函数，就是我在项目中最常用的模板：

void SPI1_Init(void) { // 1. 开启外设时钟 RCC_EnablePeripheralClock(RCC_SPI1); RCC_EnablePeripheralClock(RCC_GPIOA); // 2. 配置 GPIO 复用功能 // PA5 = SCLK, PA6 = MISO, PA7 = MOSI GPIO_SetMode(GPIOA, 5, GPIO_MODE_AF_PP); // 推挽输出 GPIO_SetMode(GPIOA, 6, GPIO_MODE_INPUT); // 输入模式 GPIO_SetMode(GPIOA, 7, GPIO_MODE_AF_PP); // 推挽输出 // 3. 复位 SPI1 控制器（软复位） SPI_Reset(SPI1); // 4. 配置控制寄存器 CR1 SPI1->CR1 = 0; SPI1->CR1 |= SPI_CR1_MSTR; // 设置为主机模式 SPI1->CR1 |= SPI_CR1_BR_2; // 分频系数32 → 72MHz/32 ≈ 2.25MHz SPI1->CR1 |= SPI_CR1_CPOL; // 空闲电平高（CPOL=1） SPI1->CR1 |= SPI_CR1_CPHA; // 第二个边沿采样（CPHA=1）→ Mode 3 SPI1->CR1 |= SPI_CR1_SSM | SPI_CR1_SSI; // 软件管理 NSS，内部上拉 SPI1->CR1 |= SPI_CR1_SPE; // 启动 SPI 功能 // 5. （可选）启用中断 SPI1->CR2 |= SPI_CR2_RXNEIE; // 接收缓冲非空中断使能 NVIC_EnableIRQ(SPI1_IRQn); }

关键点解析：

RCC_EnablePeripheralClock：这是第一步！很多初学者忘了开时钟，结果寄存器写不进去，程序跑飞都不知道为啥。
GPIO 复用配置：必须将引脚设为“Alternate Function Push-Pull”，否则无法输出 SCLK 或 MOSI 信号。
CR1 寄存器组合配置：
MSTR表示主机角色；
BR[2:0]决定波特率，这里用了/32，实际可根据 Flash 或传感器要求调整；
CPOL=1, CPHA=1组合成SPI Mode 3，这是 W25Q64 等 Flash 常见的工作模式；
SSM | SSI实现软件片选管理，避免外部干扰导致误选。
中断使能：如果你打算用中断收发数据，记得打开RXNEIE并注册中断服务例程。

第二步：基础通信 —— 字节级全双工传输

有了初始化，下一步就是实现最基本的发送/接收功能。由于 SPI 是全双工，每次发送一个字节的同时也会收到一个字节。

于是我们封装出这个经典函数：

uint8_t SPI_TransferByte(uint8_t tx_data) { // 等待发送缓冲区空（TXE 标志置位） while (!(SPI1->SR & SPI_SR_TXE)); // 写入数据，自动启动传输 SPI1->DR = tx_data; // 等待接收完成（RXNE 标志置位） while (!(SPI1->SR & SPI_SR_RXNE)); // 读取 DR 寄存器获取返回值 return SPI1->DR; }

它是怎么工作的？

TXE：Transmit Buffer Empty，表示可以写入新数据；
写入DR后，硬件自动开始移位操作；
移位完成后，RXNE（Receive Buffer Not Empty）标志被置位；
此时读取DR即可获得对方回传的数据。

✅提示：即使你只想发数据，也不能跳过读DR的步骤！否则下次读会拿到旧数据。

这个函数适用于小数据量场景，比如读写传感器寄存器、发送 Flash 命令等。但对于连续音频流，频繁轮询会严重占用 CPU。

第三步：释放 CPU —— 使用 DMA 实现零负载批量传输

这才是 wl_arm 的真正优势所在：强大的 DMA 引擎可以让你的 SPI 在后台默默搬运数据，CPU 去干更重要的事。

以下是使用 DMA 进行双向传输的典型实现：

void SPI_TransferDMA(uint8_t *tx_buf, uint8_t *rx_buf, uint16_t len) { // 配置 DMA1_Channel3：内存 → 外设（发送） DMA_Configuration(DMA1_Channel3, (uint32_t)tx_buf, // 源地址 (uint32_t)&SPI1->DR, // 目标地址 len, // 数据长度 DMA_DIR_MEM2PER | // 方向：内存到外设 DMA_CIRC_DISABLE | // 非循环模式 DMA_PRIORITY_HIGH); // 高优先级 // 配置 DMA1_Channel2：外设 → 内存（接收） DMA_Configuration(DMA1_Channel2, (uint32_t)&SPI1->DR, // 源地址 (uint32_t)rx_buf, // 目标地址 len, DMA_DIR_PER2MEM | DMA_CIRC_DISABLE | DMA_PRIORITY_HIGH); // 开启 SPI 的 DMA 请求 SPI1->CR2 |= SPI_CR2_TXDMAEN | SPI_CR2_RXDMAEN; // 启动两个 DMA 通道 DMA_Start(DMA1_Channel3); DMA_Start(DMA1_Channel2); // 【可选】等待完成（也可用中断回调替代） while (DMA_GetStatus(DMA1_Channel3) != DMA_STATUS_COMPLETE || DMA_GetStatus(DMA1_Channel2) != DMA_STATUS_COMPLETE); }

为什么这么设计？

双通道 DMA：发送和接收分别使用独立通道，确保同步性；
高优先级：防止其他 DMA 请求打断音频流；
完成后轮询或中断：调试阶段可用轮询，量产建议改为中断通知，进一步降低 CPU 占用。

⚠️ 注意事项：开启 DMA 前务必确认 SPI 已使能（SPE=1），否则可能引发总线错误。

实战案例：构建智能语音采集系统

现在让我们把这套驱动放到真实系统中检验一下。

假设我们的设备是一个带本地存储的语音记录仪，架构如下：

[wl_arm MCU] │ ├── SPI1 ──→ W25Q64 Flash ← 存储录音文件 ├── SPI2 ──→ SPDIF-to-I²S Bridge ← 获取数字音频 └── SPI3 ──→ LIS3DH IMU ← 检测设备姿态

当用户按下录音键时，系统需要完成以下动作：

通过 SPI3 读取 IMU 状态，判断设备是否静止；
初始化 I²S 接口接收 PCM 数据流；
打开 W25Q64 Flash，准备写入；
将 PCM 数据通过 SPI1 分块写入 Flash；
每次写完一页后，读取 Flash 状态寄存器确认完成；
录音结束，关闭接口，进入低功耗模式。

遇到的问题与解决方案

❌ 问题1：录音过程中 CPU 占用率达 90%+

原因：最初采用轮询方式逐字节写 Flash，每写一个字节都要等忙状态。

解决：改用SPI_TransferDMA()+ Flash Page Program 命令，一次写入 256 字节，并利用 DMA 自动搬运，CPU 占用降至 15% 以下。

❌ 问题2：多个 SPI 设备争抢总线

现象：IMU 数据偶尔错乱，Flash 写入失败。

根源：SPI1 和 SPI3 共享同一组中断向量？不！其实是软件层面并发访问未加保护。

对策：
- 添加互斥锁机制（如 FreeRTOS 的xSemaphoreTake()）；
- 或者在驱动层统一调度，禁止跨任务直接调用底层 SPI 函数。

❌ 问题3：高频 SPI 引发电源噪声，导致 ADC 采样失真

发现：录音中有轻微“咔哒”声。

排查：用示波器查看 VDD，发现 SPI 传输期间出现毛刺。

改进：
- 在 PCB 布局中为 SPI 走线添加地屏蔽；
- 加强去耦电容（0.1μF + 10μF 并联）；
- 降低 SPI 速率至 2MHz（仍满足 Flash 性能需求）。

工程最佳实践总结

经过多个项目的打磨，我总结出一套在 wl_arm 平台上开发 SPI 驱动的“黄金法则”：

✅ 必做项

始终检查时钟使能顺序：RCC → GPIO → SPI；
精确匹配 CPOL/CPHA：不同设备可能使用不同模式，切勿全局固定；
使用逻辑分析仪验证时序：哪怕只抓一次 CS/SCLK/MOSI/MISO，也能省下三天调试时间；
对 Flash/EEPROM 添加超时重试机制：防止因忙等待无限阻塞；
封装标准 API 接口：

int spi_open(spi_dev_t dev_id); int spi_write(spi_dev_t dev, uint8_t *buf, size_t len); int spi_read(spi_dev_t dev, uint8_t *buf, size_t len); int spi_close(spi_dev_t dev);

这样未来移植到 RT-Thread 或 Zephyr 也能无缝衔接。