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