如何在 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 延遲。