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