簡(jiǎn)介面向STM32嵌入式開(kāi)發(fā)者與上位機(jī)編程愛(ài)好者這份資料圍繞正點(diǎn)原子miniSTM32OV7725攝像頭采集圖像通過(guò)串口將彩色圖片數(shù)據(jù)發(fā)送至PC端并解碼還原為BMP格式進(jìn)行顯示覆蓋數(shù)據(jù)采集、DMA傳輸、BMP編碼、UART發(fā)送與上位機(jī)解析等完整鏈路。壓縮包共499個(gè)文件大小約10.92MB除HAL庫(kù)工程源碼、C語(yǔ)言與匯編文件外還包含多個(gè)上位機(jī)工程模塊、調(diào)試配置腳本及Git版本管理信息便于對(duì)照學(xué)習(xí)與二次開(kāi)發(fā)。已有5785人瀏覽學(xué)習(xí)。通過(guò)學(xué)習(xí)可掌握STM32與OV7725的驅(qū)動(dòng)配置、串口通信協(xié)議設(shè)計(jì)、BMP圖像格式構(gòu)造、以及微控制器與PC間大數(shù)據(jù)量傳輸?shù)墓こ袒幚矸椒ㄟm合需要實(shí)現(xiàn)圖像傳輸或進(jìn)行串口調(diào)試進(jìn)階的開(kāi)發(fā)者。 很多人第一次做“STM32串口發(fā)彩色圖片”這個(gè)需求第一反應(yīng)是把整張圖的數(shù)組用串口發(fā)出去不就完了我第一次也是這么踩進(jìn)去的。結(jié)果在115200波特率下一張320×240的RGB565彩色圖光數(shù)據(jù)量就是153600字節(jié)理論耗時(shí)13秒多中途還因?yàn)榕紶杹G字節(jié)整幀作廢。那時(shí)我才意識(shí)到串口發(fā)一張彩色圖片真正的難點(diǎn)根本不是“發(fā)”這個(gè)動(dòng)作而是怎么在有限帶寬和不可靠的字節(jié)流里把上十萬(wàn)字節(jié)的二進(jìn)制數(shù)據(jù)完整送達(dá)對(duì)端。這篇文章就把我從協(xié)議設(shè)計(jì)、STM32 DMA發(fā)送、上位機(jī)接收解碼到實(shí)戰(zhàn)排坑的完整思路寫(xiě)下來(lái)給正準(zhǔn)備做串口圖傳、攝像頭回傳或者UART二進(jìn)制大數(shù)據(jù)透?jìng)鞯呐笥炎鰝€(gè)參考。如果你是老手可以直接跳到第2節(jié)的協(xié)議和第3節(jié)的代碼框架如果你剛接觸串口建議按順序看每一步我都盡量解釋了為什么這么做。1. 先算筆賬一張彩色圖片到底有多大串口要多長(zhǎng)時(shí)間才能發(fā)完1.1 數(shù)據(jù)量公式很多朋友做串口發(fā)彩色圖片上來(lái)就在串口助手里選個(gè)115200然后到處找“為什么圖片發(fā)不完”。其實(shí)在做通信之前先花半分鐘估算一下數(shù)據(jù)量能省掉后面一大半的煩躁。嵌入式里最常見(jiàn)的彩色圖片格式是RGB565一個(gè)像素用2個(gè)字節(jié)表示高5位紅色、中間6位綠色、低5位藍(lán)色。所以數(shù)據(jù)量公式就是字節(jié)數(shù) 寬度 × 高度 × 2我整理了一個(gè)實(shí)際場(chǎng)景的計(jì)算表波特率按8位數(shù)據(jù)、1位起始位、1位停止位、無(wú)校驗(yàn)的最常見(jiàn)配置來(lái)算有效數(shù)據(jù)速率約為波特率的十分之一分辨率像素?cái)?shù)RGB565大小115200耗時(shí)460800耗時(shí)921600耗時(shí)160×1201920038400字節(jié)約3.3秒約0.83秒約0.42秒320×24076800153600字節(jié)約13.3秒約3.3秒約1.7秒640×480307200614400字節(jié)約53.3秒約13.3秒約6.7秒注意這只是純數(shù)據(jù)負(fù)載的時(shí)間如果像后面那樣在每包加上幀頭、長(zhǎng)度、校驗(yàn)實(shí)際時(shí)間還會(huì)多出5%到10%?？吹竭@個(gè)表你就能理解為什么很多串口圖傳Demo的分辨率都選擇320×240以下——不是STM32存不下而是串口帶寬真的太貴了。115200發(fā)一幀完整圖片要13秒這臺(tái)設(shè)備基本上就被串口占死了單片機(jī)暫時(shí)什么都干不了。1.2 圖片格式的選擇串口發(fā)彩色圖片不是只有RGB565一種選項(xiàng)。我見(jiàn)過(guò)三種常見(jiàn)做法發(fā)BMP位圖STM32讀SD卡或Flash里的BMP文件按文件字節(jié)流透?jìng)?。BMP格式簡(jiǎn)單PC端直接用圖片查看器打開(kāi)缺點(diǎn)是未壓縮數(shù)據(jù)量和RGB565一樣大甚至更大。發(fā)JPEG/JPEG流很多攝像頭模組比如OV2640能直接輸出JPEG數(shù)據(jù)STM32不參與解碼只是把壓縮后的字節(jié)流轉(zhuǎn)發(fā)出去。文件體積小很多同一張320×240的圖可能只有30~50KB串口時(shí)間能縮短一半以上。缺點(diǎn)是STM32側(cè)無(wú)法直接在屏幕上顯示JPEG除非再加軟解庫(kù)。發(fā)RGB565裸數(shù)據(jù)這是嵌入式顯示最常見(jiàn)的格式也是我后面代碼示例的默認(rèn)格式。RGB565可以直接用LCD顯示接收端轉(zhuǎn)成BMP也簡(jiǎn)單適合做“攝像頭采集串口回傳顯示”這類應(yīng)用。如果你只是想把STM32某次調(diào)試產(chǎn)生的截圖傳回電腦看我建議選RGB565裸數(shù)據(jù)像素布局固定、解析邏輯清晰如果你在乎傳輸速度且攝像頭本身輸出JPEG那就直接透?jìng)鱆PEG字節(jié)流STM32連色彩轉(zhuǎn)換都省了。這兩種思路不要混用否則協(xié)議和解析會(huì)變得很別扭。2. 一個(gè)能用的最小分包協(xié)議幀頭、長(zhǎng)度、序號(hào)、校驗(yàn)一個(gè)都不能少2.1 為什么不能像發(fā)字符串一樣發(fā)圖片串口本質(zhì)上是一條字節(jié)流它本身不認(rèn)“消息”“包”這種高層概念。你用printf(hello)能發(fā)字符串是因?yàn)榻邮斩酥肋@一串字符到換行符就結(jié)束了但二進(jìn)制圖片數(shù)據(jù)里什么字節(jié)都可能出現(xiàn)包括0x00、0xFF甚至恰好是換行符。如果你不規(guī)定每一包的邊界接收端根本不知道一張圖從哪里開(kāi)始、到哪里結(jié)束。更麻煩的是串口會(huì)丟字節(jié)。別管CH340還是FT232在高波特率、長(zhǎng)導(dǎo)線、干擾大的環(huán)境下偶爾丟一個(gè)字節(jié)是常態(tài)。沒(méi)有協(xié)議時(shí)丟一個(gè)字節(jié)會(huì)導(dǎo)致后面所有數(shù)據(jù)整體錯(cuò)位整個(gè)文件直接報(bào)廢。所以說(shuō)做串口發(fā)圖片協(xié)議不是可選項(xiàng)而是必選項(xiàng)。2.2 協(xié)議字段定義與三種幀類型我實(shí)際用的協(xié)議非常樸素沒(méi)有上復(fù)雜的數(shù)據(jù)鏈路層框架就是簡(jiǎn)單的手寫(xiě)幀。每個(gè)數(shù)據(jù)包可以統(tǒng)一定義為下面的結(jié)構(gòu)字段長(zhǎng)度說(shuō)明幀頭2字節(jié)固定為0xAA 0x55接收端靠它初步定位類型1字節(jié)0x01開(kāi)始幀、0x02數(shù)據(jù)幀、0x03結(jié)束幀序號(hào)1字節(jié)數(shù)據(jù)幀編號(hào)0~255循環(huán)用于檢測(cè)丟包長(zhǎng)度2字節(jié)本包數(shù)據(jù)區(qū)長(zhǎng)度小端序數(shù)據(jù)N字節(jié)實(shí)際負(fù)載建議256字節(jié)或512字節(jié)校驗(yàn)1字節(jié)對(duì)類型、序號(hào)、長(zhǎng)度、數(shù)據(jù)所有字節(jié)逐字節(jié)異或?yàn)槭裁磶^用0xAA 0x55因?yàn)檫@是個(gè)比較特殊的高低交替序列接收端容易在字節(jié)流里認(rèn)出來(lái)。但說(shuō)實(shí)話如果你的數(shù)據(jù)里恰好連續(xù)出現(xiàn)0xAA 0x55確實(shí)可能誤判所以光靠幀頭不行還必須結(jié)合長(zhǎng)度字段和校驗(yàn)來(lái)判斷找到疑似幀頭后先解析出長(zhǎng)度再校驗(yàn)如果校驗(yàn)不過(guò)就退回一個(gè)字節(jié)繼續(xù)找。這個(gè)“不信任幀頭、信任校驗(yàn)”的思路是二進(jìn)制串口協(xié)議的通用基礎(chǔ)。整個(gè)傳輸流程分成三種幀開(kāi)始幀負(fù)載前4字節(jié)是圖片寬度和高度各2字節(jié)后面可以帶總包數(shù)、總字節(jié)數(shù)。接收端收到開(kāi)始幀后為拼接緩沖分配空間知道接下來(lái)要收多少包。數(shù)據(jù)幀每個(gè)包攜帶256字節(jié)圖片數(shù)據(jù)序號(hào)從0開(kāi)始累加。接收端根據(jù)序號(hào)把數(shù)據(jù)寫(xiě)入到緩沖的對(duì)應(yīng)偏移處這樣就算中間丟了某一包也能立刻發(fā)現(xiàn)。結(jié)束幀負(fù)載可以放一個(gè)簡(jiǎn)單的CRC或者固定標(biāo)志接收端收到結(jié)束幀并確認(rèn)該收的包都齊了就觸發(fā)顯示/保存流程。如果發(fā)現(xiàn)丟包可以在這個(gè)時(shí)間點(diǎn)申請(qǐng)重傳。2.3 發(fā)送狀態(tài)機(jī)從IDLE到SEND_END發(fā)送端我建議用狀態(tài)機(jī)而不是用一層層嵌套循環(huán)去連續(xù)發(fā)。狀態(tài)劃分很簡(jiǎn)單IDLE - SEND_START - SEND_DATA_x - SEND_END - IDLE每個(gè)狀態(tài)對(duì)應(yīng)發(fā)送一種幀。SEND_DATA_x實(shí)際上是重復(fù)發(fā)送若干次的子狀態(tài)每發(fā)送完一包序號(hào)加1并更新到下一包。用狀態(tài)機(jī)的好處是方便和DMA中斷配合DMA發(fā)送完成中斷里把狀態(tài)切換一下主循環(huán)只管檢查狀態(tài)該發(fā)下一包就發(fā)下一包收發(fā)邏輯非常清晰。后面第3節(jié)我會(huì)給出代碼框架。3. STM32端怎么發(fā)DMA、全局緩沖區(qū)和發(fā)送完成回調(diào)的配合3.1 數(shù)據(jù)源攝像頭、SD卡文件還是內(nèi)存數(shù)組做串口發(fā)圖片之前必須先明確圖片數(shù)據(jù)在哪里。常見(jiàn)三種來(lái)源攝像頭DMA采集到內(nèi)存數(shù)組比如OV2640輸出的RGB565幀通過(guò)DCMI接口存進(jìn)一段連續(xù)內(nèi)存。發(fā)送時(shí)按固定大小從數(shù)組里切塊放到串口DMA緩沖區(qū)。SD卡/Flash里的文件從文件系統(tǒng)讀出一塊BMP或JPEG數(shù)據(jù)再放入發(fā)送緩沖區(qū)。這時(shí)要注意文件系統(tǒng)的扇區(qū)緩沖和串口發(fā)送緩沖之間要復(fù)制不能直接讓DMA操作文件系統(tǒng)內(nèi)部指針。固定生成的測(cè)試圖案調(diào)通信鏈路時(shí)最好用不依賴攝像頭方便對(duì)比花屏問(wèn)題。不管哪種來(lái)源我都建議抽象成一個(gè)“取下一塊數(shù)據(jù)”的回調(diào)函數(shù)上層邏輯只知道每包要發(fā)256字節(jié)數(shù)據(jù)具體從攝像頭、SD卡還是內(nèi)存數(shù)組來(lái)對(duì)發(fā)送邏輯是透明的。這樣換攝像頭、換分辨率都會(huì)方便很多。3.2 DMA發(fā)送代碼框架用全局包結(jié)構(gòu)體避坑我用的HAL庫(kù)代碼大致長(zhǎng)這樣。先定義包結(jié)構(gòu)#define IMG_PKG_DATA_LEN 256 #define PKG_HEADER0 0xAA #define PKG_HEADER1 0x55 typedef enum { PKG_TYPE_START 0x01, PKG_TYPE_DATA 0x02, PKG_TYPE_END 0x03 } PkgType; typedef struct { uint8_t head[2]; uint8_t type; uint8_t seq; uint8_t len_low; uint8_t len_high; uint8_t data[IMG_PKG_DATA_LEN]; uint8_t checksum; } ImgPacket;注意這里我用的是小端長(zhǎng)度字節(jié)序STM32是小端處理器直接這樣定義結(jié)構(gòu)體、按字節(jié)發(fā)送是自然匹配的。如果接收端是上位機(jī)程序也需要按小端解析。然后是發(fā)送控制部分static ImgPacket tx_pkt; static volatile uint8_t tx_busy 0; static uint8_t pkg_seq 0; void UART_SendOnePacket(ImgPacket *pkt, uint16_t total_len) { tx_busy 1; HAL_UART_Transmit_DMA(huart1, (uint8_t *)pkt, total_len); } void HAL_UART_TxCpltCallback(UART_HandleTypeDef *huart) { if (huart-Instance USART1) { tx_busy 0; } }使用DMA發(fā)送時(shí)最關(guān)鍵的一個(gè)坑是tx_pkt必須是全局或靜態(tài)變量不能是函數(shù)里的局部變量。IAR和KEIL在優(yōu)化情況下局部變量不是立刻消失但DMA傳輸是異步的函數(shù)返回后這塊棧內(nèi)存隨時(shí)可能被其他邏輯覆蓋最終發(fā)出去的就是一堆被改過(guò)的數(shù)據(jù)。我一開(kāi)始就是因?yàn)橥祽邪寻Y(jié)構(gòu)體定義在函數(shù)內(nèi)部結(jié)果發(fā)出來(lái)的數(shù)據(jù)偶爾正常偶爾錯(cuò)亂排查了很久才發(fā)現(xiàn)是這個(gè)原因。完整的發(fā)送圖片幀偽代碼如下void SendImageFrame(uint16_t width, uint16_t height, uint8_t *img_buf, uint32_t img_size) { // 1. 填充并發(fā)送開(kāi)始幀 tx_pkt.type PKG_TYPE_START; tx_pkt.data[0] width 0xFF; tx_pkt.data[1] width 8; tx_pkt.data[2] height 0xFF; tx_pkt.data[3] height 8; tx_pkt.len_low 4; tx_pkt.len_high 0; UART_SendOnePacket(tx_pkt, 11); // 幀頭2 類型1 序號(hào)1 長(zhǎng)度2 數(shù)據(jù)4 校驗(yàn)1 // 2. 循環(huán)發(fā)送數(shù)據(jù)幀 pkg_seq 0; uint32_t offset 0; while (offset img_size) { while (tx_busy); // 等上一包DMA發(fā)完 uint16_t len (img_size - offset IMG_PKG_DATA_LEN) ? IMG_PKG_DATA_LEN : (uint16_t)(img_size - offset); tx_pkt.type PKG_TYPE_DATA; tx_pkt.seq pkg_seq; tx_pkt.len_low len 0xFF; tx_pkt.len_high len 8; memcpy(tx_pkt.data, img_buf offset, len); UART_SendOnePacket(tx_pkt, 2 1 1 2 len 1); offset len; } // 3. 發(fā)送結(jié)束幀 while (tx_busy); tx_pkt.type PKG_TYPE_END; tx_pkt.len_low 0; tx_pkt.len_high 0; UART_SendOnePacket(tx_pkt, 7); // 幀頭2 類型1 序號(hào)1 長(zhǎng)度2 校驗(yàn)1 }這個(gè)版本用的是阻塞等tx_busy清零簡(jiǎn)單直觀。如果想要更高的吞吐可以把“等待發(fā)完”改成“在回調(diào)里觸發(fā)下一包發(fā)送”吞吐能提升一些但邏輯會(huì)稍微繞。對(duì)串口這個(gè)速度級(jí)別來(lái)說(shuō)阻塞等DMA實(shí)際上CPU占用率并不高大多數(shù)時(shí)候都在等外設(shè)所以我的經(jīng)驗(yàn)是先用簡(jiǎn)單的輪詢等待調(diào)通了再優(yōu)化不遲。3.3 雙緩沖為什么單緩沖發(fā)圖像早晚會(huì)花屏如果你的圖片數(shù)據(jù)是一邊采集一邊發(fā)送比如攝像頭連續(xù)出幀那單緩沖肯定扛不住DMA還沒(méi)把某一包發(fā)完攝像頭DMA就已經(jīng)把下一幀覆蓋到同一塊內(nèi)存里了發(fā)出去的數(shù)據(jù)自然就花了。解決方案是準(zhǔn)備兩塊緩沖區(qū)攝像頭DMA往A緩沖填充時(shí)串口DMA從B緩沖發(fā)送等攝像頭填完A切換去填B串口再發(fā)A。乒乓切換各不干擾。雙緩沖的關(guān)鍵是兩塊緩沖區(qū)都要是全局?jǐn)?shù)組并且在切換前確認(rèn)對(duì)方已經(jīng)用完。用標(biāo)志位或者DMA回調(diào)計(jì)數(shù)都能實(shí)現(xiàn)。很多圖像庫(kù)/攝像頭庫(kù)本身會(huì)做這樣的雙緩沖但如果你是自己從攝像頭原始數(shù)據(jù)流里切塊發(fā)送就一定要注意這個(gè)問(wèn)題。4. 上位機(jī)怎么收從串口助手到Python協(xié)議解析4.1 直接用串口助手看HEX大圖不現(xiàn)實(shí)串口發(fā)圖片給PC很多人第一時(shí)間打開(kāi)串口助手開(kāi)啟十六進(jìn)制顯示然后看著滿屏的0xAA 0x55暈過(guò)去。幾十萬(wàn)字節(jié)的數(shù)據(jù)靠人眼根本無(wú)法校驗(yàn)手動(dòng)復(fù)制更是扯淡。如果只是驗(yàn)證STM32有沒(méi)有發(fā)出數(shù)據(jù)用串口助手看看HEX收到的大致字節(jié)數(shù)夠不夠倒是可以的。XCOM、SSCOM這類工具一般都有“保存接收數(shù)據(jù)”的功能可以把原始二進(jìn)制流完整存成文件再離線寫(xiě)腳本解析。但要注意有些串口助手會(huì)在接收數(shù)據(jù)里插入接收時(shí)間戳或者按文本模式過(guò)濾字節(jié)這些都會(huì)破壞二進(jìn)制數(shù)據(jù)完整性保存前一定要看清楚設(shè)置。真正做項(xiàng)目時(shí)我還是推薦直接用Python寫(xiě)一個(gè)小工具一邊收一邊解析靈活得多。4.2 用Python按協(xié)議收?qǐng)D并保存的解析循環(huán)Python的pyserial庫(kù)是串口上位機(jī)的主流選擇。核心思路是維護(hù)一個(gè)不斷增長(zhǎng)的接收緩沖然后循環(huán)做三件事找?guī)^、解析長(zhǎng)度、校驗(yàn)。下面是一個(gè)可運(yùn)行的解析骨架配合前面STM32端的協(xié)議import serial import struct ser serial.Serial(COM3, 921600, timeout0.1) buf b image_data b while True: buf ser.read(512) while True: idx buf.find(b\xAA\x55) if idx 0: # 找不到幀頭只保留最后一個(gè)字節(jié)防止幀頭跨包 buf buf[-1:] break if len(buf) - idx 6: break pkg_type buf[idx 2] seq buf[idx 3] length struct.unpack(H, buf[idx 4:idx 6])[0] if len(buf) - idx 6 length 1: break payload buf[idx 6:idx 6 length] checksum buf[idx 6 length] calc pkg_type ^ seq ^ (length 0xFF) ^ (length 8) for b in payload: calc ^ b if calc ! checksum: buf buf[idx 1:] continue if pkg_type 0x01: # 開(kāi)始幀 width, height struct.unpack(HH, payload[:4]) image_data b elif pkg_type 0x02: # 數(shù)據(jù)幀 image_data payload elif pkg_type 0x03: # 結(jié)束幀 print(f收到一幀: {len(image_data)} 字節(jié)) with open(image.rgb565, wb) as f: f.write(image_data) buf buf[idx 6 length 1:]這套循環(huán)需要注意幾個(gè)細(xì)節(jié)ser.read(512)一次讀不到一包很正常所以外層循環(huán)要一直讀內(nèi)層循環(huán)要把緩沖里所有完整包都解析完。找不到幀頭時(shí)不能直接把緩沖清空要保留最后一個(gè)字節(jié)。否則幀頭正好被前一次讀取切在末尾時(shí)就會(huì)漏掉導(dǎo)致整個(gè)圖接不上。校驗(yàn)失敗時(shí)從idx 1重新找而不是從idx 2因?yàn)楫?dāng)前幀頭可能是數(shù)據(jù)里碰巧出現(xiàn)的假幀頭下一字節(jié)才可能是真正的幀頭。這個(gè)腳本雖然丑但作為調(diào)試工具完全夠用。實(shí)際項(xiàng)目里可以把“搜幀頭、解析包、處理包”抽成獨(dú)立的類方便加超時(shí)、重傳、日志等邏輯。4.3 RGB565轉(zhuǎn)BMP大小端和數(shù)據(jù)對(duì)齊的細(xì)節(jié)如果傳輸?shù)氖荝GB565裸數(shù)據(jù)上位機(jī)收到后還不能直接當(dāng)圖片顯示要轉(zhuǎn)成PC常見(jiàn)的RGB888格式。轉(zhuǎn)換的核心是每個(gè)像素2字節(jié)按低字節(jié)在前組合from PIL import Image def rgb565_to_image(data, width, height): img Image.new(RGB, (width, height)) for y in range(height): for x in range(width): offset (y * width x) * 2 lo data[offset] hi data[offset 1] pixel (hi 8) | lo r (pixel 11) 0x1F g (pixel 5) 0x3F b pixel 0x1F img.putpixel((x, y), (r 3, g 2, b 3)) return img這里有個(gè)非常容易踩的坑如果STM32發(fā)送時(shí)直接發(fā)內(nèi)存里的uint16_t數(shù)組串口外設(shè)按字節(jié)從低地址開(kāi)始發(fā)送所以低字節(jié)在前。接收端也必須按低字節(jié)在前解析。如果你在協(xié)議里規(guī)定了大端序發(fā)送前就需要把高低字節(jié)交換。兩種都可以但兩端必須一致。我見(jiàn)過(guò)不少所謂的“花屏”最后查到底不是數(shù)據(jù)丟包而是大小端寫(xiě)反了顏色通道全部錯(cuò)位。5. 實(shí)際調(diào)試中我踩過(guò)的四個(gè)大坑每一個(gè)都值得你繞開(kāi)5.1 DMA發(fā)送函數(shù)連續(xù)調(diào)用板子直接HardFault第一次寫(xiě)串口DMA發(fā)送時(shí)我在主循環(huán)里連續(xù)調(diào)用HAL_UART_Transmit_DMA來(lái)發(fā)多包數(shù)據(jù)邏輯上想著“發(fā)完一包再發(fā)下一包”但完全沒(méi)有判斷傳輸是否完成的意識(shí)。實(shí)際運(yùn)行起來(lái)第二次調(diào)用的返回碼是HAL_BUSY因?yàn)樯弦淮蜠MA還沒(méi)結(jié)束。如果無(wú)視返回值強(qiáng)行調(diào)用輕則數(shù)據(jù)錯(cuò)亂重則觸發(fā)HardFault或者其他外設(shè)異常。解決方式就是第3節(jié)的tx_busy標(biāo)志。每次調(diào)用前檢查tx_busy或者檢查HAL_UART_GetState(huart1)是否等于HAL_UART_STATE_READY。另外可以在回調(diào)里給一個(gè)計(jì)數(shù)值主循環(huán)通過(guò)計(jì)數(shù)差判斷DMA發(fā)完了多少包這樣既能判斷空閑又能統(tǒng)計(jì)數(shù)據(jù)吞吐量。5.2 高波特率下的丟字節(jié)CH340、FT232還是邏輯分析儀波特率不是想開(kāi)多高就開(kāi)多高。我實(shí)測(cè)手頭幾款USB轉(zhuǎn)串口模塊CH340在460800以下表現(xiàn)穩(wěn)定到921600大部分也還行但偶爾會(huì)有丟字節(jié)FT232系列到921600通常更穩(wěn)但也要看具體板子設(shè)計(jì)和驅(qū)動(dòng)版本。遇到丟字節(jié)先不要急著改代碼按下面步驟排查把波特率降到460800再測(cè)如果問(wèn)題消失說(shuō)明是極限波特率下的電氣問(wèn)題。檢查USB轉(zhuǎn)串口模塊到STM32的連線長(zhǎng)度杜邦線盡量控制在10cm以內(nèi)并避開(kāi)電機(jī)、繼電器這類干擾源。用邏輯分析儀抓RX/TX波形人工數(shù)一數(shù)一幀里有沒(méi)有少字節(jié)確認(rèn)是發(fā)送端還是接收端在丟。檢查STM32時(shí)鐘配置是否真的讓串口跑在了目標(biāo)波特率注意如果使用內(nèi)部RC振蕩器高頻波特率的誤差會(huì)放大盡量用外部晶振。不要以為115200就100%可靠波特率誤差、兩路設(shè)備的工作電壓差異都會(huì)造成偶發(fā)錯(cuò)位。協(xié)議里的重傳機(jī)制永遠(yuǎn)是最后的兜底方案。5.3 斷包錯(cuò)位后的自動(dòng)同步機(jī)制串口通信最難受的場(chǎng)景是接收端一上電發(fā)送端可能已經(jīng)發(fā)了一半圖片此時(shí)接收端不知道幀頭在哪后續(xù)包全部按錯(cuò)位解析。我遇到過(guò)好幾次現(xiàn)象是“前幾張圖正常重連后第一張永遠(yuǎn)花屏”。解決辦法就是4.2節(jié)里寫(xiě)的“持續(xù)搜索幀頭校驗(yàn)回退”邏輯。接收端一旦失步就一個(gè)字節(jié)一個(gè)字節(jié)地移動(dòng)搜索窗口直到某一包通過(guò)校驗(yàn)恢復(fù)同步。這時(shí)由于序號(hào)是連續(xù)的接收端能立刻算出丟了多少包從而決定是申請(qǐng)重傳還是直接放棄當(dāng)前幀等待下一幀。這里要注意應(yīng)用層的超時(shí)和重傳要結(jié)合具體場(chǎng)景設(shè)計(jì)如果是實(shí)時(shí)的攝像頭預(yù)覽丟了就丟了等下一幀更合理如果是傳輸一張關(guān)鍵照片那必須等到完整幀才顯示。5.4 明明數(shù)據(jù)完整畫(huà)面卻花屏錯(cuò)亂大小端與行對(duì)齊最后這個(gè)大坑最隱蔽。數(shù)據(jù)全都在校驗(yàn)也都對(duì)但顯示出來(lái)的圖像要么顏色詭異要么整幅圖斜著切了幾條線。顏色詭異八成是RGB565大小端問(wèn)題整幅圖斜切則要檢查數(shù)據(jù)流里是否每一行都有行對(duì)齊填充。比如說(shuō)RGB565裸數(shù)據(jù)每行字節(jié)數(shù)如果是奇數(shù)而某些顯示庫(kù)會(huì)按4字節(jié)對(duì)齊逐行存儲(chǔ)就會(huì)導(dǎo)致每一行錯(cuò)開(kāi)幾個(gè)字節(jié)。串口發(fā)送的時(shí)候必須和接收端的行寬約定一致發(fā)送方按“一行一行掃過(guò)去”的順序發(fā)接收方按同樣順序拼回。我個(gè)人調(diào)試這類問(wèn)題最有效的方法是先用純色測(cè)試圖比如整幀紅色、整幀藍(lán)色走一遍鏈路。如果純色都出現(xiàn)一道道異常條紋那就不是圖像內(nèi)容問(wèn)題而是行對(duì)齊或者分辨率約定不一致如果純色正常、復(fù)雜圖像花才懷疑到數(shù)據(jù)搬運(yùn)和壓縮環(huán)節(jié)。這個(gè)排查順序能幫你快速縮小問(wèn)題范圍。最后再分享一個(gè)我習(xí)慣的做法跑串口圖傳時(shí)先開(kāi)一個(gè)160×120的小分辨率把協(xié)議、換算、顯示鏈路全部跑通再一步步把分辨率拉上去。每次重新燒錄后讓STM32復(fù)位后主動(dòng)發(fā)一張完整測(cè)試圖PC端記錄收到首包和末包的時(shí)間和表里的理論值對(duì)比立刻就能判斷出波特率、DMA配置是否正常。串口發(fā)彩色圖片這件事原理不復(fù)雜但把數(shù)據(jù)量、協(xié)議、DMA緩沖、上位機(jī)解析這幾個(gè)環(huán)節(jié)串起來(lái)之后任何一個(gè)地方出錯(cuò)都會(huì)讓屏幕給你臉色看。我最初花了一晚上在花屏里打轉(zhuǎn)最后打印出協(xié)議字段才發(fā)現(xiàn)是大小端反了。希望這篇能幫你少踩幾個(gè)坑早點(diǎn)把完整圖像從板子上“送”出來(lái)。本文還有配套的精品資源點(diǎn)擊獲取