模擬串口定時器掃描接收函數(shù)這個場景做過單片機(jī)開發(fā)的朋友應(yīng)該都不陌生一根串口線連著上位機(jī)你要在不依賴操作系統(tǒng)、不指望核心提供完整中斷體系的前提下把不定長的數(shù)據(jù)幀完整地收下來。很多人第一反應(yīng)就是寫一個RX中斷回調(diào)在回調(diào)里把字節(jié)塞進(jìn)緩沖區(qū)然后主循環(huán)里解析。這套思路本身沒毛病但在某些硬件資源緊張、串口數(shù)量多、或者工程里跑著RTOS且中斷優(yōu)先級分配非常棘手的情況下你會發(fā)現(xiàn)自己被迫回到“定時器掃描接收”這條老路。這篇文章就把我實際項目中驗證過的一套“定時器掃描式串口接收”方案完整拆開講。從定時器為什么會成為接收引擎、接收緩沖區(qū)怎么設(shè)計、掃描邏輯如何和幀協(xié)議配合到參數(shù)怎么估算、坑在哪里一條線理清楚。如果你手頭正好資源緊張或者想在模擬環(huán)境中先用定時器把串口接收邏輯跑通后面的代碼和思路可以拿過去直接改。1. 定時器掃描接收的適用邊界以及它為什么重要中斷接收當(dāng)然是理想方案。但談能不能用得先看手上有什么芯片、什么外設(shè)資源、以及整個系統(tǒng)的中斷拓?fù)?。我遇到過幾種不得不放棄RX中斷的情況串口數(shù)量多例如同時驅(qū)動三四路UART外設(shè)中斷向量和總線仲裁已經(jīng)復(fù)雜再給每路串口配獨(dú)立RX中斷出bug之后排查鏈路很長某些低端芯片的UART只支持查詢模式或者RXNE標(biāo)志在特定低功耗狀態(tài)下喚醒不及時單片機(jī)主頻不高但數(shù)據(jù)速率也不太高用定時器周期性查詢足夠覆蓋數(shù)據(jù)到達(dá)的節(jié)奏工程規(guī)模大希望接收邏輯和數(shù)據(jù)解析嚴(yán)格分時隔離中斷里僅做標(biāo)記統(tǒng)一由定時器周期“掃描”。定期器掃描的核心思路就是把“我有新數(shù)據(jù)了”這個事件從硬件中斷里剝離出來變成一個周期性的軟件輪詢動作。定時器負(fù)責(zé)提供穩(wěn)定的時間節(jié)拍每隔幾百微秒到幾毫秒去查看一次串口的接收緩沖區(qū)標(biāo)志然后把數(shù)據(jù)搬運(yùn)到自己的環(huán)形隊列里。這聽起來像是退化了但在許多工業(yè)控制、傳感器匯聚、協(xié)議網(wǎng)關(guān)場景中它反而是工程上最穩(wěn)的方案。因為接收速率低、幀長度短、時序?qū)崟r性要求又不算苛刻掃描節(jié)拍完全能追得上數(shù)據(jù)到達(dá)的速度。1.1 定時器掃描的兩個關(guān)鍵前提不是所有串口場景都適合硬上掃描式接收。動手之前先確認(rèn)這兩件事第一數(shù)據(jù)速率和幀長的乘積要顯著低于“掃描周期內(nèi)能搬運(yùn)的字節(jié)數(shù)”。比如波特率9600每個字節(jié)約1.04ms如果定時器掃描周期為1ms一次掃描平均能取到接近一個字節(jié)足夠但如果是115200波特率一個字節(jié)約86.8us掃描周期就必須壓到幾十微秒級別否則緩沖區(qū)會溢出。第二緩沖區(qū)容量要足夠容納一個完整的數(shù)據(jù)幀。這個邏輯很樸素既然掃描不是實時取走字節(jié)的那硬件FIFO加軟件隊列就必須能裝得下“從第一個字節(jié)到最后一個字節(jié)之間的所有數(shù)據(jù)”。如果緩沖區(qū)比最長幀還小掃描稍慢就會丟幀尾。1.2 模擬串口場景怎么理解“模擬串口”這個詞我理解有兩層意思。一層是純軟件層面的模擬在PC機(jī)上用虛擬串口對或者用軟件模擬單片機(jī)的UART外設(shè)寄存器讓接收邏輯跑在定時器掃描的模型下。這種場景常見于項目早期硬件還沒回來先用上位機(jī)模擬串口設(shè)備驗證協(xié)議解析邏輯自動化測試環(huán)境里用定時器周期性向被測模塊注入串口數(shù)據(jù)模擬真實傳感器上報。另一層是指硬件串口不夠用、或者執(zhí)行鏈路不想中斷化于是通過外部引腳用定時器進(jìn)行bit-banging式的接收掃描。不過bit-banging的時序和這里討論的“定時器掃描接收函數(shù)”略有區(qū)別本文側(cè)重前者硬件UART仍然在工作只是我們用定時器周期性檢查它的接收寄存器。搞清楚這個邊界之后下面的緩沖區(qū)設(shè)計、掃描入口、協(xié)議解析才能真正落地。2. 接收模型拆解硬件寄存器、軟件緩沖、掃描節(jié)拍定時器掃描式接收函數(shù)本質(zhì)上是一條“數(shù)據(jù)搬運(yùn)鏈”硬件UART收到字節(jié) → 放入硬件RDR寄存器 → 定時器觸發(fā)掃描 → 軟件讀取寄存器并寫入環(huán)形隊列 → 上層協(xié)議解析取走數(shù)據(jù)這中間每一環(huán)都要保證不阻塞、不覆蓋、不丟失。因此先把數(shù)據(jù)結(jié)構(gòu)定清楚是整個方案的地基。2.1 環(huán)形隊列掃描接收的標(biāo)配數(shù)據(jù)結(jié)構(gòu)串口接收天然就是一個生產(chǎn)者、消費(fèi)者模型。硬件是生產(chǎn)者協(xié)議解析是消費(fèi)者定時器掃描只是搬運(yùn)工。生產(chǎn)者的寫入節(jié)奏不完全可控取決于上位機(jī)什么時候發(fā)數(shù)據(jù)消費(fèi)者的讀取節(jié)奏也不固定取決于主循環(huán)什么時候調(diào)度解析任務(wù)。環(huán)形隊列正好解決兩邊節(jié)奏不一致的問題。環(huán)形隊列的基本實現(xiàn)并不復(fù)雜但在多場景下有兩個細(xì)節(jié)要特別注意隊頭隊尾指針的更新要用volatile修飾防止編譯器優(yōu)化掉關(guān)鍵讀寫隊列為空的判斷和隊列為滿的判斷要能區(qū)分常用方法是“留一個槽位不用”用(tail1)%max head表示滿。#define RX_RING_SIZE 64 typedef struct { volatile uint8_t buf[RX_RING_SIZE]; volatile uint16_t head; volatile uint16_t tail; } ring_queue_t;寫入端比較簡單把字節(jié)放進(jìn)隊尾static inline int ring_write(ring_queue_t *q, uint8_t byte) { uint16_t next (q-tail 1) % RX_RING_SIZE; if (next q-head) { return -1; /* 隊列滿 */ } q-buf[q-tail] byte; q-tail next; return 0; }2.2 掃描函數(shù)要做什么、不做什么經(jīng)驗不足的時候最容易犯的錯就是把掃描函數(shù)寫成“又搬運(yùn)又解析”也就是在定時器中斷里直接去判斷幀頭、丟幀尾、查校驗。這樣做表面上省了一次函數(shù)調(diào)用實際上把不定長的協(xié)議解析邏輯拖進(jìn)了中斷上下文。協(xié)議一旦復(fù)雜解析時間抖動會直接影響下一次掃描節(jié)拍最終反而丟數(shù)據(jù)。正確的分工方式是這樣的掃描函數(shù)只負(fù)責(zé)“把硬件接收寄存器里有數(shù)據(jù)搬到環(huán)形隊列”幀解析統(tǒng)一放在主循環(huán)或獨(dú)立任務(wù)里定時器掃描不關(guān)心協(xié)議內(nèi)容未知字節(jié)一視同仁地搬進(jìn)隊列。這樣處理的好處是數(shù)據(jù)搬運(yùn)的耗時變得固定。不管來的是1字節(jié)還是10字節(jié)掃描一次的執(zhí)行時間都是若干個內(nèi)存拷貝操作加指針更新時間耗盡全可控不會因為協(xié)議分支出現(xiàn)極端耗時。2.3 掃描入口的代碼骨架我把最常用的定時器掃描入口寫成這樣。這里以裸機(jī)環(huán)境為例定時器中斷里調(diào)用scan_uart_rx()static ring_queue_t uart1_rx_q; static UART_Type *active_uart /* 指向當(dāng)前要掃描的串口 */; void timer_irq_handler(void) { scan_uart_rx(active_uart, uart1_rx_q); } void scan_uart_rx(UART_Type *uart, ring_queue_t *q) { uint8_t byte; /* 盡量把當(dāng)前RDR里的數(shù)據(jù)一次取完而不是只取一個 */ while (uart-SR UART_SR_RXNE) { byte uart-RDR; if (ring_write(q, byte) ! 0) { /* 隊列滿記錄溢出標(biāo)志視項目需要丟棄或置錯誤位 */ q_overflow_flag 1; break; } } }這里必須說明一點(diǎn)掃描函數(shù)里用了while (uart-SR UART_SR_RXNE)循環(huán)讀取而不是只讀一次。原因很簡單雖然定時器周期固定但上位機(jī)可能在兩個掃描周期之間一個字節(jié)都不發(fā)也可能連續(xù)發(fā)完一整幀。如果掃描周期是1ms而數(shù)據(jù)幀是連續(xù)10個字節(jié)那么在某一次掃描中會同時發(fā)現(xiàn)RXNE置位如果不把它讀完下一次掃描就可能撞上緩沖區(qū)溢出。很多從中斷接收轉(zhuǎn)過來的開發(fā)者習(xí)慣一次中斷只讀一字節(jié)到了定時器掃描場景就會漏數(shù)據(jù)。務(wù)必記住在掃描模式下一次掃描要“能讀多少讀多少”。2.4 多串口擴(kuò)展當(dāng)一個工程里有多個串口時定時器掃描方案的優(yōu)勢就體現(xiàn)出來了。不需要每個串口都申請一個獨(dú)立中斷號只需要在一份定時器中斷里依次掃描各串口void timer_irq_handler(void) { scan_uart_rx(UART1, uart1_rx_q); scan_uart_rx(UART2, uart2_rx_q); scan_uart_rx(UART3, uart3_rx_q); }當(dāng)然前提是這幾個串口的接收寄存器都不是“邊讀邊清”的類型或者你顯式處理了狀態(tài)標(biāo)志。有些UART的RXNE標(biāo)志在讀取RDR后自動清除有些需要手動寫0。具體芯片具體分析但掃描邏輯的骨架不變。3. 定時器節(jié)拍的選型原則頻率、波特率、負(fù)荷之間的博弈定時器掃描接收最容易被低估的就是節(jié)拍選型。節(jié)拍太慢緩沖區(qū)溢出丟數(shù)據(jù)節(jié)拍太快CPU全部耗在查詢上主循環(huán)幾乎沒機(jī)會跑業(yè)務(wù)。3.1 節(jié)拍由什么決定首先要承認(rèn)一個現(xiàn)實定時器掃描接收的上限不會太高。它不是一個能支撐高波特率大流量的方案。一般實踐中9600波特率、38400波特率用掃描式完全沒問題115200波特率如果數(shù)據(jù)是稀疏的、短幀的也能用再往上比如1M波特率甚至更高掃描式就會非常吃力。一個可估算的公式是設(shè)掃描周期為T_s波特率對應(yīng)字節(jié)時間為T_b 10 / 波特率含起始位停止位每個掃描周期平均到達(dá)的字節(jié)數(shù)為 T_s / T_b。為確保不丟數(shù)據(jù)必須滿足 RX環(huán)形隊列長度 2 × T_s / T_b 最大突發(fā)幀長。之所以乘2是為了給“掃描瞬間剛好來一批數(shù)據(jù)”留出緩沖余量。舉個例子波特率9600T_b約1.04ms取掃描周期1ms則每個周期平均到達(dá)約0.96字節(jié)。如果最大一幀是20字節(jié)那么環(huán)形隊列至少要能裝下大約20 2 22字節(jié)保險起見定到32或64。再看115200T_b約86.8us。取掃描周期100us則每個周期平均到達(dá)1.15字節(jié)。如果幀長32字節(jié)隊列至少要35字節(jié)以上而且CPU每100us就要進(jìn)一次定時器中斷做一輪掃描負(fù)荷已經(jīng)不小了。3.2 實際選型時的優(yōu)先順序我的做法是“先定協(xié)議再定節(jié)拍最后定隊列長度”。具體步驟是確認(rèn)最大單幀字節(jié)數(shù)確認(rèn)波特率和字節(jié)時間選擇一個讓“每周期到達(dá)字節(jié)數(shù)”不超過1.5的掃描周期按上述公式計算隊列長度并向上取整到2的冪方便隊列模運(yùn)算優(yōu)化實測滿載發(fā)包100000字節(jié)統(tǒng)計溢出標(biāo)志是否被置位。如果你手上的芯片支持可調(diào)分頻的定時器盡量選能輸出“接近整數(shù)微秒”的周期方便用邏輯分析儀驗證。3.3 節(jié)拍選擇的實測現(xiàn)象我在某次測試中把掃描周期分別設(shè)為1ms、500us、200us觀察同一波特率下接收是否丟幀。觀察結(jié)果是掃描周期9600波特率效果115200波特率效果1ms穩(wěn)定無丟幀幀較長時偶爾溢出500us穩(wěn)定穩(wěn)定但CPU占用升高200us穩(wěn)定穩(wěn)定CPU占用明顯這說明問題的關(guān)鍵在于“掃描周期是否遠(yuǎn)小于字節(jié)間隔”而不是掃描本身有多快。9600波特率下1ms掃描能穩(wěn)定工作是因為1ms接近1.04ms的字節(jié)時間平均而言每次掃描只會有一次RXNE115200波特率下1ms就太慢了必須壓縮到200~500us才保險。4. 幀解析層如何基于掃描式接收實現(xiàn)穩(wěn)定的狀態(tài)機(jī)數(shù)據(jù)搬進(jìn)環(huán)形隊列只是第一步。真正讓“模擬串口定時器掃描接收函數(shù)”可用的是上層幀解析如何從隊列里準(zhǔn)確、魯棒地切出每一幀數(shù)據(jù)。4.1 不定長幀與定時器掃描的適配常見的串口幀協(xié)議往往是“幀頭長度字節(jié)數(shù)據(jù)區(qū)校驗”。比如0xAA 0x55 LEN DATA[LEN] CHECKSUM這類協(xié)議在中斷接收模式下習(xí)慣用逐字節(jié)狀態(tài)機(jī)處理每進(jìn)一次中斷就推進(jìn)一次狀態(tài)。到了掃描接收模式處理方式略有不同但狀態(tài)機(jī)依然是最穩(wěn)的選擇。區(qū)別在于中斷模式里每個字節(jié)都有可能觸發(fā)一次狀態(tài)判斷掃描模式里我們應(yīng)該一次性把隊列里的所有字節(jié)都丟進(jìn)狀態(tài)機(jī)直到隊列為空。這個“盡量把隊列取空”的處理思路和掃描函數(shù)盡量讀空硬件寄存器是同一邏輯都是為了在定時器到達(dá)的瞬間把積壓數(shù)據(jù)消費(fèi)掉給下一次掃描留出充足余量。void rx_frame_process(ring_queue_t *q) { uint8_t byte; while (ring_read(q, byte) 0) { rx_state_machine(byte); } }4.2 一個可復(fù)用的通用狀態(tài)機(jī)模板用狀態(tài)機(jī)解析串口幀的好處是它天然能應(yīng)對“幀跨多個掃描周期”的情況。掃描只負(fù)責(zé)搬運(yùn)數(shù)據(jù)解析狀態(tài)在兩次掃描之間會保持因此哪怕上位機(jī)把一個幀分成兩段發(fā)送也不影響解析結(jié)果。我常用的模板是三態(tài)一長度計數(shù)器enum { ST_IDLE, ST_HDR2, ST_LEN, ST_DATA, ST_CHK } rx_state; uint8_t expect_len; uint8_t data_count; uint8_t checksum; uint8_t frame_buf[64]; void rx_state_machine(uint8_t byte) { switch (rx_state) { case ST_IDLE: if (byte 0xAA) { rx_state ST_HDR2; } break; case ST_HDR2: if (byte 0x55) { rx_state ST_LEN; } else { rx_state ST_IDLE; /* 回到尋找?guī)^狀態(tài) */ } break; case ST_LEN: expect_len byte; data_count 0; checksum 0; rx_state ST_DATA; if (expect_len 0) { rx_state ST_CHK; } break; case ST_DATA: frame_buf[data_count] byte; checksum ^ byte; if (data_count expect_len) { rx_state ST_CHK; } break; case ST_CHK: if (byte checksum) { /* 幀校驗通過可以取走frame_buf */ handle_valid_frame(frame_buf, expect_len); } rx_state ST_IDLE; break; default: rx_state ST_IDLE; break; } }這段代碼里checksum用的是異或校驗實際項目按你的協(xié)議換成CRC或累加和即可。重點(diǎn)在于狀態(tài)機(jī)的推進(jìn)完全由“當(dāng)前字節(jié)”和“當(dāng)前狀態(tài)”決定而不管這個字節(jié)是哪一個掃描周期帶來的。4.3 為什么狀態(tài)機(jī)解法優(yōu)于“查幀頭內(nèi)存拷貝”有些開發(fā)者追求簡單直接在環(huán)形隊列里查找?guī)^找到就把整段數(shù)據(jù)拷貝出來解析。這個思路在低負(fù)載、單幀環(huán)境是可以跑的但一旦數(shù)據(jù)流中出現(xiàn)誤碼或干擾字節(jié)查找法會產(chǎn)生“偽幀頭”誤判而且偽幀頭之后的所有數(shù)據(jù)全被污染。狀態(tài)機(jī)的好處是任何時候只要校驗不過狀態(tài)立刻回到IDLE重新等待幀頭最多只丟失這一幀。對工業(yè)現(xiàn)場偶發(fā)干擾的處理能力明顯更強(qiáng)。4.4 掃描式接收下的超時判斷掃描接收還有一個中斷模式少有的問題怎么判斷一幀數(shù)據(jù)接收完成中斷模式下人們常用“空閑中斷”或者“接收到最后一個字節(jié)后啟動軟件超時計時”。掃描模式下反而簡單了既然我們自己是定時器驅(qū)動的那么天然可以在定時器掃描里順便數(shù)一下“距離上一次收到新數(shù)據(jù)已經(jīng)過了多少個掃描周期”。如果連續(xù)幾個掃描周期都沒有讀到新字節(jié)并且狀態(tài)機(jī)不是在IDLE態(tài)就認(rèn)為這一幀“傳輸超時”。void timer_irq_handler(void) { if (scan_uart_rx(active_uart, uart1_rx_q) 0) { rx_timeout_cnt 0; } else if (rx_timeout_cnt 0xFFFF) { rx_timeout_cnt; } if (rx_timeout_cnt 3) { on_rx_timeout(); rx_timeout_cnt 0; } }這里的“3個掃描周期”只是個經(jīng)驗值。具體要選幾個周期取決于協(xié)議允許的最大幀內(nèi)字節(jié)間隔。如果上位機(jī)發(fā)完幀頭后因為某種原因停頓了很長時間狀態(tài)機(jī)就能在超時后安全復(fù)位避免半個殘幀一直卡在狀態(tài)機(jī)里不出來。5. 仿真與測試讓函數(shù)在真實數(shù)據(jù)流里站穩(wěn)腳跟這部分是我最想強(qiáng)調(diào)的。定時器掃描接收這套邏輯停留在紙面上時感覺很簡單真正接入系統(tǒng)后你會發(fā)現(xiàn)bug往往不在掃描函數(shù)本身而在于周邊環(huán)境的干涉。5.1 用PC端虛擬串口模擬真實設(shè)備的注入測試如果手頭硬件還沒到位可以先在PC上模擬測試。創(chuàng)建一對虛擬串口比如COM3和COM4被測程序監(jiān)聽COM3測試腳本向COM4周期性寫入模擬幀數(shù)據(jù)觀察被測程序是否能完整解析出每一幀。測試腳本最核心的寫法是模擬真實設(shè)備的“不規(guī)則發(fā)包”。很多人在仿真測試時習(xí)慣固定間隔、固定長度地發(fā)數(shù)據(jù)測出來的結(jié)果過于理想。真實環(huán)境中上位機(jī)通常會受到操作系統(tǒng)調(diào)度、USB轉(zhuǎn)串口緩沖、應(yīng)用層負(fù)載的影響發(fā)送時間間隔并不均勻。因此至少要構(gòu)造以下三種模式來壓測測試模式具體做法考察點(diǎn)均勻間隔每100ms發(fā)一幀幀長固定基本功能正確性突發(fā)連續(xù)一次性發(fā)50幀間隔僅1~2ms環(huán)形隊列吞吐、是否溢出隨機(jī)抖動間隔在5ms~50ms間隨機(jī)變化掃描節(jié)拍與解析狀態(tài)機(jī)的魯棒性這三種模式跑完基本能還原出真實環(huán)境中最棘手的場景。突發(fā)連續(xù)模式最容易暴露“環(huán)形隊列太小”的問題隨機(jī)抖動模式最容易暴露“超時判斷太敏感”的問題。5.2 常見bug復(fù)盤以下四類bug是我在實際開發(fā)中真實遇到過的每條都能讓你排查好幾個小時第一類掃描函數(shù)里一次只讀一字節(jié)導(dǎo)致漏數(shù)據(jù)。表面現(xiàn)象是偶發(fā)性丟字節(jié)邏輯分析儀上能看到RXNE拉高但程序就是沒讀完。這需要把掃描函數(shù)里的while循環(huán)加回去。第二類環(huán)形隊列的讀寫指針跨優(yōu)化級別后跑飛。編譯器在高優(yōu)化等級下可能把head和tail的讀操作緩存到寄存器里導(dǎo)致寫端認(rèn)為隊列滿、讀端認(rèn)為隊列空。解決方法是給共享變量加volatile必要時使用內(nèi)存屏障。第三類定時器中斷和協(xié)議解析函數(shù)操作同一個隊列。掃描中斷寫隊尾主循環(huán)解析讀隊頭表面上一個寫一個讀沒有競態(tài)但如果讀操作改動了tail的緩存副本或者主循環(huán)在判斷隊列空時被中斷打斷就可能出現(xiàn)指針錯亂?？煽孔龇ㄊ潜ＷC環(huán)形隊列的單次讀取操作在關(guān)中斷保護(hù)下完成也就是uint8_t ring_read(ring_queue_t *q, uint8_t *byte) { uint8_t r 0; __disable_irq(); if (q-head ! q-tail) { *byte q-buf[q-head]; q-head (q-head 1) % RX_RING_SIZE; r 1; } __enable_irq(); return r; }第四類波特率誤差累積導(dǎo)致邊緣采樣錯位。掃描式接收雖然不直接參與位采樣但它的掃描節(jié)拍本身存在誤差如果定時器精度不夠或者分頻系數(shù)選擇不合理導(dǎo)致掃描的實際周期比預(yù)期長緩沖區(qū)就可能在最長幀場景下溢出。這種問題在9200波特率以上更容易被觀察到。5.3 調(diào)試時的觀測手段推薦一個非常有效的調(diào)試組合邏輯分析儀測UART RX線、定時器中斷GPIO翻轉(zhuǎn)、隊列溢出標(biāo)志輸出。操作方法如下在定時器中斷入口處翻轉(zhuǎn)一個空閑GPIO在環(huán)形隊列溢出時置位另一個GPIO。用邏輯分析儀同時采集這三個信號。當(dāng)出現(xiàn)丟幀時你能直接在波形上看到串口RX上明明有連續(xù)字節(jié)到達(dá)定時器掃描GPIO有規(guī)律地翻轉(zhuǎn)溢出GPIO在某一刻突然拉高。這一個動作就能把問題從“到底哪里丟了”快速定位到“是掃描不夠快還是隊列不夠深”非常管用。5.4 對Ring隊列長度的一次實際調(diào)參記錄某次項目里我用115200波特率接收一臺上位機(jī)的數(shù)據(jù)幀最長幀為80字節(jié)。起初我將環(huán)形隊列設(shè)為96字節(jié)500us掃描周期滿載測試時發(fā)現(xiàn)偶發(fā)溢出。那時候我直接用隊列長度向上漲改成128字節(jié)問題仍然存在。后來用邏輯分析儀看波形才發(fā)現(xiàn)上位機(jī)每秒會發(fā)一次突發(fā)包一次突發(fā)里連發(fā)三幀也就是240字節(jié)會在極短時間窗口內(nèi)涌進(jìn)來。500us掃描周期完全扛不住這么密集的數(shù)據(jù)把掃描周期降到100us之后128字節(jié)隊列就穩(wěn)定了。這個案例說明了一個很關(guān)鍵的原則發(fā)現(xiàn)丟數(shù)據(jù)時先看“數(shù)據(jù)到達(dá)的突發(fā)特性”再調(diào)隊列長度或掃描周期。盲目加大隊列只是在掩蓋掃描周期不夠短的根本問題。6. 定時器掃描接收背后的工程取舍思路文章最后我想聊一點(diǎn)比代碼更重要的東西。定時器掃描式串口接收在技術(shù)層面確實比中斷式接收“低端”一些但在工程層面它代表了一種非常典型的取舍方式用CPU時間片換取中斷復(fù)雜度。實際項目中我見過很多開發(fā)者在串口接收這件事上過度設(shè)計。明明協(xié)議幀很短、數(shù)據(jù)量很小非要配一堆DMA、空閑中斷、雙緩沖區(qū)結(jié)果調(diào)試成本比功能本身還高。而定時器掃描方案在合適的場景里往往半小時就能調(diào)通并穩(wěn)定運(yùn)行。不過也要清醒地認(rèn)識到掃描方案不是免費(fèi)的。它的代價是CPU負(fù)荷增加、實時性響應(yīng)延遲變大、數(shù)據(jù)吞吐上限受限。如果未來某一天項目需要把波特率提高到460800以上或者需要同時處理大量串口數(shù)據(jù)流那你還是得回到中斷加DMA的路線上來。從工程演進(jìn)的角度看定時器掃描接收更像是一把“瑞士軍刀”它不華麗但絕大多數(shù)低中速業(yè)務(wù)場景都夠用而且足夠簡單可靠。我個人的習(xí)慣是優(yōu)先使用這套方案把業(yè)務(wù)跑通如果后期壓力測試顯示瓶頸確實在串口接收上再針對性升級成中斷或DMA方式。這樣既能快速交付又不至于在一開始就陷入底層外設(shè)配置的泥潭里。這套思路同樣適用于那些在PC上做模擬串口和通信協(xié)議仿真的項目——先讓接收邏輯穩(wěn)定、健壯、可觀察再考慮高性能傳輸?shù)氖?。希望這篇拆解能幫你在自己的項目里少踩幾個坑。