如何在 STM32F3 上修复 SPI 的片选时序？

Question

我正在使用 STM32F303RE 进行一个需要全双工 SPI 的项目，并且我正在使用 STM 提供的 HAL 库。 虽然所有线路都在 SCK、MOSI 和 MISO 方面工作，但我注意到片选线路的低电平比必要的要长得多，并且似乎在 20kHz 左右触发，而不是 2MHz SPI。 这是一个问题，因为我使用的从设备触发了 CS 线，并且在多次 SPI 调用期间数据被损坏。 我怎样才能确定时间？

我目前正在使用手动 GPIO，它只是在 SPI 调用之前和之后设置低/高。 从在线阅读来看，似乎 CS 引脚是很多人的问题源，因为也可以选择使用硬件 NSS 信号，尽管人们建议不要这样做，因为它不能正常工作。

// Set SS pin low to activate
HAL_GPIO_WritePin(GPIOB, GPIO_PIN_1, GPIO_PIN_RESET);

// Read Temp
if(HAL_SPI_TransmitReceive(&hspi2, (uint8_t*)&master_buffer_tx[4], (uint8_t*)&master_buffer_rx[4], 1, 1000)!=HAL_OK){
      Error_Handler();
}

// Check finished
while(HAL_SPI_GetState(&hspi2) != HAL_SPI_STATE_READY){
}

// Set SS pin high to deactivate
HAL_GPIO_WritePin(GPIOB, GPIO_PIN_1, GPIO_PIN_SET);

HAL_Delay(10);

我预计 CS 会在 SCK 之前的大约半个周期和之后的类似情况下走低。 这些是我可能的想法：“检查完成”行是否导致了问题？ 会不会是我的时钟设置？ 我使用的 GPIO 引脚应该与 NSS 所在的位置相同吗？ 我应该使用硬件 NSS 吗？ 我需要使用中断和 DMA 吗？

对不起，如果这看起来很幼稚，因为我仍在努力理解微控制器。 谢谢！

CS 和 SCK 时序

Answer 1

我想我可以解释激活 CS 和 SPI 传输之间的延迟：如果您查看HAL_SPI_TransmitReceive()内部，您会发现它实际上需要很多操作来设置和启动实际的 SPI 传输。 根据您的时钟配置，这很容易花费几微秒（另请参阅此问题）。

我对 SPI 传输后直到 CS 被取消断言的延迟感到有点困惑。 与传输准备相比，HAL 代码需要更少的操作来完成传输。 “检查完成”代码不需要很多周期，因为它实际上只检查软件标志（甚至不是硬件寄存器）。 不过该调用不是必需的，因为HAL_SPI_TransmitReceive()是一个阻塞函数，它仅在 SPI 传输完成后返回。

关于您的问题，我想推荐使用硬件 NSS 功能。 但是再想一想，一旦启用了 SPI 单元，就会断言 CS。 ST HAL 似乎没有在每次传输后禁用 SPI 单元 - 所以这不会按预期工作。

我认为您需要进一步分析在实际 SPI 传输和 CS 取消断言之间 HAL 内部发生了什么。 这看起来不像是正常行为。 没有必要使用中断或 DMA 来改善 CS 行为。 这些功能从 CPU 加载负载，但需要更复杂的代码，这可能不会改善 CS 延迟。