STM32F337：SPI从机帧同步答案

【问题标题】：STM32F337: SPI slave frame synchronizationSTM32F337：SPI从机帧同步
【发布时间】：2018-03-11 13:46:09
【问题描述】：

我有一个带有 STM32F337 的应用程序，它应该实现一个 SPI 从机协议。

每个 SPI 事务数据包或帧，无论您想如何称呼它们，都应该有，比如说，正好 100 个字节。

主机使用 NSS 线确保帧同步，就像在任何好的 SPI 应用程序中一样。

因此，为了传输 100 字节，主机将 NSS 拉低（置位），以通常的方式将 800 位时钟发送到从机，然后再次将 NSS 拉高（解除置位）。

每当一个事务出错时，下一个事务应该通过同步再次正常，因此在 NSS 的“高时间”期间应该评估并重新建立事务。为了实现这一点，我需要一个 NSS 线的中断信号，如果传输的字节数小于 100，它甚至应该触发。（测试表明，只有在传输 100 个字节时才会触发 DMA 中断，没有无论 NSS 多久被取消断言并再次断言。）

我发现µC 单元中的 SPI 从外设只使用 NSS 线来控制 MISO 线的状态（高 Z 与否），但不控制使用它的通信，即。 e.它不会重置任何 DMA 状态或其他任何东西。

因此，我必须找到一种方法来复用 NSS 功能和 EXTI 之间的线路，以便在线路状态发生变化时产生中断。但我看不出有什么办法可以做到这一点——至少，STM32Cube 不会让我为 NSS 和 EXTI 使用相同的引脚。

这是 Cube 还是 µC 单位的限制？我还有其他选择吗（一次将信号连接到多个引脚除外）？

【问题讨论】：

SPI 协议中的 IMO 只需检查该行即可。在这种情况下，EXTI 将由它制作“意大利面条代码”，当您收到数据时，您就知道它是完全没有必要的。
不幸的是，您的问题完全无法理解。显然，您希望对“事务”进行某种同步，这样 100 字节的包就不会以块的形式发送，而 NSS 在两者之间被取消断言？
@PeterJ_01 不幸的是，SPI 外设检查 NSS 以控制 MISO 的状态（= 从模式下的输出），但它不会重置事务状态。（除非我看到或配置了错误。）

标签： arm microcontroller interrupt stm32 spi

【解决方案1】：

我同意这是 STM32 SPI 从机实现的主要限制。每当NSS 被置低时，SPI 单元都无法生成中断。

恕我直言，最好的解决方案确实是将NSS 线连接到两个 MCU 引脚，以便能够并行使用硬件 NSS 和 EXTI 功能。

如果这不可行，我的解决方案是使用NSS 信号作为EXTI 中断，并使用软件NSS 管理（位SSMin SPI_CR1）管理SPI 从机。 EXTI 可以在两个边沿上触发（即在NSS 的断言和取消断言时），并且SPI 从机由EXTI 中断处理程序的软件（SPI_CR1 中的位SSI）启用和禁用。

此方法的关键路径是准备 SPI 从设备以接收断言 NSS 的时间。由该事件触发的 EXTI 中断需要高优先级，但根据时钟配置和 SPI 主控的时序要求，CPU 可能不够快，无法通过软件切换 NSS 位。在这种情况下，可以选择提前开启SSI（软件 NSS） - 但这可能不适用于每个应用程序（例如，与多个从机共享的 SPI 通道）。

【讨论】：

相比之下，Atmel SAM 器件中的 SPI 外设将在从模式下在 CS 被取反时生成传输完成中断。（AFAICT，STM32 SPI 不实现传输完成，即使在主模式下也是如此。）

【解决方案2】：

STM 命名法或 CS 中的 NSS 仅选择从机，并通知未选择的从机进入 HI-Z 状态以释放总线。

不是同步机制，DMA不会触发任何中断，因为NSS线被置低。

【讨论】：

让我们假设一个 SPI 事务，其中单个时钟脉冲由于 EMC 问题而“丢失”。当 NSS 被取消断言时，从机仅接收到 99 个字节和 7 位，而不是预期的 100 个字节。 SPI 从机应该如何处理这种情况？当 NSS 被取消断言时刷新移位寄存器或在 NSS 再次被断言时继续传输？
@PJ - CS 还启用接收路径，这样未选择的从设备不会输入接收数据。
@PJ - 处于 Hi-Z 状态的从机已将其 MISO（输出）引脚置于三态。它对 MOSI 和时钟引脚（两个输入）的作用是完全不同的。
@PJ - 当然，我原来的评论应该更正确地理解为：“CS 还启用了接收和发送移位寄存器的时钟，这样未选择的从机不会将数据输入或输出他们的移位寄存器。”这与将 MISO 引脚设为三态和“释放总线”一样重要——在某些情况下更是如此——并且是一个明显的问题。如果这就是您所说的“HI-Z 状态”，那么我们完全同意。
@Jeremy 请停止。从站不会对 MOSI 做任何事情 - 它只能从中读取，否则从站已损坏。但我们不考虑损坏的硬件。