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