Embassy-rs项目中的STM32H7 SAI接口阻塞问题分析与解决

问题背景

在嵌入式开发领域，STM32H7系列微控制器因其强大的处理能力被广泛应用于音频处理场景。embassy-rs项目作为Rust语言下的异步嵌入式框架，为STM32H7提供了完善的硬件抽象层支持。近期在Daisy Seed开发板(rev.7)上使用SAI(Serial Audio Interface)接口时，开发者遇到了一个典型问题：sai_receiver.read()和sai_transmitter.write()操作无法完成，导致音频处理流程阻塞。

技术分析

SAI接口是STM32系列中专门为音频数据传输设计的外设，支持I2S、PCM等音频协议。在embassy-rs的实现中，SAI接口的操作被设计为异步Future模式，这种设计使得开发者可以编写非阻塞的音频处理代码。

问题的核心在于SAI主从时钟配置与时序控制。在Daisy Seed的不同硬件版本中：

1. rev 1.1版本使用WM8731编解码器，其配置特点是：

   • 接收器(Receiver)作为主设备(Master)
   • 发送器(Transmitter)作为从设备(Slave)
   • 通过I2C接口进行初始化配置

2. rev 1.2版本使用PCM3060编解码器，其配置特点是：

   • 发送器作为主设备
   • 接收器作为从设备
   • 采用硬件模式配置(通过配置引脚)，不使用I2C接口

问题根源

在embassy-rs的版本演进过程中，SAI接口的初始化逻辑发生了变化：

1. 旧版本中，开发者需要显式调用.start()方法来启动SAI接口，这会初始化DMA并启动时钟
2. 新版本(0.2.0以后)中，.start()方法被移除，DMA初始化被移至.write()方法内部执行

这种变更导致了以下问题链：

1. 对于rev 1.2硬件(发送器为主设备)：

   • 当代码先执行rx.read().await时
   • 由于主设备时钟尚未启动(发送器还未执行.write())
   • 从设备接收器无法获取时钟参考，导致永久阻塞

2. 对于rev 1.1硬件(接收器为主设备)：

   • 接收器作为主设备会在初始化时启动时钟
   • 因此不会出现阻塞问题

解决方案

针对这一问题，最简单的修复方法是调整代码执行顺序：

// 修改前(会导致阻塞)
let (rx_sample, tx_sample) = join(
    sai_receiver.read(&mut rx_buf),
    sai_transmitter.write(&tx_buf),
).await;

// 修改后(正确顺序)
let (rx_sample, tx_sample) = join(
    sai_transmitter.write(&tx_buf),  // 先启动主设备
    sai_receiver.read(&mut rx_buf),  // 再启动从设备
).await;

这一调整确保了主设备时钟先于从设备初始化，符合硬件工作的时序要求。

深入理解

从这个问题中我们可以得到几个重要的嵌入式开发经验：

1. 时钟域管理：在涉及主从设备的系统中，必须确保时钟源先于依赖它的设备初始化
2. 版本兼容性：框架的更新可能会改变底层硬件的初始化流程，需要仔细阅读变更日志
3. 硬件差异：即使是同一系列开发板的不同版本，也可能存在关键配置差异
4. 异步编程：在嵌入式异步编程中，操作的执行顺序可能直接影响硬件行为

最佳实践建议

基于此问题的经验，建议开发者在实现类似音频接口时：

1. 明确硬件的主从关系，查阅编解码器数据手册
2. 在代码中添加清晰的注释说明时钟配置
3. 对关键外设的初始化顺序进行文档记录
4. 考虑添加超时机制防止永久阻塞
5. 在版本升级时，特别注意硬件抽象层的变更说明

通过这个问题，我们不仅解决了具体的SAI接口阻塞问题，更深入理解了嵌入式音频系统中时钟管理和初始化顺序的重要性，这对开发高质量音频应用具有普遍指导意义。