调一块 SPI 接口的 2.4 寸 TFT 屏幕插上去白屏折腾了整整一个下午。又是查初始化代码又是量电压最后发现是 CPOL 和 CPHA 填反了就那么一比特的配置差异整块屏就是不工作。从那以后我养成了一个习惯看到“SPI 协议全双工”这几个字先想清楚一件事——全双工到底意味着什么数据在两根线上是怎么“同时”跑的。本文不打算讲那种“SPI 四根线SCLK、MOSI、MISO、CS”的入门科普而是从一个写驱动的人视角把 SPI 全双工从底层原理到实战中容易踩的坑完整捋一遍。适合正在调 SPI 屏幕、Flash、传感器或者被硬件片选和软件片选折腾过的工程师也适合刚学 STM32、香橙派这类平台准备用 SPI 和外部器件通信的开发者。1. 全双工的物理本质两根数据线上的“同时”是怎么发生的很多人理解全双工就是“能同时收和发”但 SPI 能同时收发的底气不是靠什么复杂仲裁机制而是靠物理上独立的收发通道和一套移位寄存器机制。1.1 移位寄存器才是全双工的核心SPI 主设备和从设备内部都有一个移位寄存器。通信时主设备的移位寄存器通过 MOSIMaster Out Slave In线一位一位往从设备里推数据与此同时从设备的移位寄存器通过 MISOMaster In Slave Out线一位一位往主设备里推数据。两根线、两个方向的移位操作由同一个 SCLK 时钟驱动。这个设计有点像两人面对面各拿一条管子中间用一根绳子同步拉——你推出去一颗珠子同时对方也推回来一颗珠子。每一拍时钟主设备“发出一个 bit”并且“收到一个 bit”两个动作在同一时刻完成。这就是全双工的物理本质一对一的收发映射发多少就收多少。我在调试中经常遇到新人问为什么 SPI 读操作要“先发一个字节”才能“读到一个字节”答案就在这个机制里——你发出去的那个字节其实是给从设备提供时钟节拍从设备利用这些时钟节拍把数据推到 MISO 线上。你发的字节本身是什么不重要重要的是你产生了时钟。1.2 主设备发一个字节的时钟里其实也收了一个字节这句话值得单独拿出来强调。SPI 每产生 8 个时钟主设备的接收寄存器里就会多出 8 个 bit。问题是这 8 个 bit 是从设备在这个时间段里推出来的而大多数从设备在收到“读命令”的第一个字节时还没准备好数据所以推回来的往往是 0x00、0xFF 或者无意义的垃圾值。这就引出了一个非常重要的实战心法读操作必须设计“先发无用字节再收有效数据”的节奏。比如要读 W25Q64 的状态寄存器主设备先发 0x05 读命令这个字节的 8 个时钟里W25Q64 回的是 0x00第二个字节开始主设备再发的任意字节通常发 0xFF对应的 8 个时钟里状态寄存器内容才通过 MISO 吐出来。1.3 半双工和全双工的区别不止是“能不能同时”I2C 只有一根 SDA 数据线收发必须分时复用这是半双工。UART 的 RX 和 TX 独立是全双工但它没有时钟线靠双方约定波特率来同步。SPI 比 UART 强的地方在于有独立的 SCLK 时钟线收发节奏完全由主设备控制所以它可以做得比 UART 更高频、更稳定。实际项目里如果用 SPI 和从设备通信但每次收发都像 I2C 一样“先只发、再只收”那就是把全双工用成了半双工通信效率和实时性会打折扣。当然很多从设备的指令协议决定了你没法做到每一拍都收有效数据但至少在传输层你要清楚自己手上拿的是一把全双工的牌。2. 时钟极性 CPOL 和时钟相位 CPHA一串乱码背后的四个模式SPI 的时序参数里最容易让人翻车的就是 CPOL 和 CPHA。我见过不少人在 CubeMX 里随便选了个 Mode 0发现通信不通就把锅甩给“硬件有问题”其实只是时序模板没匹配上从设备的规格。2.1 CPOL 决定空闲电平CPHA 决定采样沿CPOLClock Polarity决定 SCLK 在空闲状态没有数据传输时的电平CPOL0 表示空闲低电平CPOL1 表示空闲高电平。CPHAClock Phase决定数据在哪个边沿被采样CPHA0 表示在第一个边沿采样通常是上升沿CPHA1 表示在第二个边沿采样通常是下降沿。注意“第一个边沿”指的是从空闲切换到非空闲状态后的第一个跳变。排列组合后就得到四种模式模式CPOLCPHA空闲电平采样边沿常见应用Mode 000低上升沿大多数 Flash、传感器Mode 101低下降沿部分音频芯片Mode 210高上升沿部分 LCD 驱动Mode 311高下降沿部分射频芯片、NRF24L012.2 选错模式会发生什么选错 CPOL/CPHA最常见的结果是数据能“动”但全是乱的。比如你发 0x01从设备收到的可能是 0x80甚至有可能是完全无法预测的值。这是因为主设备在错误的时刻去采样 MISO采到的不是稳定的数据电平而是边沿切换瞬间的中间态。我曾经帮同事排查一个 NRF24L01 通信问题他用的模式是 Mode 0NRF24L01 死活读不到寄存器。查数据手册发现NRF24L01 需要 Mode 0 或 Mode 1但它的 SPI 时序要求从设备输出数据在时钟下降沿之后稳定。检查波形后发现主设备在上升沿采样而 NRF24L01 的输出数据刚好在上升沿前后变化导致采样不稳。改成 Mode 1下降沿采样后问题立解。2.3 怎么快速判断该用哪个模式最靠谱的方式是直接看从设备数据手册里的时序图。看 SCLK 空闲时是高还是低确定 CPOL看数据在哪个边沿稳定、哪个边沿变化或者看手册里“Data Setup”“Data Hold”相对哪个沿描述确定 CPHA。如果手头有逻辑分析仪抓一下从设备输出数据线和 SCLK 的波形对比数据手册里的采样窗口一抓一个准。没有逻辑分析仪时可以把四种模式都试一遍看哪个模式能读到预期的数据。我在调试未知器件时会在代码里做一个“模式扫描”循环切换四种模式读同一个寄存器能读出数据手册标注的默认值就是对的模式。2.4 CubeMX 里的配置细节在 CubeMX 里配置 SPI 时有“Clock Polarity”和“Clock Phase”两个下拉框对应 CPOL 和 CPHA。很多人直接选 Low/First Edge也就是 Mode 0然后就不管了。这个默认值对于 W25Q64、GD25Q128E 这类 Flash 是没问题的但遇到其他器件时一定要查手册。还有一个容易被忽略的参数BaudRate Prescaler。SPI 时钟不是想多快就多快从设备支持的 SCLK 频率上限会写在数据手册里。比如 W25Q64 支持最高 80MHz但如果你用 STM32F103 的 APB2 时钟 72MHz分频配置不当SCLK 实际频率可能超出从设备支持范围。别只看“能通”还要看“稳不稳”。3. 硬件片选与软件片选自动和手动之间的可靠性博弈片选CS/SS/NSS是 SPI 通信的“门禁”谁被拉低谁就参与通信。但片选的实现方式硬件片选和软件片选在实战中带来的问题完全不一样。3.1 硬件片选的便利与陷阱硬件片选是指 MCU 的 SPI 外设自动控制 NSS 引脚。你只管往数据寄存器里写数据外设在传输开始前自动把 NSS 拉低传输结束后自动拉高。听起来很省心但这里有个坑有些 MCU 的硬件 NSS 模式会和“多主机错误检测”绑定。比如 STM32NSS 硬件模式Hardware NSS Output如果配置不当NSS 引脚上的电平变化会被 SPI 外设理解成“总线上有多个主机抢占”从而触发 MODF 错误通信直接中断。我在 STM32F103 上就遇到过这个问题。配置成 Hardware NSS Output 模式后只要从设备占用总线时间长一点SPI 就报 MODF。后来改成 Hardware NSS Input 模式用外部 GPIO 手动控制片选反而稳定了。所以我的建议是除非你确定外设的硬件 NSS 行为和你用的从设备完全匹配否则别迷信硬件片选。更多时候软件片选GPIO 手动拉低/拉高反而更可控。3.2 软件片选灵活但有三个前提软件片选就是用普通 GPIO 控制从设备的 CS 引脚。它的好处是可以任意选择引脚而且拉低/拉高的时机完全由你掌控对多从设备总线特别友好。但有三个前提第一片选拉低后不能马上就开始发数据。从设备从 CS 拉低到准备好接收数据需要一小段时间tCSSChip Select Setup Time。如果 CS 刚拉低就立刻送 SCLK有些从设备会漏掉前面的 bit。解决方法是加一个微秒级别的延时或者利用从设备的“CS 拉低后先等一点时间”的要求。第二片选拉高之前要确保最后一个 bit 已经完全送出。特别是高速 SP I 通信时如果数据寄存器写完不等于移位寄存器送完你立刻拉高 CS最后一个 bit 传输会被截断。第三软件片选和 GPIO 翻转速度要匹配。这在 Linux 平台特别明显通过 GPIO 子系统拉低/拉高一个引脚中间可能有系统调用、驱动框架的开销延迟比 MCU 裸机上的 GPIO 操作大得多。如果你用软件片选配合高速 SPI比如 10MHz 以上GPIO 的翻转延迟会让从设备误判片选时序。3.3 Linux 下软件拉片选的实操经验热搜词里有一条“linux spi 软件拉片选”这确实是 Linux 下 SPI 开发容易踩坑的地方。Linux SPI 子系统提供了设备树里cs-gpios属性可以指定用 GPIO 来做片选。但实际操作中GPIO 片选和 SPI 控制器内置片选的行为并不完全一致。内置片选由 SPI 控制器硬件自动控制和 SCLK 严格同步GPIO 片选由驱动代码控制软件操作和时间点之间可能有几十微秒的延迟。我在香橙派 Zero3 上调 SPI 时发现用 GPIO 片选连接一块 Flash每次读数据都偶发失败。用示波器看波形CS 拉低之后 SCLK 并没有立即开始中间有几微秒的空白。这个空白对慢速器件没影响但对某些对时序敏感的从设备就是致命问题。最后通过给 SPI 驱动打补丁在 GPIO 片选控制里增加udelay才把问题解决。在 MCU 裸机开发中软件片选同样需要注意如果你的主循环和 SPI 传输之间插了太多中断处理CS 的拉低和 SCLK 启动之间的间隔可能不稳定。这种情况下可以考虑用定时器中断来精确控制片选时序或者干脆在 SPI 传输函数内直接操作 GPIO减少中间层。3.4 多从设备场景下的片选策略多从设备共用一个 SPI 总线时片选策略尤其重要。基本原则是同一时刻只能有一个从设备的 CS 被拉低否则两个从设备都会在 MISO 上输出数据造成总线冲突。我在 RK 平台做“SPI 转 CAN”扩展时总线上挂了两个 SPI 转 CAN 模块一个 SPI 转 UART 模块。这时候如果依赖硬件 NSS每个外设都要占用一个硬件 NSS 引脚引脚不够用改用 GPIO 软件片选后三个模块只需要一个 SPI 外设和三个 GPIO扩展性就好多了。多从设备切换时还要注意从一个从设备切换到另一个从设备中间至少留一个“总线空闲时间”让前一个从设备彻底释放 MISO。有些从设备在 CS 拉高后不会立刻停止驱动 MISO需要几个时钟周期的缓冲。可以用“先拉高 CS再发 8 个空时钟再拉低下一个 CS”的方式来隔离。4. 从 W25Q64 看全双工主设备发什么才能换回数据W25Q64 和 GD25Q128E 这类 SPI Flash 是学习 SPI 最好的“教具”因为它们的状态机设计得很经典清晰展示了 SPI 全双工下“主设备发什么、从设备回什么”的完整逻辑。4.1 读 JEDEC ID 的完整时序读 JEDEC ID 是验证 SPI Flash 通信是否正常的首选操作。W25Q64 的读 ID 指令是 0x9F。以下是完整时序主设备拉低 CS主设备发送 0x9F读 ID 指令主设备发送任意字节通常 0x00 或 0xFF从设备回传 Manufacturer ID对于 Winbond 是 0xEF主设备继续发送任意字节从设备回传 Memory Type对于 W25Q64 是 0x40主设备再发送任意字节从设备回传 Capacity CodeW25Q64 是 0x17主设备拉高 CS。用代码表示就是连续三次 HAL_SPI_TransmitReceiveuint8_t cmd 0x9F; uint8_t dummy 0xFF; uint8_t rxBuf[3] {0}; HAL_GPIO_WritePin(CS_GPIO_Port, CS_Pin, GPIO_PIN_RESET); HAL_SPI_Transmit(hspi, cmd, 1, HAL_MAX_DELAY); HAL_SPI_TransmitReceive(hspi, dummy, rxBuf[0], 1, HAL_MAX_DELAY); HAL_SPI_TransmitReceive(hspi, dummy, rxBuf[1], 1, HAL_MAX_DELAY); HAL_SPI_TransmitReceive(hspi, dummy, rxBuf[2], 1, HAL_MAX_DELAY); HAL_GPIO_WritePin(CS_GPIO_Port, CS_Pin, GPIO_PIN_SET);如果你读出来的 ID 是 0x00 或者 0xFF先别急着重焊芯片回头检查 CS 有没有拉低、模式是不是 Mode 0 或 Mode 3、SCLK 频率是不是太高。这三个问题占了 SPI Flash 通信失败原因的八成。4.2 从设备的“半双工式应答”全双工的另一层含义值得说清楚的是虽然 SPI 总线物理上是全双工的但很多从设备包括 W25Q64内部逻辑是“半双工式”的它们在一个时刻要么处理接收要么准备发送不会边收边算。比如读数据指令 0x03 3 字节地址发送期间Flash 内部在解析地址、准备数据此时 MISO 上回的是垃圾值等地址解析完毕后续每个时钟才从数据缓冲区里往外吐数据。所以理解 SPI 全双工要拆成两层物理层MOSI 和 MISO 同时传输每个时钟同时收发一个 bit协议层从设备可能“用完你的时钟才给你回数据”你发出去的 dummy 字节本质上是在“买时间”。这个理解非常关键。设计驱动时你不能想当然地认为“我发一个读命令马上就能读回数据”而是要把命令发送和实际数据读取之间的“时间差”考虑进去。4.3 写使能、读状态寄存器与全双工读写的配合SPI Flash 写操作还涉及一个常见的全双工协作场景。写 Flash 前要先发 0x06Write Enable然后发 0x02Page Program或 0x02 带地址数据最后还要轮询读状态寄存器0x05等 WIPWrite In Progress位从 1 变成 0。轮询状态寄存器时很多人会这样写uint8_t cmdReadStatus 0x05; uint8_t status 0xFF; do { HAL_GPIO_WritePin(CS_GPIO_Port, CS_Pin, GPIO_PIN_RESET); HAL_SPI_Transmit(hspi, cmdReadStatus, 1, HAL_MAX_DELAY); HAL_SPI_TransmitReceive(hspi, dummy, status, 1, HAL_MAX_DELAY); HAL_GPIO_WritePin(CS_GPIO_Port, CS_Pin, GPIO_PIN_SET); } while (status 0x01);这里有个细节读状态寄存器时主设备发的第二个字节必须是“任意有效的时钟”但如果你想一次性完成“发命令 读数据”完全可以把 0x05 和 dummy 字节合并成一个 2 字节的 TransmitReceiveuint8_t txBuf[2] {0x05, 0xFF}; uint8_t rxBuf[2] {0}; HAL_GPIO_WritePin(CS_GPIO_Port, CS_Pin, GPIO_PIN_RESET); HAL_SPI_TransmitReceive(hspi, txBuf, rxBuf, 2, HAL_MAX_DELAY); HAL_GPIO_WritePin(CS_GPIO_Port, CS_Pin, GPIO_PIN_SET); status rxBuf[1]; // 第二个字节是从设备回的状态这样一次传输就完成了命令发送和数据读取效率更高也更符合“全双工”的设计理念。4.4 读操作的“垃圾字节”技巧最后分享一个读操作的小技巧。很多从设备的读操作主设备发的 dummy 字节内容不影响从设备输出。但有些器件对 dummy 字节有要求比如有些 ADC 芯片要求 dummy 必须是 0x00有些传感器要求 0xFF。查数据手册时看到“Dont Care”字样可以随便发但看到“Should be 0x00”这类字样就不能乱来。我在调 AD7124 这类 ADC 时就吃过 dummy 字节填错的亏。AD7124 的通信寄存器读操作后面跟的 dummy 字节如果非 0x00读出来的数据会偏移一位。后来把所有 dummy 都统一改成 0x00问题消失。所以dummy 字节不是“真随便”它需要配合具体器件的规格来定。5. 软件模拟 SPI没有硬件外设时的保底方案不是所有平台都有硬件 SPI 外设也不是所有场景都适合用硬件 SPI。软件模拟 SPIGPIO 位操作在很多项目里依然是刚需。5.1 什么时候该用软件模拟 SPI引脚不够硬件 SPI 引脚被其他功能占用或者你需要把引脚映射到非 SPI 引脚上非标准时序从设备对时序有特殊要求比如需要很慢的 SCLK、特殊的空闲电平硬件 SPI 配不出来调试阶段软件 SPI 的每一步都可以打断点观察排查时序问题比硬件 SPI 直观C51、Arduino 这类简单平台没有硬件 SPI 或者硬件 SPI 用起来不够灵活。5.2 一个可用的软件模拟 SPI 实现以最常用的 Mode 0CPOL0CPHA0为例空闲时 SCLK 为低数据在上升沿采样所以主设备应该在 SCLK 拉低时把数据放到 MOSI 上然后拉高 SCLK让从设备采样。#define SPI_SCLK_LOW() HAL_GPIO_WritePin(SCLK_Port, SCLK_Pin, GPIO_PIN_RESET) #define SPI_SCLK_HIGH() HAL_GPIO_WritePin(SCLK_Port, SCLK_Pin, GPIO_PIN_SET) #define SPI_MOSI_LOW() HAL_GPIO_WritePin(MOSI_Port, MOSI_Pin, GPIO_PIN_RESET) #define SPI_MOSI_HIGH() HAL_GPIO_WritePin(MOSI_Port, MOSI_Pin, GPIO_PIN_SET) #define SPI_MISO_READ() HAL_GPIO_ReadPin(MISO_Port, MISO_Pin) uint8_t software_spi_transfer(uint8_t byte) { uint8_t received 0; for (int i 7; i 0; i--) { // 先放数据到 MOSIMSB 先出 if (byte (1 i)) { SPI_MOSI_HIGH(); } else { SPI_MOSI_LOW(); } // 拉高 SCLK从设备在上升沿采样 MOSI SPI_SCLK_HIGH(); // 主设备在上升沿之后读取 MISO received (received 1) | SPI_MISO_READ(); // 拉低 SCLK准备下一位 SPI_SCLK_LOW(); } return received; }这段代码在逻辑上是正确的但实际工程里要注意两点第一GPIO 翻转速度。如果 HAL_GPIO_WritePin 内部做了太多检查和寄存器读写每次翻转可能要几百纳秒导致 SCLK 频率上不去。想提高速度可以直接操作寄存器#define SPI_SCLK_HIGH() (GPIOA-BSRR GPIO_PIN_5) #define SPI_SCLK_LOW() (GPIOA-BRR GPIO_PIN_5)第二SCLK 拉高之后不能立刻读 MISO要留一点时间让从设备把数据驱动到 MISO 线上。高速场景下加个__NOP()空指令延时低速场景可以忽略。5.3 软件模拟 SPI 的局限与调试优势软件模拟 SPI 的局限很明显它做不到真正的“同时收发”和高速传输。因为每个 bit 都是靠 GPIO 翻转和延时函数拼出来的SCLK 频率通常只能到几百 kHz 到 1MHz 左右而且 CPU 全程参与没法用 DMA。如果你要驱动高速 SPI Flash 或者跑图形刷屏软件模拟 SPI 基本不现实。但调试上它有个硬件 SPI 比不了的优势每一步都是代码在控制你可以在每一位翻转处打断点观察 MOSI、MISO 电平是否和预期一致。这个特性特别适合定位“从设备没有响应”“数据移位”这类问题。我在调试一款国产 SPI 触摸屏驱动时就是靠软件模拟 SPI 一步一步从寄存器读回数据确认触摸 IC 的 ID 正确后才切换到硬件 SPI 的。5.4 C51、香橙派等平台上的软件模拟 SPI 差异C51 平台做软件模拟 SPI 时注意 51 单片机的 GPIO 是准双向口读外部信号前要先写 1拉高再读。另外 51 的指令周期比较长软件 SPI 的频率会更低但对温湿度传感器这类低速器件够用。香橙派这类 Linux 平台做软件模拟 SPI 就更“重”了。虽然可以用 libgpiod 或者 wiringOP 操作 GPIO但每次 GPIO 翻转都有系统调用开销速度很难上去。更现实的做法是写一个内核模块直接在驱动里操作 GPIO 寄存器或者用 Linux 的spi-gpio驱动把 GPIO 模拟成 SPI 控制器。这个驱动在设备树里配置一下就能用适合做低速调试场景但别指望它跑到几十 MHz。6. 让全双工跑得更顺DMA 与一次传输的数据组织SPI 全双工最大的实战价值在于一次传输你既能发出数据也能收回数据。如果懂得组织数据缓冲SPI 的通信效率会有质的提升。6.1 为什么 SPI 适合配 DMASPI 通信是连续时钟驱动的主设备一旦发起传输SCLK 就会按设定频率持续翻转直到传输结束。如果每个字节都用 CPU 中断处理CPU 需要不断往数据寄存器写发送数据、读接收数据传输频率越高中断越频繁CPU 占用越严重。DMA 的价值在于你只需要配置好发送缓冲、接收缓冲、传输长度DMA 控制器会自动把数据从内存搬到 SPI 数据寄存器、从 SPI 数据寄存器搬到内存。整个过程 CPU 不参与搬运只在传输完成时收到一个中断。在 STM32 平台启用 SPI DMA 发送、DMA 接收CubeMX 里勾选 “SPI TX DMA Request” 和 “SPI RX DMA Request” 就生成了 HAL_SPI_Transmit_DMA 和 HAL_SPI_Receive_DMA 函数。但实战中我更常用的是带收发一起的 DMA 传输——HAL_SPI_TransmitReceive_DMA一次调用同时配置发送和接收 DMA正好利用全双工特性。6.2 一次传输的数据组织把“发”和“收”排布好DMA 传输的效率很大程度取决于你把发送缓冲组织得是否合理。以读 W25Q64 的 100 字节数据为例发送缓冲[0x03][addr2][addr1][addr0][dummy][dummy]...[dummy]共 4 100 104 字节接收缓冲对应 104 字节的位置前 4 字节是垃圾值后 100 字节是有效数据。这种“命令 地址 数据”的连续发送比“先发命令、再发地址、再收数据”三段式操作要快得多因为 CS 全程拉低从设备的状态机连续执行不需要反复等待片选稳定时间。uint8_t txBuf[104]; uint8_t rxBuf[104]; txBuf[0] 0x03; txBuf[1] (address 16) 0xFF; txBuf[2] (address 8) 0xFF; txBuf[3] address 0xFF; for (int i 4; i 104; i) { txBuf[i] 0xFF; // dummy换回 Flash 的输出数据 } HAL_GPIO_WritePin(CS_GPIO_Port, CS_Pin, GPIO_PIN_RESET); HAL_SPI_TransmitReceive_DMA(hspi, txBuf, rxBuf, 104); // 等 DMA 传输完成中断后rxBuf[4] 到 rxBuf[103] 就是有效数据 HAL_GPIO_WritePin(CS_GPIO_Port, CS_Pin, GPIO_PIN_SET);注意 CS 拉高之前一定要确认 DMA 传输完全结束。如果你在 DMA 传输尚未完成时就拉高 CS最后一次传输可能被截断最后几个字节会丢失。可以在 DMA 传输完成回调函数里拉高 CS比在主循环里轮询传输标志更可靠。6.3 CubeMX 配置 SPI 时还要注意的几个参数配置 SPI 外设时除了 CPOL/CPHA还有三个参数决定通信成败一是“Data Size”。大多数 SPI 器件是 8 位数据但有些器件支持 16 位模式。如果从设备寄存器地址和数据是 16 位对齐的配置成 16 位数据长度可以减少指令周期但前提是两边都支持。二是“First Bit”。SPI 通常是 MSB First但个别器件要求 LSB First比如某些 LED 驱动芯片。配置错了整包数据位序颠倒表现和 CPOL/CPHA 配错类似。三是“CRC”。部分 STM32 的 SPI 外设支持硬件 CRC 校验但这东西在绝大多数场景下用不上反而会干扰正常传输。除非你在做高可靠性工业总线否则建议保持关闭。6.4 从全双工到实际项目SPI 转 CAN 的选型思路热搜词里有“rk spi转can”这类方案在嵌入式里很常见MCU 没有多余的 CAN 控制器但需要接 CAN 总线设备于是用 SPI 转 CAN 芯片比如 MCP2515扩展出一个 CAN 接口。这类芯片本质上是“SPI 从设备 CAN 控制器”组合。主设备通过 SPI 往芯片写入发送缓冲区内容、配置滤波器、读取接收缓冲区数据。因为 CAN 总线收发是异步的主设备需要不断轮询 SPI 读芯片的中断/状态寄存器判断有没有新报文到达。在这种场景下SPI 全双工的价值就体现在“一次 SPI 读操作可以同时写入读寄存器命令和接收到寄存器内容”省去了一次单独的写命令操作间接降低了总线占用率。但要注意SPI 转 CAN 芯片的 SCLK 频率通常支持不到太高MCP2515 大概也就 10MHz 左右配置分频时别贪快。如果你在做类似扩展建议把 SPI 读芯片状态寄存器和读接收缓冲区合并成 DMA 批量传输比如一次读 20 字节的接收缓冲主设备只需要发一个读命令和 19 个 dummy 字节就能在传输完成中断里拿到整包 CAN 数据比逐字节中断读取高效得多。7. 最后聊聊那些不太容易被写进文档里的经验SPI 全双工听起来是个很“底层”的概念但真正决定一个 SPI 驱动稳不稳的往往是那些文档里不会细讲的小细节。第一个经验是调 SPI 驱动之前务必准备一个逻辑分析仪。我见过太多工程师凭肉眼猜时序猜半天发现是某个配置位写错了。逻辑分析仪一抓波形CPOL、CPHA、数据位序、片选时序一目了然。几十块钱的 8 通道逻辑分析仪就够用根本不需要买昂贵的示波器。第二个经验是把 SPI 通信的“最小验证程序”单独抽出来。不要一上来就在大工程里调 SPI那样中断、任务调度、其他外设耦合在一起出了问题根本分不清是谁的锅。先写一个裸机小程序只做一件事——初始化 SPI、读从设备的 ID、把 ID 打印到串口。这一步通过了再往大工程里集成问题就会少很多。第三个经验是数据手册一定要看“Timing Characteristics”那一节。SPI 不是把四根线接对了就能跑通它有时序要求SCLK 最高频率多少、CS 拉低到 SCLK 第一个沿的最小时间tCSS、最后一个沿到 CS 拉高的最小时间tCSH、数据建立时间tSU、保持时间tH。这些参数直接影响你配置的分频系数和代码里的延时。我曾经遇到一块国产 Flash标称支持 50MHz实际跑 30MHz 就偶发错误后来把频率降到 20MHz 才稳定。别迷信标称值留足余量才是工程之道。调完一块 SPI 器件后我习惯把它的“模式 最高频率 dummy 字节要求 片选时序要求”记在一个小本子上下次再用同型号器件直接翻本子能省不少重新试错的时间。SPI 的底层魔法说穿了就一句话全双工的收发是同一个时钟驱动的镜子你给它什么节奏它照单全收。真正考验工程师的是你有没有把从设备手册里那几页时序图“翻译”成正确的寄存器配置和代码逻辑。
SPI全双工从底层原理到实战：CPOL/CPHA、片选与DMA避坑指南
调一块 SPI 接口的 2.4 寸 TFT 屏幕插上去白屏折腾了整整一个下午。又是查初始化代码又是量电压最后发现是 CPOL 和 CPHA 填反了就那么一比特的配置差异整块屏就是不工作。从那以后我养成了一个习惯看到“SPI 协议全双工”这几个字先想清楚一件事——全双工到底意味着什么数据在两根线上是怎么“同时”跑的。本文不打算讲那种“SPI 四根线SCLK、MOSI、MISO、CS”的入门科普而是从一个写驱动的人视角把 SPI 全双工从底层原理到实战中容易踩的坑完整捋一遍。适合正在调 SPI 屏幕、Flash、传感器或者被硬件片选和软件片选折腾过的工程师也适合刚学 STM32、香橙派这类平台准备用 SPI 和外部器件通信的开发者。1. 全双工的物理本质两根数据线上的“同时”是怎么发生的很多人理解全双工就是“能同时收和发”但 SPI 能同时收发的底气不是靠什么复杂仲裁机制而是靠物理上独立的收发通道和一套移位寄存器机制。1.1 移位寄存器才是全双工的核心SPI 主设备和从设备内部都有一个移位寄存器。通信时主设备的移位寄存器通过 MOSIMaster Out Slave In线一位一位往从设备里推数据与此同时从设备的移位寄存器通过 MISOMaster In Slave Out线一位一位往主设备里推数据。两根线、两个方向的移位操作由同一个 SCLK 时钟驱动。这个设计有点像两人面对面各拿一条管子中间用一根绳子同步拉——你推出去一颗珠子同时对方也推回来一颗珠子。每一拍时钟主设备“发出一个 bit”并且“收到一个 bit”两个动作在同一时刻完成。这就是全双工的物理本质一对一的收发映射发多少就收多少。我在调试中经常遇到新人问为什么 SPI 读操作要“先发一个字节”才能“读到一个字节”答案就在这个机制里——你发出去的那个字节其实是给从设备提供时钟节拍从设备利用这些时钟节拍把数据推到 MISO 线上。你发的字节本身是什么不重要重要的是你产生了时钟。1.2 主设备发一个字节的时钟里其实也收了一个字节这句话值得单独拿出来强调。SPI 每产生 8 个时钟主设备的接收寄存器里就会多出 8 个 bit。问题是这 8 个 bit 是从设备在这个时间段里推出来的而大多数从设备在收到“读命令”的第一个字节时还没准备好数据所以推回来的往往是 0x00、0xFF 或者无意义的垃圾值。这就引出了一个非常重要的实战心法读操作必须设计“先发无用字节再收有效数据”的节奏。比如要读 W25Q64 的状态寄存器主设备先发 0x05 读命令这个字节的 8 个时钟里W25Q64 回的是 0x00第二个字节开始主设备再发的任意字节通常发 0xFF对应的 8 个时钟里状态寄存器内容才通过 MISO 吐出来。1.3 半双工和全双工的区别不止是“能不能同时”I2C 只有一根 SDA 数据线收发必须分时复用这是半双工。UART 的 RX 和 TX 独立是全双工但它没有时钟线靠双方约定波特率来同步。SPI 比 UART 强的地方在于有独立的 SCLK 时钟线收发节奏完全由主设备控制所以它可以做得比 UART 更高频、更稳定。实际项目里如果用 SPI 和从设备通信但每次收发都像 I2C 一样“先只发、再只收”那就是把全双工用成了半双工通信效率和实时性会打折扣。当然很多从设备的指令协议决定了你没法做到每一拍都收有效数据但至少在传输层你要清楚自己手上拿的是一把全双工的牌。2. 时钟极性 CPOL 和时钟相位 CPHA一串乱码背后的四个模式SPI 的时序参数里最容易让人翻车的就是 CPOL 和 CPHA。我见过不少人在 CubeMX 里随便选了个 Mode 0发现通信不通就把锅甩给“硬件有问题”其实只是时序模板没匹配上从设备的规格。2.1 CPOL 决定空闲电平CPHA 决定采样沿CPOLClock Polarity决定 SCLK 在空闲状态没有数据传输时的电平CPOL0 表示空闲低电平CPOL1 表示空闲高电平。CPHAClock Phase决定数据在哪个边沿被采样CPHA0 表示在第一个边沿采样通常是上升沿CPHA1 表示在第二个边沿采样通常是下降沿。注意“第一个边沿”指的是从空闲切换到非空闲状态后的第一个跳变。排列组合后就得到四种模式模式CPOLCPHA空闲电平采样边沿常见应用Mode 000低上升沿大多数 Flash、传感器Mode 101低下降沿部分音频芯片Mode 210高上升沿部分 LCD 驱动Mode 311高下降沿部分射频芯片、NRF24L012.2 选错模式会发生什么选错 CPOL/CPHA最常见的结果是数据能“动”但全是乱的。比如你发 0x01从设备收到的可能是 0x80甚至有可能是完全无法预测的值。这是因为主设备在错误的时刻去采样 MISO采到的不是稳定的数据电平而是边沿切换瞬间的中间态。我曾经帮同事排查一个 NRF24L01 通信问题他用的模式是 Mode 0NRF24L01 死活读不到寄存器。查数据手册发现NRF24L01 需要 Mode 0 或 Mode 1但它的 SPI 时序要求从设备输出数据在时钟下降沿之后稳定。检查波形后发现主设备在上升沿采样而 NRF24L01 的输出数据刚好在上升沿前后变化导致采样不稳。改成 Mode 1下降沿采样后问题立解。2.3 怎么快速判断该用哪个模式最靠谱的方式是直接看从设备数据手册里的时序图。看 SCLK 空闲时是高还是低确定 CPOL看数据在哪个边沿稳定、哪个边沿变化或者看手册里“Data Setup”“Data Hold”相对哪个沿描述确定 CPHA。如果手头有逻辑分析仪抓一下从设备输出数据线和 SCLK 的波形对比数据手册里的采样窗口一抓一个准。没有逻辑分析仪时可以把四种模式都试一遍看哪个模式能读到预期的数据。我在调试未知器件时会在代码里做一个“模式扫描”循环切换四种模式读同一个寄存器能读出数据手册标注的默认值就是对的模式。2.4 CubeMX 里的配置细节在 CubeMX 里配置 SPI 时有“Clock Polarity”和“Clock Phase”两个下拉框对应 CPOL 和 CPHA。很多人直接选 Low/First Edge也就是 Mode 0然后就不管了。这个默认值对于 W25Q64、GD25Q128E 这类 Flash 是没问题的但遇到其他器件时一定要查手册。还有一个容易被忽略的参数BaudRate Prescaler。SPI 时钟不是想多快就多快从设备支持的 SCLK 频率上限会写在数据手册里。比如 W25Q64 支持最高 80MHz但如果你用 STM32F103 的 APB2 时钟 72MHz分频配置不当SCLK 实际频率可能超出从设备支持范围。别只看“能通”还要看“稳不稳”。3. 硬件片选与软件片选自动和手动之间的可靠性博弈片选CS/SS/NSS是 SPI 通信的“门禁”谁被拉低谁就参与通信。但片选的实现方式硬件片选和软件片选在实战中带来的问题完全不一样。3.1 硬件片选的便利与陷阱硬件片选是指 MCU 的 SPI 外设自动控制 NSS 引脚。你只管往数据寄存器里写数据外设在传输开始前自动把 NSS 拉低传输结束后自动拉高。听起来很省心但这里有个坑有些 MCU 的硬件 NSS 模式会和“多主机错误检测”绑定。比如 STM32NSS 硬件模式Hardware NSS Output如果配置不当NSS 引脚上的电平变化会被 SPI 外设理解成“总线上有多个主机抢占”从而触发 MODF 错误通信直接中断。我在 STM32F103 上就遇到过这个问题。配置成 Hardware NSS Output 模式后只要从设备占用总线时间长一点SPI 就报 MODF。后来改成 Hardware NSS Input 模式用外部 GPIO 手动控制片选反而稳定了。所以我的建议是除非你确定外设的硬件 NSS 行为和你用的从设备完全匹配否则别迷信硬件片选。更多时候软件片选GPIO 手动拉低/拉高反而更可控。3.2 软件片选灵活但有三个前提软件片选就是用普通 GPIO 控制从设备的 CS 引脚。它的好处是可以任意选择引脚而且拉低/拉高的时机完全由你掌控对多从设备总线特别友好。但有三个前提第一片选拉低后不能马上就开始发数据。从设备从 CS 拉低到准备好接收数据需要一小段时间tCSSChip Select Setup Time。如果 CS 刚拉低就立刻送 SCLK有些从设备会漏掉前面的 bit。解决方法是加一个微秒级别的延时或者利用从设备的“CS 拉低后先等一点时间”的要求。第二片选拉高之前要确保最后一个 bit 已经完全送出。特别是高速 SP I 通信时如果数据寄存器写完不等于移位寄存器送完你立刻拉高 CS最后一个 bit 传输会被截断。第三软件片选和 GPIO 翻转速度要匹配。这在 Linux 平台特别明显通过 GPIO 子系统拉低/拉高一个引脚中间可能有系统调用、驱动框架的开销延迟比 MCU 裸机上的 GPIO 操作大得多。如果你用软件片选配合高速 SPI比如 10MHz 以上GPIO 的翻转延迟会让从设备误判片选时序。3.3 Linux 下软件拉片选的实操经验热搜词里有一条“linux spi 软件拉片选”这确实是 Linux 下 SPI 开发容易踩坑的地方。Linux SPI 子系统提供了设备树里cs-gpios属性可以指定用 GPIO 来做片选。但实际操作中GPIO 片选和 SPI 控制器内置片选的行为并不完全一致。内置片选由 SPI 控制器硬件自动控制和 SCLK 严格同步GPIO 片选由驱动代码控制软件操作和时间点之间可能有几十微秒的延迟。我在香橙派 Zero3 上调 SPI 时发现用 GPIO 片选连接一块 Flash每次读数据都偶发失败。用示波器看波形CS 拉低之后 SCLK 并没有立即开始中间有几微秒的空白。这个空白对慢速器件没影响但对某些对时序敏感的从设备就是致命问题。最后通过给 SPI 驱动打补丁在 GPIO 片选控制里增加udelay才把问题解决。在 MCU 裸机开发中软件片选同样需要注意如果你的主循环和 SPI 传输之间插了太多中断处理CS 的拉低和 SCLK 启动之间的间隔可能不稳定。这种情况下可以考虑用定时器中断来精确控制片选时序或者干脆在 SPI 传输函数内直接操作 GPIO减少中间层。3.4 多从设备场景下的片选策略多从设备共用一个 SPI 总线时片选策略尤其重要。基本原则是同一时刻只能有一个从设备的 CS 被拉低否则两个从设备都会在 MISO 上输出数据造成总线冲突。我在 RK 平台做“SPI 转 CAN”扩展时总线上挂了两个 SPI 转 CAN 模块一个 SPI 转 UART 模块。这时候如果依赖硬件 NSS每个外设都要占用一个硬件 NSS 引脚引脚不够用改用 GPIO 软件片选后三个模块只需要一个 SPI 外设和三个 GPIO扩展性就好多了。多从设备切换时还要注意从一个从设备切换到另一个从设备中间至少留一个“总线空闲时间”让前一个从设备彻底释放 MISO。有些从设备在 CS 拉高后不会立刻停止驱动 MISO需要几个时钟周期的缓冲。可以用“先拉高 CS再发 8 个空时钟再拉低下一个 CS”的方式来隔离。4. 从 W25Q64 看全双工主设备发什么才能换回数据W25Q64 和 GD25Q128E 这类 SPI Flash 是学习 SPI 最好的“教具”因为它们的状态机设计得很经典清晰展示了 SPI 全双工下“主设备发什么、从设备回什么”的完整逻辑。4.1 读 JEDEC ID 的完整时序读 JEDEC ID 是验证 SPI Flash 通信是否正常的首选操作。W25Q64 的读 ID 指令是 0x9F。以下是完整时序主设备拉低 CS主设备发送 0x9F读 ID 指令主设备发送任意字节通常 0x00 或 0xFF从设备回传 Manufacturer ID对于 Winbond 是 0xEF主设备继续发送任意字节从设备回传 Memory Type对于 W25Q64 是 0x40主设备再发送任意字节从设备回传 Capacity CodeW25Q64 是 0x17主设备拉高 CS。用代码表示就是连续三次 HAL_SPI_TransmitReceiveuint8_t cmd 0x9F; uint8_t dummy 0xFF; uint8_t rxBuf[3] {0}; HAL_GPIO_WritePin(CS_GPIO_Port, CS_Pin, GPIO_PIN_RESET); HAL_SPI_Transmit(hspi, cmd, 1, HAL_MAX_DELAY); HAL_SPI_TransmitReceive(hspi, dummy, rxBuf[0], 1, HAL_MAX_DELAY); HAL_SPI_TransmitReceive(hspi, dummy, rxBuf[1], 1, HAL_MAX_DELAY); HAL_SPI_TransmitReceive(hspi, dummy, rxBuf[2], 1, HAL_MAX_DELAY); HAL_GPIO_WritePin(CS_GPIO_Port, CS_Pin, GPIO_PIN_SET);如果你读出来的 ID 是 0x00 或者 0xFF先别急着重焊芯片回头检查 CS 有没有拉低、模式是不是 Mode 0 或 Mode 3、SCLK 频率是不是太高。这三个问题占了 SPI Flash 通信失败原因的八成。4.2 从设备的“半双工式应答”全双工的另一层含义值得说清楚的是虽然 SPI 总线物理上是全双工的但很多从设备包括 W25Q64内部逻辑是“半双工式”的它们在一个时刻要么处理接收要么准备发送不会边收边算。比如读数据指令 0x03 3 字节地址发送期间Flash 内部在解析地址、准备数据此时 MISO 上回的是垃圾值等地址解析完毕后续每个时钟才从数据缓冲区里往外吐数据。所以理解 SPI 全双工要拆成两层物理层MOSI 和 MISO 同时传输每个时钟同时收发一个 bit协议层从设备可能“用完你的时钟才给你回数据”你发出去的 dummy 字节本质上是在“买时间”。这个理解非常关键。设计驱动时你不能想当然地认为“我发一个读命令马上就能读回数据”而是要把命令发送和实际数据读取之间的“时间差”考虑进去。4.3 写使能、读状态寄存器与全双工读写的配合SPI Flash 写操作还涉及一个常见的全双工协作场景。写 Flash 前要先发 0x06Write Enable然后发 0x02Page Program或 0x02 带地址数据最后还要轮询读状态寄存器0x05等 WIPWrite In Progress位从 1 变成 0。轮询状态寄存器时很多人会这样写uint8_t cmdReadStatus 0x05; uint8_t status 0xFF; do { HAL_GPIO_WritePin(CS_GPIO_Port, CS_Pin, GPIO_PIN_RESET); HAL_SPI_Transmit(hspi, cmdReadStatus, 1, HAL_MAX_DELAY); HAL_SPI_TransmitReceive(hspi, dummy, status, 1, HAL_MAX_DELAY); HAL_GPIO_WritePin(CS_GPIO_Port, CS_Pin, GPIO_PIN_SET); } while (status 0x01);这里有个细节读状态寄存器时主设备发的第二个字节必须是“任意有效的时钟”但如果你想一次性完成“发命令 读数据”完全可以把 0x05 和 dummy 字节合并成一个 2 字节的 TransmitReceiveuint8_t txBuf[2] {0x05, 0xFF}; uint8_t rxBuf[2] {0}; HAL_GPIO_WritePin(CS_GPIO_Port, CS_Pin, GPIO_PIN_RESET); HAL_SPI_TransmitReceive(hspi, txBuf, rxBuf, 2, HAL_MAX_DELAY); HAL_GPIO_WritePin(CS_GPIO_Port, CS_Pin, GPIO_PIN_SET); status rxBuf[1]; // 第二个字节是从设备回的状态这样一次传输就完成了命令发送和数据读取效率更高也更符合“全双工”的设计理念。4.4 读操作的“垃圾字节”技巧最后分享一个读操作的小技巧。很多从设备的读操作主设备发的 dummy 字节内容不影响从设备输出。但有些器件对 dummy 字节有要求比如有些 ADC 芯片要求 dummy 必须是 0x00有些传感器要求 0xFF。查数据手册时看到“Dont Care”字样可以随便发但看到“Should be 0x00”这类字样就不能乱来。我在调 AD7124 这类 ADC 时就吃过 dummy 字节填错的亏。AD7124 的通信寄存器读操作后面跟的 dummy 字节如果非 0x00读出来的数据会偏移一位。后来把所有 dummy 都统一改成 0x00问题消失。所以dummy 字节不是“真随便”它需要配合具体器件的规格来定。5. 软件模拟 SPI没有硬件外设时的保底方案不是所有平台都有硬件 SPI 外设也不是所有场景都适合用硬件 SPI。软件模拟 SPIGPIO 位操作在很多项目里依然是刚需。5.1 什么时候该用软件模拟 SPI引脚不够硬件 SPI 引脚被其他功能占用或者你需要把引脚映射到非 SPI 引脚上非标准时序从设备对时序有特殊要求比如需要很慢的 SCLK、特殊的空闲电平硬件 SPI 配不出来调试阶段软件 SPI 的每一步都可以打断点观察排查时序问题比硬件 SPI 直观C51、Arduino 这类简单平台没有硬件 SPI 或者硬件 SPI 用起来不够灵活。5.2 一个可用的软件模拟 SPI 实现以最常用的 Mode 0CPOL0CPHA0为例空闲时 SCLK 为低数据在上升沿采样所以主设备应该在 SCLK 拉低时把数据放到 MOSI 上然后拉高 SCLK让从设备采样。#define SPI_SCLK_LOW() HAL_GPIO_WritePin(SCLK_Port, SCLK_Pin, GPIO_PIN_RESET) #define SPI_SCLK_HIGH() HAL_GPIO_WritePin(SCLK_Port, SCLK_Pin, GPIO_PIN_SET) #define SPI_MOSI_LOW() HAL_GPIO_WritePin(MOSI_Port, MOSI_Pin, GPIO_PIN_RESET) #define SPI_MOSI_HIGH() HAL_GPIO_WritePin(MOSI_Port, MOSI_Pin, GPIO_PIN_SET) #define SPI_MISO_READ() HAL_GPIO_ReadPin(MISO_Port, MISO_Pin) uint8_t software_spi_transfer(uint8_t byte) { uint8_t received 0; for (int i 7; i 0; i--) { // 先放数据到 MOSIMSB 先出 if (byte (1 i)) { SPI_MOSI_HIGH(); } else { SPI_MOSI_LOW(); } // 拉高 SCLK从设备在上升沿采样 MOSI SPI_SCLK_HIGH(); // 主设备在上升沿之后读取 MISO received (received 1) | SPI_MISO_READ(); // 拉低 SCLK准备下一位 SPI_SCLK_LOW(); } return received; }这段代码在逻辑上是正确的但实际工程里要注意两点第一GPIO 翻转速度。如果 HAL_GPIO_WritePin 内部做了太多检查和寄存器读写每次翻转可能要几百纳秒导致 SCLK 频率上不去。想提高速度可以直接操作寄存器#define SPI_SCLK_HIGH() (GPIOA-BSRR GPIO_PIN_5) #define SPI_SCLK_LOW() (GPIOA-BRR GPIO_PIN_5)第二SCLK 拉高之后不能立刻读 MISO要留一点时间让从设备把数据驱动到 MISO 线上。高速场景下加个__NOP()空指令延时低速场景可以忽略。5.3 软件模拟 SPI 的局限与调试优势软件模拟 SPI 的局限很明显它做不到真正的“同时收发”和高速传输。因为每个 bit 都是靠 GPIO 翻转和延时函数拼出来的SCLK 频率通常只能到几百 kHz 到 1MHz 左右而且 CPU 全程参与没法用 DMA。如果你要驱动高速 SPI Flash 或者跑图形刷屏软件模拟 SPI 基本不现实。但调试上它有个硬件 SPI 比不了的优势每一步都是代码在控制你可以在每一位翻转处打断点观察 MOSI、MISO 电平是否和预期一致。这个特性特别适合定位“从设备没有响应”“数据移位”这类问题。我在调试一款国产 SPI 触摸屏驱动时就是靠软件模拟 SPI 一步一步从寄存器读回数据确认触摸 IC 的 ID 正确后才切换到硬件 SPI 的。5.4 C51、香橙派等平台上的软件模拟 SPI 差异C51 平台做软件模拟 SPI 时注意 51 单片机的 GPIO 是准双向口读外部信号前要先写 1拉高再读。另外 51 的指令周期比较长软件 SPI 的频率会更低但对温湿度传感器这类低速器件够用。香橙派这类 Linux 平台做软件模拟 SPI 就更“重”了。虽然可以用 libgpiod 或者 wiringOP 操作 GPIO但每次 GPIO 翻转都有系统调用开销速度很难上去。更现实的做法是写一个内核模块直接在驱动里操作 GPIO 寄存器或者用 Linux 的spi-gpio驱动把 GPIO 模拟成 SPI 控制器。这个驱动在设备树里配置一下就能用适合做低速调试场景但别指望它跑到几十 MHz。6. 让全双工跑得更顺DMA 与一次传输的数据组织SPI 全双工最大的实战价值在于一次传输你既能发出数据也能收回数据。如果懂得组织数据缓冲SPI 的通信效率会有质的提升。6.1 为什么 SPI 适合配 DMASPI 通信是连续时钟驱动的主设备一旦发起传输SCLK 就会按设定频率持续翻转直到传输结束。如果每个字节都用 CPU 中断处理CPU 需要不断往数据寄存器写发送数据、读接收数据传输频率越高中断越频繁CPU 占用越严重。DMA 的价值在于你只需要配置好发送缓冲、接收缓冲、传输长度DMA 控制器会自动把数据从内存搬到 SPI 数据寄存器、从 SPI 数据寄存器搬到内存。整个过程 CPU 不参与搬运只在传输完成时收到一个中断。在 STM32 平台启用 SPI DMA 发送、DMA 接收CubeMX 里勾选 “SPI TX DMA Request” 和 “SPI RX DMA Request” 就生成了 HAL_SPI_Transmit_DMA 和 HAL_SPI_Receive_DMA 函数。但实战中我更常用的是带收发一起的 DMA 传输——HAL_SPI_TransmitReceive_DMA一次调用同时配置发送和接收 DMA正好利用全双工特性。6.2 一次传输的数据组织把“发”和“收”排布好DMA 传输的效率很大程度取决于你把发送缓冲组织得是否合理。以读 W25Q64 的 100 字节数据为例发送缓冲[0x03][addr2][addr1][addr0][dummy][dummy]...[dummy]共 4 100 104 字节接收缓冲对应 104 字节的位置前 4 字节是垃圾值后 100 字节是有效数据。这种“命令 地址 数据”的连续发送比“先发命令、再发地址、再收数据”三段式操作要快得多因为 CS 全程拉低从设备的状态机连续执行不需要反复等待片选稳定时间。uint8_t txBuf[104]; uint8_t rxBuf[104]; txBuf[0] 0x03; txBuf[1] (address 16) 0xFF; txBuf[2] (address 8) 0xFF; txBuf[3] address 0xFF; for (int i 4; i 104; i) { txBuf[i] 0xFF; // dummy换回 Flash 的输出数据 } HAL_GPIO_WritePin(CS_GPIO_Port, CS_Pin, GPIO_PIN_RESET); HAL_SPI_TransmitReceive_DMA(hspi, txBuf, rxBuf, 104); // 等 DMA 传输完成中断后rxBuf[4] 到 rxBuf[103] 就是有效数据 HAL_GPIO_WritePin(CS_GPIO_Port, CS_Pin, GPIO_PIN_SET);注意 CS 拉高之前一定要确认 DMA 传输完全结束。如果你在 DMA 传输尚未完成时就拉高 CS最后一次传输可能被截断最后几个字节会丢失。可以在 DMA 传输完成回调函数里拉高 CS比在主循环里轮询传输标志更可靠。6.3 CubeMX 配置 SPI 时还要注意的几个参数配置 SPI 外设时除了 CPOL/CPHA还有三个参数决定通信成败一是“Data Size”。大多数 SPI 器件是 8 位数据但有些器件支持 16 位模式。如果从设备寄存器地址和数据是 16 位对齐的配置成 16 位数据长度可以减少指令周期但前提是两边都支持。二是“First Bit”。SPI 通常是 MSB First但个别器件要求 LSB First比如某些 LED 驱动芯片。配置错了整包数据位序颠倒表现和 CPOL/CPHA 配错类似。三是“CRC”。部分 STM32 的 SPI 外设支持硬件 CRC 校验但这东西在绝大多数场景下用不上反而会干扰正常传输。除非你在做高可靠性工业总线否则建议保持关闭。6.4 从全双工到实际项目SPI 转 CAN 的选型思路热搜词里有“rk spi转can”这类方案在嵌入式里很常见MCU 没有多余的 CAN 控制器但需要接 CAN 总线设备于是用 SPI 转 CAN 芯片比如 MCP2515扩展出一个 CAN 接口。这类芯片本质上是“SPI 从设备 CAN 控制器”组合。主设备通过 SPI 往芯片写入发送缓冲区内容、配置滤波器、读取接收缓冲区数据。因为 CAN 总线收发是异步的主设备需要不断轮询 SPI 读芯片的中断/状态寄存器判断有没有新报文到达。在这种场景下SPI 全双工的价值就体现在“一次 SPI 读操作可以同时写入读寄存器命令和接收到寄存器内容”省去了一次单独的写命令操作间接降低了总线占用率。但要注意SPI 转 CAN 芯片的 SCLK 频率通常支持不到太高MCP2515 大概也就 10MHz 左右配置分频时别贪快。如果你在做类似扩展建议把 SPI 读芯片状态寄存器和读接收缓冲区合并成 DMA 批量传输比如一次读 20 字节的接收缓冲主设备只需要发一个读命令和 19 个 dummy 字节就能在传输完成中断里拿到整包 CAN 数据比逐字节中断读取高效得多。7. 最后聊聊那些不太容易被写进文档里的经验SPI 全双工听起来是个很“底层”的概念但真正决定一个 SPI 驱动稳不稳的往往是那些文档里不会细讲的小细节。第一个经验是调 SPI 驱动之前务必准备一个逻辑分析仪。我见过太多工程师凭肉眼猜时序猜半天发现是某个配置位写错了。逻辑分析仪一抓波形CPOL、CPHA、数据位序、片选时序一目了然。几十块钱的 8 通道逻辑分析仪就够用根本不需要买昂贵的示波器。第二个经验是把 SPI 通信的“最小验证程序”单独抽出来。不要一上来就在大工程里调 SPI那样中断、任务调度、其他外设耦合在一起出了问题根本分不清是谁的锅。先写一个裸机小程序只做一件事——初始化 SPI、读从设备的 ID、把 ID 打印到串口。这一步通过了再往大工程里集成问题就会少很多。第三个经验是数据手册一定要看“Timing Characteristics”那一节。SPI 不是把四根线接对了就能跑通它有时序要求SCLK 最高频率多少、CS 拉低到 SCLK 第一个沿的最小时间tCSS、最后一个沿到 CS 拉高的最小时间tCSH、数据建立时间tSU、保持时间tH。这些参数直接影响你配置的分频系数和代码里的延时。我曾经遇到一块国产 Flash标称支持 50MHz实际跑 30MHz 就偶发错误后来把频率降到 20MHz 才稳定。别迷信标称值留足余量才是工程之道。调完一块 SPI 器件后我习惯把它的“模式 最高频率 dummy 字节要求 片选时序要求”记在一个小本子上下次再用同型号器件直接翻本子能省不少重新试错的时间。SPI 的底层魔法说穿了就一句话全双工的收发是同一个时钟驱动的镜子你给它什么节奏它照单全收。真正考验工程师的是你有没有把从设备手册里那几页时序图“翻译”成正确的寄存器配置和代码逻辑。
