1. 串口亂碼這件事為什么總讓人抓狂搞嵌入式的朋友大概都有過這種體驗代碼邏輯翻來覆去檢查了十幾遍串口助手那邊就是一堆看不懂的字符有時候是規(guī)律的“燙燙燙”有時候是零星的亂碼夾雜著幾個正常字節(jié)還有時候干脆一個字節(jié)都收不到。你換了一根USB轉(zhuǎn)串口線換了一個串口助手甚至換了一塊板子問題依舊。更讓人崩潰的是同樣的代碼昨天還好好的今天上電就亂碼了。串口通信看起來簡單——兩根線一個波特率發(fā)出去收回來就完事了。但恰恰是這種“看起來簡單”的東西一旦出問題排查起來往往比復雜的網(wǎng)絡(luò)協(xié)議還費勁。因為串口通信的可靠性依賴于太多底層細節(jié)時鐘樹的配置、GPIO工作模式的選擇、中斷優(yōu)先級的安排、DMA通道的分配、地線的質(zhì)量、甚至周圍有沒有大功率設(shè)備在干擾。這篇文章不打算給你講串口通信的基礎(chǔ)教程那種內(nèi)容網(wǎng)上太多了。我想做的是把“串口亂碼”這個現(xiàn)象當成一個系統(tǒng)性問題來拆解從五個最常見的根因入手逐一分析背后的原理、排查方法和解決思路。這五個原因分別是時鐘偏差、GPIO模式配置錯誤、中斷處理不當、DMA與緩沖區(qū)問題、地線環(huán)路與硬件干擾。每一個我都會結(jié)合實際案例和可操作的排查步驟來講盡量讓你看完之后能直接上手定位問題。不管你是剛接觸STM32、GD32、ESP32、CH32V這類MCU的新手還是已經(jīng)在做FPGA串口、Linux串口、PLC串口通信的老手這篇文章里的排查思路都是通用的。串口亂碼的本質(zhì)無非是“發(fā)送方和接收方對信號的理解不一致”而我們要做的就是找到這個“不一致”到底出在哪里。2. 五個核心原因的整體排查思路2.1 為什么先看時鐘偏差串口通信是異步通信沒有單獨的時鐘線。發(fā)送方和接收方各自用自己的時鐘來約定波特率雙方靠起始位來同步。這就意味著如果發(fā)送方的實際波特率和接收方預期的波特率偏差超過一定范圍采樣就會出錯數(shù)據(jù)就會亂。這個容忍范圍是多少呢對于標準的UART協(xié)議接收方通常在每個位的中間位置采樣。如果波特率偏差導致采樣點偏移超過半個位周期就會采到錯誤的位。理論上總偏差發(fā)送方偏差接收方偏差不能超過±5%實際工程中建議控制在±2%以內(nèi)才比較穩(wěn)妥。時鐘偏差的來源主要有幾個一是系統(tǒng)時鐘配置錯誤比如外部晶振頻率和代碼里寫的不一致二是PLL倍頻參數(shù)算錯了三是波特率分頻系數(shù)計算時用了整數(shù)除法導致截斷誤差四是時鐘源本身精度不夠比如用內(nèi)部RC振蕩器做時鐘源。2.2 GPIO模式為什么會影響串口很多人覺得GPIO配置就是選個復用功能就完事了但實際上GPIO的工作模式對串口通信質(zhì)量影響很大。推挽輸出和開漏輸出的驅(qū)動能力不同上拉和下拉會影響空閑電平復用功能的映射關(guān)系如果搞錯了TX和RX可能根本就沒接到USART外設(shè)上。特別是在STM32、GD32這類MCU上GPIO的8種工作模式輸入浮空、輸入上拉、輸入下拉、模擬輸入、開漏輸出、推挽輸出、推挽復用、開漏復用如果選錯了輕則通信不穩(wěn)定重則完全不通。而且不同系列的MCU復用功能的配置方式還不一樣有的用AFR寄存器有的用AFIO有的用設(shè)備樹。2.3 中斷處理不當會帶來什么后果串口通信中中斷是用來處理接收和發(fā)送事件的。如果中斷優(yōu)先級設(shè)置不當或者中斷服務(wù)函數(shù)里做了太多耗時操作就會導致數(shù)據(jù)丟失或接收緩沖區(qū)溢出。更隱蔽的問題是中斷嵌套和中斷上下文的問題——在高優(yōu)先級中斷里調(diào)用了低優(yōu)先級的串口發(fā)送函數(shù)或者在中斷里用了阻塞式的延時都會導致串口行為異常。還有一種情況是中斷進不去或者進去了但標志位沒清除干凈導致反復進中斷或者再也進不去。這類問題在CH32V、GD32等國產(chǎn)MCU上尤其常見因為中斷向量表的配置和GCC編譯器的屬性聲明方式跟Keil不太一樣。2.4 DMA和緩沖區(qū)的關(guān)系用DMA做串口收發(fā)是很常見的優(yōu)化手段但DMA配置不當也會導致亂碼。比如DMA的傳輸寬度設(shè)置錯了字節(jié)vs半字vs字或者DMA的源地址和目標地址搞反了或者DMA傳輸完成中斷和串口空閑中斷的配合有問題。緩沖區(qū)的問題更隱蔽發(fā)送緩沖區(qū)被覆蓋、接收緩沖區(qū)溢出、緩沖區(qū)大小和DMA傳輸長度不匹配這些都會導致數(shù)據(jù)錯亂。而且這類問題往往不是每次都出現(xiàn)可能跑幾個小時才復現(xiàn)一次排查起來非常頭疼。2.5 地線環(huán)路為什么是隱形殺手前面四個原因都是軟件和配置層面的地線環(huán)路是純硬件問題。當兩個設(shè)備通過串口連接時如果它們各自接了不同的電源地或者地線走線形成了環(huán)路就會在地線上產(chǎn)生電流進而導致信號電平的參考點發(fā)生偏移。這種偏移可能表現(xiàn)為偶發(fā)的亂碼也可能表現(xiàn)為通信距離縮短甚至可能損壞收發(fā)器芯片。地線環(huán)路的問題在實驗室里往往不容易復現(xiàn)因為實驗室的設(shè)備通常共地良好。但到了現(xiàn)場特別是工業(yè)環(huán)境或者長距離通信場景地線環(huán)路就成了高頻問題。3. 時鐘偏差最容易被忽略的根因3.1 波特率是怎么算出來的要理解時鐘偏差首先得搞清楚波特率是怎么從系統(tǒng)時鐘算出來的。以STM32為例USART的波特率計算公式是BaudRate fCK / (16 * USARTDIV)其中fCK是USART外設(shè)的時鐘頻率USARTDIV是一個分頻系數(shù)由整數(shù)部分和小數(shù)部分組成。比如系統(tǒng)時鐘72MHz要得到115200的波特率USARTDIV 72000000 / (16 * 115200) 39.0625整數(shù)部分是39小數(shù)部分是0.0625。小數(shù)部分再乘以16得到1所以BRR寄存器的值就是0x271。你可以自己算一下72000000 / (16 * 39.0625) 115200剛好。但問題在于很多MCU的波特率寄存器小數(shù)部分只有4位也就是精度只有1/16。如果你算出來的小數(shù)部分不能精確表示就會有截斷誤差。比如某個時鐘頻率下算出來的USARTDIV是39.07小數(shù)部分0.07乘以16等于1.12只能取1實際分頻就是39.0625誤差很小。但如果算出來是39.5小數(shù)部分0.5乘以16等于8剛好能表示沒問題。最怕的是算出來小數(shù)部分接近0.5但又不是0.5的情況誤差就會比較大。3.2 實際案例GD32F470的時鐘配置陷阱我之前用GD32F470VET6做項目的時候遇到過一個典型的時鐘偏差問題。代碼是從GD32F407的工程移植過來的系統(tǒng)時鐘配置看起來一樣都是200MHz。但串口就是亂碼用示波器量了一下TX引腳發(fā)現(xiàn)實際波特率大概是108000左右跟設(shè)定的115200差了6%以上。排查過程是這樣的先確認了外部晶振是25MHz然后檢查PLL配置。GD32F470的PLL配置和F407有些差異特別是PLL分頻系數(shù)和倍頻系數(shù)的組合。F407的工程里用的是25MHz晶振PLLM25PLLN400PLLP2得到200MHz。但F470的PLL架構(gòu)略有不同同樣的參數(shù)配置出來的時鐘不是200MHz而是192MHz左右。用192MHz去算115200的波特率USARTDIV 192000000 / (16 * 115200) 104.1667整數(shù)部分104小數(shù)部分0.1667乘以16等于2.67取2實際分頻104.125實際波特率 192000000 / (16 * 104.125) 115240左右誤差0.03%看起來沒問題啊。但問題在于GD32F470的USART時鐘源不一定直接來自系統(tǒng)時鐘。如果USART掛在APB1上而APB1的分頻系數(shù)設(shè)置不對實際時鐘可能又不一樣。我最后查出來是APB1的分頻系數(shù)設(shè)成了4而不是2導致USART時鐘只有48MHz算出來的波特率偏差就大了。排查時鐘偏差的第一步用示波器或者邏輯分析儀量一下TX引腳的實際波特率。如果沒有儀器可以發(fā)送已知的固定字節(jié)比如0x55用示波器看方波的周期周期倒數(shù)就是實際波特率。3.3 內(nèi)部RC振蕩器的坑有些低成本方案會用MCU內(nèi)部的RC振蕩器作為時鐘源省掉外部晶振。內(nèi)部RC的精度通常在±1%到±5%之間而且隨溫度變化很大。如果你用內(nèi)部RC做時鐘源波特率偏差可能一開始就在臨界點上溫度一變就亂碼了。我見過一個案例某產(chǎn)品用STM32F030的內(nèi)部HSI8MHz做時鐘源波特率設(shè)的9600。常溫下通信正常到了冬天戶外溫度零下十幾度就開始間歇性亂碼。后來換成外部晶振問題就消失了。所以如果你的項目對串口通信可靠性有要求建議還是用外部晶振。如果實在要用內(nèi)部RC至少要做溫度補償或者把波特率降下來波特率越低對時鐘偏差的容忍度越高。3.4 波特率偏差的容忍度計算前面提到總偏差不能超過±5%但這個數(shù)字是怎么來的我們來推導一下。UART接收方在每個位的中間采樣。假設(shè)發(fā)送方的波特率是T接收方的波特率是R偏差為誤差 (T - R) / R接收方從起始位的下降沿開始計數(shù)到第n個位的采樣點累計的時間誤差是累計誤差 n * 位周期 * 誤差對于8位數(shù)據(jù)1位停止位最壞情況下第9個位停止位的采樣點偏移最大。如果累計誤差超過半個位周期就會采錯9 * 位周期 * 誤差 0.5 * 位周期 誤差 0.5 / 9 5.56%所以理論上±5%是極限但實際工程中要考慮噪聲、信號邊沿抖動等因素建議控制在±2%以內(nèi)。對于115200這種高波特率位周期只有8.68微秒對時鐘精度的要求就更高了。4. GPIO模式配置不只是選個復用功能4.1 GPIO的8種工作模式到底怎么選STM32和GD32系列MCU的GPIO有8種工作模式很多人配置串口的時候直接抄例程選個“推挽復用”就完事了。但實際上TX和RX的模式選擇是有講究的。TX引腳應(yīng)該配置為推挽復用輸出GPIO_Mode_AF_PP。推挽輸出的驅(qū)動能力強能提供足夠的電流驅(qū)動串口線。開漏輸出需要外部上拉電阻如果上拉電阻太大上升沿會變緩高速通信時可能導致位采樣錯誤。RX引腳應(yīng)該配置為浮空輸入GPIO_Mode_IN_FLOATING或者上拉輸入GPIO_Mode_IPU。浮空輸入適合外部已經(jīng)有上拉電阻的情況上拉輸入適合外部沒有上拉的情況。如果配成下拉輸入空閑電平會被拉低接收方會一直認為收到了起始位導致亂碼。我見過一個案例有人把RX配成了下拉輸入結(jié)果串口助手一直收到0x00。因為空閑狀態(tài)下RX被拉低接收方認為是起始位然后采樣8個位都是0最后停止位也是0就收到了0x00。這種情況用示波器看TX引腳是正常的但RX引腳一直被拉低。4.2 復用功能映射的坑不同系列的MCU串口引腳的復用功能映射方式不一樣。STM32F1系列用AFIO寄存器來重映射F4系列用AFR寄存器來選擇復用功能編號GD32F470跟F4類似但也有差異。以STM32F407為例USART1的TX可以映射到PA9或者PB6RX可以映射到PA10或者PB7。如果你在代碼里配置了PA9為復用功能但沒有設(shè)置AFR寄存器選擇AF7USART1那PA9可能就接到了別的外設(shè)上串口自然不通。GD32F470VET6的復用功能配置跟STM32F4類似但AF編號可能不同。比如USART0的TX在PA9上AF編號是AF7但有些GD32型號可能是AF8。這個一定要查數(shù)據(jù)手冊的復用功能映射表不能憑經(jīng)驗猜。4.3 GPIO速度設(shè)置的影響GPIO的輸出速度GPIO_Speed也是一個容易被忽略的參數(shù)。STM32的GPIO速度有2MHz、25MHz、50MHz、100MHz幾檔。速度越高功耗越大但邊沿越陡峭。對于115200的波特率位周期8.68微秒邊沿時間只要遠小于位周期就行。2MHz的速度對應(yīng)邊沿時間大約幾百納秒完全夠用。但如果你把速度設(shè)得太低比如2MHz而波特率又很高比如1Mbps邊沿時間可能占到位的十分之一以上導致采樣點偏移。反過來速度設(shè)得太高雖然邊沿陡峭但EMI輻射也會增大可能干擾其他信號。我的經(jīng)驗是115200及以下的波特率GPIO速度設(shè)25MHz就夠了更高的波特率設(shè)50MHz或100MHz。沒必要一上來就設(shè)最高速度除非你的通信速率確實很高。4.4 設(shè)備樹中的GPIO配置在Linux系統(tǒng)上做串口通信GPIO的配置是通過設(shè)備樹Device Tree來描述的。比如全志V3S或者Jetson TK1這類平臺串口的引腳配置在設(shè)備樹的pinctrl節(jié)點里。一個典型的設(shè)備樹串口配置是這樣的uart0 { pinctrl-names default; pinctrl-0 uart0_pins_a; status okay; }; uart0_pins_a: uart00 { pins PB4, PB5; function uart0; };如果設(shè)備樹里的引腳配置和實際硬件不一致串口就不會工作。而且Linux下的串口設(shè)備節(jié)點/dev/ttyS0等需要正確的權(quán)限才能訪問否則會報“Permission denied”。在Ubuntu下查看串口設(shè)備可以用ls -l /dev/ttyS* ls -l /dev/ttyUSB* dmesg | grep tty如果串口被其他程序占用了可以用lsof查看lsof /dev/ttyUSB0Win7下查看串口被哪個程序占用可以用“資源監(jiān)視器”或者第三方工具如Process Explorer來查。5. 中斷處理優(yōu)先級、上下文與標志位5.1 中斷優(yōu)先級配置的常見錯誤串口中斷的優(yōu)先級配置直接影響通信的實時性和可靠性。如果串口接收中斷的優(yōu)先級太低可能被其他高優(yōu)先級中斷打斷導致接收數(shù)據(jù)丟失。如果優(yōu)先級太高又可能影響其他關(guān)鍵任務(wù)的執(zhí)行。在STM32和GD32上中斷優(yōu)先級分為搶占優(yōu)先級和響應(yīng)優(yōu)先級。搶占優(yōu)先級決定能否嵌套響應(yīng)優(yōu)先級決定同搶占優(yōu)先級下的排隊順序。串口接收中斷一般建議設(shè)置為中等偏高的搶占優(yōu)先級確保能及時響應(yīng)但不要高到影響系統(tǒng)滴答定時器SysTick等關(guān)鍵中斷。我遇到過一個案例有人把串口接收中斷的搶占優(yōu)先級設(shè)成了最低同時系統(tǒng)里有一個高優(yōu)先級的定時器中斷每100微秒觸發(fā)一次每次執(zhí)行50微秒。結(jié)果串口接收中斷經(jīng)常被延遲導致接收緩沖區(qū)溢出數(shù)據(jù)丟失。5.2 中斷服務(wù)函數(shù)里的禁忌操作中斷服務(wù)函數(shù)ISR應(yīng)該盡可能短小精悍。以下操作在ISR里是禁忌阻塞式延時在ISR里調(diào)用delay_ms()之類的函數(shù)會導致其他中斷無法響應(yīng)。浮點運算如果MCU沒有FPU浮點運算會消耗大量時間即使有FPU也要注意上下文保存的問題。動態(tài)內(nèi)存分配malloc()和free()不是可重入的在ISR里調(diào)用可能導致堆損壞。打印調(diào)試信息在ISR里調(diào)用printf()通過串口輸出會導致遞歸調(diào)用或者死鎖。正確的做法是在ISR里只做最少的事情——讀取數(shù)據(jù)、清除標志位、把數(shù)據(jù)放入緩沖區(qū)然后設(shè)置一個標志位或者發(fā)送信號量讓主循環(huán)去處理后續(xù)邏輯。5.3 CH32V在GCC下的中斷函數(shù)定義CH32V系列是RISC-V內(nèi)核的MCU在GCC編譯器下定義中斷函數(shù)的方式和ARM核不太一樣。ARM核用__attribute__((interrupt))或者特定的中斷向量表而CH32V需要用__attribute__((interrupt(WCH-Interrupt-fast)))來聲明。一個典型的CH32V串口中斷函數(shù)定義void USART1_IRQHandler(void) __attribute__((interrupt(WCH-Interrupt-fast))); void USART1_IRQHandler(void) { if(USART_GetITStatus(USART1, USART_IT_RXNE) ! RESET) { uint8_t data USART_ReceiveData(USART1); // 處理數(shù)據(jù) USART_ClearITPendingBit(USART1, USART_IT_RXNE); } }如果忘了加__attribute__((interrupt))編譯器不會生成正確的中斷返回指令導致中斷進去之后出不來或者返回地址錯誤程序跑飛。5.4 中斷標志位清除的時機中斷標志位的清除時機很關(guān)鍵。以STM32的USART為例接收中斷標志位RXNE在讀取數(shù)據(jù)寄存器DR時自動清除但有些標志位需要手動清除比如溢出錯誤標志ORE、幀錯誤標志FE、噪聲標志NE等。如果ORE標志沒有及時清除會導致后續(xù)接收中斷無法觸發(fā)。我見過一個案例串口因為噪聲導致了一次ORE但代碼里沒有處理ORE結(jié)果串口再也收不到數(shù)據(jù)了。排查了半天才發(fā)現(xiàn)是ORE標志沒清。正確的做法是在中斷服務(wù)函數(shù)里檢查所有可能的錯誤標志并逐一清除void USART1_IRQHandler(void) { if(USART_GetITStatus(USART1, USART_IT_RXNE) ! RESET) { uint8_t data USART_ReceiveData(USART1); // 處理數(shù)據(jù) } if(USART_GetITStatus(USART1, USART_IT_ORE) ! RESET) { USART_ClearITPendingBit(USART1, USART_IT_ORE); } if(USART_GetITStatus(USART1, USART_IT_FE) ! RESET) { USART_ClearITPendingBit(USART1, USART_IT_FE); } }5.5 中斷進不去的原因排查中斷進不去是另一個常見問題?？赡艿脑虬ㄖ袛嗍鼓芪粵]有設(shè)置NVIC_EnableIRQ沒調(diào)用中斷向量表地址不對特別是用了Bootloader或者重映射的情況中斷優(yōu)先級分組設(shè)置錯誤中斷標志位在使能中斷之前就已經(jīng)被清除了全局中斷沒有使能__enable_irq()沒調(diào)用排查的時候可以一步步來先確認NVIC的中斷使能寄存器ISER對應(yīng)位是否置1再確認中斷掛起寄存器ISPR是否有對應(yīng)的掛起位然后確認中斷向量表里的地址是否正確。6. DMA與緩沖區(qū)效率提升背后的陷阱6.1 串口DMA的配置要點用DMA做串口收發(fā)可以大大減輕CPU負擔但配置不當也會引入新的問題。以STM32為例串口TX的DMA配置需要注意DMA通道要選對不同串口對應(yīng)的DMA通道不一樣傳輸方向是內(nèi)存到外設(shè)Memory to Peripheral傳輸寬度要和數(shù)據(jù)寬度匹配串口是字節(jié)傳輸所以源和目標都應(yīng)該是字節(jié)ByteDMA模式一般選單次模式Normal不是循環(huán)模式Circular傳輸完成中斷要正確配置一個典型的配置代碼DMA_InitTypeDef DMA_InitStructure; DMA_InitStructure.DMA_PeripheralBaseAddr (uint32_t)USART1-DR; DMA_InitStructure.DMA_MemoryBaseAddr (uint32_t)tx_buffer; DMA_InitStructure.DMA_DIR DMA_DIR_PeripheralDST; DMA_InitStructure.DMA_BufferSize tx_len; DMA_InitStructure.DMA_PeripheralInc DMA_PeripheralInc_Disable; DMA_InitStructure.DMA_MemoryInc DMA_MemoryInc_Enable; DMA_InitStructure.DMA_PeripheralDataSize DMA_PeripheralDataSize_Byte; DMA_InitStructure.DMA_MemoryDataSize DMA_MemoryDataSize_Byte; DMA_InitStructure.DMA_Mode DMA_Mode_Normal; DMA_InitStructure.DMA_Priority DMA_Priority_Medium; DMA_Init(DMA1_Channel4, DMA_InitStructure);如果DMA_PeripheralDataSize和DMA_MemoryDataSize設(shè)成了HalfWord或者Word而串口是字節(jié)傳輸就會導致數(shù)據(jù)錯位。比如發(fā)送0x01 0x02 0x03 0x04DMA按半字傳輸可能會變成0x0201 0x0403接收方看到的就是亂碼。6.2 接收緩沖區(qū)的設(shè)計串口接收緩沖區(qū)的設(shè)計直接影響數(shù)據(jù)完整性。常見的方案有單緩沖區(qū)簡單但接收和處理不能同時進行容易丟數(shù)據(jù)雙緩沖區(qū)Ping-Pong一個緩沖區(qū)接收另一個處理交替使用環(huán)形緩沖區(qū)適合不定長數(shù)據(jù)但實現(xiàn)稍復雜用DMA接收時通常配合串口空閑中斷IDLE來判斷一幀數(shù)據(jù)結(jié)束。空閑中斷的觸發(fā)條件是總線空閑一個字節(jié)的時間。在空閑中斷里讀取DMA的剩余傳輸數(shù)量計算出接收到的數(shù)據(jù)長度然后處理數(shù)據(jù)。這里有一個坑DMA的剩余傳輸數(shù)量寄存器NDTR在傳輸過程中是實時變化的讀取的時候要注意原子性。如果先讀NDTR再讀數(shù)據(jù)可能在讀NDTR之后、讀數(shù)據(jù)之前又收到了新數(shù)據(jù)導致長度計算錯誤。6.3 緩沖區(qū)溢出的排查緩沖區(qū)溢出是串口亂碼的常見原因之一。表現(xiàn)是接收到的數(shù)據(jù)前半部分正常后半部分亂碼或者數(shù)據(jù)整體偏移。排查方法在接收中斷或者DMA完成中斷里記錄每次接收的數(shù)據(jù)長度和緩沖區(qū)剩余空間。如果發(fā)現(xiàn)接收長度超過了緩沖區(qū)大小就說明溢出了。解決方法是增大緩沖區(qū)或者提高數(shù)據(jù)處理速度。如果數(shù)據(jù)處理本身很慢可以考慮用多級緩沖或者把數(shù)據(jù)先存到外部RAM里。6.4 串口DMA與中斷的配合串口DMA和中斷的配合需要仔細設(shè)計。以接收為例通常的流程是串口接收DMA配置為循環(huán)模式緩沖區(qū)大小設(shè)為N串口空閑中斷使能空閑中斷觸發(fā)時讀取DMA剩余傳輸數(shù)量計算接收長度處理數(shù)據(jù)重置DMA如果需要這里的關(guān)鍵是DMA模式的選擇。如果用循環(huán)模式DMA會一直循環(huán)填充緩沖區(qū)不會停止。如果用單次模式每次接收完需要重新配置DMA。循環(huán)模式適合連續(xù)數(shù)據(jù)流單次模式適合定長數(shù)據(jù)幀。7. 地線環(huán)路與硬件干擾看不見的殺手7.1 地線環(huán)路是怎么形成的地線環(huán)路是指兩個設(shè)備之間的地線形成了閉合回路。比如設(shè)備A通過串口線連接到設(shè)備B同時設(shè)備A和設(shè)備B又各自通過電源線接到了同一個插線板上。這樣串口線的地線和電源線的地線就形成了一個環(huán)路。當?shù)鼐€上有電流流過時由于地線本身有電阻和電感會在不同位置產(chǎn)生電位差。這個電位差會疊加在串口信號上導致接收方看到的電平發(fā)生偏移。偏移小的時候表現(xiàn)為偶發(fā)亂碼偏移大的時候可能完全無法通信。7.2 地線環(huán)路的實際表現(xiàn)地線環(huán)路導致的串口問題有幾個典型特征通信距離越遠問題越嚴重周圍有大功率設(shè)備如電機、變頻器工作時問題加劇用手觸摸設(shè)備外殼或者串口線時亂碼情況會變化換一根短一點的串口線問題可能減輕我遇到過一個工業(yè)現(xiàn)場的案例PLC通過RS485串口連接到一個遠程的儀表距離大概50米。在實驗室里測試完全正常到了現(xiàn)場就頻繁亂碼。后來發(fā)現(xiàn)是PLC和儀表分別接了不同的電源地兩個地之間存在幾伏的電位差。加了一個隔離型RS485收發(fā)器之后問題就解決了。7.3 隔離方案的選擇解決地線環(huán)路最徹底的方法是使用隔離。常見的隔離方案有光耦隔離在TX和RX線上各加一個光耦實現(xiàn)電氣隔離。成本低但速度受限適合低速通信。磁耦隔離用變壓器或者電容隔離速度高但成本也高。隔離型收發(fā)器比如ADM2483、ADM2582等集成了隔離和收發(fā)功能使用方便。選擇隔離方案時需要考慮通信速率、成本、體積等因素。對于115200及以下的波特率光耦隔離就夠用了。對于更高的速率建議用磁耦或者隔離型收發(fā)器。7.4 硬件濾波與保護除了隔離還可以通過硬件濾波來抑制干擾。常見的措施包括在串口線上加共模電感抑制共模干擾在TX和RX線上加TVS管防止靜電和浪涌在收發(fā)器電源引腳加去耦電容一般用100nF和10uF并聯(lián)在RS485總線的A、B線上加偏置電阻確?？臻e時電平穩(wěn)定這些措施雖然不能完全消除地線環(huán)路的影響但可以顯著提高通信的可靠性。8. 常見問題速查表與排查流程8.1 串口亂碼問題速查表現(xiàn)象可能原因排查方法解決方案全部亂碼無正常字節(jié)波特率不匹配示波器量TX引腳周期重新計算波特率分頻偶發(fā)亂碼大部分正常時鐘偏差臨界檢查時鐘源精度換外部晶振或降低波特率收到0x00或0xFFGPIO模式錯誤檢查RX引腳電平改為浮空或上拉輸入數(shù)據(jù)錯位字節(jié)順序亂DMA傳輸寬度錯誤檢查DMA數(shù)據(jù)寬度配置改為Byte傳輸接收一段時間后停止中斷標志未清除檢查ORE/FE標志在ISR中清除所有錯誤標志通信距離短就正常地線環(huán)路測量兩地電位差加隔離或共模電感中斷進不去NVIC配置錯誤檢查ISER/ISPR寄存器重新配置中斷優(yōu)先級發(fā)送正常接收亂碼RX引腳配置錯誤檢查RX復用功能映射查數(shù)據(jù)手冊確認AF編號8.2 系統(tǒng)化排查流程遇到串口亂碼建議按以下順序排查確認硬件連接TX接RXRX接TX地線接好。用萬用表量一下串口線的通斷。量TX引腳波形用示波器或者邏輯分析儀看TX引腳有沒有波形波特率對不對。檢查時鐘配置確認系統(tǒng)時鐘、APB時鐘、USART時鐘的計算是否正確。檢查GPIO配置確認TX和RX的復用功能映射、工作模式、速度設(shè)置。檢查中斷配置確認中斷優(yōu)先級、中斷使能、標志位清除。檢查DMA配置確認DMA通道、傳輸方向、數(shù)據(jù)寬度、模式。檢查緩沖區(qū)確認緩沖區(qū)大小、讀寫指針、溢出保護。檢查硬件環(huán)境確認地線連接、隔離措施、濾波電路。這個順序是從簡單到復雜從硬件到軟件。大部分問題在前三步就能定位。8.3 實操心得與避坑技巧心得一先量波形再改代碼。很多人一遇到亂碼就開始改代碼改了半天發(fā)現(xiàn)是硬件問題。先用示波器量一下TX引腳的波形確認波特率和數(shù)據(jù)內(nèi)容能省很多時間。心得二用已知數(shù)據(jù)測試。發(fā)送固定的0x55或0xAA這兩個字節(jié)的方波周期最容易測量。0x55是01010101方波周期等于位周期0xAA是10101010也是方波。用示波器量周期倒數(shù)就是波特率。心得三串口助手也有坑。有些串口助手在接收到錯誤數(shù)據(jù)時會自動丟棄或者顯示異常導致你看到的亂碼和實際接收到的數(shù)據(jù)不一致。建議用示波器或者邏輯分析儀直接抓取原始數(shù)據(jù)。心得四注意電平標準。TTL電平、RS232電平、RS485電平不能直接互連。TTL是0-3.3V或0-5VRS232是負邏輯-15V到15VRS485是差分信號。接錯了不僅亂碼還可能燒芯片。心得五地線一定要接。有些人只接TX和RX不接地線覺得能省一根線。但串口通信的參考電平是地線不接地線的話兩邊的電平參考點不一致必然亂碼。心得六長距離通信要加保護。超過1米的串口線建議加共模電感和TVS管。超過10米的建議用RS485或者加隔離。超過100米的必須用RS485加隔離加中繼。9. 從具體平臺看串口問題的差異性9.1 STM32與GD32的差異STM32和GD32雖然引腳兼容但在串口配置上有一些細微差異。GD32的USART時鐘源選擇比STM32更靈活但默認配置可能不同。比如GD32F470的USART0默認掛在APB2上而STM32F407的USART1也掛在APB2上但分頻系數(shù)可能不同。另外GD32的中斷向量表偏移和STM32可能不一樣特別是在用Bootloader的時候。如果中斷向量表沒有正確重映射中斷就進不去。9.2 ESP32的串口配置ESP32的串口配置和STM32差異較大。ESP32有三個UART默認的UART0用于下載和調(diào)試UART1和UART2可以自由使用。在Arduino框架下用Serial.begin(115200)就可以初始化串口但要注意引腳映射。ESP32的GPIO矩陣允許幾乎任意引腳映射到UART但有些引腳在啟動時有特殊功能不能隨便用。比如GPIO6到GPIO11通常連接了SPI Flash不能用作串口。在PlatformIO下開發(fā)ESP32S3串口輸出的配置和ESP32類似但要注意USB串口和硬件串口的區(qū)別。ESP32S3有內(nèi)置的USB-Serial-JTAG可以直接通過USB輸出串口數(shù)據(jù)不需要額外的USB轉(zhuǎn)串口芯片。9.3 FPGA的串口實現(xiàn)FPGA實現(xiàn)串口發(fā)送ASCII字符串需要自己寫UART發(fā)送模塊。核心是一個波特率發(fā)生器和一個移位寄存器。波特率發(fā)生器的分頻系數(shù)計算分頻系數(shù) 系統(tǒng)時鐘頻率 / 波特率比如系統(tǒng)時鐘50MHz波特率115200分頻系數(shù) 50000000 / 115200 434.027取434實際波特率 50000000 / 434 115207誤差0.006%完全夠用。Verilog實現(xiàn)串口發(fā)送整數(shù)和浮點數(shù)需要先把整數(shù)和浮點數(shù)轉(zhuǎn)換成ASCII字符串然后逐字節(jié)發(fā)送。整數(shù)轉(zhuǎn)換可以用除法和取模浮點數(shù)轉(zhuǎn)換比較復雜可以用sprintf或者自己實現(xiàn)。9.4 Linux下的串口配置Linux下配置串口用termios結(jié)構(gòu)體設(shè)置波特率、數(shù)據(jù)位、停止位、校驗位等。一個典型的配置struct termios options; tcgetattr(fd, options); cfsetispeed(options, B115200); cfsetospeed(options, B115200); options.c_cflag | (CLOCAL | CREAD); options.c_cflag ~PARENB; options.c_cflag ~CSTOPB; options.c_cflag ~CSIZE; options.c_cflag | CS8; tcsetattr(fd, TCSANOW, options);Linux下串口接收數(shù)據(jù)丟失的常見原因是緩沖區(qū)設(shè)置太小或者讀取速度跟不上?？梢杂胹elect()或者poll()來監(jiān)聽串口事件及時讀取數(shù)據(jù)。10. 幾個真實案例的完整復盤10.1 案例一GD32F470VET6串口亂碼問題描述GD32F470VET6開發(fā)板串口配置為115200-8-N-1發(fā)送字符串“Hello”串口助手收到亂碼。排查過程用示波器量TX引腳發(fā)現(xiàn)波特率約為9600而不是115200。檢查代碼發(fā)現(xiàn)系統(tǒng)時鐘配置為200MHz但USART時鐘源選擇的是APB1而APB1的分頻系數(shù)設(shè)成了4導致USART時鐘只有50MHz。重新計算波特率分頻50000000 / (16 * 115200) 27.126整數(shù)部分27小數(shù)部分0.126*162實際分頻27.125實際波特率 50000000 / (16 * 27.125) 115207誤差0.006%。修改APB1分頻系數(shù)為2USART時鐘變?yōu)?00MHz重新計算分頻100000000 / (16 * 115200) 54.253整數(shù)部分54小數(shù)部分0.253*164實際分頻54.25實際波特率 100000000 / (16 * 54.25) 115207誤差0.006%。重新編譯下載串口輸出正常。經(jīng)驗總結(jié)GD32F470的時鐘樹比F407復雜APB1和APB2的分頻系數(shù)會影響USART時鐘。配置串口之前一定要確認USART的時鐘源和實際頻率。10.2 案例二ESP32外部中斷導致串口亂碼問題描述ESP32開發(fā)板用外部中斷檢測按鍵同時用串口輸出調(diào)試信息。按鍵按下時串口輸出亂碼。排查過程檢查串口配置波特率115200正常。檢查中斷服務(wù)函數(shù)發(fā)現(xiàn)按鍵中斷的優(yōu)先級設(shè)成了最高而且ISR里有Serial.println()調(diào)用。Serial.println()在ISR里調(diào)用會導致串口發(fā)送和中斷處理沖突因為串口發(fā)送本身也可能觸發(fā)中斷。修改方案在ISR里只設(shè)置一個標志位在主循環(huán)里檢測標志位并輸出調(diào)試信息。重新測試按鍵按下時串口輸出正常。經(jīng)驗總結(jié)ISR里不要調(diào)用串口發(fā)送函數(shù)尤其是高優(yōu)先級中斷。串口發(fā)送最好放在主循環(huán)或者低優(yōu)先級任務(wù)里。10.3 案例三RS485長距離通信亂碼問題描述PLC通過RS485連接遠程儀表距離50米通信頻繁亂碼。排查過程在實驗室用短距離測試通信正常。到現(xiàn)場測量PLC和儀表的地線電位差發(fā)現(xiàn)約有2V的交流電壓。判斷是地線環(huán)路導致的共模干擾。在RS485總線上加裝隔離型收發(fā)器問題解決。經(jīng)驗總結(jié)長距離RS485通信一定要考慮地線環(huán)路問題。隔離是最徹底的解決方案雖然成本高一些但能避免很多現(xiàn)場問題。11. 串口調(diào)試工具與技巧匯總11.1 常用串口調(diào)試工具串口調(diào)試助手Windows下最常用的串口調(diào)試工具支持HEX和ASCII顯示支持定時發(fā)送。SSCOM功能更強大支持多條發(fā)送指令、數(shù)據(jù)校驗、波形顯示。minicomLinux下的串口終端工具適合命令行環(huán)境。screenLinux下簡單的串口終端screen /dev/ttyUSB0 115200即可。邏輯分析儀抓取串口波形分析時序和協(xié)議。示波器測量波特率、電平、邊沿時間。11.2 串口封裝與代碼復用在實際項目中串口通信代碼通常需要封裝成模塊方便復用。一個典型的串口封裝包括初始化函數(shù)配置GPIO、USART、中斷、DMA發(fā)送函數(shù)支持阻塞發(fā)送和DMA發(fā)送接收函數(shù)支持中斷接收和DMA接收回調(diào)函數(shù)數(shù)據(jù)接收完成后的處理邏輯C語言下的串口封裝可以用結(jié)構(gòu)體來管理串口實例typedef struct { USART_TypeDef *usart; uint8_t *rx_buffer; uint16_t rx_size; uint16_t rx_head; uint16_t rx_tail; void (*rx_callback)(uint8_t *data, uint16_t len); } uart_handle_t;這種封裝方式在STM32、GD32、CH32V等平臺上都可以通用只需要修改底層的寄存器操作。11.3 串口燒寫失敗的排查串口燒寫失敗也是常見問題可能的原因包括BOOT引腳電平不對STM32需要BOOT01BOOT10進入系統(tǒng)存儲器啟動模式串口線連接錯誤TX接RXRX接TX波特率不匹配有些Bootloader固定用9600或115200復位時序不對需要先拉低復位再發(fā)送同步字節(jié)串口被其他程序占用排查的時候可以先確認BOOT引腳電平然后用示波器看TX引腳有沒有數(shù)據(jù)發(fā)出再檢查串口助手的配置。12. 寫在最后的一些個人體會串口亂碼這個問題說大不大說小不小。它不會讓程序崩潰但會讓調(diào)試變得極其痛苦。我這些年踩過的坑總結(jié)下來就是一句話串口通信的可靠性取決于最薄弱的那個環(huán)節(jié)。時鐘、GPIO、中斷、DMA、地線任何一個環(huán)節(jié)出問題都會表現(xiàn)為亂碼。排查的時候我的習慣是先從硬件入手用示波器量波形確認物理層沒問題再往上查配置。軟件配置里優(yōu)先檢查時鐘和GPIO這兩個是最容易出錯的。中斷和DMA的問題往往更隱蔽需要結(jié)合代碼和實際現(xiàn)象來分析。還有一點很重要不要迷信例程。很多例程是針對特定開發(fā)板寫的換一塊板子或者換一個芯片型號時鐘配置、引腳映射可能就不一樣了。一定要查數(shù)據(jù)手冊和參考手冊確認每一個寄存器的配置。最后分享一個小技巧如果你懷疑是波特率偏差導致的亂碼可以試著把波特率降低一半或者降低到9600。如果降低之后通信正常了那基本可以確定是時鐘偏差問題。因為波特率越低對時鐘精度的要求越低容忍度越高。這個方法雖然不能解決根本問題但能幫你快速定位方向。