背景
最近被测试提了个BUG,说某款产品在用户按下前面板的按键后,对应的按键灯没有亮起来。前面板跟主机是通过SPI口通信,前面板是从机 ,从机想要主动发送消息,需要通过GPIO中断来通知主机 :
上图前面板是STM32(没有RTOS),主机是RK3588平台,INT是GPIO管脚,CS、MISO、MOSI是SPI标准信号。
整个通信过程是异步的:
前面板 主机 检测到用户按下了hold键 发送SPI请求:用户按下了hold键 主机App要求点亮hold键和numeric键的按键灯 接收SPI命令:点亮hold键和numeric键的按键灯 点亮hold键和numeric键的按键灯 前面板 主机
hold键示例的视频:
按键按下到按键灯亮起
思路
因为前面板是从机,它不知道主机什么时候会发消息,因此需要一直监听SPI总线,等待主机的command
。另一方面,它也不知道用户什么时候会按下按键,因此需要一直扫描按键接口,并在检测到按键活动后尽快向SPI总线发送消息,即request
,这两种事件对于STM32来说,都是异步的。
SPI总线虽然是双向通信的,但是仅限同步收发(UART是异步收发)。换句话说,尽管STM32发送request
的同时可以接收command
,但这两种消息的信源(用户和app)却不是同步的,因此不能调用HAL_SPI_TransmitReceive_DMA
等双向API来通信,只能分别调用HAL_SPI_Transmit_DMA
和HAL_SPI_Receive_DMA
来模拟异步通信。
解决方法
为了清晰,用流程图来描述:
SPI发送完成中断 SPI接收完成中断 主循环 否 是 进入中断 退出中断 进入中断 退出中断 调用HAL_SPI_Receive_DMA接收command 扫描按键 处理SPI command,点亮LED 用户按下某个按键 调用HAL_SPI_Abort中止当前的SPI接收 调用HAL_SPI_Transmit_DMA发送request
注意事项:
- STM32绝大部分时间都在监听并执行主机发来的command,仅在用户按下按键时才发送request
- 发送request前,必须先abort掉当前的SPI接收流程(SPI同步通信模式的限制)
- STM没有Linux那种用户态和内核态的说法,因此在中断里也可以再次启动SPI接收流程,即恢复到监听下一个command的状态。
- 最好给command和request分别开辟一个队列,接收中断将command入队,主循环将command出队;主循环发送request前将其入队,发送完成中断将其出队。这样做的好处是可以容纳不同类型、不同时间点的request(按键、旋钮、command的response等),以及不同类型、不同时间点的command(LED点亮命令、蜂鸣器开关命令、固件版本查询命令等)。
可能存在的问题
按照上述思路写完代码后,发现只要用户有按键行为,按键灯就仍然点不亮,从串口打印来看,是接收到的command出现了掐头或去尾的现象。
分析是SPI内部的FIFO没有正确清空,网上搜了下,这篇文章分析得比较到位,我在评论区找到了解决办法,贴出来:
c
void reset_spi1(void)
{
__HAL_RCC_SPI1_FORCE_RESET();
__HAL_RCC_SPI1_RELEASE_RESET();
MX_SPI1_Init();
}
在每次启动接收前都调一下上面的代码,就可能清空FIFO。经测试,SPI没有再出现掐头去尾的现象。
总结
如果应用场景是双向异步通信,且是系统拓扑是点到点,就别选SPI了,UART更好。