簡介STM32F091多串口程序是一份基于ARM Cortex-M0內(nèi)核微控制器的UART驅(qū)動與中斷接收工程適合嵌入式開發(fā)者、物聯(lián)網(wǎng)及工業(yè)控制領(lǐng)域技術(shù)人員參考。程序圍繞主串口中斷接收展開實現(xiàn)一個主串口向五個乃至七個從串口的數(shù)據(jù)轉(zhuǎn)發(fā)可通過中斷優(yōu)先級管理、獨立DMA通道或輪詢標(biāo)識靈活擴展涵蓋時鐘初始化、GPIO復(fù)用、波特率數(shù)據(jù)位配置、接收中斷及可選DMA傳輸?shù)韧暾襟E。壓縮包內(nèi)含881個文件以C源文件、頭文件、匯編文件、編譯生成的目標(biāo)鏈接文件、Keil工程配置及芯片文檔為主輔以網(wǎng)頁與PDF說明總體積約7.58MB目錄結(jié)構(gòu)清晰便于對照學(xué)習(xí)。已有767人學(xué)習(xí)下載。通過分析這些代碼可深入理解STM32F091多串口的驅(qū)動寫法、中斷處理與轉(zhuǎn)發(fā)邏輯并借鑒防止數(shù)據(jù)丟失、保障實時性的工程經(jīng)驗對實現(xiàn)多路串口橋接或數(shù)據(jù)采集系統(tǒng)有直接價值。1. STM32F091 多串口程序難點從來不在串口多而在它們同時工作做 STM32F091 多串口程序最有意思的一點是單看任何一個串口配置都簡單到能閉眼寫完但當(dāng)真把 8 個 UART 全部掛上外設(shè)、跑起數(shù)據(jù)時問題就全來了——中斷互相搶占、DMA 通道不夠分、波特率誤差在某個串口上突然放大、一幀數(shù)據(jù)被空閑中斷硬生生拆成兩半。我見過不少開發(fā)者被這些現(xiàn)象折磨到懷疑芯片體質(zhì)最后只能靠玄學(xué)調(diào)參。這篇文章想直接把 STM32F091 多串口程序的完整落地路徑講透先盤資源、再分配通道、給出可抄的初始化和收發(fā)代碼最后把最容易翻車的幾個場景以現(xiàn)象到原因到解決的方式列清楚。適合正在做多傳感器采集、一主多從協(xié)議轉(zhuǎn)換、或把多個串口模塊同時掛到一顆低成本 M0 芯片上的從業(yè)者。2. 多串口方案的資源底牌8 個 UART 與中斷/DMA 怎么分才不打架2.1 STM32F091 的串口資源盤點哪些口能復(fù)用哪些口要省著用STM32F091 這顆片子最吸引人的一點是它在一顆 M0 內(nèi)核上放了一堆串口資源片上最多提供 USART1/USART2 和 UART3 到 UART8加起來 8 個串口。但“有”和“能用”之間隔著幾道坎。第一道坎是引腳。每個串口的 TX/RX 并不是固定在某一對引腳上的而是有多組復(fù)用選擇具體映射關(guān)系要去數(shù)據(jù)手冊的 alternate function 表里查。開始畫原理圖之前我會先把目標(biāo)封裝的所有引腳和 AF 映射列出來而不是等板子回來了再拿杜邦線飛。有些引腳同時掛在了多個串口候選上選了 A 串口B 串口就只能換引腳這一步在布局階段就要定死。第二道坎是 M0 內(nèi)核的資源預(yù)算。F091 的主頻上限是 48MHzFlash 和 RAM 都談不上寬裕8 個串口如果全部走中斷收發(fā)一個大數(shù)據(jù)幀進(jìn)來CPU 時間就會被反復(fù)打斷主循環(huán)里的業(yè)務(wù)邏輯幾乎跑不動。所以做多串口程序前第一件事不是寫代碼而是給每個串口定工作模式和優(yōu)先級。我一般會按“數(shù)據(jù)量 × 實時性”把串口分成三類第一類是高速持續(xù)數(shù)據(jù)流比如 4G 模塊、Wi-Fi 透傳走 DMA 收發(fā)第二類是中等數(shù)據(jù)量、需要及時響應(yīng)的設(shè)備比如稱重儀表、條碼槍走中斷 空閑中斷判斷第三類是低頻配置口比如按鍵面板、調(diào)試日志輪詢就夠用。注意8 個串口不要全上 DMAF091 的 DMA 資源非常緊張。它在手冊里的 DMA 請求映射表串口和 DMA 通道的分配是有講究的有的通道天然只能服務(wù)特定幾個外設(shè)串口一多先到先得后配的串口就可能找不到空閑通道。2.2 中斷與 DMA 通道分配先分優(yōu)先級再寫代碼動手寫時鐘和串口初始化代碼之前先畫一張分配表。比如一個典型應(yīng)用串口 1 接上位機走 DMA 收發(fā)搶占優(yōu)先級最高串口 2 接定位模塊走 DMA 接收 空閑中斷串口 3 接傳感器走中斷接收串口 4 到串口 8 做配置口或日志口其中一部分甚至只在開機時讀寫一輪。串口典型用途收發(fā)方式波特率中斷/優(yōu)先級策略USART1上位機通信RX: DMA 空閑中斷TX: DMA115200搶占優(yōu)先級最高USART2定位模塊RX: DMA 空閑中斷TX: 輪詢9600搶占優(yōu)先級次高UART3傳感器輪詢RX: 中斷逐字節(jié)TX: 輪詢115200普通優(yōu)先級UART4-UART8配置/日志/低速設(shè)備RX: 查詢或低優(yōu)先級中斷9600低優(yōu)先級或關(guān)閉中斷這張表解決的是一個非常重要的問題中斷嵌套順序。F091 的 NVIC 支持搶占優(yōu)先級多串口同時收發(fā)時只有優(yōu)先級最高的串口能立刻打斷主流程其他串口的數(shù)據(jù)會排隊。很多翻車場景的根源就是把所有串口的中斷優(yōu)先級都設(shè)成了最好的一檔結(jié)果任意一個串口來數(shù)據(jù)都能打斷一切主循環(huán)直接餓死。具體到實現(xiàn)層面先定哪幾個串口必須高優(yōu)先級哪幾個串口能容忍延遲再用這張表指導(dǎo) CubeMX 里的配置和代碼里的優(yōu)先級設(shè)置效率會高很多。另外F091 是 M0 內(nèi)核沒有位帶操作。需要保護(hù)多串口共享的緩沖區(qū)索引時不要想著用位帶原子改標(biāo)志老老實實用臨界區(qū)或者關(guān)中斷。這是以后寫收發(fā)緩沖時必須記住的前提。3. 初始化配置時鐘、波特率誤差與 CubeMX 批量生成3.1 從 8MHz 換到 48MHz 系統(tǒng)時鐘算清 BRR 誤差再動手串口初始化前先把系統(tǒng)時鐘拉起來。F091 外部晶振常見是 8MHz內(nèi)部 PLL 可以倍頻到 48MHz把系統(tǒng)時鐘跑到最高頻串口波特率生成器才有足夠的整數(shù)分頻粒度。這里注意一個坑從 8MHz 切到 48MHz 時Flash 等待周期要跟著設(shè)置好否則程序可能直接跑飛。CubeMX 生成的代碼一般會自動處理這些但如果你習(xí)慣手寫寄存器初始化最容易漏的就是這一步。F091 的串口時鐘來自 APB 總線。系統(tǒng)時鐘 48MHz 時只要 APB 分頻器設(shè)為 /1串口外設(shè)時鐘就是 48MHz。波特率分頻的計算公式是 BRR 串口時鐘 / 波特率但實際寫入 BRR 寄存器的值和這個商并不完全相等因為 BRR 只有有限位數(shù)取整后必然產(chǎn)生誤差。計算一個實際例子時鐘 48MHz、波特率 115200 時48,000,000 / 115,200 416.666取整后實際波特率約為 115,107誤差約 0.08%完全可用。但如果外部晶振是 12MHzPLL 配置不當(dāng)導(dǎo)致串口時鐘變成 44MHz44,000,000 / 115,200 381.94取整誤差到了 0.2% 附近接某些對時序敏感的對端設(shè)備就可能出現(xiàn)概率性亂碼。這就是多串口程序的第一個核心邏輯波特率誤差不是“有或沒有”而是“能不能壓在接收端的容忍范圍里”。常見 UART 異步通信在 8-N-1 格式下接收端能容忍約 ±2% 的頻率偏差超過這個邊界串口助手打出來的字可能正常但接真實模塊就開始隨機翻車。所以在配置串口時我建議優(yōu)先保證所有串口共用同一個串口時鐘源不要一個串口用一個時鐘。CubeMX 的 Clock Configuration 頁面可以直接看到系統(tǒng)時鐘、APB 分頻和串口時鐘的關(guān)系把 APB 分頻設(shè)置成 /1讓所有 UART 共享 48MHz 時鐘是最省心的做法。3.2 CubeMX 多串口初始化與表驅(qū)動配置用 CubeMX 配多串口時我喜歡把重復(fù)勞動壓縮到最小。在 Pinout 頁面把用到的串口引腳逐個點亮每個 UART 的 Mode 選 AsynchronousParameter Settings 里配置波特率、字長 8、停止位 1、無校驗。這里有個經(jīng)驗值同一項目的多個串口波特率盡量用整數(shù)分頻能整除的值比如 48MHz 時鐘下 115200、9600、38400 都相對友好而 57600 在某些分頻組合下誤差偏大。CubeMX 生成工程后HAL 庫會給每個串口生成一個UART_HandleTypeDef實例和對應(yīng)的MX_USARTx_UART_Init函數(shù)。串口多了之后逐個手寫初始化函數(shù)非常容易漏配我會再加一層表驅(qū)動封裝。用一張配置表把串口實例、波特率、優(yōu)先級、中斷回調(diào)入口統(tǒng)一起來主循環(huán)里通過索引訪問后面新增串口只需要改表不用改邏輯。typedef struct { UART_HandleTypeDef *huart; uint32_t baudrate; IRQn_Type irq; uint8_t preempt_prio; } uart_cfg_t; const uart_cfg_t uart_configs[] { { huart1, 115200, USART1_IRQn, 1 }, { huart2, 9600, USART2_IRQn, 2 }, { huart3, 115200, USART3_IRQn, 8 }, }; void uart_common_init(const uart_cfg_t *cfg) { HAL_NVIC_SetPriority(cfg-irq, cfg-preempt_prio, 0); HAL_NVIC_EnableIRQ(cfg-irq); }這段代碼的作用是把中斷優(yōu)先級和中斷使能從每個串口的初始化里抽出來統(tǒng)一由配置表驅(qū)動。preempt_prio字段寫成 1、2、8代表不同的搶占優(yōu)先級數(shù)值越小優(yōu)先級越高。多串口場景下控制鏈路和高速鏈路用低數(shù)值日志和低速配置口用高數(shù)值這樣即使日志串口瘋狂刷屏也不會堵死核心通信鏈路。注意這個例子里我把優(yōu)先級抽出來了但每個串口的波特率、引腳復(fù)用、DMA 通道仍然看 CubeMX 里那一段配置不在表驅(qū)動范圍內(nèi)因為它們和具體外設(shè)強綁定。初始化時還有一個容易忽略的參數(shù)TX/RX 的 GPIO 速度尤其是波特率拉到 460800 或者 1M 時GPIO 輸出速度必須足夠快否則信號邊沿變形短距離通信也可能丟字節(jié)。CubeMX 默認(rèn)的 GPIO 設(shè)置通常偏低我在高速串口上會手動把對應(yīng)引腳的 GPIO Speed 調(diào)到 Very High。4. 收發(fā)實現(xiàn)空閑中斷DMA 怎么搭才穩(wěn)4.1 接收不定長數(shù)據(jù)的兩種姿勢空閑中斷與 DMA 半滿中斷串口接收有兩種典型的實現(xiàn)方式多串口程序里需要根據(jù)每個口的數(shù)據(jù)特點去選。第一種是“DMA 半滿/全滿中斷”。先給 DMA 配置一個固定大小的接收緩沖區(qū)DMA 每接收一半或收滿就觸發(fā)一次中斷應(yīng)用層去緩沖區(qū)取數(shù)據(jù)。這種方式的優(yōu)點是中斷頻率固定、實時性可控缺點是無法直接知道一幀數(shù)據(jù)什么時候結(jié)束應(yīng)用層要自己判斷數(shù)據(jù)邊界對不定長包處理很不友好。第二種是“空閑中斷 DMA”。F091 的 UART 模塊在檢測到串口總線空閑時會置上 IDLE 標(biāo)志產(chǎn)生一次中斷。這是處理不定長幀最順手的組合DMA 一直在接收等到總線空閑了空閑中斷告訴你“這一批數(shù)據(jù)到了”應(yīng)用層再從 DMA 緩沖區(qū)按實際收到的字節(jié)數(shù)取出。相比半滿中斷空閑中斷天然對應(yīng)一幀結(jié)束非常適合多個串口分別接不同協(xié)議的從設(shè)備。我在項目里的通用姿勢是所有數(shù)據(jù)量稍大的串口都走空閑中斷 DMA 接收DMA 緩沖區(qū)設(shè)成該串口可能出現(xiàn)的最大幀長度。緩沖區(qū)長度要比理論最大幀長略大一點防止一個異常長包直接寫穿緩沖。初始化時調(diào)用HAL_UARTEx_ReceiveToIdle_DMA()這個 API 會同時開啟 DMA 接收和空閑中斷一幀數(shù)據(jù)結(jié)束后進(jìn)入HAL_UARTEx_RxEventCallback()回調(diào)回調(diào)參數(shù)里的Size就是實際收到的字節(jié)數(shù)。用回調(diào)而不是在中斷里直接處理業(yè)務(wù)可以把串口邏輯和協(xié)議解析解耦。#define UART1_RX_BUF_SIZE 128 uint8_t uart1_rx_buf[UART1_RX_BUF_SIZE]; void start_uart1_rx(void) { // 這個調(diào)用同時打開 DMA 和空閑中斷收到一幀后回調(diào) HAL_UARTEx_ReceiveToIdle_DMA(huart1, uart1_rx_buf, UART1_RX_BUF_SIZE); __HAL_DMA_DISABLE_IT(hdma_usart1_rx, DMA_IT_HT); // 關(guān)閉半傳輸中斷只關(guān)心滿幀和空閑 }說明一下這幾行的用意HAL_UARTEx_ReceiveToIdle_DMA()是啟動接收的關(guān)鍵一次性完成 DMA 通道、接收緩沖和空閑中斷的綁定關(guān)閉半傳輸中斷是為了減少無謂的上下文切換因為多串口場景下 CPU 時間很寶貴。如果你需要處理超長數(shù)據(jù)流可以保留半中斷在兩個緩沖區(qū)之間交替但大部分設(shè)備通信場景都用不上。4.2 環(huán)形緩沖區(qū)與最小協(xié)議解析代碼空閑中斷雖然能分辨一幀結(jié)束但如果主循環(huán)來不及處理回調(diào)里積累的數(shù)據(jù)會丟失。所以多串口程序里我堅持引入環(huán)形緩沖區(qū)中斷回調(diào)只管把數(shù)據(jù)寫進(jìn)環(huán)形緩沖主循環(huán)按自己的節(jié)奏讀出來做協(xié)議解析。這樣即使某個串口突然涌進(jìn)大量數(shù)據(jù)也不會立即丟幀。環(huán)形緩沖區(qū)有幾個細(xì)節(jié)必須注意緩沖區(qū)大小必須是 2 的 N 次方這樣取模運算可以優(yōu)化成位與省掉除法讀寫索引要定義成volatile避免中斷和主循環(huán)之間的緩存一致性問題只允許一個生產(chǎn)者一個消費者時不用加鎖但生產(chǎn)者和消費者各自只修改自己的索引。#define RBUF_SIZE 256 typedef struct { uint8_t buf[RBUF_SIZE]; volatile uint16_t head; // 寫索引中斷回調(diào)里更新 volatile uint16_t tail; // 讀索引主循環(huán)里更新 } ring_buf_t; uint16_t rbuf_used(ring_buf_t *rb) { return (uint16_t)(rb-head - rb-tail); } uint8_t rbuf_pop(ring_buf_t *rb, uint8_t *out) { if (rb-tail rb-head) { return 0; } *out rb-buf[rb-tail]; rb-tail (uint16_t)((rb-tail 1) (RBUF_SIZE - 1)); return 1; }這個實現(xiàn)里head和tail都用uint16_t并且讓它們自由計數(shù)、不歸零。讀取后索引只做遞增用 (RBUF_SIZE - 1)完成折返。判斷緩沖區(qū)空不空只需要比較兩個索引是否相等。這種寫法避免了“讀寫索引在同一時刻被兩邊修改”帶來的競爭是嵌入式里最常見的無鎖單生產(chǎn)者消費者模型。有了緩沖協(xié)議解析就可以完全搬到主循環(huán)。拿最常見的“幀頭 長度 數(shù)據(jù) 校驗”格式舉例解析代碼是一個簡單的狀態(tài)機typedef enum { PARSE_WAIT_HEAD, PARSE_WAIT_LEN, PARSE_WAIT_DATA, PARSE_WAIT_CRC, } parse_state_t; parse_state_t parse_state PARSE_WAIT_HEAD; uint8_t frame_data[64]; uint16_t frame_index 0; uint16_t frame_len 0; void parse_byte(uint8_t byte) { switch (parse_state) { case PARSE_WAIT_HEAD: if (byte 0xAA) { parse_state PARSE_WAIT_LEN; } break; case PARSE_WAIT_LEN: frame_len byte; frame_index 0; parse_state PARSE_WAIT_DATA; break; case PARSE_WAIT_DATA: frame_data[frame_index] byte; if (frame_index frame_len) { parse_state PARSE_WAIT_CRC; } break; case PARSE_WAIT_CRC: // 校驗字節(jié)比對在這里做匹配成功則上傳完整幀給業(yè)務(wù)層 parse_state PARSE_WAIT_HEAD; break; default: parse_state PARSE_WAIT_HEAD; break; } }狀態(tài)機的價值在于每個串口的協(xié)議解析互不干擾每個串口維護(hù)自己的parse_state主循環(huán)可以輪流喂給 8 個解析器。多串口項目里不要寫“一個中斷里把協(xié)議全解完”的結(jié)構(gòu)那會讓優(yōu)先級高的串口搶占大量 CPU 時間其它串口的緩沖很快溢出。5. 多串口程序避坑清單4 個讓開發(fā)者翻車的真實場景5.1 波特率誤差為什么自己打印正常對端全是亂碼現(xiàn)象板子通過串口連電腦串口助手自發(fā)自收完全正常連到某個定位模塊或工業(yè)儀表上數(shù)據(jù)就開始出現(xiàn)概率性亂碼有時候重啟一下又好一陣子。原因自發(fā)自收是同一個芯片的同一個串口時鐘誤差再大兩邊也是“同源偏差”互相能容忍而對端設(shè)備用的是自己的晶振時鐘兩邊頻率誤差疊加后超過了 UART 接收端容忍的閾值。最典型的誘因是外部晶振頻率不是按串口時鐘最優(yōu)值選的或者 APB 分頻器設(shè)置讓串口時鐘變成了一個尷尬的值。解決先查時鐘樹。用 CubeMX 的 Clock Configuration把串口時鐘統(tǒng)一到 48MHz確認(rèn) APB 分頻是 /1。然后按“串口時鐘 / 波特率”逐口手算 BRR 取整誤差誤差超過 0.5% 的串口優(yōu)先換波特率或換時鐘源而不是調(diào)接受端的采樣點。如果你用的是無源晶振而不是有源晶振還要考慮晶振負(fù)載電容是否匹配頻率偏了 30ppm 不算事偏到 0.1% 就足以在長幀場景下產(chǎn)生誤碼。這一條是典型“看著代碼沒問題、實際玄學(xué)”的坑先懷疑時鐘再懷疑線材。5.2 DMA 通道被占新串口一開老串口就不動了現(xiàn)象串口 1 的 DMA 收發(fā)一直跑得很好后來在 CubeMX 里新增了串口 4 并給它配了 DMA 接收編譯燒錄后串口 1 的接收數(shù)據(jù)全部停止DMA 好像失效了。原因F091 的 DMA 請求映射并不是所有串口都能獨占通道兩個串口的 RX 請求可能映射到同一個 DMA 通道或者新增串口使能時把已有通道的配置覆蓋掉了。CubeMX 在圖形界面里不會主動告訴你“該通道已被占用”只有查參考手冊的 DMA 請求映射表才能發(fā)現(xiàn)沖突。解決打開參考手冊的 DMA 請求映射表把已使用的每個串口的 DMA 請求和通道號列成一張核對表確保通道不重疊。通道沖突時優(yōu)先讓高速串口保留 DMA 通道低速串口改用中斷接收。如果你發(fā)現(xiàn)某個串口必須 DMA、又實在沒有空閑通道只能調(diào)整引腳復(fù)用或者換用其它具備 DMA 能力的外設(shè)組合而不是硬塞。每次在 CubeMX 里改完配置后重新生成代碼時我會順手看一眼生成的dma.c和stm32f0xx_hal_msp.c確認(rèn)新通道配置沒有覆蓋舊通道。5.3 中斷優(yōu)先級全拉滿主循環(huán)卡死與系統(tǒng)響應(yīng)失靈現(xiàn)象多個串口同時以較高頻率收發(fā)數(shù)據(jù)時主循環(huán)里的輪詢?nèi)蝿?wù)明顯變慢再極端一些喂狗不及時導(dǎo)致復(fù)位或者按鍵響應(yīng)延遲好幾秒。調(diào)試一看中斷一直在進(jìn)來主循環(huán)根本沒機會跑。原因把 8 個串口的中斷優(yōu)先級全部設(shè)成最高任何一個字節(jié)到達(dá)都會立即搶占主流程。M0 的中斷響應(yīng)雖然快但頻繁切換上下文累積起來就是巨大的 CPU 開銷。數(shù)據(jù)量大的串口沖擊下主循環(huán)的優(yōu)先級被徹底邊緣化。解決回歸到第 2 章的分配表給每個串口按重要性設(shè)置搶占優(yōu)先級?？刂奇溌酚米罡邇?yōu)先級數(shù)據(jù)采集用中等優(yōu)先級日志串口必須給最低優(yōu)先級。NVIC 里搶占優(yōu)先級數(shù)值越小優(yōu)先級越高日志口設(shè)成一個較大的數(shù)值比如 10 以上再配合日志開關(guān)宏發(fā)布版本直接關(guān)閉日志串口中斷。這里還有一個容易忽略的點DMA 接收完成中斷和空閑中斷不要全擠在同一檔位給 DMA 完成留一個稍高的優(yōu)先級否則大幀接收過程中如果被更高優(yōu)先級串口反復(fù)打斷DMA 配置可能被卸載重載。5.4 空閑中斷誤觸發(fā)一幀數(shù)據(jù)被硬生生拆成兩段現(xiàn)象某個串口接收不定長幀數(shù)據(jù)量一多協(xié)議層偶爾報“幀頭丟失”或者“長度不對”。抓日志發(fā)現(xiàn)一個完整的 64 字節(jié)幀有時被拆成 30 字節(jié)和 34 字節(jié)兩段分別觸發(fā)了兩次空閑中斷。原因空閑中斷的判定標(biāo)準(zhǔn)是串口線路上超過一個字節(jié)時間沒有電平翻轉(zhuǎn)。如果發(fā)送方在兩段數(shù)據(jù)之間插入了一個稍長的間隔比如對端設(shè)備分兩次寫入串口中間間隔了幾毫秒接收端就會認(rèn)為上一幀結(jié)束置位 IDLE。解決不要在空閑中斷回調(diào)里立刻按“一整幀”處理而是把數(shù)據(jù)先送進(jìn)環(huán)形緩沖區(qū)由協(xié)議狀態(tài)機負(fù)責(zé)拼幀。狀態(tài)機只認(rèn)幀頭、幀長和校驗不依賴空閑中斷來切幀邊界同時加一個超時計數(shù)器比如累計 50ms 沒有新數(shù)據(jù)到達(dá)才認(rèn)為當(dāng)前幀結(jié)束。這樣即使 IDLE 誤觸發(fā)數(shù)據(jù)也不會丟只是多一次回調(diào)拼幀結(jié)果仍正確。另外排查一下對端設(shè)備的發(fā)送邏輯是否會在幀中間做延遲很多第三方模塊的固件會在指令和應(yīng)答之間人為穿插延遲。6. 驗證穩(wěn)定性與進(jìn)階用回環(huán)壓測和多級日志守住最后一公里6.1 串口回環(huán)壓力測試讓每個口都自發(fā)自收跑一個晚上多串口程序最怕的不是功能寫不完而是功能寫完了卻不敢保證穩(wěn)定性。我的驗證習(xí)慣是一塊測試板、一根短接線把每個串口的 TX 和 RX 外部短接然后讓每個串口自發(fā)自收跑一整晚統(tǒng)計誤碼和丟幀。void uart_loopback_test(UART_HandleTypeDef *huart, uint32_t count) { uint8_t tx 0x00; uint8_t rx 0x00; uint32_t error_cnt 0; for (uint32_t i 0; i count; i) { tx (uint8_t)(i 0xFF); HAL_UART_Transmit(huart, tx, 1, 100); HAL_UART_Receive(huart, rx, 1, 100); if (tx ! rx) { error_cnt; } } // error_cnt 大于 0 時把結(jié)果和串口編號上報到日志口 }這段回環(huán)邏輯的意義不在于多復(fù)雜而在于能用最小的代碼量持續(xù)壓測每個串口的物理鏈路和驅(qū)動配置。測試時注意幾件事所有串口同時跑不要一個個測否則并發(fā)下的中斷沖突和 DMA 競爭測不出來測試期間日志串口保持打開方便觀察哪個口的 error_cnt 在增長連續(xù)跑 8 小時以上才有說服力偶發(fā)的誤碼往往出現(xiàn)在溫度變化或電壓波動的時候。6.2 從多串口裸機到可維護(hù)系統(tǒng)協(xié)議狀態(tài)機與低功耗喚醒回環(huán)壓測通過后多串口程序才算真正落地。接下來我一般會再做兩件提升可維護(hù)性的事第一把每個串口的協(xié)議解析統(tǒng)一成第 4 章那類狀態(tài)機避免不同串口用不同風(fēng)格的處理邏輯第二預(yù)留一個固定日志串口用分級日志輸出框架運行時能單獨打開某個串口的調(diào)試信息。F091 的資源注定它跑不了復(fù)雜的調(diào)度系統(tǒng)但一套清晰的驅(qū)動分層能讓后續(xù)維護(hù)的人少流很多汗。特別提醒一下低功耗場景如果項目要求休眠時靠串口喚醒F091 的串口喚醒能力需要把對應(yīng)引腳配置成中斷喚醒源同時注意 DMA 在低功耗模式下是否關(guān)閉。這類需求通常只保留一個監(jiān)聽串口把其它串口在休眠前全部去使能才能把功耗壓下去。我自己吃了不少多串口程序的虧后來養(yǎng)成了一個習(xí)慣無論芯片資源多緊張都要先做一張串口分配表再動代碼。表里標(biāo)清楚 8 個口的用途、工作模式、優(yōu)先級和波特率后面所有配置、代碼、排錯都以這張表為準(zhǔn)。這個習(xí)慣幫我避開了絕大多數(shù)“功能全寫完才發(fā)現(xiàn)通道沖突”的血淚場景。希望幫到你。本文還有配套的精品資源點擊獲取