告别全双工烦恼：在STM32与Hi3516间实现SPI“伪半双工”通信的保姆级指南

嵌入式SPI通信实战：从全双工到高效伪半双工的协议设计革新

在嵌入式系统开发中，SPI总线因其简单高效的特性成为芯片间通信的首选方案之一。但当面对主从设备需要频繁进行一问一答式交互的场景时，标准的全双工SPI通信反而可能成为性能瓶颈。本文将分享一种创新的"伪半双工"协议设计方法，通过软件逻辑改造硬件全双工的SPI总线，实现更稳定、更高效的通信架构。

1. 传统SPI通信的痛点与突破思路

许多工程师第一次接触SPI总线时，都会被其"全双工"特性所吸引——主机和从机可以同时收发数据，理论上能够实现更高的带宽利用率。但在实际项目开发中，特别是主从设备采用问答式交互的系统中，这种特性反而带来了诸多挑战。

1.1 全双工SPI的典型问题

• 数据污染问题：主机发送命令时，从机必须同时返回数据，即使此时从机并无有效数据可发
• DMA配置耦合：发送和接收缓冲区大小必须严格匹配，否则会导致数据错位或丢失
• 资源浪费：无效数据占用了宝贵的总线时间和处理资源

我在最近的一个智能传感器项目中就遇到了这样的困境：STM32作为从机需要向Hi3516主机上报数据，但主机80%的时间都在发送控制命令，从机大部分回复都是无效填充数据。

1.2 伪半双工的核心思想

经过多次实验和方案迭代，我们提炼出"伪半双工"通信的三大设计原则：

1. 状态隔离：明确划分发送和接收状态，避免同时操作
2. 硬件辅助：利用NOTIFY引脚实现主从协同
3. 弹性缓冲：动态调整DMA缓冲区大小适应不同场景

注意：所谓"伪半双工"并非真正的半双工硬件模式，而是在全双工硬件基础上通过协议实现的逻辑半双工

2. 硬件架构与信号设计

实现可靠的伪半双工通信，需要精心设计硬件接口和信号交互机制。下面是我们在一个工业级项目中的实际硬件配置方案。

2.1 主从设备连接拓扑

2.2 关键硬件设计要点

1. NOTIFY引脚的必要性：

   • 从机通过拉高NOTIFY向主机请求发送机会
   • 主机需定期轮询NOTIFY状态（建议周期<1ms）
   • 硬件消抖电路可提升信号稳定性

2. 信号完整性优化：

   // STM32端GPIO配置示例（以HAL库为例） GPIO_InitTypeDef GPIO_InitStruct = {0}; GPIO_InitStruct.Pin = SPI_NOTIFY_PIN; GPIO_InitStruct.Mode = GPIO_MODE_OUTPUT_PP; GPIO_InitStruct.Pull = GPIO_NOPULL; GPIO_InitStruct.Speed = GPIO_SPEED_FREQ_LOW; // 降低输出速度减少过冲 HAL_GPIO_Init(SPI_NOTIFY_PORT, &GPIO_InitStruct);

3. 阻抗匹配建议：

   • 对于PCB走线长度>10cm的应用
   • 在SCLK和MOSI上串联22-100Ω电阻
   • 使用示波器观察信号过冲情况调整阻值

3. 软件状态机设计与实现

伪半双工通信的核心在于精确的状态管理。我们设计了一套基于事件驱动的主从协同状态机，下面详细解析其工作原理。

3.1 从机状态机实现

// 从机状态定义 typedef enum { SPI_STATE_IDLE, // 空闲状态 SPI_STATE_RECEIVING, // 接收数据中 SPI_STATE_SENDING, // 发送数据中 SPI_STATE_WAIT_TX // 等待发送机会 } SPI_StateTypeDef; // 状态转换条件判断 void SPI_StateMachine_Update(void) { static uint32_t last_tick = 0; uint32_t current_tick = HAL_GetTick(); // 状态超时处理（防止死锁） if((current_tick - last_tick) > STATE_TIMEOUT_MS) { current_state = SPI_STATE_IDLE; HAL_GPIO_WritePin(NOTIFY_GPIO_Port, NOTIFY_Pin, GPIO_PIN_RESET); } switch(current_state) { case SPI_STATE_IDLE: if(has_data_to_send()) { current_state = SPI_STATE_WAIT_TX; last_tick = current_tick; } break; case SPI_STATE_WAIT_TX: if(!is_receiving_data()) { HAL_GPIO_WritePin(NOTIFY_GPIO_Port, NOTIFY_Pin, GPIO_PIN_SET); current_state = SPI_STATE_SENDING; last_tick = current_tick; } break; // 其他状态处理... } }

3.2 主机侧处理逻辑

主机作为通信的主动方，需要特别处理好NOTIFY信号的检测和状态切换：

1. 发送前检查：

   bool Host_CanTransmit(void) { return (HAL_GPIO_ReadPin(NOTIFY_GPIO_Port, NOTIFY_Pin) == GPIO_PIN_RESET); }

2. NOTIFY响应机制：

   • 检测到NOTIFY变高后，主机应在1ms内启动SPI接收
   • 接收长度应匹配从机的发送缓冲区大小
   • 接收完成后主动拉低CS信号通知从机

3.3 超时处理策略

为防止通信死锁，必须实现全面的超时检测：

4. DMA高级配置技巧

DMA是提升SPI通信效率的关键，但在伪半双工模式下需要特殊的配置策略。

4.1 动态DMA缓冲区管理

// 动态调整DMA接收大小的示例 void SPI_Reconfig_DMA_RX_Size(uint16_t size) { HAL_SPI_DMAStop(&hspi1); // 重新配置DMA接收流 hdma_spi1_rx.Instance->CNDTR = size; // 更新内存地址和长度 SPI_Handle->hdmarx->Init.MemDataAlignment = DMA_MDATAALIGN_BYTE; SPI_Handle->hdmarx->Init.MemInc = DMA_MINC_ENABLE; HAL_DMA_Start(SPI_Handle->hdmarx, (uint32_t)&SPI_Handle->Instance->DR, (uint32_t)rx_buffer, size); HAL_SPI_Receive_DMA(SPI_Handle, rx_buffer, size); }

4.2 发送/接收模式切换流程

1. 从接收切换到发送：

   • 停止当前DMA传输
   • 重新配置DMA为内存到外设模式
   • 设置正确的发送数据长度
   • 启动DMA传输后拉高NOTIFY

2. 从发送切换回接收：

   • 等待DMA传输完成中断
   • 立即拉低NOTIFY引脚
   • 重新配置DMA为外设到内存模式
   • 恢复最大接收缓冲区大小

4.3 DMA中断优化处理

void DMA1_Channel2_3_IRQHandler(void) { // 只处理接收完成中断 if(__HAL_DMA_GET_FLAG(&hdma_spi1_rx, DMA_FLAG_TC2)) { __HAL_DMA_CLEAR_FLAG(&hdma_spi1_rx, DMA_FLAG_TC2); // 计算实际接收数据量 uint16_t received = RX_BUFFER_SIZE - __HAL_DMA_GET_COUNTER(&hdma_spi1_rx); if(received > 0) { // 触发数据处理回调 SPI_RxComplete_Callback(received); } } }

5. 性能优化与实测数据

经过伪半双工改造后，通信系统的性能得到了显著提升。以下是我们在1Mbps SPI时钟下的实测结果：

5.1 效率对比测试

5.2 关键优化手段

1. 动态缓冲区调整：

   • 空闲时设置256字节接收缓冲区
   • 发送时精确匹配待发数据长度

2. 中断合并技术：

   // 配置DMA中断优先级分组 HAL_NVIC_SetPriority(DMA1_Channel2_3_IRQn, 0, 0); HAL_NVIC_SetPriority(SPI1_IRQn, 1, 0);

3. 内存访问优化：

   • 确保DMA缓冲区32字节对齐
   • 使用__attribute__((section(".dma_buffer")))指定特殊内存区域

5.3 异常情况处理

在实际部署中，我们还发现了几个需要特别注意的边界情况：

1. 主从时钟偏差累积：

   • 长时间通信后可能出现位偏移
   • 解决方案：每100帧插入1ms静默期

2. 电源噪声干扰：

   • 电机启动时可能导致SPI误码
   • 改进措施：在电源引脚增加10μF钽电容

3. 热插拔场景：

   // 检测CS线异常状态的代码片段 if(HAL_GPIO_ReadPin(CS_GPIO_Port, CS_Pin) == GPIO_PIN_RESET) { if(!spi_active) { SPI_Reset_Communication(); } }

6. 移植与适配指南

这套方案已经在多个STM32系列芯片上成功实施，下面分享关键的移植注意事项。

6.1 不同STM32系列的适配要点

6.2 其他主控芯片的适配

对于非STM32从机设备，需要实现以下关键功能：

1. NOTIFY引脚检测：

   # Raspberry Pi示例代码 import RPi.GPIO as GPIO GPIO.setmode(GPIO.BCM) GPIO.setup(NOTIFY_PIN, GPIO.IN) def check_notify(): return GPIO.input(NOTIFY_PIN) == GPIO.HIGH

2. 动态SPI模式切换：

   • 主机需支持即时切换发送/接收模式
   • 建议使用硬件SPI控制器而非bit-banging

6.3 调试技巧与工具推荐

1. 逻辑分析仪配置：

   • 至少4通道（SCLK, MOSI, MISO, NOTIFY）
   • 采样率≥4倍SPI时钟频率

2. 关键调试断点：

   • NOTIFY引脚状态变化时刻
   • DMA配置变更位置
   • 状态机转换节点

3. 性能分析工具：

   # OpenOCD性能分析命令 openocd -f interface/stlink.cfg -f target/stm32h7x.cfg \ -c "init" -c "arm semihosting enable" -c "perf stat"

在实际项目中移植这套方案时，建议先用开发板搭建测试环境，逐步验证各个功能模块。我们团队在首次实现时，花了2天时间专门调试DMA状态切换的时序问题，最终发现是GPIO速度配置不当导致的信号延迟。这个经验告诉我们，嵌入式通信系统的可靠性往往取决于对这些细节的把握。