接收與空閑中斷定幀實(shí)戰(zhàn)詳解)
最近在調(diào)STM32N6的串口這顆芯片的定位很有意思——Cortex-M55內(nèi)核加上NPU主頻能跑到800MHz算力在MCU里算天花板級(jí)別了。但不管內(nèi)核多強(qiáng)外部通信始終繞不開USART。我在用STM32N6做一臺(tái)小型運(yùn)動(dòng)控制器的串口協(xié)議交互時(shí)發(fā)現(xiàn)很多同學(xué)對(duì)USART配合DMA做循環(huán)接收Cyclic Receiving還存在幾個(gè)常見誤區(qū)一是不知道循環(huán)模式和普通模式的區(qū)別二是不知道怎樣用空閑中斷定幀三是環(huán)形緩沖區(qū)的讀寫索引經(jīng)常算錯(cuò)。這篇文章就把這套方案從原理、配置到代碼實(shí)現(xiàn)完整梳理一遍幫大家少踩坑。這套方案解決的核心問題有兩個(gè)高波特率下不丟數(shù)據(jù)以及不定長(zhǎng)數(shù)據(jù)幀的可靠接收。適合正在用STM32N6、STM32H7系列做串口通信、需要高效收發(fā)數(shù)據(jù)的開發(fā)者參考。如果你之前一直用單字節(jié)中斷接收或者DMA接收固定長(zhǎng)度后頻繁重開這篇文章尤其值得看。1. 項(xiàng)目背景與方案選型思考1.1 STM32N6的串口資源與接收痛點(diǎn)STM32N6的USART外設(shè)和STM32H7基本一脈相承支持到9Mbit/s的波特率帶有FIFO、硬件流控、超時(shí)寄存器等高級(jí)功能。芯片內(nèi)部的DMA控制器支持8個(gè)DMA流每個(gè)流有8個(gè)通道請(qǐng)求映射理論上可以支撐多個(gè)高速外設(shè)并行搬運(yùn)數(shù)據(jù)。但外設(shè)資源豐富是一回事能不能用對(duì)是另一回事。我之前調(diào)試一塊基于STM32N6的采集板時(shí)上位機(jī)以921600波特率持續(xù)下發(fā)數(shù)據(jù)幀每幀長(zhǎng)度在8到64字節(jié)之間不固定。最開始用傳統(tǒng)的串口接收中斷逐字節(jié)處理結(jié)果在系統(tǒng)同時(shí)跑NPU推理和顯示屏刷新時(shí)中斷頻繁搶占導(dǎo)致緩沖區(qū)溢出偶爾還會(huì)出現(xiàn)字節(jié)丟失。事后分析發(fā)現(xiàn)單字節(jié)中斷處理在波特率超過460800以后CPU負(fù)載占比就已經(jīng)很可觀了高頻次中斷帶來的上下文切換開銷遠(yuǎn)比你想象的大。換用DMA之后CPU只需要在空閑中斷觸發(fā)時(shí)去DMA緩沖區(qū)里取一次數(shù)據(jù)中間的所有字節(jié)搬運(yùn)都由DMA完成。實(shí)測(cè)下來921600波特率下DMA循環(huán)接收方案的CPU占用率相比中斷接收可以下降一個(gè)數(shù)量級(jí)以上這對(duì)于需要把大部分算力讓給NPU做推理的STM32N6來說意義非常明顯。1.2 為什么選循環(huán)模式而不是普通DMA模式很多第一次接觸DMA接收的同學(xué)第一反應(yīng)是把DMA配置成Normal模式設(shè)置接收長(zhǎng)度然后調(diào)用HAL_UART_Receive_DMA。這種做法最直觀的問題在于當(dāng)DMA緩沖區(qū)收滿之后傳輸就會(huì)停止軟件必須重新調(diào)用一次HAL_UART_Receive_DMA才能繼續(xù)接收。這在固定長(zhǎng)度的數(shù)據(jù)幀場(chǎng)景下還沒什么問題但遇到不定長(zhǎng)數(shù)據(jù)就非常尷尬——因?yàn)闊o法預(yù)先知道DMA通道該搬運(yùn)多少字節(jié)。循環(huán)模式Circular Mode則不同。DMA啟動(dòng)后每接收一個(gè)字節(jié)硬件寫指針向后推進(jìn)緩沖區(qū)寫滿后自動(dòng)回繞到起始地址繼續(xù)寫入整個(gè)過程完全不需要CPU介入也不會(huì)自動(dòng)停止。你只需要在任意時(shí)刻讀取DMA的計(jì)數(shù)器__HAL_DMA_GET_COUNTER就能知道當(dāng)前DMA寫到了緩沖區(qū)哪個(gè)位置。這個(gè)機(jī)制在嵌入式里可以類比成音頻播放的環(huán)形緩沖區(qū)播放器不停地從緩沖區(qū)取數(shù)據(jù)寫入DAC寫滿了就回到開頭繼續(xù)只要消費(fèi)速度跟得上生產(chǎn)速度就能無間斷運(yùn)行。USART DMA循環(huán)接收本質(zhì)上就是一個(gè)由硬件維護(hù)寫指針、由軟件維護(hù)讀指針的環(huán)形緩沖區(qū)。1.3 兩種主流方案對(duì)比空閑中斷定幀 vs 超時(shí)定時(shí)器用DMA循環(huán)接收數(shù)據(jù)核心問題不是接收本身而是怎么把一幀完整的數(shù)據(jù)從持續(xù)流動(dòng)的字節(jié)流中切分出來。常見的定幀策略有兩種。第一種是串口空閑中斷IDLE定幀。USART在檢測(cè)到總線上一個(gè)字節(jié)都沒有的空閑狀態(tài)后會(huì)觸發(fā)IDLE中斷。通常協(xié)議設(shè)計(jì)里一幀數(shù)據(jù)的每個(gè)字節(jié)之間是緊密相連的幀與幀之間會(huì)有短暫間隔這個(gè)間隔正好可以被空閑中斷捕捉到。當(dāng)IDLE中斷觸發(fā)時(shí)說明一幀數(shù)據(jù)已經(jīng)完整進(jìn)入DMA緩沖區(qū)此時(shí)去讀取DMA寫指針和軟件維護(hù)的讀指針就能把這一幀數(shù)據(jù)提取出來。這種方案實(shí)現(xiàn)簡(jiǎn)單、實(shí)時(shí)性高是當(dāng)前最主流的做法。第二種方案是利用定時(shí)器做超時(shí)定幀。比如開一個(gè)微秒級(jí)定時(shí)器收到第一個(gè)字節(jié)后啟動(dòng)計(jì)時(shí)超過設(shè)定時(shí)間沒有新字節(jié)到來就認(rèn)為一幀接收完成。這種方案的優(yōu)點(diǎn)是定幀時(shí)間可控即使數(shù)據(jù)幀內(nèi)部有低頻字節(jié)流也不會(huì)誤判但實(shí)現(xiàn)復(fù)雜度高一些還要額外占用一個(gè)定時(shí)器資源。我個(gè)人的習(xí)慣是優(yōu)先使用空閑中斷定幀因?yàn)镾TM32N6的USART硬件已經(jīng)幫你做了幀間隔檢測(cè)不需要額外軟件代價(jià)。只有在數(shù)據(jù)幀內(nèi)部字節(jié)間隔本來就很大的特殊協(xié)議下才會(huì)考慮超時(shí)定幀。2. 工程配置與關(guān)鍵參數(shù)解析2.1 CubeMX中的USART與DMA配置在STM32CubeMX里配置STM32N6的USART DMA循環(huán)接收有幾個(gè)關(guān)鍵點(diǎn)需要注意。項(xiàng)目里我以USART1為例引腳選擇PA9TX和PA10RX這兩個(gè)引腳在多數(shù)開發(fā)板上直接連到USB轉(zhuǎn)串口芯片方便調(diào)試。先看USART參數(shù)的配置波特率按實(shí)際需求設(shè)置我常用的幾個(gè)檔位是115200、460800、921600數(shù)據(jù)字長(zhǎng)8位停止位1位校驗(yàn)None同步模式關(guān)閉硬件流控關(guān)閉重點(diǎn)是DMA Settings選項(xiàng)卡。點(diǎn)擊Add添加USART1_RX通道方向選擇Peripheral to MemoryMode一定要選擇Circular。這里就是最容易出錯(cuò)的地方——很多同學(xué)按照網(wǎng)上的教程配置成Normal模式結(jié)果第一包數(shù)據(jù)收完后再也收不到第二包其實(shí)就是因?yàn)镈MA傳輸完成后硬件自動(dòng)失能了。DMA數(shù)據(jù)寬度建議Peripheral和Memory都選Byte也就是8位。因?yàn)閁SART每次接收一個(gè)字節(jié)如果對(duì)外設(shè)側(cè)配置成Half Word或者Word雖然也能接收但緩沖區(qū)的每個(gè)元素會(huì)占用2字節(jié)或4字節(jié)空間處理起來反而麻煩。外設(shè)地址不需要手動(dòng)填CubeMX會(huì)自動(dòng)幫你關(guān)聯(lián)到USART1的DR寄存器。內(nèi)存地址需要填到循環(huán)緩沖區(qū)首地址也就是我在工程里定義的uart_rx_buf數(shù)組。2.2 循環(huán)緩沖區(qū)大小怎么定緩沖區(qū)大小的選擇直接決定了系統(tǒng)能承受的最大數(shù)據(jù)突發(fā)量。主要考慮三個(gè)因素波特率、協(xié)議最大幀長(zhǎng)、CPU響應(yīng)空閑中斷的延遲。我給出的經(jīng)驗(yàn)公式是緩沖區(qū)大小至少是最大幀長(zhǎng)的2倍然后向上取整到2的冪次。為什么要2倍因?yàn)槿绻彌_區(qū)大小只等于最大幀長(zhǎng)當(dāng)DMA寫指針回繞后緩沖區(qū)頭部還存著上一次未處理完的數(shù)據(jù)新數(shù)據(jù)和舊數(shù)據(jù)會(huì)發(fā)生覆蓋競(jìng)爭(zhēng)。2倍緩沖區(qū)可以保證在極端情況下即使CPU因?yàn)橹袛嗲短谆蚋邇?yōu)先級(jí)任務(wù)阻塞而延遲響應(yīng)舊的未讀取數(shù)據(jù)也不會(huì)被新數(shù)據(jù)覆蓋。以我的運(yùn)動(dòng)控制器為例協(xié)議最大幀長(zhǎng)64字節(jié)我配置了256字節(jié)的緩沖區(qū)。這已經(jīng)留出了足夠的余量同時(shí)不會(huì)過多浪費(fèi)RAM。STM32N6的RAM空間很充裕但如果用的是資源較小的型號(hào)128字節(jié)緩沖區(qū)搭配64字節(jié)最大幀長(zhǎng)也足夠。還有一點(diǎn)CubeMX中NVIC設(shè)置里記得打開DMA中斷和USART1全局中斷。DMA中斷在后面的接收完成回調(diào)中會(huì)用到USART1全局中斷是空閑中斷的基礎(chǔ)。2.3 空閑中斷的開啟方式空閑中斷的開啟位置CubeMX不會(huì)幫你做需要在代碼里手動(dòng)加上。推薦的開啟位置是在main函數(shù)中調(diào)用串口初始化之后HAL_UART_Receive_DMA(huart1, uart_rx_buf, UART_RX_BUF_SIZE); __HAL_UART_ENABLE_IT(huart1, UART_IT_IDLE);第一行啟動(dòng)DMA循環(huán)接收第二行使能USART的空閑中斷。順序不能顛倒否則可能會(huì)漏掉啟動(dòng)瞬間的字節(jié)。之后接收過程就完全由硬件接管CPU可以放心去干別的事。3. 代碼實(shí)現(xiàn)與核心機(jī)制3.1 完整代碼框架與初始化流程下面給出我整理的、可以直接抄到工程里用的完整代碼結(jié)構(gòu)。先定義緩沖區(qū)變量/* uart_dma_cyclic.h */ #ifndef __UART_DMA_CYCLIC_H #define __UART_DMA_CYCLIC_H #include main.h #define UART_RX_BUF_SIZE 256 extern volatile uint16_t uart_rx_read_index; extern uint8_t uart_rx_buf[UART_RX_BUF_SIZE]; void UART_StartDMAReceive(UART_HandleTypeDef *huart); void UART_ProcessFrame(uint8_t *data, uint16_t len); #endif對(duì)應(yīng)的源文件/* uart_dma_cyclic.c */ #include uart_dma_cyclic.h uint8_t uart_rx_buf[UART_RX_BUF_SIZE]; volatile uint16_t uart_rx_read_index 0; static volatile uint16_t uart_rx_write_index 0; static volatile uint8_t uart_rx_frame_pending 0; void UART_StartDMAReceive(UART_HandleTypeDef *huart) { HAL_UART_Receive_DMA(huart, uart_rx_buf, UART_RX_BUF_SIZE); __HAL_UART_ENABLE_IT(huart, UART_IT_IDLE); }初始化調(diào)用在main.c中int main(void) { /* ... CubeMX生成的初始化代碼 ... */ /* 啟動(dòng)USART1 DMA循環(huán)接收 */ UART_StartDMAReceive(huart1); while (1) { /* 主循環(huán)如果空閑中斷標(biāo)記了一幀數(shù)據(jù)就處理它 */ if (uart_rx_frame_pending) { uart_rx_frame_pending 0; /* 計(jì)算當(dāng)前DMA寫指針位置 */ uint16_t write_index UART_RX_BUF_SIZE - __HAL_DMA_GET_COUNTER(hdma_usart1_rx); /* 如果寫指針前進(jìn)到了讀指針之前說明數(shù)據(jù)回繞了 */ if (write_index uart_rx_read_index) { uint16_t len write_index - uart_rx_read_index; UART_ProcessFrame(uart_rx_buf[uart_rx_read_index], len); uart_rx_read_index write_index; } else { /* 數(shù)據(jù)發(fā)生了回繞需要分兩段處理 */ uint16_t len1 UART_RX_BUF_SIZE - uart_rx_read_index; uint16_t len2 write_index; UART_ProcessFrame(uart_rx_buf[uart_rx_read_index], len1); UART_ProcessFrame(uart_rx_buf[0], len2); uart_rx_read_index write_index; } } } }我在主循環(huán)里做幀處理而不是直接在中斷回調(diào)里做。這個(gè)設(shè)計(jì)決策的原因后面會(huì)展開講。3.2 空閑中斷回調(diào)處理STM32 HAL庫中空閑中斷會(huì)在串口中斷處理函數(shù)里被捕獲HAL_UART_IDLE_Callback是弱定義的回調(diào)函數(shù)由用戶重新實(shí)現(xiàn)。但有個(gè)細(xì)節(jié)HAL庫默認(rèn)的HAL_UART_IRQHandler并不會(huì)自動(dòng)清除IDLE標(biāo)志你需要手動(dòng)調(diào)用__HAL_UART_CLEAR_IDLEFLAG否則中斷會(huì)反復(fù)觸發(fā)導(dǎo)致系統(tǒng)卡死。這是一個(gè)非常經(jīng)典的坑。我在工程中的實(shí)現(xiàn)如下void HAL_UART_IdleCpltCallback(UART_HandleTypeDef *huart) { if (huart huart1) { /* 清除IDLE標(biāo)志防止再次進(jìn)入中斷 */ __HAL_UART_CLEAR_IDLEFLAG(huart1); /* 設(shè)置幀待處理標(biāo)志由主循環(huán)去消費(fèi) */ uart_rx_frame_pending 1; } }這個(gè)回調(diào)函數(shù)在中斷上下文執(zhí)行所以我只做兩件事清標(biāo)志、置軟件標(biāo)志。真正的數(shù)據(jù)處理放在主循環(huán)里做這樣避免了中斷里做耗時(shí)操作帶來的優(yōu)先級(jí)反轉(zhuǎn)和阻塞風(fēng)險(xiǎn)??赡苡腥藭?huì)問為什么不直接調(diào)用HAL_UART_Receive_DMA對(duì)于循環(huán)模式不需要重新啟動(dòng)DMA一直在后臺(tái)運(yùn)行所以這里只需要更新標(biāo)志即可。3.3 數(shù)據(jù)解析與環(huán)形緩沖區(qū)索引維護(hù)環(huán)形緩沖區(qū)的索引維護(hù)是整個(gè)方案的核心難點(diǎn)同時(shí)也是最容易出bug的地方。我在代碼里維護(hù)了兩個(gè)索引uart_rx_read_index軟件維護(hù)的讀索引表示一幀數(shù)據(jù)從哪里開始DMA寫指針通過__HAL_DMA_GET_COUNTER獲取表示DMA當(dāng)前寫到了哪里兩者之間的區(qū)域就是這一幀接收到的完整數(shù)據(jù)。處理邏輯前面已經(jīng)展示核心思想是如果寫指針大于等于讀指針說明沒有回繞直接取中間區(qū)域如果寫指針小于讀指針說明數(shù)據(jù)跨越了緩沖區(qū)末尾需要分兩段取出。關(guān)于讀索引的更新時(shí)機(jī)我特別想強(qiáng)調(diào)一點(diǎn)讀索引必須在數(shù)據(jù)被完全消費(fèi)之后再更新不能提前。如果UART_ProcessFrame只是把數(shù)據(jù)拷貝到業(yè)務(wù)緩沖區(qū)那么讀索引可以在拷貝完成后立即更新但如果處理函數(shù)是異步消費(fèi)比如把數(shù)據(jù)指針直接交給某個(gè)隊(duì)列那么讀索引必須等到數(shù)據(jù)真正用完才能更新。否則DMA新寫入的數(shù)據(jù)會(huì)覆蓋舊數(shù)據(jù)導(dǎo)致后續(xù)處理拿到錯(cuò)亂的數(shù)據(jù)。我的習(xí)慣是在UART_ProcessFrame中同步完成解析或拷貝解析后立即更新讀索引避免多線程或異步上下文帶來的競(jìng)爭(zhēng)問題。對(duì)于需要異步處理的場(chǎng)景建議直接拷貝一份到獨(dú)立緩沖區(qū)犧牲一點(diǎn)內(nèi)存換取邏輯簡(jiǎn)單性和可靠性。下面給一個(gè)UART_ProcessFrame的簡(jiǎn)單示例做幀頭判斷和回顯void UART_ProcessFrame(uint8_t *data, uint16_t len) { /* 協(xié)議示例幀頭0xAA 0x55后跟2字節(jié)長(zhǎng)度再加數(shù)據(jù)體和校驗(yàn) */ if (len 6) return; if ((data[0] 0xAA) (data[1] 0x55)) { uint16_t payload_len (data[2] 8) | data[3]; if (payload_len 6 len) { /* 校驗(yàn)數(shù)據(jù)體做業(yè)務(wù)處理 ... */ /* 這里可以打印或者轉(zhuǎn)發(fā)到其他外設(shè) */ } } }3.4 多串口擴(kuò)展與Freertos集成建議STM32N6的串口數(shù)量不少如果工程里需要同時(shí)管理多個(gè)串口的DMA循環(huán)接收一個(gè)有效的辦法是為每個(gè)串口準(zhǔn)備一套獨(dú)立的緩沖區(qū)和索引變量??梢栽诨卣{(diào)函數(shù)里通過huart-Instance判斷是哪個(gè)串口然后分別處理。我的一個(gè)板卡上有三路串口同時(shí)以不同波特率工作我把每路串口的緩沖區(qū)分開定義同時(shí)在IDLE回調(diào)中按串口序號(hào)存放到獨(dú)立的待處理標(biāo)志位中。如果工程使用了FreeRTOS可以進(jìn)一步優(yōu)化在空閑中斷里直接給對(duì)應(yīng)任務(wù)發(fā)一個(gè)二值信號(hào)量數(shù)據(jù)解析任務(wù)阻塞在信號(hào)量上一旦有數(shù)據(jù)幀完整接收任務(wù)被喚醒并進(jìn)行處理。這樣可以天然解決數(shù)據(jù)處理和接收之間的異步競(jìng)爭(zhēng)問題并且CPU利用率最優(yōu)。ST官方在不少應(yīng)用筆記里也推薦這種設(shè)計(jì)模式實(shí)際工程中測(cè)試下來非常穩(wěn)定。4. 常見問題與排查實(shí)錄4.1 只收到第一包數(shù)據(jù)之后就靜默了這個(gè)現(xiàn)象我在支持群里見得太多了。表現(xiàn)形式是開發(fā)板上電后第一次串口發(fā)送數(shù)據(jù)能收到之后再發(fā)任何數(shù)據(jù)都沒有反應(yīng)。排查思路非常簡(jiǎn)單看DMA模式配置。絕大多數(shù)情況是CubeMX里DMA Mode選擇了Normal。在Normal模式下DMA搬運(yùn)完設(shè)定長(zhǎng)度的數(shù)據(jù)后硬件會(huì)自動(dòng)關(guān)閉該DMA通道后續(xù)USART接收的數(shù)據(jù)不會(huì)再被搬運(yùn)到內(nèi)存。雖然軟件沒有主動(dòng)調(diào)用DMA停止但硬件行為已經(jīng)停止了。解決方式也很直接把DMA模式改為Circular。改完之后重新生成工程再測(cè)試就正常了。還有一個(gè)細(xì)節(jié)值得補(bǔ)充即使配置成了Circular模式也建議在初始化后調(diào)用一次HAL_UART_Receive_DMA啟動(dòng)接收。有些用戶認(rèn)為Circular模式啟動(dòng)后就不需要這一句了實(shí)際上不調(diào)用的話DMA根本不會(huì)開始搬運(yùn)數(shù)據(jù)要等第一次傳輸請(qǐng)求觸發(fā)時(shí)才會(huì)啟動(dòng)。穩(wěn)妥起見初始化流程中顯式調(diào)用一次最保險(xiǎn)。4.2 數(shù)據(jù)正常但偶爾會(huì)出現(xiàn)錯(cuò)位或粘包數(shù)據(jù)錯(cuò)位通常不是DMA的問題而是協(xié)議解析層面的問題。常見情況是數(shù)據(jù)幀沒有固定幀頭解析邏輯直接按長(zhǎng)度截取數(shù)據(jù)一旦丟了一個(gè)字節(jié)后續(xù)所有幀都會(huì)錯(cuò)位。粘包問題則是空閑中斷定幀不準(zhǔn)——當(dāng)上位機(jī)連續(xù)快速發(fā)送多幀數(shù)據(jù)且?guī)g隔小于一個(gè)字節(jié)時(shí)間時(shí)空閑中斷不會(huì)觸發(fā)多幀數(shù)據(jù)會(huì)被粘成一幀。解決錯(cuò)位問題首先要確保解析邏輯具備幀同步能力比如使用幀頭長(zhǎng)度校驗(yàn)的結(jié)構(gòu)。每次解析時(shí)先從緩沖區(qū)中找到幀頭再按長(zhǎng)度字段取數(shù)據(jù)。如果校驗(yàn)失敗放棄當(dāng)前幀并繼續(xù)搜索下一個(gè)幀頭這樣可以快速恢復(fù)同步。粘包問題則取決于協(xié)議設(shè)計(jì)。對(duì)于幀間隔極短的應(yīng)用建議在應(yīng)用層實(shí)現(xiàn)超時(shí)重發(fā)機(jī)制或長(zhǎng)度校驗(yàn)來輔助拆分如果協(xié)議允許也可以適度拉大幀間隔。還有一個(gè)做法是在協(xié)議幀末尾增加幀尾字節(jié)如0x0D 0x0A空閑中斷負(fù)責(zé)粗粒度分段幀尾用于細(xì)粒度校驗(yàn)。4.3 DMA中斷優(yōu)先級(jí)與NVIC配置不當(dāng)DMA循環(huán)接收對(duì)中斷優(yōu)先級(jí)的要求其實(shí)是“適中”——因?yàn)閿?shù)據(jù)搬運(yùn)不需要中斷參與但I(xiàn)DLE中斷需要足夠高的優(yōu)先級(jí)以便及時(shí)標(biāo)志幀接收完成。我的建議是把DMA中斷優(yōu)先級(jí)設(shè)置為最高優(yōu)先級(jí)的下一級(jí)把USART全局中斷設(shè)置為最高優(yōu)先級(jí)。這樣串口收發(fā)相關(guān)的中斷不會(huì)被其他任務(wù)阻塞太久同時(shí)不會(huì)影響系統(tǒng)時(shí)鐘等關(guān)鍵中斷。優(yōu)先級(jí)過低會(huì)導(dǎo)致什么后果如果系統(tǒng)里有高頻定時(shí)器中斷或更高優(yōu)先級(jí)的通信中斷USART的IDLE中斷可能長(zhǎng)時(shí)間得不到響應(yīng)。此時(shí)DMA緩沖區(qū)已經(jīng)在持續(xù)接收數(shù)據(jù)如果緩沖區(qū)不夠大數(shù)據(jù)就可能被覆蓋表現(xiàn)為偶發(fā)丟幀。如果你的工程中確實(shí)存在多個(gè)高優(yōu)先級(jí)中斷爭(zhēng)搶CPU可以考慮把USART全局中斷優(yōu)先級(jí)調(diào)高或者增大DMA緩沖區(qū)來爭(zhēng)取更多響應(yīng)時(shí)間。4.4 回繞邊界處理的隱藏bug環(huán)形緩沖區(qū)最容易寫錯(cuò)的地方就是回繞處理。我在第一個(gè)版本里也踩過坑寫指針回繞后直接計(jì)算write_index - read_index得到一個(gè)很大的數(shù)然后從緩沖區(qū)起始地址開始拷貝一堆無效數(shù)據(jù)導(dǎo)致解析出來的幀內(nèi)容完全錯(cuò)亂。經(jīng)過排查是回繞分支的數(shù)據(jù)長(zhǎng)度計(jì)算邏輯有誤。正確的做法是當(dāng)寫指針小于讀指針時(shí)要分成兩段處理第一段從讀指針到緩沖區(qū)末尾第二段從緩沖區(qū)頭到寫指針。兩段數(shù)據(jù)長(zhǎng)度相加才是完整的一幀。使用前面章節(jié)里寫的判斷邏輯基本可以覆蓋所有情況。還有一個(gè)隱蔽的邊界場(chǎng)景是讀指針恰好等于寫指針。此時(shí)有兩種可能一種是緩沖區(qū)為空一種是緩沖區(qū)恰好被填滿。在多數(shù)應(yīng)用場(chǎng)景這是小概率事件但如果對(duì)可靠性要求極高可以通過維護(hù)一個(gè)總接收字節(jié)計(jì)數(shù)器來做消歧。4.5 如何驗(yàn)證DMA接收是否正常工作調(diào)試階段我習(xí)慣在空閑中斷回調(diào)里加一個(gè)翻轉(zhuǎn)GPIO的操作用示波器觀察每次串口收到一幀引腳電平就翻轉(zhuǎn)一次。如果GPIO翻轉(zhuǎn)頻率與上位機(jī)發(fā)送幀頻一致說明DMA循環(huán)接收和空閑中斷都在正常工作。邏輯分析儀也可以用來查看IDLE中斷的觸發(fā)間隔是否符合預(yù)期。另外一個(gè)有用的調(diào)試技巧是定期打印DMA計(jì)數(shù)器的值。不要直接打印所有內(nèi)容而是打印讀指針和寫指針的位置觀察它們的差值是否始終小于緩沖區(qū)大小。如果發(fā)現(xiàn)差值長(zhǎng)時(shí)間接近緩沖區(qū)大小說明數(shù)據(jù)消費(fèi)速度跟不上接收速度需要優(yōu)化處理邏輯或增大緩沖區(qū)。5. 實(shí)測(cè)經(jīng)驗(yàn)與性能參考5.1 不同緩沖區(qū)大小下的表現(xiàn)對(duì)比我在STM32N6平臺(tái)上做過一組對(duì)比測(cè)試條件是921600波特率、連續(xù)下發(fā)不定長(zhǎng)數(shù)據(jù)幀8到64字節(jié)隨機(jī)長(zhǎng)度CPU主頻800MHz。測(cè)試結(jié)果如下表緩沖區(qū)大小平均CPU占用率接收處理部分最大可容忍處理延遲是否丟幀64字節(jié)約0.5%約0.55ms偶發(fā)丟幀128字節(jié)約0.5%約1.1ms不丟幀256字節(jié)約0.5%約2.1ms不丟幀512字節(jié)約0.5%約4.4ms不丟幀這個(gè)延遲指的是從最后一字節(jié)到達(dá)UART到IDLE中斷置位之間的窗口期也是CPU最壞情況下可以延遲處理而不丟幀的時(shí)間窗口??梢钥吹紺PU占用率幾乎不變但更大的緩沖區(qū)能顯著提升系統(tǒng)的魯棒性。如果你的系統(tǒng)需要接收短時(shí)間突發(fā)的大量數(shù)據(jù)建議緩沖區(qū)開到512字節(jié)甚至1KB在STM32N6上這點(diǎn)RAM占用微不足道。5.2 這套方案的性能邊界從底層機(jī)制看DMA循環(huán)接收的吞吐上限由三個(gè)因素決定DMA總線帶寬、USART外設(shè)FIFO深度和內(nèi)部總線的仲裁優(yōu)先級(jí)。在STM32N6上DMA控制器連接在AXI總線上帶寬完全不是瓶頸實(shí)際接收速度的上限基本由USART外設(shè)決定。按9Mbit/s的最高波特率計(jì)算每秒約1.1MB的數(shù)據(jù)量DMA循環(huán)接收可以輕松應(yīng)對(duì)。我在壓力測(cè)試中把波特率拉到3Mbit/s連續(xù)傳輸1GB數(shù)據(jù)緩沖區(qū)大小512字節(jié)沒有出現(xiàn)丟幀和錯(cuò)位。這套方案的可靠性和性能在常規(guī)MCU通信場(chǎng)景下完全夠用。5.3 踩坑后的心得總結(jié)調(diào)完這個(gè)方案后我自己總結(jié)了幾條經(jīng)驗(yàn)不一定在文檔里能直接找到但對(duì)實(shí)際工程很有幫助。第一DMA循環(huán)接收的精髓不是DMA本身而是空閑中斷和環(huán)形緩沖區(qū)的配合。把這兩個(gè)機(jī)制理解透了即使換用其他廠家芯片核心思路也完全一致——用硬件搬運(yùn)數(shù)據(jù)、用空閑中斷定幀、用環(huán)形緩沖區(qū)暫存、用軟件索引消費(fèi)。第二STM32N6的HAL庫在CubeMX生成代碼時(shí)默認(rèn)情況下不會(huì)幫你開啟IDLE中斷這是設(shè)計(jì)取舍不是bug。初始化時(shí)記得手動(dòng)打開IDLE中斷否則數(shù)據(jù)來了一律進(jìn)入DMA緩沖區(qū)但沒有任何機(jī)制告訴你“這幀收完了”。第三一旦代碼穩(wěn)定跑起來盡量不要在接收回調(diào)鏈路上加太多代碼。保持“中斷置標(biāo)志 → 主循環(huán)處理”的結(jié)構(gòu)既方便調(diào)試也為將來引入RTOS做信號(hào)量預(yù)留了干凈的擴(kuò)展點(diǎn)。