STM32 SPI双机通信详解

STM32 SPI双机通信技术深度解析

在现代嵌入式系统中，多MCU协同工作已成常态。无论是工业控制中的主控与执行单元通信，还是传感器网络中数据汇聚的需求，稳定高效的设备间通信都至关重要。当需要在两个STM32微控制器之间实现高速、低延迟的数据交换时，SPI（Serial Peripheral Interface）往往成为首选方案——它不像UART那样受限于速率和方向切换，也不像I²C那样受总线竞争和地址冲突的困扰。

而真正让SPI脱颖而出的是它的 全双工同步机制 ：同一时刻，主从双方可以同时发送与接收数据。这种特性使得STM32之间的SPI双机通信不仅效率高，而且时序可控性强，非常适合对实时性要求较高的场景。比如，在一个电机控制系统中，主MCU负责调度指令，从MCU采集编码器反馈并回传状态，通过SPI可在几微秒内完成一次闭环交互。

要让这样的通信可靠运行，并非简单连接四根线就能搞定。实际开发中，开发者常遇到“明明代码写得一样，却收不到正确数据”、“偶尔出现BUSY标志卡死”等问题。这些问题背后，往往是时钟极性配置不匹配、NSS管理混乱或DMA缓冲区处理不当等细节所致。

---

SPI的本质是一对移位寄存器的双向联动。主机每发出一个SCK脉冲，就将MOSI线上的一位数据推送给从机；与此同时，从机也通过MISO线回传一位数据。这个过程在每个时钟周期并行发生，形成真正的全双工通信。整个流程由四个关键信号驱动：

• SCK ：时钟源来自主机，决定了通信速率；
• MOSI/MISO ：分别承载下行与上行数据流；
• NSS（片选） ：虽名为“片选”，但在双机通信中更多是通信启动的同步信号。

值得注意的是，虽然标准SPI支持多从机架构，但在两台STM32互联的应用中，通常采用 单主单从模式 ，即一方固定为主机（Master），另一方为从机（Slave）。这是因为SPI协议本身没有仲裁机制，若双方同时尝试发起通信，极易导致总线冲突。即便某些型号支持双主模式，也需要额外的外部逻辑进行协调，反而增加了复杂度。

真正影响通信成败的核心参数是 CPOL（时钟极性）和CPHA（时钟相位） 的组合。这二者共同定义了四种工作模式：

模式	CPOL	CPHA	数据采样边沿
0	0	0	第一个上升沿
1	0	1	第二个下降沿
2	1	0	第一个下降沿
3	1	1	第二个上升沿

假设主从设备分别设置为Mode 0和Mode 1，即使物理连接无误，也会因为采样时机错位而导致接收到的数据完全错误。因此， 主从必须严格保持CPOL和CPHA一致 ，这是调试中最容易忽视却又最关键的一步。

以STM32F1系列为例，其SPI模块挂载在APB总线上，SPI1位于高速APB2（最高72MHz），其余SPI接口则位于APB1。这意味着SPI1理论上可支持高达36MHz的SCK频率（PCLK/2）。然而，从机能否跟上这一速度，取决于其CPU响应中断的能力以及SPI外设的处理延迟。实践中建议初始调试时将波特率预分频设为256，即SCK ≈ 280kHz（72MHz / 256），待通信稳定后再逐步提升速率。

硬件层面，引脚配置不容小觑。MOSI、SCK和NSS应配置为复用推挽输出，MISO则需设为浮空输入（或带上拉的输入模式），确保信号完整性。尤其在长距离布线或噪声环境中，可在SCK和数据线上串联33Ω电阻以抑制反射。此外，务必保证两地共地良好，否则微弱的电平差异可能导致采样失败。

软件实现上，使用HAL库能显著降低开发门槛。以下是一个典型的主机初始化配置：

SPI_HandleTypeDef hspi1;

void MX_SPI1_Init(void)
{
    hspi1.Instance = SPI1;
    hspi1.Init.Mode = SPI_MODE_MASTER;
    hspi1.Init.Direction = SPI_DIRECTION_2LINES;
    hspi1.Init.DataSize = SPI_DATASIZE_8BIT;
    hspi1.Init.CLKPolarity = SPI_POLARITY_LOW;
    hspi1.Init.CLKPhase = SPI_PHASE_1EDGE;   // Mode 0
    hspi1.Init.NSS = SPI_NSS_SOFT;
    hspi1.Init.BaudRatePrescaler = SPI_BAUDRATEPRESCALER_64;
    hspi1.Init.FirstBit = SPI_FIRSTBIT_MSB;
    HAL_SPI_Init(&hspi1);
}

从机端只需将 SPI_MODE_MASTER 改为 SPI_MODE_SLAVE ，其余参数保持一致即可。特别提醒：即使是从机，也推荐使用 软件NSS模式 （SPI_NSS_SOFT），并通过外部GPIO感知通信起始。这样可以避免因硬件NSS自动检测带来的误触发问题，尤其是在系统复位或电源波动期间。

通信函数的设计直接影响可靠性。很多人直接调用 HAL_SPI_Transmit() 后便认为数据已送达，却忽略了从机可能尚未准备好接收。更稳健的做法是使用 HAL_SPI_TransmitReceive() ，强制完成一次完整的字节交换，并手动控制NSS电平：

uint8_t spi_transfer(uint8_t tx_data)
{
    uint8_t rx_data;
    HAL_StatusTypeDef status;

    HAL_GPIO_WritePin(SPI_NSS_PORT, SPI_NSS_PIN, GPIO_PIN_RESET);  // 拉低片选
    status = HAL_SPI_TransmitReceive(&hspi1, &tx_data, &rx_data, 1, 100);
    HAL_GPIO_WritePin(SPI_NSS_PORT, SPI_NSS_PIN, GPIO_PIN_SET);     // 拉高释放

    if (status != HAL_OK) {
        Error_Handler();
    }

    return rx_data;
}

这里设置100ms超时非常关键。一旦SPI陷入BUSY状态（如从机未及时读取DR寄存器），函数会及时退出而非无限等待，防止系统卡死。

说到BUSY标志异常，这是现场最常见的故障之一。现象表现为：主机发送后， SPI_SR 中的 BSY 位一直为1，无法继续通信。排查思路如下：

1. 检查从机是否及时读取SPI_DR
   当从机接收到一字节后，RXNE标志置位，但如果不立即读取DR寄存器，下一轮数据就会覆盖前值，甚至引发溢出错误（OVR标志）。尤其在轮询方式下，若主循环中有延时操作，很容易错过最佳读取时机。

2. 确认主从模式对称性
   曾有案例显示，主机使用DMA发送，而从机用中断接收，结果DMA传输完成后主机立刻释放NSS，导致最后一个字节还未完全移入从机DR就被截断。解决办法是在主机侧加入适当的延时，或改用DMA双通道配合完成标志同步。

3. 警惕FIFO溢出（部分高端型号）
   虽然F1系列无FIFO，但F4/L4等型号具备16级缓冲。若程序未及时清空接收缓冲，连续高速通信时可能发生溢出。此时应启用RXNE中断或DMA搬运，避免数据堆积。

另一个典型问题是“只能单向通信”。表面上看MOSI有数据输出，MISO却始终为0xFF或随机值。此时应重点检查三点：
- MISO线路是否反接？常见于PCB设计失误；
- 从机是否启用了MISO输出功能？某些配置错误会导致SPI处于单线模式；
- 主机是否误用了 Transmit() 而非 TransmitReceive() ？后者才会触发SCK时钟，前者在某些条件下可能静默执行。

对于大数据量传输场景，如音频流或图像帧传递，强烈建议启用DMA。STM32的SPI外设天然支持DMA请求，只需开启 CR2 中的TXEIE和RXNEIE中断，并绑定对应DMA通道，即可实现零CPU干预的批量传输。例如，使用DMA双缓冲机制，可在后台持续收发数据的同时，前台处理已接收的数据块，极大提升吞吐效率。

当然，再好的硬件也需要合理的协议支撑。裸SPI只负责字节传送，不包含任何校验或帧界定机制。因此应用层需自行设计通信协议。一个简洁有效的做法是采用定长帧+XOR校验：

[命令码][数据低][数据高][校验和]

主机发送0x01查询温度，从机返回当前ADC值，并计算前三字节的异或作为第四字节。主机收到后重新计算校验，若不符则重试。配合超时重传机制，可大幅提升链路鲁棒性。

PCB布局方面也有讲究。理想情况下，SCK与MOSI/MISO走线尽量等长，减少 skew 带来的时序偏差；远离SWD调试接口、PWM输出等高频干扰源；必要时在电源入口加磁珠和去耦电容，抑制数字噪声串扰。

最后提一点经验之谈： 永远不要依赖“默认状态” 。有些开发者认为只要两边都用HAL库初始化，默认配置应该兼容。但实际上不同工程模板或CubeMX版本可能导致细微差异。最稳妥的方式是明确写出所有关键参数，哪怕看起来冗余，也要确保主从完全对齐。

---

正是这些看似琐碎的细节，决定了SPI通信是“稳定如钟”还是“时通时断”。当你看到示波器上整齐划一的SCK波形，MISO与MOSI数据精准对齐，那一刻你会明白：嵌入式系统的魅力，不仅在于功能实现，更在于对每一个时钟边沿的精确掌控。

这种高度集成且可控的通信方式，正推动着智能设备向更高层次的协同演进。未来随着RISC-V架构MCU的普及，跨平台SPI互连将成为常态，而今天掌握的这些底层原理，将是跨越生态壁垒的坚实桥梁。