搞嵌入式的主從機通信遇到UART串口線上憑空多出來幾個字節(jié)真的是再常見不過的問題了。尤其是master和slave兩塊MCU之間通過UART互聯(lián)從機莫名其妙收到一堆0x00、0xFF或者亂碼輕則丟數(shù)據(jù)重則整個通信邏輯都亂了。這篇文章就專門聊聊這個“unwanted bytes”到底怎么來的以及我實際排查中總結(jié)出來的一套套路。不管你是剛?cè)腴T還是已經(jīng)調(diào)過幾年串口這篇內(nèi)容應(yīng)該都能給你一些參考。1. 問題現(xiàn)象與整體排查思路1.1 先明確“多余字節(jié)”長什么樣在動手查代碼之前第一步一定是把現(xiàn)象描述準(zhǔn)確。我自己接過不少類似的排查需求發(fā)現(xiàn)大家說“串口收到多余數(shù)據(jù)”的時候其實指的根本不是同一種情況。我一般會把現(xiàn)象拆成三類每一類的排查方向完全不同。第一類是多余的幀也就是從機明明只該收到一條指令結(jié)果收到了兩條或者收到一條完整的指令再加一個殘缺的尾巴。這種情況通常和軟件發(fā)送邏輯、幀同步、緩沖區(qū)處理有關(guān)。第二類是幀內(nèi)的多余字節(jié)比如主機發(fā)的幀是AA 55 01 02 03從機收到的卻是AA 55 01 02 03 00尾部多了一個0x00。這種情況一般指向波特率誤差、停止位采樣錯誤、電平不穩(wěn)定。第三類是隨機亂碼像是7F 3A C2 00 FF這種完全沒有規(guī)律的東西而且不是每次復(fù)現(xiàn)。這種情況優(yōu)先懷疑硬件干擾、共地問題、電源紋波、上電時序。所以接到問題之后我會先追問一句話多余出來的字節(jié)是固定的0x00或0xFF還是完全隨機的亂碼是每次通信都出現(xiàn)還是偶爾出現(xiàn)固定值的字節(jié)大概率是邏輯問題隨機亂碼大概率是物理鏈路問題。1.2 排查要先硬件后軟件很多人一上來就翻代碼盯著中斷處理函數(shù)看半天其實效率很低。我自己踩過太多次坑之后總結(jié)出來的原則是先確認(rèn)物理鏈路可靠再懷疑軟件邏輯。具體來說我的排查順序是這樣的用示波器直接看RX/TX兩個引腳的波形確認(rèn)空閑電平、起始位、停止位是否干凈。用USB轉(zhuǎn)TTL工具把從機單獨接出來用PC串口助手發(fā)同樣的數(shù)據(jù)看從機是否還會收到多余字節(jié)。如果PC直連從機沒問題再把主機接回去用示波器對比主機發(fā)出的波形和從機實際收到的波形。最后才回到代碼層面檢查波特率配置、中斷處理、緩沖區(qū)管理。這個順序看起來笨但能省掉大量無意義的代碼審查時間。尤其在第2步PC直連從機如果一切正常那說明從機的接收軟件邏輯基本沒問題問題大概率出在主機端或者主從機之間的物理鏈路上。2. UART通信參數(shù)與硬件連接的核心坑點2.1 波特率誤差比你想的更敏感UART通信的基礎(chǔ)是波特率而波特率的本質(zhì)是雙方對時間基準(zhǔn)的約定。很多MCU內(nèi)部用的是不那么精確的RC振蕩器比如常溫下標(biāo)稱8MHz實際上可能是7.9MHz到8.1MHz之間浮動再加上溫度變化誤差會更大。波特率誤差會直接導(dǎo)致什么后果呢以9600bps為例每一位的寬度約為104.16微秒。UART接收端會在每個bit的中間點采樣如果雙方的波特率存在偏差那么越靠后的bit采樣點偏離真實bit中心就越遠(yuǎn)。假設(shè)主機的波特率比從機快2%那么到第10個bit數(shù)據(jù)位第8位的時候采樣點已經(jīng)偏移了約2個bit的2%也就是大約20微秒雖然還不至于立刻采錯但如果幀更長或者誤差再大一點就會出現(xiàn)采樣到錯誤電平的情況進(jìn)而表現(xiàn)為多了字節(jié)、少了字節(jié)、或者整個幀錯位。我在實踐中一般會用這樣一個標(biāo)準(zhǔn)通信雙方的波特率誤差之和不要超過±2%如果要跑長幀或者高速率比如460800以上這個指標(biāo)要收緊到±1%以內(nèi)。檢查方法也很簡單看芯片手冊里UART外設(shè)的時鐘源是什么如果是內(nèi)部RC就用邏輯分析儀實測一下主機發(fā)出的波形計算實際波特率再和從機的配置對比。另外提一句有些從機為了省電會動態(tài)切換時鐘源比如運行在外部晶振、低功耗模式切到內(nèi)部RC喚醒之后沒切回來結(jié)果就是波特率整個漂掉。這種問題最隱蔽因為代碼邏輯完全沒問題就是硬件狀態(tài)變了。2.2 共地、電平匹配與上拉電阻UART本質(zhì)上是用電壓差來表示邏輯0和邏輯1的。既然是電壓差那就必須有參考地。如果主從機各自供電、沒有共地那么兩者的GND之間可能存在幾伏的電位差這時候TX引腳輸出的高電平在從機看來可能完全不是預(yù)期電平直接導(dǎo)致數(shù)據(jù)錯誤。還有一種常見情況是電平不匹配。比如主機是5V的TTL電平從機是3.3V的MCU如果從機引腳不是5V容忍5V tolerant的那主機的高電平5V可能直接損壞從機RX引腳或者讓從機讀取到不確定的電平狀態(tài)。更隱蔽的是反過來3.3V主機的TX高電平只有3.3V接5V的從機如果從機RX的輸入高電平閾值比較高就可能讀不到高電平導(dǎo)致整幀數(shù)據(jù)全是錯的這在某些老款5V器件上特別明顯。再有一個容易被忽略的點是TX引腳空閑狀態(tài)的電平。UART空閑時TX線應(yīng)該是高電平起始位是低電平。如果主機在上電初始化階段GPIO被默認(rèn)配置為下拉輸入或者浮空輸入那TX線可能會短暫拉低從機就會認(rèn)為這是一個起始位開始接收數(shù)據(jù)然后收到一個全是0x00或者0xFF的垃圾字節(jié)。解決辦法是確保主從機共地最好使用同一電源系統(tǒng)。電平不一致時加電平轉(zhuǎn)換芯片不要用電阻分壓湊合。TX和RX線上各加一個10kΩ上拉電阻到VCC保證空閑狀態(tài)是確定的高電平。主機的TX引腳在GPIO初始化之前先通過硬件下拉電阻保證上電默認(rèn)低電平再在軟件初始化完成后切換為UART功能并輸出高電平這樣從機就不會誤檢到起始位。2.3 硬件干擾與電源噪聲如果現(xiàn)場環(huán)境有電機、繼電器、逆變器這類設(shè)備UART線就是一根天然的天線很容易耦合到干擾信號。這種干擾在示波器上看起來可能只是幾十納秒的毛刺但在UART接收端看來如果毛刺電平低于起始位觸發(fā)電平就可能被當(dāng)成一個起始位從而啟動一次接收過程。處理硬件干擾我常用的幾招雙絞線傳輸把TX和GND絞在一起RX和GND絞在一起減少環(huán)路面積。串聯(lián)電阻在TX和RX線上各串聯(lián)一個100Ω到1kΩ的電阻配合引腳寄生電容組成低通濾波能有效濾掉高頻毛刺。屏蔽如果傳輸距離超過30cm或者環(huán)境特別惡劣直接上屏蔽線屏蔽層單端接地。電源去耦MCU的VCC引腳旁邊放0.1μF陶瓷電容如果MCU旁邊有繼電器或電機驅(qū)動還要考慮加磁珠或者LC濾波。光電隔離如果兩個MCU之間的地電位真的無法統(tǒng)一或者傳輸距離很遠(yuǎn)直接用光耦隔離每個方向一路。電源噪聲這個問題我要多說一句。很多MCU內(nèi)部有多個電源域比如模擬電源、數(shù)字電源、IO電源。如果IO電源紋波大UART接收引腳的輸入閾值就會抖動本來不該觸發(fā)的中斷可能就觸發(fā)了。所以看到“偶爾多一個字節(jié)”這種問題先不要懷疑代碼去量一下MCU電源引腳的紋波特別是通信瞬間的紋波。3. 軟件層面的核心細(xì)節(jié)與實現(xiàn)要點3.1 串口初始化時鐘、GPIO、外設(shè)配置的順序問題很多人在初始化串口的時候習(xí)慣先把GPIO配置成復(fù)用功能然后再初始化UART外設(shè)。這個順序在某些MCU上會有問題尤其是主機的TX引腳如果GPIO先切到復(fù)用功能而UART外設(shè)還沒使能TX引腳的電平是未定義的可能正好是個低電平從機就直接收到一個起始位了。我一般的初始化步驟是這樣的先使能GPIO時鐘和UART時鐘。配置TX引腳為復(fù)用推挽輸出RX引腳為復(fù)用浮空輸入。先拉高TX引腳電平再使能UART外設(shè)。配置波特率、數(shù)據(jù)位、停止位、校驗位。使能接收中斷或DMA最后才使能UART。這里的關(guān)鍵是第3步確保TX引腳在UART外設(shè)接管之前處于確定的高電平狀態(tài)。如果MCU的GPIO模塊在上電后會默認(rèn)輸出高電平那問題不大但有些MCU默認(rèn)輸出低電平這時候就要在GPIO初始化之后、UART外設(shè)使能之前先寫一個高電平到TX引腳。另外注意從機的RX引腳在初始化完成之前可能一直處于浮空狀態(tài)此時外界任何噪聲都可能被當(dāng)成數(shù)據(jù)。所以在從機端RX引腳要配置為帶上拉的輸入模式或者直接配置為復(fù)用功能并額外使能內(nèi)部上拉確保復(fù)位后到UART初始化完成之間RX引腳是穩(wěn)定的高電平。3.2 接收緩沖區(qū)管理放棄裸奔的寄存器直讀如果從機接收數(shù)據(jù)用的是“每收到一個字節(jié)就進(jìn)中斷直接把數(shù)據(jù)存到一個靜態(tài)變量里”這種方式那想處理unwanted bytes就非常痛苦。因為中斷里只要有一點點邏輯問題比如響應(yīng)不及時UART硬件接收寄存器就會被新數(shù)據(jù)覆蓋產(chǎn)生溢出錯誤而后面的數(shù)據(jù)就全亂了。我建議無論多簡單的項目都用一個環(huán)形緩沖區(qū)ring buffer來管理接收數(shù)據(jù)。中斷里只做一件事把收到的一個字節(jié)丟進(jìn)環(huán)形緩沖區(qū)。主循環(huán)或者狀態(tài)機里再按幀協(xié)議去解析緩沖區(qū)里的數(shù)據(jù)。這樣做的核心好處是中斷處理時間極短不容易丟字節(jié)主循環(huán)可以隨時檢查緩沖區(qū)里有沒有完整幀即使收到了unwanted bytes也只是在緩沖區(qū)里多占一個位置不會立刻打亂接收流程。環(huán)形緩沖區(qū)的實現(xiàn)很簡單#define RX_BUF_SIZE 256 static volatile uint8_t rx_buf[RX_BUF_SIZE]; static volatile uint16_t rx_head 0; static volatile uint16_t rx_tail 0; void UART_RX_IRQHandler(void) { /* 讀出數(shù)據(jù)寄存器自動清除接收中斷標(biāo)志 */ uint8_t data UART-DR; uint16_t next (rx_head 1) % RX_BUF_SIZE; if (next ! rx_tail) { rx_buf[rx_head] data; rx_head next; } else { /* 緩沖區(qū)滿置溢出標(biāo)志 */ uart_overflow_flag 1; } }這套邏輯里最關(guān)鍵的是head和tail的更新方式。生產(chǎn)者中斷只修改head消費者主循環(huán)只修改tail兩邊不需要加鎖也永遠(yuǎn)不會沖突。緩沖區(qū)滿的判斷是(head 1) % SIZE tail也就是說整個緩沖區(qū)最多只能存SIZE - 1個字節(jié)犧牲一個字節(jié)的位置來區(qū)分“空”和“滿”。3.3 幀協(xié)議與狀態(tài)機解析讓“多余字節(jié)”無處遁形有了環(huán)形緩沖區(qū)之后下一步就是怎么從緩沖區(qū)里解析出有效幀。如果主機和從機之間的通信沒有幀協(xié)議只是發(fā)了幾個字節(jié)、收了幾個字節(jié)那任何多余字節(jié)都會直接導(dǎo)致業(yè)務(wù)數(shù)據(jù)錯位根本沒法防護(hù)。我強烈建議哪怕只是兩個MCU之間互相傳一個開關(guān)量也一定要定義幀格式。我常用的幀格式是幀頭(2字節(jié)) 長度(1字節(jié)) 命令(1字節(jié)) 數(shù)據(jù)(N字節(jié)) CRC(2字節(jié)) 幀尾(1字節(jié))具體一點幀頭固定為0xAA 0x55用于同步。長度是指命令數(shù)據(jù)CRC的總字節(jié)數(shù)。CRC用CRC16-Modbus算法覆蓋從長度到數(shù)據(jù)的所有字節(jié)。幀尾固定為0x0D 0x0A做第二重校驗。解析的時候用狀態(tài)機而不是簡單地“收到幀頭就認(rèn)為后面是有效數(shù)據(jù)”typedef enum { FRAME_STATE_HEADER1, FRAME_STATE_HEADER2, FRAME_STATE_LENGTH, FRAME_STATE_DATA, FRAME_STATE_CRC1, FRAME_STATE_CRC2, FRAME_STATE_TAIL } frame_state_t; uint8_t frame_buf[256]; uint8_t frame_len 0; frame_state_t frame_state FRAME_STATE_HEADER1; void protocol_parse(uint8_t byte) { switch (frame_state) { case FRAME_STATE_HEADER1: if (byte 0xAA) frame_state FRAME_STATE_HEADER2; else frame_state FRAME_STATE_HEADER1; break; case FRAME_STATE_HEADER2: if (byte 0x55) frame_state FRAME_STATE_LENGTH; else frame_state (byte 0xAA) ? FRAME_STATE_HEADER2 : FRAME_STATE_HEADER1; break; case FRAME_STATE_LENGTH: frame_len byte; if (frame_len 200) frame_state FRAME_STATE_HEADER1; else frame_state FRAME_STATE_DATA; break; case FRAME_STATE_DATA: frame_buf[byte_index] byte; if (byte_index frame_len) frame_state FRAME_STATE_CRC1; break; /* CRC和幀尾檢查略 */ } }這個狀態(tài)機的好處是即使緩沖區(qū)里混入了多余字節(jié)比如上電瞬間的0x00只要不是0xAA狀態(tài)機就會被重置或者停留在幀頭探測狀態(tài)不會誤以為一個殘幀是有效數(shù)據(jù)。我自己寫過不少協(xié)議解析這個思路是最穩(wěn)的。3.4 使能UART空閑中斷或DMAIDLE方式如果MCU硬件支持我建議使用UART空閑中斷IDLE line interrupt或者DMA IDLE中斷來接收不定長數(shù)據(jù)。這種方式比逐字節(jié)中斷更高效而且天然能識別“一幀數(shù)據(jù)收完了”。具體做法是配置UART的RX DMA把收到的數(shù)據(jù)直接搬運到內(nèi)存緩沖區(qū)同時使能UART總線空閑中斷。當(dāng)總線上超過一個字節(jié)時間沒有新數(shù)據(jù)時觸發(fā)空閑中斷此時DMA搬運的字節(jié)數(shù)就是當(dāng)前幀的長度主循環(huán)再對這個緩沖區(qū)做協(xié)議解析。這種方式的優(yōu)勢在于DMA搬運過程中即使收到unwanted bytes也只是被機械地搬到緩沖區(qū)里不會阻塞CPU空閑中斷標(biāo)識一幀的結(jié)束不會把兩幀數(shù)據(jù)混在一起。只要協(xié)議解析端做好幀頭探測和CRC校驗?zāi)嵌嘤嘧止?jié)的影響就可以被完全隔離。4. 主從機通信中的特殊場景與處理方案4.1 上電時序?qū)е碌膯釉肼曃矣龅竭^一個特別典型的案例兩塊MCU共用一個電源master上電后立即初始化UART并向slave發(fā)送“同步請求”但slave的電源和時鐘還沒穩(wěn)定GPIO還處于默認(rèn)狀態(tài)串口外設(shè)也沒有初始化。此時master發(fā)過來的字節(jié)被slave的GPIO當(dāng)成普通IO讀到驅(qū)動了一些誤操作等slave的UART初始化完成后再去讀接收寄存器里面已經(jīng)積壓了幾個垃圾字節(jié)。這種問題的本質(zhì)是主從機之間的啟動時序沒有協(xié)調(diào)。解決辦法一般有兩種軟件握手上電master啟動后先等待1秒再發(fā)送任何數(shù)據(jù)讓slave有足夠時間完成初始化。如果系統(tǒng)對啟動時間有要求可以改為slave初始化完成后主動發(fā)一個“ready”字節(jié)master收到后再開始業(yè)務(wù)通信。硬件使能控制如果主從機只是板級通信可以在master的TX線上串聯(lián)一個MOS管開關(guān)master的某個GPIO控制這個開關(guān)master確認(rèn)slave ready后再打開開關(guān)。實際項目里我見過太多因為上電時序?qū)е碌膯栴}而且這類問題特別容易在“斷電重新上電”時復(fù)現(xiàn)冷啟動反而不一定出現(xiàn)因為電容放電時間不同。4.2 半雙工通信的TX/RX方向切換如果主從機之間用的是RS485之類的半雙工總線那unwanted bytes還有一個非常容易忽視的來源方向切換時總線電平還沒有穩(wěn)定。RS485收發(fā)器都有一個DE發(fā)送使能引腳切換到發(fā)送模式后總線電平需要一點時間才能建立穩(wěn)定。如果master在DE拉高之后立刻發(fā)送數(shù)據(jù)前幾個字節(jié)很可能是錯誤的。同理從機在發(fā)送完回復(fù)后DE拉低切換到接收模式的瞬間總線上可能有回波或者殘余電平也會被當(dāng)成數(shù)據(jù)收下來。我處理半雙工通信時一般會DE拉高后延時至少半個字節(jié)時間比如9600波特率下約50微秒再發(fā)數(shù)據(jù)。發(fā)送完成后先延時一個字節(jié)時間再拉低DE。在協(xié)議層從機收到一幀完整數(shù)據(jù)后先延時一小段再回復(fù)避免和master的發(fā)送尾巴撞車。如果需要極端可靠可以在幀尾之后再加一個靜默間隔讓總線電平穩(wěn)定后再切換方向。4.3 從機地址廣播與回環(huán)測試還有個場景是master通過UART廣播給多個slave每個slave用自己的地址來過濾數(shù)據(jù)。如果某個slave的接收引腳有虛焊、冷焊或者連接器接觸不良就會間歇性收到錯誤字節(jié)。這種問題軟件上很難完全規(guī)避只能靠協(xié)議層加CRC和地址校驗來防止誤動作。另外如果master的TX可以直接回環(huán)接到自己的RX做自測要注意這時候收到的數(shù)據(jù)其實是自己發(fā)出去的不能作為slave狀態(tài)的判斷依據(jù)。有些開發(fā)者在這里被繞進(jìn)去以為自己發(fā)了什么slave就收到了什么結(jié)果問題根本出在slave側(cè)的接收引腳上。5. 實操案例復(fù)盤一次“電動機一啟動就多字節(jié)”的排查過程5.1 現(xiàn)象描述與初步定位那是一個溫度采集系統(tǒng)master是STM32F103slave是STM32G0兩個MCU之間用UART通信9600波特率距離大約20cmPCB板內(nèi)走線。slave主要采集溫度傳感器數(shù)據(jù)master定時輪詢slave?，F(xiàn)場有個24V的直流電機跟控制板共用電源。現(xiàn)象是電機不啟動的時候通信一切正常電機一啟動slave就會收到大量亂碼字節(jié)嚴(yán)重時直接進(jìn)不了接收狀態(tài)機。我拿到這個問題后的第一步是接上示波器觀察電機啟動瞬間master TX引腳和slave RX引腳上的波形。結(jié)果發(fā)現(xiàn)電機啟動瞬間slave RX上出現(xiàn)了一串幅度超過3.3V的振鈴頻率非常高顯然不是master發(fā)出的正常數(shù)據(jù)。再查電源發(fā)現(xiàn)電機啟動瞬間24V電源電壓跌落而控制板上的3.3V LDO輸出也跟著出現(xiàn)了一個不小的跌落尖峰持續(xù)時間大約幾十毫秒。MCU的IO電源不穩(wěn)RX引腳的輸入閾值也跟著漂外部噪聲就能輕易被當(dāng)成UART信號采到。5.2 硬件改動定位到根因是電源和地平面噪聲后硬件做了三個改動在電機驅(qū)動部分與MCU控制部分之間把地平面分開單點連接減少電機電流回流對控制地平面的干擾。在24V到3.3V LDO之間增加磁珠和更大容量的儲能電容抑制電機啟動瞬間的電源跌落。slave的RX引腳串聯(lián)了1kΩ電阻并在RX到GND之間并聯(lián)一個100pF電容組成一個低通濾波器濾掉高頻噪聲毛刺。改完之后再用示波器看電機啟動瞬間RX引腳上的波形干凈了很多不再觸發(fā)UART接收。5.3 軟件加固硬件改完之后我又在軟件上做了幾層防御防止以后換了個更惡劣的環(huán)境又出問題幀協(xié)議增加CRC校驗CRC不對的幀一律丟棄。接收狀態(tài)機增加超時重置超過50ms沒有收到完整幀狀態(tài)機強制回到幀頭探測狀態(tài)。slave在收到一幀數(shù)據(jù)后如果CRC校驗失敗不會做任何動作也不會回復(fù)NACK避免干擾總線。這套組合拳下來電機啟停、正反轉(zhuǎn)頻繁操作slave再也沒有收到過無用的多余字節(jié)。6. 常見問題速查表與避坑經(jīng)驗6.1 問題排查速查表現(xiàn)象可能原因排查方法解決方案固定多出0x00/0xFF字節(jié)TX上電默認(rèn)低電平被識別為起始位示波器看上電瞬間TX波形確認(rèn)TX默認(rèn)高電平或加上拉隨機亂碼波特率誤差過大邏輯分析儀實測計算誤差改用外部晶振或調(diào)整分頻值偶爾多一個字節(jié)接收中斷響應(yīng)不及時導(dǎo)致溢出查看溢出錯誤標(biāo)志位改用DMAIDLE或縮短中斷處理時間電機/繼電器動作時出錯電源或地平面噪聲示波器看RX波形和電源紋波濾波、隔離、分割地平面長線傳輸收到亂碼信號反射/干擾波形上看振鈴串聯(lián)匹配電阻、雙絞線、屏蔽線從機喚醒后通信錯亂時鐘源切換導(dǎo)致波特率漂移檢查從機時鐘配置鎖定時鐘源或重新初始化波特率半雙工總線多發(fā)一幀方向切換電平未穩(wěn)定示波器看DE和總線電平加延時切換方向6.2 我踩過的幾個坑第一個坑是只檢查代碼不看波形。剛開始做嵌入式那兩年遇到串口多字節(jié)我第一反應(yīng)永遠(yuǎn)是中斷里是不是有Bug然后是協(xié)議解析是不是有漏洞折騰一整天發(fā)現(xiàn)是TX引腳上電默認(rèn)低電平這種硬件問題。后來我養(yǎng)成了一個習(xí)慣直接上邏輯分析儀先把物理層波形拍下來再決定要不要看代碼。第二個坑是對波特率誤差掉以輕心。有次兩個板子一個用外部12MHz晶振一個用內(nèi)部RC都配置成115200波特率。從機總是間歇性收到錯幀查了很久才發(fā)現(xiàn)從機內(nèi)部RC實際頻率偏了將近1.5%雖然數(shù)據(jù)位短的時候不是每次都錯但只要幀稍微長一點就必錯。從那次之后涉及UART通信的兩個MCU我會把兩邊的時鐘配置都拉出來對比確認(rèn)誤差在可接受范圍內(nèi)。第三個坑是在中斷里做太多事情。早期寫過“收到字節(jié)-判斷是否幀頭-是則繼續(xù)接收-存到全局?jǐn)?shù)組”這種代碼中斷處理函數(shù)越來越長結(jié)果波特率稍微快一點比如460800中斷還沒處理完下一個字節(jié)就到了直接溢出丟字節(jié)。后來全部改成中斷里只入環(huán)形緩沖區(qū)協(xié)議解析放主循環(huán)整個世界清凈了。6.3 經(jīng)驗心得排查UART的unwanted bytes問題本質(zhì)上是在和不確定性作斗爭。我的總結(jié)可以用一句話概括先把物理鏈路做成確定性的再談軟件邏輯。如果你把示波器探針往RX引腳上一放看到的是干凈利落的波形那軟件再怎么復(fù)雜也不至于收到垃圾數(shù)據(jù)如果波形本身臟得一塌糊涂那代碼寫得再完美也是白搭。另外設(shè)計階段就考慮清楚幀格式和通訊協(xié)議這件事真的能省掉后面特別多麻煩。哪怕只是兩個MCU在同一個板上通信我也建議至少有個幀頭和長度字段CRC甚至都可以不要但沒有幀頭和狀態(tài)機你連數(shù)據(jù)從哪里開始、到哪里結(jié)束都說不清那多余字節(jié)就是必然事件。反過來只要有狀態(tài)機幀頭過濾長度校驗就算物理環(huán)境有輕度干擾軟件也能幫你做掉一層防護(hù)。所以如果你現(xiàn)在正被這個問題折磨著我的建議是關(guān)掉代碼編輯器先拿起示波器或者邏輯分析儀看清楚線上到底跑的是什么再決定下一步往哪走。很多時候問題的答案不在代碼里就在那根你一直沒認(rèn)真看的線上。