：SPI從機主動發(fā)送數(shù)據(jù)的3種實現(xiàn)方案)
做嵌入式這些年SPI 算是我用得最多的接口之一。前段時間有個項目兩個 STM32 要高速交換數(shù)據(jù)從機采集完一批數(shù)據(jù)后必須“立刻”發(fā)給主機。需求一提出來很多人第一反應(yīng)是SPI 從機怎么主動發(fā)數(shù)據(jù)SPI 主機才能提供時鐘從機連時鐘都沒有怎么主動這句話對但也不全對。SPI 從機確實不能憑空發(fā)起傳輸?shù)梢酝ㄟ^別的辦法“通知”主機來讀數(shù)據(jù)。這篇文章我就拿 STM32 為例分享從機主動發(fā)送數(shù)據(jù)的 3 種實現(xiàn)方式方案一是 GPIO 請求線加中斷方案二是主機輪詢方案三是 DMA 加乒乓緩沖各有優(yōu)缺點代碼也都給出來。1. 先搞清楚SPI從機憑什么“主動”1.1 SPI主從機制的底層邏輯SPI 之所以叫同步串行接口關(guān)鍵在于“同步”這兩個字。通信時誰提供 SCK 時鐘誰就是主機。主機控制 CS 片選信號決定跟哪個從機通信主機也決定什么時候開始傳輸、傳多少字節(jié)。從機的角色是被動的它只能檢測 CS 是否拉低、SCK 有沒有時鐘過來然后在時鐘的驅(qū)動下把數(shù)據(jù)從移位寄存器里送出去或者把總線上的數(shù)據(jù)收進來。所以從機“主動發(fā)送數(shù)據(jù)”這句話嚴格來說在 SPI 協(xié)議層面是不成立的。SCK 是主機的專屬資源從機沒有能力拉出 SCK 波形自然也就沒法啟動一次完整傳輸。我們要做的是在應(yīng)用層解決“從機有數(shù)據(jù)要發(fā)給主機”這個需求本質(zhì)思路都指向一句話讓從機通過某種方式告訴主機“我這有數(shù)據(jù)了你趕緊來讀”然后由主機發(fā)起 SPI 傳輸。這篇文章講的三種方式全是在這句話的基礎(chǔ)上展開的。1.2 三種思路的出發(fā)點第一種方式最直接從機專門拉一根 GPIO 線接到主機的 EXTI 中斷腳。從機有數(shù)據(jù)要發(fā)時先把 SPI 發(fā)送寄存器準備好再把這根請求線拉高主機收到中斷后就知道從機在等自己讀數(shù)據(jù)于是拉低 CS、啟動 SPI 接收。第二種方式省掉這根請求線主機按照固定周期主動發(fā)一個“讀命令”給從機從機收到命令后回傳數(shù)據(jù)。這種方式從機永遠不會主動開口但它實現(xiàn)了“從機數(shù)據(jù)能被及時拿走”的效果。代價是主機必須一直輪詢實時性和總線利用率都一般。第三種方式是把第一種方式的請求線和 DMA 結(jié)合適合數(shù)據(jù)量大、要求 CPU 占用低的場景。從機采集完數(shù)據(jù)后先啟動 SPI 的 DMA 發(fā)送然后拉高請求線主機在中斷里只用啟動 DMA 接收剩下的事全部交給 DMA 搬運。數(shù)據(jù)吞吐高而且不需要 CPU 一字節(jié)一字節(jié)地去處理。三種方式并不沖突實際項目里甚至可以組合使用。下面我分別把硬件連接、CubeMX 配置思路和 STM32 HAL 庫代碼拆開講。2. 方式一請求線EXTI中斷最快最直觀2.1 硬件連接與CubeMX配置思路方式一需要額外一根 GPIO 線我習慣叫它 REQ 線。連接是這樣的從機某個 GPIO 配置成推挽輸出接到主機的另一個 GPIO 輸入腳主機這個 GPIO 配置成 EXTI 外部中斷上升沿觸發(fā)。其他四根線照舊SCK、MOSI、MISO、CS 都接好主機和從機共地。CubeMX 里主機的 SPI 配置為 Full-Duplex Master從機配置為 Full-Duplex Slave。傳輸模式建議先用 Mode 0也就是 CPOL0、CPHA0這樣不容易出錯。主機 CS 引腳用普通 GPIO 輸出即可我習慣叫 CS_GPIO_Port / CS_Pin。從機的 NSS 如果不想用硬件控制可以把從機 SPI 的 NSS 設(shè)為 Software然后在初始化后把 SSI 置 1讓從機始終處于選中狀態(tài)真正的外部 CS 線就不參與 SPI 外設(shè)的使能判斷了。如果從機使用硬件 NSS則需要確保主機 CS 拉低時從機能檢測到片選有效時序要求更高新手階段容易被 NSS 的電平搞得一頭霧水所以軟件 NSS 更穩(wěn)。從機的 REQ 引腳在 CubeMX 里配成 GPIO_Output初始狀態(tài)輸出低電平主機的 REQ 引腳在 GPIO 配置里選擇 External Interrupt Mode with Rising edge trigger使能 EXTI 中斷。這里要注意主機的 GPIO 模式如果支持內(nèi)部上拉/下拉最好根據(jù)實際情況選擇是否啟用。REQ 線一般沒有高速翻轉(zhuǎn)要求普通推挽輸出就夠了。2.2 主機端代碼實現(xiàn)主機端的核心邏輯是在 EXTI 回調(diào)函數(shù)里只做一個標志位置位真正耗時的 SPI 接收放到主循環(huán)里處理不要在中斷服務(wù)函數(shù)里直接跑阻塞式 HAL_SPI_Receive否則主機整個中斷會被拉得很長其他實時任務(wù)可能被餓死。/* main.c 全局變量 */ volatile uint8_t g_slave_req 0; uint8_t g_rx_buf[32]; /* EXTI 回調(diào)REQ 引腳上升沿觸發(fā) */ void HAL_GPIO_EXTI_Callback(uint16_t GPIO_Pin) { if (GPIO_Pin REQ_Pin) { g_slave_req 1; } } /* 主循環(huán) */ while (1) { if (g_slave_req) { g_slave_req 0; /* 拉低片選通知從機開始傳輸 */ HAL_GPIO_WritePin(CS_GPIO_Port, CS_Pin, GPIO_PIN_RESET); /* 主機提供時鐘接收從機數(shù)據(jù) */ HAL_SPI_Receive(hspi1, g_rx_buf, sizeof(g_rx_buf), 100); /* 拉高片選結(jié)束本次傳輸 */ HAL_GPIO_WritePin(CS_GPIO_Port, CS_Pin, GPIO_PIN_SET); ProcessData(g_rx_buf, sizeof(g_rx_buf)); } }這里有一個關(guān)鍵點主機的 HAL_SPI_Receive 在讀數(shù)據(jù)的同時SPI 硬件也會把數(shù)據(jù)線上的數(shù)據(jù)移位進來但根據(jù) SPI 全雙工特性主機發(fā)送的字節(jié)是 0x00 或 0xFF具體由 HAL 庫的清零處理決定。所以從機側(cè)只要提前把數(shù)據(jù)放進發(fā)送寄存器主機這邊就能完整收到。2.3 從機端代碼實現(xiàn)從機端要做的事就是應(yīng)用層準備好了數(shù)據(jù)后先把數(shù)據(jù)放進 SPI 發(fā)送通道再拉高 REQ 線通知主機。為什么要先放數(shù)據(jù)再拉高 REQ因為主機接收到中斷后馬上就會拉低 CS 并啟動時鐘如果從機這時候才開始填 SPI 數(shù)據(jù)寄存器第一個字節(jié)大概率來不及主機收到的第一個字節(jié)就是錯的。/* main.c 從機側(cè) */ uint8_t g_tx_buf[32]; volatile uint8_t g_tx_busy 0; void Slave_SendData(uint8_t *data, uint16_t len) { while (g_tx_busy); // 等待上一次發(fā)送完成 memcpy(g_tx_buf, data, len); /* 先啟動中斷發(fā)送讓第一個字節(jié)預(yù)裝載到 SPI 數(shù)據(jù)寄存器 */ HAL_SPI_Transmit_IT(hspi1, g_tx_buf, len); g_tx_busy 1; /* 再通知主機過來讀 */ HAL_GPIO_WritePin(REQ_GPIO_Port, REQ_Pin, GPIO_PIN_SET); } /* 從機發(fā)送完成回調(diào) */ void HAL_SPI_TxCpltCallback(SPI_HandleTypeDef *hspi) { if (hspi hspi1) { /* 主機已經(jīng)讀完撤下請求線允許下一次請求 */ HAL_GPIO_WritePin(REQ_GPIO_Port, REQ_Pin, GPIO_PIN_RESET); g_tx_busy 0; } }從機調(diào)用 HAL_SPI_Transmit_IT 的時候CS 可能還是高電平SCK 也沒有時鐘但這不是問題。SPI 外設(shè)使能后數(shù)據(jù)寄存器是可寫的HAL_SPI_Transmit_IT 會把第一字節(jié)寫到數(shù)據(jù)寄存器里然后等 TXE 事件。等到主機拉低 CS、開始產(chǎn)生 SCK 時鐘時第一字節(jié)被移出去TXE 置位中斷再填充第二字節(jié)。所以“先啟動發(fā)送再通知主機”這個順序絕對不能反。2.4 方式一的關(guān)鍵細節(jié)第一個細節(jié)是請求線觸發(fā)方式。我在代碼里用的是上升沿觸發(fā)從機拉高 REQ 請求主機收到上升沿中斷。主機的判斷要帶標志位去清不要在主循環(huán)和 EXTI 回調(diào)之間出現(xiàn)競態(tài)。如果同時來了多個請求可以給標志位加計數(shù)但如果只需要“有數(shù)據(jù)就讀”一個標志位就夠了。第二個細節(jié)是 CS 的時序。對從機來說主機 CS 拉低后從機 SPI 外設(shè)才真正進入被選中狀態(tài)。如果從機用的是硬件 NSS那么 CS 線必須先于 SCK 拉低且持續(xù)到整個幀結(jié)束如果從機用軟件 NSS則外部 CS 不直接控制 SPI 外設(shè)但仍建議用 GPIO 模擬 CS 來保證從機應(yīng)用層能知道當前是否被選中這樣在調(diào)試時你能清楚看見時序。第三個細節(jié)是中斷優(yōu)先級。主機 EXTI 中斷不要設(shè)置成最高優(yōu)先級因為中斷里只置標志位實際 SPI 接收在主循環(huán)里所以優(yōu)先級比系統(tǒng)節(jié)拍低一點即可。從機 SPI 發(fā)送中斷的優(yōu)先級則要看實時性要求數(shù)據(jù)量大時建議把 SPI 中斷優(yōu)先級調(diào)高避免 SCK 時鐘太快導(dǎo)致 TXE 中斷沒來得及填充下一字節(jié)從而出現(xiàn)丟數(shù)據(jù)。3. 方式二主機輪詢命令應(yīng)答省一根請求線3.1 兩階段讀命令協(xié)議設(shè)計方式二適合不想多拉線的場景主機只要定時發(fā)命令從機在命令的驅(qū)動下返回數(shù)據(jù)。很多人寫到這里會忽略一個問題SPI 是全雙工通信主機發(fā)命令字節(jié)的同時從機的 MISO 線上其實也在輸出數(shù)據(jù)。從機在收到命令之后才準備數(shù)據(jù)那就晚了因為這個字節(jié)已經(jīng)隨著時鐘移出去了。所以需要把一次“讀取操作”拆成兩個階段。第一階段主機發(fā)送一字節(jié)命令從機接收命令的同時MISO 上送出的是上一次預(yù)留的應(yīng)答字節(jié)或者占位字節(jié)這一階段主機收到的數(shù)據(jù)一般丟棄。第二階段主機再發(fā)送一字節(jié)啞數(shù)據(jù)從機在收到第一階段的命令后已經(jīng)把真正的數(shù)據(jù)放到 SPI 發(fā)送數(shù)據(jù)寄存器里了這一次時鐘會把數(shù)據(jù)完整送出主機收到的就是有效數(shù)據(jù)。計算一下開銷每次讀取有效數(shù)據(jù) 1 字節(jié)實際總線傳輸 2 字節(jié)。如果主機輪詢周期是 1ms那么當前這包數(shù)據(jù)的最大延遲大約是 2ms平均延遲 1ms 左右。數(shù)據(jù)量小、實時性要求不高時這種方式很實用。3.2 主機輪詢代碼主機端比較簡單用一個定時器或者直接在主循環(huán)里做周期輪詢。我建議用定時器的回調(diào)置一個標志位主循環(huán)里處理避免在定時器中斷里阻塞太久。每次讀完再啟動下一次。/* main.c 主機 */ uint8_t cmd CMD_READ_DATA; uint8_t dummy 0; uint8_t rx_dummy; uint8_t rx_data; void TimerPeriodElapsedCallback(TIM_HandleTypeDef *htim) { if (htim htim2) { g_poll_flag 1; } } while (1) { if (g_poll_flag) { g_poll_flag 0; /* CS 拉低 */ HAL_GPIO_WritePin(CS_GPIO_Port, CS_Pin, GPIO_PIN_RESET); /* 階段 1發(fā)送命令收到的是從機的占位數(shù)據(jù) */ HAL_SPI_TransmitReceive(hspi1, cmd, rx_dummy, 1, 10); /* 階段 2發(fā)送啞字節(jié)同時讀取從機的有效數(shù)據(jù) */ HAL_SPI_TransmitReceive(hspi1, dummy, rx_data, 1, 10); /* CS 拉高 */ HAL_GPIO_WritePin(CS_GPIO_Port, CS_Pin, GPIO_PIN_SET); ProcessSensorData(rx_data); } }如果主機需要一次讀取多個字節(jié)可以從機側(cè)在命令階段之后連續(xù)輸出多個有效字節(jié)。比如讀取 16 字節(jié)溫度數(shù)據(jù)主機第一階段發(fā)命令第二階段連續(xù)發(fā) 16 個啞字節(jié)從機狀態(tài)機里根據(jù)命令把 16 字節(jié)連續(xù)發(fā)送出來。3.3 從機狀態(tài)機代碼從機側(cè)我推薦用 HAL 庫的 HAL_SPI_TransmitReceive_IT讓狀態(tài)機始終處于接收狀態(tài)。初始化時先啟動一次“命令接收”傳輸收到命令后在回調(diào)里切換到“數(shù)據(jù)發(fā)送”狀態(tài)發(fā)送完成后再切換回“命令接收”狀態(tài)。/* 從機全局變量 */ uint8_t rx_byte; uint8_t tx_byte; uint8_t tx_dummy 0xFF; volatile uint8_t spi_state STATE_WAIT_CMD; // 0等命令1發(fā)數(shù)據(jù) /* 初始化時啟動命令接收 */ void Slave_SPI_Init(void) { spi_state STATE_WAIT_CMD; HAL_SPI_TransmitReceive_IT(hspi1, tx_dummy, rx_byte, 1); } /* 發(fā)送接收完成回調(diào) */ void HAL_SPI_TxRxCpltCallback(SPI_HandleTypeDef *hspi) { if (hspi ! hspi1) return; if (spi_state STATE_WAIT_CMD) { if (rx_byte CMD_READ_DATA) { tx_byte ReadSensorData(); spi_state STATE_SEND_DATA; } /* 不管是不是有效命令都回到等待命令狀態(tài) 但若收到有效命令下一階段就會發(fā)送有效數(shù)據(jù) */ if (spi_state STATE_SEND_DATA) { /* 階段 2主機發(fā)送啞字節(jié)時從機發(fā)送 tx_byte */ HAL_SPI_TransmitReceive_IT(hspi1, tx_byte, rx_byte, 1); } else { HAL_SPI_TransmitReceive_IT(hspi1, tx_dummy, rx_byte, 1); } } else if (spi_state STATE_SEND_DATA) { /* 數(shù)據(jù)發(fā)送完成重新等命令 */ spi_state STATE_WAIT_CMD; HAL_SPI_TransmitReceive_IT(hspi1, tx_dummy, rx_byte, 1); } }這個狀態(tài)機代碼的精髓在于從機永遠在等主機發(fā)起的 SPI 傳輸永遠處于“接收命令或發(fā)送數(shù)據(jù)”的循環(huán)中。主機不來時鐘這個狀態(tài)機就一直掛著主機時鐘來了從機的數(shù)據(jù)就會自動被讀走。這種方式雖然叫“從機主動發(fā)送”但實際協(xié)議層面是主機一直在主動讀從機的主動性體現(xiàn)在“有數(shù)據(jù)時能及時通過命令應(yīng)答帶出去”。3.4 延遲與總線效率分析方式二最怕的是主機輪詢周期和數(shù)據(jù)到達時機不對齊。比如傳感器每 10ms 更新一次主機若 5ms 輪詢一次那讀取到的數(shù)據(jù)平均會有 2.5ms 左右的陳舊延遲。主機若在數(shù)據(jù)更新前讀拿到的就是上一周期的舊值如果業(yè)務(wù)要求拿到“最新值”可以給協(xié)議加一個狀態(tài)字段從機在應(yīng)答數(shù)據(jù)里帶一個“數(shù)據(jù)更新序號”或者“數(shù)據(jù)有效標志”主機讀到舊值時可以選擇連續(xù)重讀或丟棄?？偩€效率方面方式二每一字節(jié)有效數(shù)據(jù)都要消耗兩個時鐘字節(jié)效率是 50%。如果主機能接受問題不大如果對總線效率敏感建議用方式一或方式三。另外主機輪詢會持續(xù)產(chǎn)生 SPI 時鐘對一些低功耗場景不友好因為主機不能一直跑否則系統(tǒng)功耗壓不下去。4. 方式三DMA批量搬運乒乓緩沖高性能大頭兵4.1 DMA請求線的配合方式方式三是方式一的升級版思路仍然是“從機請求主機讀取”但把“逐字節(jié)中斷搬運”替換成“DMA 搬運”。使用 DMA 的好處很明顯主機收到 REQ 中斷后只需拉低 CS、啟動一次 HAL_SPI_Receive_DMACPU 就可以去做別的事了DMA 會在 SPI 時鐘驅(qū)動下把數(shù)據(jù)自動搬到內(nèi)存。從機這邊也一樣數(shù)據(jù)在 DMA 的驅(qū)動下自動從內(nèi)存搬到 SPI 發(fā)送數(shù)據(jù)寄存器不需要內(nèi)核逐字節(jié)處理。這里有一個很重要的硬性約束從機必須先啟動 DMA 發(fā)送讓 DMA 把第一字節(jié)送到 SPI 數(shù)據(jù)寄存器再拉高 REQ 線。主機收到 REQ 后立即拉低 CS 并啟動讀取此時 SPI 時鐘一產(chǎn)生第一字節(jié)就能直接移出。如果順序顛倒從機先拉高 REQ主機隨后馬上產(chǎn)生時鐘而 DMA 還沒來得及把第一字節(jié)寫入 SPI 數(shù)據(jù)寄存器第一個字節(jié)就會變成上一個殘留數(shù)據(jù)或者干脆是空數(shù)據(jù)主機接收到的第一字節(jié)就會錯位。4.2 乒乓緩沖為了什么DMA 搬運數(shù)據(jù)是直接從內(nèi)存緩沖區(qū)搬到 SPI 外設(shè)不需要 CPU 參與。這意味著 CPU 可以在 DMA 正在發(fā)送緩沖區(qū) A 的時候去往緩沖區(qū) B 填充新數(shù)據(jù)等下一輪發(fā)送輪到緩沖區(qū) B 時CPU 又可以去填充緩沖區(qū) A。這叫乒乓緩沖。為什么一定要乒乓因為如果你只有一個緩沖區(qū)CPU 在一輪采集后填充完數(shù)據(jù)啟動 DMA 發(fā)送接著 CPU 又想在新一輪數(shù)據(jù)到達時填充同一個緩沖區(qū)就會導(dǎo)致 DMA 還沒發(fā)完的數(shù)據(jù)被新數(shù)據(jù)覆蓋主機讀到的數(shù)據(jù)前后撕裂或者出現(xiàn)半個新幀、半個舊幀。乒乓緩沖把“填充數(shù)據(jù)”和“發(fā)送數(shù)據(jù)”在時間上錯開只要 CPU 填充緩沖區(qū) B 的速度比 DMA 發(fā)送緩沖區(qū) A 的速度快就不會互相干擾。乒乓緩沖的代碼結(jié)構(gòu)簡單說就是兩個數(shù)組一個正在被 DMA 讀另一個正在被 CPU 填。發(fā)送完成后交換角色。我這里給一個單緩沖的簡化版本重點是把 DMA 和 REQ 請求怎么配合講清楚真正做乒乓時把下面代碼里的單個 buffer 換成 buffer[2]再用一個索引來切換即可。4.3 從機和主機代碼骨架從機側(cè)代碼假設(shè)傳感器采集好的數(shù)據(jù)已經(jīng)放在 g_tx_buffer 里長度為 BUF_LEN。/* 從機 */ #define BUF_LEN 256 uint8_t g_tx_buffer[BUF_LEN]; /* 應(yīng)用層數(shù)據(jù)準備好后主動發(fā)送 */ void Slave_RequestSend(uint8_t *data) { /* 拷貝數(shù)據(jù)到 DMA 發(fā)送緩沖區(qū) */ memcpy(g_tx_buffer, data, BUF_LEN); /* 等待上一次 DMA 發(fā)送完全結(jié)束 */ while (HAL_SPI_GetState(hspi1) ! HAL_SPI_STATE_READY); /* 先啟動 DMA 發(fā)送讓第一字節(jié)預(yù)裝載 */ HAL_SPI_Transmit_DMA(hspi1, g_tx_buffer, BUF_LEN); /* 再通知主機來讀 */ HAL_GPIO_WritePin(REQ_GPIO_Port, REQ_Pin, GPIO_PIN_SET); } /* 從機 DMA 發(fā)送完成回調(diào) */ void HAL_SPI_TxCpltCallback(SPI_HandleTypeDef *hspi) { if (hspi hspi1) { /* 主機讀完了撤下請求線 */ HAL_GPIO_WritePin(REQ_GPIO_Port, REQ_Pin, GPIO_PIN_RESET); } }主機側(cè)代碼收到 REQ 中斷后啟動 DMA 接收。/* 主機全局變量 */ uint8_t g_rx_buffer[BUF_LEN]; volatile uint8_t g_slave_req 0; void HAL_GPIO_EXTI_Callback(uint16_t GPIO_Pin) { if (GPIO_Pin REQ_Pin) { g_slave_req 1; } } /* 主循環(huán) */ while (1) { if (g_slave_req) { g_slave_req 0; /* 拉低 CS從機開始輸出數(shù)據(jù) */ HAL_GPIO_WritePin(CS_GPIO_Port, CS_Pin, GPIO_PIN_RESET); /* 啟動 DMA 接收主機產(chǎn)生 BUF_LEN 個時鐘 */ HAL_SPI_Receive_DMA(hspi1, g_rx_buffer, BUF_LEN); } } /* DMA 接收完成回調(diào) */ void HAL_SPI_RxCpltCallback(SPI_HandleTypeDef *hspi) { if (hspi hspi1) { /* 拉高 CS結(jié)束本次傳輸 */ HAL_GPIO_WritePin(CS_GPIO_Port, CS_Pin, GPIO_PIN_SET); /* 處理數(shù)據(jù) */ ProcessData(g_rx_buffer, BUF_LEN); } }這段代碼看起來很簡單但實際項目里我會把 HAL_SPI_Receive_DMA 放到 EXTI 回調(diào)里直接啟動因為函數(shù)本身只是配置 DMA 并開啟傳輸耗時極短。主循環(huán)里置標志位再處理也是一種穩(wěn)妥做法優(yōu)先級上并沒有問題。真正要注意的是 CS 引腳和 DMA 狀態(tài)的配合如果上一次 DMA 還沒有完成下一次 REQ 就來了主機這邊必須等待或做保護否則 CS 拉低之后啟動 DMA 會出現(xiàn)并發(fā)錯誤。4.4 避免DMA傳輸踩坑DMA 的第一個坑是緩沖區(qū)長度超長時SPI 時鐘連續(xù)翻轉(zhuǎn)如果主機和從機的波特率分頻設(shè)置不一致或者主頻不同就可能導(dǎo)致采樣點偏移。STM32 的 SPI 從模式一般可以跟得上主機速率但要注意 SPI 的時鐘極性和相位必須完全一致特別是 Mode 0 和 Mode 3 這兩個模式都不難配只是千萬別一邊配 Mode 0、一邊配 Mode 3。第二個坑是 DMA 中斷和 SPI 中斷的優(yōu)先級。從機在 DMA 發(fā)送完整個緩沖區(qū)后觸發(fā)完成中斷這個中斷里要拉低 REQ不能拖太久。如果 REQ 線被長時間占用主機可能來不及在下一輪請求前釋放資源。實際上我在做高速傳輸時會把從機的 DMA 中斷優(yōu)先級設(shè)置為較高主機的 EXTI 請求線中斷優(yōu)先級設(shè)置為中等SPI 的全局中斷優(yōu)先級設(shè)置為比 EXTI 低一點保證“請求”和“發(fā)送完成”不會被 DMA 中斷的長時間處理拖延。第三個坑是首字節(jié)錯誤。前面反復(fù)強調(diào)過從機要先啟動 DMA 再拉高 REQ。但還有一個細節(jié)是 DMA 配置里 Data Width 要和 SPI 數(shù)據(jù)寬度一致。STM32 的 SPI 通常配置 8 位數(shù)據(jù)DMA 的 Peripheral Data Size 和 Memory Data Size 都應(yīng)該是 Byte。如果配成 Half Word 或者 WordDMA 搬運的數(shù)據(jù)寬度會和 SPI 外設(shè)不匹配收發(fā)內(nèi)容直接亂掉。第四個坑是 CS 線。數(shù)據(jù)量大時CS 全程拉低直到 DMA 結(jié)束這一點協(xié)議上沒有爭議。但 CS 拉高前要確保主機已經(jīng)不再產(chǎn)生 SCK 時鐘。有些 HAL 庫版本在 SPI 完成 DMA 后會自動處理但 CS 是普通 GPIO不會自動拉高所以必須在 DMA 完成回調(diào)里手動操作。從機側(cè)如果使用硬件 NSS當 CS 拉高時從機 SPI 外設(shè)會強制停止當前傳輸導(dǎo)致 DMA 發(fā)送了一半被中止這個現(xiàn)象在調(diào)試時非常隱蔽。所以我個人強烈建議從機用軟件 NSS外部 CS 只做電平參考SPI 外設(shè)的選中狀態(tài)靠 SSI 位保持這樣即使 CS 提前拉高從機 DMA 也不會突然中斷。5. 三種方式怎么選一張表講清楚5.1 核心維度對比我把三種實現(xiàn)方式的關(guān)鍵參數(shù)放在一起直接對照著看更清楚。對比維度方式一請求線EXTI方式二主機輪詢方式三DMA請求線額外硬件引腳需要 1 根 REQ 線不需要額外引腳需要 1 根 REQ 線實時性高從機一拉線主機馬上響應(yīng)中取決于輪詢周期高請求后 DMA 批量讀取從機數(shù)據(jù)量小到中幾十字節(jié)合適小以單字節(jié)或短數(shù)據(jù)為主大幾百字節(jié)到幾 KB 最合適CPU 占用主機接收時消耗 CPU主機持續(xù)輪詢占用高主機和從機 CPU 占用都很低總線效率高一次傳輸全是有用數(shù)據(jù)低需要命令啞字節(jié)兩階段高批量數(shù)據(jù)一次傳完實現(xiàn)復(fù)雜度簡單簡單但協(xié)議要設(shè)計好較復(fù)雜需要處理 DMA 和乒乓典型場景按鍵、告警、小包數(shù)據(jù)傳感器周期上報、狀態(tài)查詢音頻、波形、高速數(shù)據(jù)采集5.2 實際項目選型經(jīng)驗如果從機只是偶發(fā)地報一下狀態(tài)比如按鍵按下、溫度越限、設(shè)備故障我一般選方式一。請求線加中斷代碼量小實時性高主機不需要一直跑輪詢功耗也低。如果是周期性的傳感器數(shù)據(jù)比如溫度、濕度、轉(zhuǎn)速這些數(shù)據(jù)本身量不大而且業(yè)務(wù)上允許幾百微秒到幾毫秒的延遲方式二最合適。它省了請求線主機按固定周期讀一次從機端只需要維護一個很簡單的狀態(tài)機。缺點就是主機輪詢必須一直跑不能停太久如果主機本身還在做其他實時任務(wù)要考慮輪詢周期是否影響整體調(diào)度。如果是做雙機間的高速數(shù)據(jù)交換比如從機采集 ADC 波形、音頻數(shù)據(jù)或者 IMU 九軸數(shù)據(jù)用方式三。請求線負責通知DMA 負責搬運乒乓緩沖負責把采集和發(fā)送流水線化。這種方式開發(fā)周期長一點但一旦調(diào)通效果非常穩(wěn)定主機側(cè)的 CPU 幾乎不用管數(shù)據(jù)搬運留給應(yīng)用層做算法和顯示。6. 常見問題與排查實錄6.1 一上電就是亂碼亂碼最常見的原因是 SPI 模式不一致。主機配置成 Mode 0從機配置成 Mode 3兩邊采樣點對不上數(shù)據(jù)就會錯位。碰到亂碼先把兩邊都改成 Mode 0CPOL0CPHA0然后檢查波特率分頻。STM32 主機 SPI 時鐘不能超過從機允許的極限從機 F103 一般建議主機 SPI 時鐘在 9 MHz 以下保守一點用 4.5 MHz 或 2.25 MHz 調(diào)通再說。另一個容易忽略的是 MISO 和 MOSI 接反。STM32 主機的 MISO 必須接從機的 MISO主機的 MOSI 必須接從機的 MOSI。很多杜邦線項目里顏色一多就容易把兩根數(shù)據(jù)線對調(diào)結(jié)果主機發(fā)命令從機收不到從機發(fā)數(shù)據(jù)主機也收不到。6.2 主機收不到從機數(shù)據(jù)先量一下 REQ 線有沒有正常拉高。如果 REQ 線一直是低電平說明從機應(yīng)用層可能沒走到發(fā)送函數(shù)或者發(fā)送函數(shù)卡在 while 等待里。再量 CS 線有沒有在主機收到請求后拉低。CS 線拉低但 MISO 沒有數(shù)據(jù)大概率是從機還沒準備好數(shù)據(jù)就通知了主機或者從機 SPI 沒有正確使能。還要檢查從機的 NSS 配置。如果從機用的硬件 NSS而主機的 CS 線和從機的 NSS 引腳沒接到一起或者電平邏輯反了從機 SPI 外設(shè)根本沒被選中自然發(fā)不出數(shù)據(jù)。從機用軟件 NSS 時要在 SPI 初始化后把 SSI 位置 1否則從機以為自己沒被選中也會罷工。6.3 請求線誤觸發(fā)或丟失請求線誤觸發(fā)大多是因為 REQ 線上有毛刺。從機 REQ 是普通 GPIO 推挽輸出正常不會有毛刺但如果主機 REQ 輸入引腳沒有使能內(nèi)部上拉懸空時很容易受干擾。建議主機 REQ 引腳配置上拉輸入并且在 EXTI 回調(diào)里加一個軟件去抖比如連續(xù)檢測兩次電平都滿足條件再置標志位。請求線丟失則要檢查從機拉高 REQ 之后是不是馬上又被自己的發(fā)送完成回調(diào)拉低了。比如主機響應(yīng)得很快CS 拉低、SCK 開始、DMA/中斷發(fā)送完成后從機立刻拉低 REQ。如果這個拉低發(fā)生在主機 EXTI 上升沿還沒被正確鎖存之前某些單片機可能會丟中斷。解決辦法是 REQ 拉低的時機不要放在從機發(fā)送完成回調(diào)里而是放到主機讀取完成后由主機主動拉低或者從機發(fā)送完成后再等一小段時間再拉低。實際項目里我習慣用從機發(fā)送完成回調(diào)拉低 REQ只要主機 EXTI 是上升沿觸發(fā)且中斷正?；径寄苕i住但如果性能測試發(fā)現(xiàn)偶發(fā)丟請求可以考慮把 REQ 改成電平觸發(fā)加標志位輪詢。6.4 DMA傳輸和中斷卡死DMA 卡死的典型現(xiàn)象是程序跑著跑著SPI 不再產(chǎn)生時鐘REQ 線一直高主機的 DMA 接收回調(diào)一直不執(zhí)行。原因一般有兩個。第一個是主機在 DMA 接收過程中再次收到 REQ 中斷主循環(huán)又把 CS 拉低、再次啟動 DMA導(dǎo)致上一次 DMA 還沒完成就被新的 DMA 請求覆蓋HAL 庫內(nèi)部狀態(tài)錯亂。解決辦法是加一個 g_dma_busy 標志DMA 接收完成回調(diào)里清除下次請求到來時如果 busy 還在就直接忽略或者排隊處理。第二個是從機 DMA 發(fā)送緩沖區(qū)在發(fā)送過程中被應(yīng)用層覆蓋了。我在做乒乓緩沖時遇到過從機正在 DMA 發(fā)送 buffer A采集任務(wù)卻把新數(shù)據(jù)寫到 buffer A導(dǎo)致發(fā)送數(shù)據(jù)被新數(shù)據(jù)污染。加乒乓緩沖后這個問題就消失了核心原則是DMA 正在用的緩沖區(qū)應(yīng)用層絕對不能寫。6.5 FreeRTOS下SPI中斷優(yōu)先級怎么設(shè)置如果項目里用了 FreeRTOSSPI 中斷和 EXTI 中斷的優(yōu)先級不能隨便給。HAL 庫在中斷回調(diào)里可能會調(diào)用portYIELD_FROM_ISR這樣的 FreeRTOS 宏如果中斷優(yōu)先級比configMAX_SYSCALL_INTERRUPT_PRIORITY更高FreeRTOS 就不允許在該中斷里調(diào)用任何與系統(tǒng)相關(guān)的 API否則會觸發(fā)斷言或直接卡死。我的習慣是把 STM32 的中斷優(yōu)先級分組設(shè)置為 4 位搶占優(yōu)先級然后 SPI 中斷和 EXTI 中斷的搶占優(yōu)先級都設(shè)置在 5~7 之間不要設(shè)到 0~3。這樣 FreeRTOS 可以管理這些中斷而且不會影響系統(tǒng)節(jié)拍。如果業(yè)務(wù)上確實需要更高的實時性可以把 SPI 中斷優(yōu)先級設(shè)為 4但代價是不能在中斷回調(diào)里調(diào)用任何 FreeRTOS API只能通過信號量或標志位通知任務(wù)不能直接在回調(diào)里osSemaphoreRelease或osMessageQueuePut。6.6 硬件NSS與軟件NSS的選擇STM32 的 SPI 支持硬件 NSS 和軟件 NSS初學者經(jīng)常在這上面踩坑。硬件 NSS 由 SPI 外設(shè)自動控制主機模式下可以在一次傳輸開始時自動拉低 NSS傳輸結(jié)束后拉高從機模式下 NSS 引腳的外部電平會直接決定從機是否被選中?？雌饋砗芊奖愕珜嶋H調(diào)試時NSS 和 SCK 的相對時序、多從機沖突、以及 DMA 傳輸過程中 CS 自動變化都會引入隱蔽問題。軟件 NSS 則是把 NSS 功能交給 GPIO 手動控制。主機側(cè) CS 引腳用普通 GPIO 拉低拉高完全由自己控制時序從機側(cè) SPI 的 NSS 配置為軟件模式然后設(shè)置 SPI 的 SSI 位為 1讓從機一直處于“邏輯選中”狀態(tài)外部 CS 線只作為應(yīng)用層判斷。這樣 SPI 外設(shè)的數(shù)據(jù)收發(fā)不會因為 CS 時序問題突然中止代碼也更好調(diào)。我個人做雙機通信更推薦軟件 NSS雖然要自己管理 CS 引腳但穩(wěn)定性會明顯好很多。7. 一點額外體會如果讓我在新項目里重新選一次偶發(fā)小數(shù)據(jù)我會選方式一周期性傳感器數(shù)據(jù)選方式二大數(shù)據(jù)量高速傳輸選方式三。實際項目里我更多是把方式一和方式三結(jié)合使用請求線負責通知DMA 負責搬運既能保證實時性又能把 CPU 從繁重的數(shù)據(jù)搬運里解放出來。SPI 的從機“主動發(fā)送”說到底只能做到通知主機來讀真正的主從關(guān)系并沒有變。選型時先想清楚數(shù)據(jù)量、延遲要求和引腳余量就不會走彎路。 STM32實戰(zhàn)：SPI從機主動發(fā)送數(shù)據(jù)的3種實現(xiàn)方案
做嵌入式這些年SPI 算是我用得最多的接口之一。前段時間有個項目兩個 STM32 要高速交換數(shù)據(jù)從機采集完一批數(shù)據(jù)后必須“立刻”發(fā)給主機。需求一提出來很多人第一反應(yīng)是SPI 從機怎么主動發(fā)數(shù)據(jù)SPI 主機才能提供時鐘從機連時鐘都沒有怎么主動這句話對但也不全對。SPI 從機確實不能憑空發(fā)起傳輸?shù)梢酝ㄟ^別的辦法“通知”主機來讀數(shù)據(jù)。這篇文章我就拿 STM32 為例分享從機主動發(fā)送數(shù)據(jù)的 3 種實現(xiàn)方式方案一是 GPIO 請求線加中斷方案二是主機輪詢方案三是 DMA 加乒乓緩沖各有優(yōu)缺點代碼也都給出來。1. 先搞清楚SPI從機憑什么“主動”1.1 SPI主從機制的底層邏輯SPI 之所以叫同步串行接口關(guān)鍵在于“同步”這兩個字。通信時誰提供 SCK 時鐘誰就是主機。主機控制 CS 片選信號決定跟哪個從機通信主機也決定什么時候開始傳輸、傳多少字節(jié)。從機的角色是被動的它只能檢測 CS 是否拉低、SCK 有沒有時鐘過來然后在時鐘的驅(qū)動下把數(shù)據(jù)從移位寄存器里送出去或者把總線上的數(shù)據(jù)收進來。所以從機“主動發(fā)送數(shù)據(jù)”這句話嚴格來說在 SPI 協(xié)議層面是不成立的。SCK 是主機的專屬資源從機沒有能力拉出 SCK 波形自然也就沒法啟動一次完整傳輸。我們要做的是在應(yīng)用層解決“從機有數(shù)據(jù)要發(fā)給主機”這個需求本質(zhì)思路都指向一句話讓從機通過某種方式告訴主機“我這有數(shù)據(jù)了你趕緊來讀”然后由主機發(fā)起 SPI 傳輸。這篇文章講的三種方式全是在這句話的基礎(chǔ)上展開的。1.2 三種思路的出發(fā)點第一種方式最直接從機專門拉一根 GPIO 線接到主機的 EXTI 中斷腳。從機有數(shù)據(jù)要發(fā)時先把 SPI 發(fā)送寄存器準備好再把這根請求線拉高主機收到中斷后就知道從機在等自己讀數(shù)據(jù)于是拉低 CS、啟動 SPI 接收。第二種方式省掉這根請求線主機按照固定周期主動發(fā)一個“讀命令”給從機從機收到命令后回傳數(shù)據(jù)。這種方式從機永遠不會主動開口但它實現(xiàn)了“從機數(shù)據(jù)能被及時拿走”的效果。代價是主機必須一直輪詢實時性和總線利用率都一般。第三種方式是把第一種方式的請求線和 DMA 結(jié)合適合數(shù)據(jù)量大、要求 CPU 占用低的場景。從機采集完數(shù)據(jù)后先啟動 SPI 的 DMA 發(fā)送然后拉高請求線主機在中斷里只用啟動 DMA 接收剩下的事全部交給 DMA 搬運。數(shù)據(jù)吞吐高而且不需要 CPU 一字節(jié)一字節(jié)地去處理。三種方式并不沖突實際項目里甚至可以組合使用。下面我分別把硬件連接、CubeMX 配置思路和 STM32 HAL 庫代碼拆開講。2. 方式一請求線EXTI中斷最快最直觀2.1 硬件連接與CubeMX配置思路方式一需要額外一根 GPIO 線我習慣叫它 REQ 線。連接是這樣的從機某個 GPIO 配置成推挽輸出接到主機的另一個 GPIO 輸入腳主機這個 GPIO 配置成 EXTI 外部中斷上升沿觸發(fā)。其他四根線照舊SCK、MOSI、MISO、CS 都接好主機和從機共地。CubeMX 里主機的 SPI 配置為 Full-Duplex Master從機配置為 Full-Duplex Slave。傳輸模式建議先用 Mode 0也就是 CPOL0、CPHA0這樣不容易出錯。主機 CS 引腳用普通 GPIO 輸出即可我習慣叫 CS_GPIO_Port / CS_Pin。從機的 NSS 如果不想用硬件控制可以把從機 SPI 的 NSS 設(shè)為 Software然后在初始化后把 SSI 置 1讓從機始終處于選中狀態(tài)真正的外部 CS 線就不參與 SPI 外設(shè)的使能判斷了。如果從機使用硬件 NSS則需要確保主機 CS 拉低時從機能檢測到片選有效時序要求更高新手階段容易被 NSS 的電平搞得一頭霧水所以軟件 NSS 更穩(wěn)。從機的 REQ 引腳在 CubeMX 里配成 GPIO_Output初始狀態(tài)輸出低電平主機的 REQ 引腳在 GPIO 配置里選擇 External Interrupt Mode with Rising edge trigger使能 EXTI 中斷。這里要注意主機的 GPIO 模式如果支持內(nèi)部上拉/下拉最好根據(jù)實際情況選擇是否啟用。REQ 線一般沒有高速翻轉(zhuǎn)要求普通推挽輸出就夠了。2.2 主機端代碼實現(xiàn)主機端的核心邏輯是在 EXTI 回調(diào)函數(shù)里只做一個標志位置位真正耗時的 SPI 接收放到主循環(huán)里處理不要在中斷服務(wù)函數(shù)里直接跑阻塞式 HAL_SPI_Receive否則主機整個中斷會被拉得很長其他實時任務(wù)可能被餓死。/* main.c 全局變量 */ volatile uint8_t g_slave_req 0; uint8_t g_rx_buf[32]; /* EXTI 回調(diào)REQ 引腳上升沿觸發(fā) */ void HAL_GPIO_EXTI_Callback(uint16_t GPIO_Pin) { if (GPIO_Pin REQ_Pin) { g_slave_req 1; } } /* 主循環(huán) */ while (1) { if (g_slave_req) { g_slave_req 0; /* 拉低片選通知從機開始傳輸 */ HAL_GPIO_WritePin(CS_GPIO_Port, CS_Pin, GPIO_PIN_RESET); /* 主機提供時鐘接收從機數(shù)據(jù) */ HAL_SPI_Receive(hspi1, g_rx_buf, sizeof(g_rx_buf), 100); /* 拉高片選結(jié)束本次傳輸 */ HAL_GPIO_WritePin(CS_GPIO_Port, CS_Pin, GPIO_PIN_SET); ProcessData(g_rx_buf, sizeof(g_rx_buf)); } }這里有一個關(guān)鍵點主機的 HAL_SPI_Receive 在讀數(shù)據(jù)的同時SPI 硬件也會把數(shù)據(jù)線上的數(shù)據(jù)移位進來但根據(jù) SPI 全雙工特性主機發(fā)送的字節(jié)是 0x00 或 0xFF具體由 HAL 庫的清零處理決定。所以從機側(cè)只要提前把數(shù)據(jù)放進發(fā)送寄存器主機這邊就能完整收到。2.3 從機端代碼實現(xiàn)從機端要做的事就是應(yīng)用層準備好了數(shù)據(jù)后先把數(shù)據(jù)放進 SPI 發(fā)送通道再拉高 REQ 線通知主機。為什么要先放數(shù)據(jù)再拉高 REQ因為主機接收到中斷后馬上就會拉低 CS 并啟動時鐘如果從機這時候才開始填 SPI 數(shù)據(jù)寄存器第一個字節(jié)大概率來不及主機收到的第一個字節(jié)就是錯的。/* main.c 從機側(cè) */ uint8_t g_tx_buf[32]; volatile uint8_t g_tx_busy 0; void Slave_SendData(uint8_t *data, uint16_t len) { while (g_tx_busy); // 等待上一次發(fā)送完成 memcpy(g_tx_buf, data, len); /* 先啟動中斷發(fā)送讓第一個字節(jié)預(yù)裝載到 SPI 數(shù)據(jù)寄存器 */ HAL_SPI_Transmit_IT(hspi1, g_tx_buf, len); g_tx_busy 1; /* 再通知主機過來讀 */ HAL_GPIO_WritePin(REQ_GPIO_Port, REQ_Pin, GPIO_PIN_SET); } /* 從機發(fā)送完成回調(diào) */ void HAL_SPI_TxCpltCallback(SPI_HandleTypeDef *hspi) { if (hspi hspi1) { /* 主機已經(jīng)讀完撤下請求線允許下一次請求 */ HAL_GPIO_WritePin(REQ_GPIO_Port, REQ_Pin, GPIO_PIN_RESET); g_tx_busy 0; } }從機調(diào)用 HAL_SPI_Transmit_IT 的時候CS 可能還是高電平SCK 也沒有時鐘但這不是問題。SPI 外設(shè)使能后數(shù)據(jù)寄存器是可寫的HAL_SPI_Transmit_IT 會把第一字節(jié)寫到數(shù)據(jù)寄存器里然后等 TXE 事件。等到主機拉低 CS、開始產(chǎn)生 SCK 時鐘時第一字節(jié)被移出去TXE 置位中斷再填充第二字節(jié)。所以“先啟動發(fā)送再通知主機”這個順序絕對不能反。2.4 方式一的關(guān)鍵細節(jié)第一個細節(jié)是請求線觸發(fā)方式。我在代碼里用的是上升沿觸發(fā)從機拉高 REQ 請求主機收到上升沿中斷。主機的判斷要帶標志位去清不要在主循環(huán)和 EXTI 回調(diào)之間出現(xiàn)競態(tài)。如果同時來了多個請求可以給標志位加計數(shù)但如果只需要“有數(shù)據(jù)就讀”一個標志位就夠了。第二個細節(jié)是 CS 的時序。對從機來說主機 CS 拉低后從機 SPI 外設(shè)才真正進入被選中狀態(tài)。如果從機用的是硬件 NSS那么 CS 線必須先于 SCK 拉低且持續(xù)到整個幀結(jié)束如果從機用軟件 NSS則外部 CS 不直接控制 SPI 外設(shè)但仍建議用 GPIO 模擬 CS 來保證從機應(yīng)用層能知道當前是否被選中這樣在調(diào)試時你能清楚看見時序。第三個細節(jié)是中斷優(yōu)先級。主機 EXTI 中斷不要設(shè)置成最高優(yōu)先級因為中斷里只置標志位實際 SPI 接收在主循環(huán)里所以優(yōu)先級比系統(tǒng)節(jié)拍低一點即可。從機 SPI 發(fā)送中斷的優(yōu)先級則要看實時性要求數(shù)據(jù)量大時建議把 SPI 中斷優(yōu)先級調(diào)高避免 SCK 時鐘太快導(dǎo)致 TXE 中斷沒來得及填充下一字節(jié)從而出現(xiàn)丟數(shù)據(jù)。3. 方式二主機輪詢命令應(yīng)答省一根請求線3.1 兩階段讀命令協(xié)議設(shè)計方式二適合不想多拉線的場景主機只要定時發(fā)命令從機在命令的驅(qū)動下返回數(shù)據(jù)。很多人寫到這里會忽略一個問題SPI 是全雙工通信主機發(fā)命令字節(jié)的同時從機的 MISO 線上其實也在輸出數(shù)據(jù)。從機在收到命令之后才準備數(shù)據(jù)那就晚了因為這個字節(jié)已經(jīng)隨著時鐘移出去了。所以需要把一次“讀取操作”拆成兩個階段。第一階段主機發(fā)送一字節(jié)命令從機接收命令的同時MISO 上送出的是上一次預(yù)留的應(yīng)答字節(jié)或者占位字節(jié)這一階段主機收到的數(shù)據(jù)一般丟棄。第二階段主機再發(fā)送一字節(jié)啞數(shù)據(jù)從機在收到第一階段的命令后已經(jīng)把真正的數(shù)據(jù)放到 SPI 發(fā)送數(shù)據(jù)寄存器里了這一次時鐘會把數(shù)據(jù)完整送出主機收到的就是有效數(shù)據(jù)。計算一下開銷每次讀取有效數(shù)據(jù) 1 字節(jié)實際總線傳輸 2 字節(jié)。如果主機輪詢周期是 1ms那么當前這包數(shù)據(jù)的最大延遲大約是 2ms平均延遲 1ms 左右。數(shù)據(jù)量小、實時性要求不高時這種方式很實用。3.2 主機輪詢代碼主機端比較簡單用一個定時器或者直接在主循環(huán)里做周期輪詢。我建議用定時器的回調(diào)置一個標志位主循環(huán)里處理避免在定時器中斷里阻塞太久。每次讀完再啟動下一次。/* main.c 主機 */ uint8_t cmd CMD_READ_DATA; uint8_t dummy 0; uint8_t rx_dummy; uint8_t rx_data; void TimerPeriodElapsedCallback(TIM_HandleTypeDef *htim) { if (htim htim2) { g_poll_flag 1; } } while (1) { if (g_poll_flag) { g_poll_flag 0; /* CS 拉低 */ HAL_GPIO_WritePin(CS_GPIO_Port, CS_Pin, GPIO_PIN_RESET); /* 階段 1發(fā)送命令收到的是從機的占位數(shù)據(jù) */ HAL_SPI_TransmitReceive(hspi1, cmd, rx_dummy, 1, 10); /* 階段 2發(fā)送啞字節(jié)同時讀取從機的有效數(shù)據(jù) */ HAL_SPI_TransmitReceive(hspi1, dummy, rx_data, 1, 10); /* CS 拉高 */ HAL_GPIO_WritePin(CS_GPIO_Port, CS_Pin, GPIO_PIN_SET); ProcessSensorData(rx_data); } }如果主機需要一次讀取多個字節(jié)可以從機側(cè)在命令階段之后連續(xù)輸出多個有效字節(jié)。比如讀取 16 字節(jié)溫度數(shù)據(jù)主機第一階段發(fā)命令第二階段連續(xù)發(fā) 16 個啞字節(jié)從機狀態(tài)機里根據(jù)命令把 16 字節(jié)連續(xù)發(fā)送出來。3.3 從機狀態(tài)機代碼從機側(cè)我推薦用 HAL 庫的 HAL_SPI_TransmitReceive_IT讓狀態(tài)機始終處于接收狀態(tài)。初始化時先啟動一次“命令接收”傳輸收到命令后在回調(diào)里切換到“數(shù)據(jù)發(fā)送”狀態(tài)發(fā)送完成后再切換回“命令接收”狀態(tài)。/* 從機全局變量 */ uint8_t rx_byte; uint8_t tx_byte; uint8_t tx_dummy 0xFF; volatile uint8_t spi_state STATE_WAIT_CMD; // 0等命令1發(fā)數(shù)據(jù) /* 初始化時啟動命令接收 */ void Slave_SPI_Init(void) { spi_state STATE_WAIT_CMD; HAL_SPI_TransmitReceive_IT(hspi1, tx_dummy, rx_byte, 1); } /* 發(fā)送接收完成回調(diào) */ void HAL_SPI_TxRxCpltCallback(SPI_HandleTypeDef *hspi) { if (hspi ! hspi1) return; if (spi_state STATE_WAIT_CMD) { if (rx_byte CMD_READ_DATA) { tx_byte ReadSensorData(); spi_state STATE_SEND_DATA; } /* 不管是不是有效命令都回到等待命令狀態(tài) 但若收到有效命令下一階段就會發(fā)送有效數(shù)據(jù) */ if (spi_state STATE_SEND_DATA) { /* 階段 2主機發(fā)送啞字節(jié)時從機發(fā)送 tx_byte */ HAL_SPI_TransmitReceive_IT(hspi1, tx_byte, rx_byte, 1); } else { HAL_SPI_TransmitReceive_IT(hspi1, tx_dummy, rx_byte, 1); } } else if (spi_state STATE_SEND_DATA) { /* 數(shù)據(jù)發(fā)送完成重新等命令 */ spi_state STATE_WAIT_CMD; HAL_SPI_TransmitReceive_IT(hspi1, tx_dummy, rx_byte, 1); } }這個狀態(tài)機代碼的精髓在于從機永遠在等主機發(fā)起的 SPI 傳輸永遠處于“接收命令或發(fā)送數(shù)據(jù)”的循環(huán)中。主機不來時鐘這個狀態(tài)機就一直掛著主機時鐘來了從機的數(shù)據(jù)就會自動被讀走。這種方式雖然叫“從機主動發(fā)送”但實際協(xié)議層面是主機一直在主動讀從機的主動性體現(xiàn)在“有數(shù)據(jù)時能及時通過命令應(yīng)答帶出去”。3.4 延遲與總線效率分析方式二最怕的是主機輪詢周期和數(shù)據(jù)到達時機不對齊。比如傳感器每 10ms 更新一次主機若 5ms 輪詢一次那讀取到的數(shù)據(jù)平均會有 2.5ms 左右的陳舊延遲。主機若在數(shù)據(jù)更新前讀拿到的就是上一周期的舊值如果業(yè)務(wù)要求拿到“最新值”可以給協(xié)議加一個狀態(tài)字段從機在應(yīng)答數(shù)據(jù)里帶一個“數(shù)據(jù)更新序號”或者“數(shù)據(jù)有效標志”主機讀到舊值時可以選擇連續(xù)重讀或丟棄?？偩€效率方面方式二每一字節(jié)有效數(shù)據(jù)都要消耗兩個時鐘字節(jié)效率是 50%。如果主機能接受問題不大如果對總線效率敏感建議用方式一或方式三。另外主機輪詢會持續(xù)產(chǎn)生 SPI 時鐘對一些低功耗場景不友好因為主機不能一直跑否則系統(tǒng)功耗壓不下去。4. 方式三DMA批量搬運乒乓緩沖高性能大頭兵4.1 DMA請求線的配合方式方式三是方式一的升級版思路仍然是“從機請求主機讀取”但把“逐字節(jié)中斷搬運”替換成“DMA 搬運”。使用 DMA 的好處很明顯主機收到 REQ 中斷后只需拉低 CS、啟動一次 HAL_SPI_Receive_DMACPU 就可以去做別的事了DMA 會在 SPI 時鐘驅(qū)動下把數(shù)據(jù)自動搬到內(nèi)存。從機這邊也一樣數(shù)據(jù)在 DMA 的驅(qū)動下自動從內(nèi)存搬到 SPI 發(fā)送數(shù)據(jù)寄存器不需要內(nèi)核逐字節(jié)處理。這里有一個很重要的硬性約束從機必須先啟動 DMA 發(fā)送讓 DMA 把第一字節(jié)送到 SPI 數(shù)據(jù)寄存器再拉高 REQ 線。主機收到 REQ 后立即拉低 CS 并啟動讀取此時 SPI 時鐘一產(chǎn)生第一字節(jié)就能直接移出。如果順序顛倒從機先拉高 REQ主機隨后馬上產(chǎn)生時鐘而 DMA 還沒來得及把第一字節(jié)寫入 SPI 數(shù)據(jù)寄存器第一個字節(jié)就會變成上一個殘留數(shù)據(jù)或者干脆是空數(shù)據(jù)主機接收到的第一字節(jié)就會錯位。4.2 乒乓緩沖為了什么DMA 搬運數(shù)據(jù)是直接從內(nèi)存緩沖區(qū)搬到 SPI 外設(shè)不需要 CPU 參與。這意味著 CPU 可以在 DMA 正在發(fā)送緩沖區(qū) A 的時候去往緩沖區(qū) B 填充新數(shù)據(jù)等下一輪發(fā)送輪到緩沖區(qū) B 時CPU 又可以去填充緩沖區(qū) A。這叫乒乓緩沖。為什么一定要乒乓因為如果你只有一個緩沖區(qū)CPU 在一輪采集后填充完數(shù)據(jù)啟動 DMA 發(fā)送接著 CPU 又想在新一輪數(shù)據(jù)到達時填充同一個緩沖區(qū)就會導(dǎo)致 DMA 還沒發(fā)完的數(shù)據(jù)被新數(shù)據(jù)覆蓋主機讀到的數(shù)據(jù)前后撕裂或者出現(xiàn)半個新幀、半個舊幀。乒乓緩沖把“填充數(shù)據(jù)”和“發(fā)送數(shù)據(jù)”在時間上錯開只要 CPU 填充緩沖區(qū) B 的速度比 DMA 發(fā)送緩沖區(qū) A 的速度快就不會互相干擾。乒乓緩沖的代碼結(jié)構(gòu)簡單說就是兩個數(shù)組一個正在被 DMA 讀另一個正在被 CPU 填。發(fā)送完成后交換角色。我這里給一個單緩沖的簡化版本重點是把 DMA 和 REQ 請求怎么配合講清楚真正做乒乓時把下面代碼里的單個 buffer 換成 buffer[2]再用一個索引來切換即可。4.3 從機和主機代碼骨架從機側(cè)代碼假設(shè)傳感器采集好的數(shù)據(jù)已經(jīng)放在 g_tx_buffer 里長度為 BUF_LEN。/* 從機 */ #define BUF_LEN 256 uint8_t g_tx_buffer[BUF_LEN]; /* 應(yīng)用層數(shù)據(jù)準備好后主動發(fā)送 */ void Slave_RequestSend(uint8_t *data) { /* 拷貝數(shù)據(jù)到 DMA 發(fā)送緩沖區(qū) */ memcpy(g_tx_buffer, data, BUF_LEN); /* 等待上一次 DMA 發(fā)送完全結(jié)束 */ while (HAL_SPI_GetState(hspi1) ! HAL_SPI_STATE_READY); /* 先啟動 DMA 發(fā)送讓第一字節(jié)預(yù)裝載 */ HAL_SPI_Transmit_DMA(hspi1, g_tx_buffer, BUF_LEN); /* 再通知主機來讀 */ HAL_GPIO_WritePin(REQ_GPIO_Port, REQ_Pin, GPIO_PIN_SET); } /* 從機 DMA 發(fā)送完成回調(diào) */ void HAL_SPI_TxCpltCallback(SPI_HandleTypeDef *hspi) { if (hspi hspi1) { /* 主機讀完了撤下請求線 */ HAL_GPIO_WritePin(REQ_GPIO_Port, REQ_Pin, GPIO_PIN_RESET); } }主機側(cè)代碼收到 REQ 中斷后啟動 DMA 接收。/* 主機全局變量 */ uint8_t g_rx_buffer[BUF_LEN]; volatile uint8_t g_slave_req 0; void HAL_GPIO_EXTI_Callback(uint16_t GPIO_Pin) { if (GPIO_Pin REQ_Pin) { g_slave_req 1; } } /* 主循環(huán) */ while (1) { if (g_slave_req) { g_slave_req 0; /* 拉低 CS從機開始輸出數(shù)據(jù) */ HAL_GPIO_WritePin(CS_GPIO_Port, CS_Pin, GPIO_PIN_RESET); /* 啟動 DMA 接收主機產(chǎn)生 BUF_LEN 個時鐘 */ HAL_SPI_Receive_DMA(hspi1, g_rx_buffer, BUF_LEN); } } /* DMA 接收完成回調(diào) */ void HAL_SPI_RxCpltCallback(SPI_HandleTypeDef *hspi) { if (hspi hspi1) { /* 拉高 CS結(jié)束本次傳輸 */ HAL_GPIO_WritePin(CS_GPIO_Port, CS_Pin, GPIO_PIN_SET); /* 處理數(shù)據(jù) */ ProcessData(g_rx_buffer, BUF_LEN); } }這段代碼看起來很簡單但實際項目里我會把 HAL_SPI_Receive_DMA 放到 EXTI 回調(diào)里直接啟動因為函數(shù)本身只是配置 DMA 并開啟傳輸耗時極短。主循環(huán)里置標志位再處理也是一種穩(wěn)妥做法優(yōu)先級上并沒有問題。真正要注意的是 CS 引腳和 DMA 狀態(tài)的配合如果上一次 DMA 還沒有完成下一次 REQ 就來了主機這邊必須等待或做保護否則 CS 拉低之后啟動 DMA 會出現(xiàn)并發(fā)錯誤。4.4 避免DMA傳輸踩坑DMA 的第一個坑是緩沖區(qū)長度超長時SPI 時鐘連續(xù)翻轉(zhuǎn)如果主機和從機的波特率分頻設(shè)置不一致或者主頻不同就可能導(dǎo)致采樣點偏移。STM32 的 SPI 從模式一般可以跟得上主機速率但要注意 SPI 的時鐘極性和相位必須完全一致特別是 Mode 0 和 Mode 3 這兩個模式都不難配只是千萬別一邊配 Mode 0、一邊配 Mode 3。第二個坑是 DMA 中斷和 SPI 中斷的優(yōu)先級。從機在 DMA 發(fā)送完整個緩沖區(qū)后觸發(fā)完成中斷這個中斷里要拉低 REQ不能拖太久。如果 REQ 線被長時間占用主機可能來不及在下一輪請求前釋放資源。實際上我在做高速傳輸時會把從機的 DMA 中斷優(yōu)先級設(shè)置為較高主機的 EXTI 請求線中斷優(yōu)先級設(shè)置為中等SPI 的全局中斷優(yōu)先級設(shè)置為比 EXTI 低一點保證“請求”和“發(fā)送完成”不會被 DMA 中斷的長時間處理拖延。第三個坑是首字節(jié)錯誤。前面反復(fù)強調(diào)過從機要先啟動 DMA 再拉高 REQ。但還有一個細節(jié)是 DMA 配置里 Data Width 要和 SPI 數(shù)據(jù)寬度一致。STM32 的 SPI 通常配置 8 位數(shù)據(jù)DMA 的 Peripheral Data Size 和 Memory Data Size 都應(yīng)該是 Byte。如果配成 Half Word 或者 WordDMA 搬運的數(shù)據(jù)寬度會和 SPI 外設(shè)不匹配收發(fā)內(nèi)容直接亂掉。第四個坑是 CS 線。數(shù)據(jù)量大時CS 全程拉低直到 DMA 結(jié)束這一點協(xié)議上沒有爭議。但 CS 拉高前要確保主機已經(jīng)不再產(chǎn)生 SCK 時鐘。有些 HAL 庫版本在 SPI 完成 DMA 后會自動處理但 CS 是普通 GPIO不會自動拉高所以必須在 DMA 完成回調(diào)里手動操作。從機側(cè)如果使用硬件 NSS當 CS 拉高時從機 SPI 外設(shè)會強制停止當前傳輸導(dǎo)致 DMA 發(fā)送了一半被中止這個現(xiàn)象在調(diào)試時非常隱蔽。所以我個人強烈建議從機用軟件 NSS外部 CS 只做電平參考SPI 外設(shè)的選中狀態(tài)靠 SSI 位保持這樣即使 CS 提前拉高從機 DMA 也不會突然中斷。5. 三種方式怎么選一張表講清楚5.1 核心維度對比我把三種實現(xiàn)方式的關(guān)鍵參數(shù)放在一起直接對照著看更清楚。對比維度方式一請求線EXTI方式二主機輪詢方式三DMA請求線額外硬件引腳需要 1 根 REQ 線不需要額外引腳需要 1 根 REQ 線實時性高從機一拉線主機馬上響應(yīng)中取決于輪詢周期高請求后 DMA 批量讀取從機數(shù)據(jù)量小到中幾十字節(jié)合適小以單字節(jié)或短數(shù)據(jù)為主大幾百字節(jié)到幾 KB 最合適CPU 占用主機接收時消耗 CPU主機持續(xù)輪詢占用高主機和從機 CPU 占用都很低總線效率高一次傳輸全是有用數(shù)據(jù)低需要命令啞字節(jié)兩階段高批量數(shù)據(jù)一次傳完實現(xiàn)復(fù)雜度簡單簡單但協(xié)議要設(shè)計好較復(fù)雜需要處理 DMA 和乒乓典型場景按鍵、告警、小包數(shù)據(jù)傳感器周期上報、狀態(tài)查詢音頻、波形、高速數(shù)據(jù)采集5.2 實際項目選型經(jīng)驗如果從機只是偶發(fā)地報一下狀態(tài)比如按鍵按下、溫度越限、設(shè)備故障我一般選方式一。請求線加中斷代碼量小實時性高主機不需要一直跑輪詢功耗也低。如果是周期性的傳感器數(shù)據(jù)比如溫度、濕度、轉(zhuǎn)速這些數(shù)據(jù)本身量不大而且業(yè)務(wù)上允許幾百微秒到幾毫秒的延遲方式二最合適。它省了請求線主機按固定周期讀一次從機端只需要維護一個很簡單的狀態(tài)機。缺點就是主機輪詢必須一直跑不能停太久如果主機本身還在做其他實時任務(wù)要考慮輪詢周期是否影響整體調(diào)度。如果是做雙機間的高速數(shù)據(jù)交換比如從機采集 ADC 波形、音頻數(shù)據(jù)或者 IMU 九軸數(shù)據(jù)用方式三。請求線負責通知DMA 負責搬運乒乓緩沖負責把采集和發(fā)送流水線化。這種方式開發(fā)周期長一點但一旦調(diào)通效果非常穩(wěn)定主機側(cè)的 CPU 幾乎不用管數(shù)據(jù)搬運留給應(yīng)用層做算法和顯示。6. 常見問題與排查實錄6.1 一上電就是亂碼亂碼最常見的原因是 SPI 模式不一致。主機配置成 Mode 0從機配置成 Mode 3兩邊采樣點對不上數(shù)據(jù)就會錯位。碰到亂碼先把兩邊都改成 Mode 0CPOL0CPHA0然后檢查波特率分頻。STM32 主機 SPI 時鐘不能超過從機允許的極限從機 F103 一般建議主機 SPI 時鐘在 9 MHz 以下保守一點用 4.5 MHz 或 2.25 MHz 調(diào)通再說。另一個容易忽略的是 MISO 和 MOSI 接反。STM32 主機的 MISO 必須接從機的 MISO主機的 MOSI 必須接從機的 MOSI。很多杜邦線項目里顏色一多就容易把兩根數(shù)據(jù)線對調(diào)結(jié)果主機發(fā)命令從機收不到從機發(fā)數(shù)據(jù)主機也收不到。6.2 主機收不到從機數(shù)據(jù)先量一下 REQ 線有沒有正常拉高。如果 REQ 線一直是低電平說明從機應(yīng)用層可能沒走到發(fā)送函數(shù)或者發(fā)送函數(shù)卡在 while 等待里。再量 CS 線有沒有在主機收到請求后拉低。CS 線拉低但 MISO 沒有數(shù)據(jù)大概率是從機還沒準備好數(shù)據(jù)就通知了主機或者從機 SPI 沒有正確使能。還要檢查從機的 NSS 配置。如果從機用的硬件 NSS而主機的 CS 線和從機的 NSS 引腳沒接到一起或者電平邏輯反了從機 SPI 外設(shè)根本沒被選中自然發(fā)不出數(shù)據(jù)。從機用軟件 NSS 時要在 SPI 初始化后把 SSI 位置 1否則從機以為自己沒被選中也會罷工。6.3 請求線誤觸發(fā)或丟失請求線誤觸發(fā)大多是因為 REQ 線上有毛刺。從機 REQ 是普通 GPIO 推挽輸出正常不會有毛刺但如果主機 REQ 輸入引腳沒有使能內(nèi)部上拉懸空時很容易受干擾。建議主機 REQ 引腳配置上拉輸入并且在 EXTI 回調(diào)里加一個軟件去抖比如連續(xù)檢測兩次電平都滿足條件再置標志位。請求線丟失則要檢查從機拉高 REQ 之后是不是馬上又被自己的發(fā)送完成回調(diào)拉低了。比如主機響應(yīng)得很快CS 拉低、SCK 開始、DMA/中斷發(fā)送完成后從機立刻拉低 REQ。如果這個拉低發(fā)生在主機 EXTI 上升沿還沒被正確鎖存之前某些單片機可能會丟中斷。解決辦法是 REQ 拉低的時機不要放在從機發(fā)送完成回調(diào)里而是放到主機讀取完成后由主機主動拉低或者從機發(fā)送完成后再等一小段時間再拉低。實際項目里我習慣用從機發(fā)送完成回調(diào)拉低 REQ只要主機 EXTI 是上升沿觸發(fā)且中斷正?；径寄苕i住但如果性能測試發(fā)現(xiàn)偶發(fā)丟請求可以考慮把 REQ 改成電平觸發(fā)加標志位輪詢。6.4 DMA傳輸和中斷卡死DMA 卡死的典型現(xiàn)象是程序跑著跑著SPI 不再產(chǎn)生時鐘REQ 線一直高主機的 DMA 接收回調(diào)一直不執(zhí)行。原因一般有兩個。第一個是主機在 DMA 接收過程中再次收到 REQ 中斷主循環(huán)又把 CS 拉低、再次啟動 DMA導(dǎo)致上一次 DMA 還沒完成就被新的 DMA 請求覆蓋HAL 庫內(nèi)部狀態(tài)錯亂。解決辦法是加一個 g_dma_busy 標志DMA 接收完成回調(diào)里清除下次請求到來時如果 busy 還在就直接忽略或者排隊處理。第二個是從機 DMA 發(fā)送緩沖區(qū)在發(fā)送過程中被應(yīng)用層覆蓋了。我在做乒乓緩沖時遇到過從機正在 DMA 發(fā)送 buffer A采集任務(wù)卻把新數(shù)據(jù)寫到 buffer A導(dǎo)致發(fā)送數(shù)據(jù)被新數(shù)據(jù)污染。加乒乓緩沖后這個問題就消失了核心原則是DMA 正在用的緩沖區(qū)應(yīng)用層絕對不能寫。6.5 FreeRTOS下SPI中斷優(yōu)先級怎么設(shè)置如果項目里用了 FreeRTOSSPI 中斷和 EXTI 中斷的優(yōu)先級不能隨便給。HAL 庫在中斷回調(diào)里可能會調(diào)用portYIELD_FROM_ISR這樣的 FreeRTOS 宏如果中斷優(yōu)先級比configMAX_SYSCALL_INTERRUPT_PRIORITY更高FreeRTOS 就不允許在該中斷里調(diào)用任何與系統(tǒng)相關(guān)的 API否則會觸發(fā)斷言或直接卡死。我的習慣是把 STM32 的中斷優(yōu)先級分組設(shè)置為 4 位搶占優(yōu)先級然后 SPI 中斷和 EXTI 中斷的搶占優(yōu)先級都設(shè)置在 5~7 之間不要設(shè)到 0~3。這樣 FreeRTOS 可以管理這些中斷而且不會影響系統(tǒng)節(jié)拍。如果業(yè)務(wù)上確實需要更高的實時性可以把 SPI 中斷優(yōu)先級設(shè)為 4但代價是不能在中斷回調(diào)里調(diào)用任何 FreeRTOS API只能通過信號量或標志位通知任務(wù)不能直接在回調(diào)里osSemaphoreRelease或osMessageQueuePut。6.6 硬件NSS與軟件NSS的選擇STM32 的 SPI 支持硬件 NSS 和軟件 NSS初學者經(jīng)常在這上面踩坑。硬件 NSS 由 SPI 外設(shè)自動控制主機模式下可以在一次傳輸開始時自動拉低 NSS傳輸結(jié)束后拉高從機模式下 NSS 引腳的外部電平會直接決定從機是否被選中?？雌饋砗芊奖愕珜嶋H調(diào)試時NSS 和 SCK 的相對時序、多從機沖突、以及 DMA 傳輸過程中 CS 自動變化都會引入隱蔽問題。軟件 NSS 則是把 NSS 功能交給 GPIO 手動控制。主機側(cè) CS 引腳用普通 GPIO 拉低拉高完全由自己控制時序從機側(cè) SPI 的 NSS 配置為軟件模式然后設(shè)置 SPI 的 SSI 位為 1讓從機一直處于“邏輯選中”狀態(tài)外部 CS 線只作為應(yīng)用層判斷。這樣 SPI 外設(shè)的數(shù)據(jù)收發(fā)不會因為 CS 時序問題突然中止代碼也更好調(diào)。我個人做雙機通信更推薦軟件 NSS雖然要自己管理 CS 引腳但穩(wěn)定性會明顯好很多。7. 一點額外體會如果讓我在新項目里重新選一次偶發(fā)小數(shù)據(jù)我會選方式一周期性傳感器數(shù)據(jù)選方式二大數(shù)據(jù)量高速傳輸選方式三。實際項目里我更多是把方式一和方式三結(jié)合使用請求線負責通知DMA 負責搬運既能保證實時性又能把 CPU 從繁重的數(shù)據(jù)搬運里解放出來。SPI 的從機“主動發(fā)送”說到底只能做到通知主機來讀真正的主從關(guān)系并沒有變。選型時先想清楚數(shù)據(jù)量、延遲要求和引腳余量就不會走彎路。