簡介本資源是一套面向嵌入式開發(fā)工程師與STM32進(jìn)階學(xué)習(xí)者的硬件JPEG解碼實(shí)戰(zhàn)方案專為STM32H743及同系列MCU設(shè)計(jì)解決高性能圖像解碼中CPU負(fù)載高、實(shí)時(shí)性差等痛點(diǎn)適用于智能顯示終端、工業(yè)HMI、視覺前端預(yù)處理等場景。壓縮包共226個(gè)文件含112個(gè)頭文件.h定義寄存器映射與接口規(guī)范86個(gè)源文件.c實(shí)現(xiàn)IPU初始化、JPEG參數(shù)配置、DMA數(shù)據(jù)搬運(yùn)及中斷管理等核心邏輯另有PNG圖像資源、工程配置文件uvprojx/uvoptx、編譯輸出hex/lib及說明文檔txt/xls整體大小2.94MB。已有136人下載學(xué)習(xí)提供開箱即用的寄存器級驅(qū)動(dòng)代碼覆蓋tjpgd兼容解碼流程、LCD顯示適配lcd.c、SD卡圖像加載sdmmc_sdcard.c等完整鏈路目錄結(jié)構(gòu)按外設(shè)模塊與功能分層組織便于理解IPU與系統(tǒng)總線協(xié)同機(jī)制并快速移植至其他H7型號。 去年做一塊帶屏的交互設(shè)備主控選了STM32H743UI框架跑起來之后發(fā)現(xiàn)一個(gè)很現(xiàn)實(shí)的問題屏幕要顯示遠(yuǎn)程下發(fā)的JPEG圖片一張1080P的照片用軟件解碼在480MHz的主頻下也要吃掉大幾十毫秒轉(zhuǎn)場動(dòng)畫直接掉幀。后來翻參考手冊才發(fā)現(xiàn)H7系列內(nèi)部集成了一個(gè)硬件JPEG編解碼外設(shè)專門干這個(gè)活兒的官方數(shù)據(jù)解一張1080P基準(zhǔn)JPEG只需要十幾毫秒。這個(gè)外設(shè)平時(shí)用的人不多大部分項(xiàng)目要么用HAL庫套一下要么直接塞軟解庫真正把它性能榨干的多是寄存器級驅(qū)動(dòng)。這篇就圍繞STM32H743的硬件JPEG解碼展開完整走一遍寄存器驅(qū)動(dòng)的實(shí)現(xiàn)思路從原理到代碼再到排坑適合正在做圖像顯示、圖傳解析或者對解碼延遲敏感的朋友。1. 項(xiàng)目背景與方案選型1.1 需求來源軟解太慢硬解是剛需先說清楚這個(gè)項(xiàng)目的真實(shí)痛點(diǎn)不然你不知道為什么非要折騰寄存器。當(dāng)時(shí)設(shè)備需求是通過以太網(wǎng)接收服務(wù)器下發(fā)的JPEG圖片解碼后顯示在800x480的RGB屏上要求連續(xù)翻頁時(shí)畫面流暢單張解碼延遲不能影響界面響應(yīng)。最開始圖省事直接上了TinyJPEG軟解庫。STM32H743的Cortex-M7雖然主頻拉到480MHz還有雙精度FPU但JPEG解碼要跑大量離散余弦逆變換和反量化運(yùn)算不是純算力能輕松扛住的。實(shí)測一張640x480的JPEG解碼時(shí)間大約在80到120ms之間跟壓縮質(zhì)量有關(guān)這個(gè)速度在靜態(tài)顯示場景下可接受但一旦要做輪播圖、相冊切換肉眼可見的卡頓就來了。后來翻了一遍STM32H743參考手冊發(fā)現(xiàn)JPEG Codec這個(gè)外設(shè)被完全忽略了它支持硬件的JPEG編碼和解碼內(nèi)部自帶DCT、量化、哈夫曼編解碼單元理論上能把解碼耗時(shí)壓到軟件解法的十分之一甚至更低。這就是項(xiàng)目方案轉(zhuǎn)向硬件解碼的直接原因。1.2 為什么選擇寄存器庫驅(qū)動(dòng)而非HAL市面上大部分H7的JPEG例子是基于HAL庫的工程里cubeMX生成一堆初始化代碼用起來確實(shí)方便。但我在這個(gè)項(xiàng)目里選擇寄存器庫驅(qū)動(dòng)主要有三個(gè)考慮代碼體積和內(nèi)存占用更可控。這個(gè)設(shè)備的內(nèi)存規(guī)劃比較緊湊HAL庫的JPEG驅(qū)動(dòng)層要實(shí)例化不少結(jié)構(gòu)體數(shù)據(jù)緩沖管理也不夠透明寄存器方式可以把每個(gè)中間環(huán)節(jié)都精確到字節(jié)。調(diào)試時(shí)能直接看寄存器狀態(tài)。HAL庫把很多狀態(tài)封裝成了結(jié)構(gòu)體出問題時(shí)你還要去翻結(jié)構(gòu)體成員寄存器驅(qū)動(dòng)則直接看JPEG_SR、JPEG_CR這些寄存器實(shí)時(shí)性最強(qiáng)。硬解流程本身就是一個(gè)狀態(tài)機(jī)用寄存器操作更符合直覺。后面你會(huì)看到JPEG硬件解碼其實(shí)就是配置幾個(gè)地址、啟動(dòng)DMA、輪詢中斷標(biāo)志這個(gè)流程用寄存器寫反而比HAL干凈。當(dāng)然寄存器驅(qū)動(dòng)對參考手冊的熟悉度要求高尤其是JPEG外設(shè)這邊寄存器數(shù)量不算多但每個(gè)位的含義必須精準(zhǔn)。其實(shí)只要把外設(shè)結(jié)構(gòu)體映射到地址上CPU直接訪問寄存器順序和邏輯比HAL回調(diào)清楚得多。1.3 硬件平臺(tái)與資源評估項(xiàng)目主控是STM32H743VIT6512KB SRAM加1MB緊耦合RAM分DTCM和ITCM外部掛了一顆W9825G6KH32MB SDRAM16位帶寬。JPEG解碼輸出幀緩沖區(qū)放在SDRAM里避免擠占片內(nèi)SRAM。運(yùn)行頻率取480MHz這個(gè)必須用H7的電源管理配置才能跑到否則默認(rèn)只有400MHz。JPEG外設(shè)的時(shí)鐘來自內(nèi)核總線480MHz下硬件解碼速度會(huì)好不少。DMA用的是DMA2支持32位傳輸配合JPEG外設(shè)的輸入輸出FIFO可以做到壓縮碼流和原始像素?cái)?shù)據(jù)流全程不經(jīng)過CPU。總結(jié)一下方案選型的邏輯圖像數(shù)據(jù)量大、解碼頻繁、延遲敏感的場景硬件JPEG解碼是優(yōu)先選擇在Embedded Python、LVGL等UI框架下搭配使用更是常見。2. STM32H743硬件JPEG解碼原理2.1 JPEG Codec內(nèi)部流程拆解STM32H743的JPEG外設(shè)本質(zhì)上是一個(gè)完整的JPEG編解碼協(xié)處理器。你在應(yīng)用層給它一段符合JPEG標(biāo)準(zhǔn)的碼流它內(nèi)部會(huì)按這個(gè)流水線工作輸入壓縮數(shù)據(jù)、熵解碼哈夫曼解碼、反量化、反向離散余弦變換IDCT、色彩空間轉(zhuǎn)換最后輸出YUV或RGB原始像素?cái)?shù)據(jù)。這里要重點(diǎn)理解硬件只接受baseline JPEG不支持progressive JPEG漸進(jìn)式JPEG這個(gè)限制直接決定了你上位機(jī)圖片處理策略后面排坑還會(huì)展開。由于硬件內(nèi)部集成了哈夫曼解碼表管理單元你需要把JPEG文件里攜帶的量化表、哈夫曼表按指定格式填入寄存器和內(nèi)存表區(qū)域硬件解碼時(shí)才能正確還原數(shù)據(jù)。外設(shè)框圖可以拆成四個(gè)主要模塊輸入FIFO與位流解析器負(fù)責(zé)從內(nèi)存讀取壓縮數(shù)據(jù)并解析JPEG標(biāo)記。哈夫曼解碼器支持標(biāo)準(zhǔn)的DC表和AC表最多4個(gè)哈夫曼表。反量化和IDCT運(yùn)算單元8x8像素塊級別的行列變換。輸出FIFO與像素格式轉(zhuǎn)換器把解碼后的YCbCr數(shù)據(jù)按配置規(guī)則輸出。解碼過程中CPU主要做配置和表加載數(shù)據(jù)通路由外設(shè)自動(dòng)完成。配合DMA搬運(yùn)整個(gè)解碼過程CPU占用極低。2.2 關(guān)鍵控制寄存器映射寄存器庫驅(qū)動(dòng)就是直接操作這些寄存器的所以先列幾個(gè)關(guān)鍵地址偏移便于后面對照。JPEG外設(shè)基址在H7系列上一般是0x5200_6000個(gè)別型號有差異以參考手冊為準(zhǔn)。JPEG_CR偏移0x00控制寄存器配置啟動(dòng)/停止、中斷使能、解碼編碼模式。JPEG_SR偏移0x04狀態(tài)寄存器顯示FIFO狀態(tài)、解碼完成、錯(cuò)誤標(biāo)志。JPEG_CONFR0偏移0x30編碼配置寄存器用于編碼模式配置UV采樣格式。JPEG_CONFR1偏移0x34解碼配置寄存器用于寫入解碼后圖像的總像素?cái)?shù)。JPEG_QUAD偏移0x38量化表地址寄存器32位對齊的內(nèi)存地址。JPEG_HURM偏移0x3C哈夫曼表地址寄存器。JPEG_PDIR偏移0x40像素?cái)?shù)據(jù)輸入寄存器CPU或DMA寫入壓縮數(shù)據(jù)。JPEG_PDOUTR偏移0x44像素?cái)?shù)據(jù)輸出寄存器CPU或DMA讀取解碼數(shù)據(jù)。JPEG_DNTR偏移0x48已解碼數(shù)據(jù)字節(jié)數(shù)寄存器。注意配置這些寄存器最需要注意的是某些寄存器只允許在JPEG外設(shè)停止?fàn)顟B(tài)下修改比如CONFR1、QUAD和HURM如果不解碼流程就直接配置會(huì)導(dǎo)致數(shù)據(jù)錯(cuò)亂。2.3 為何能做到低CPU占用從原理上講硬件解碼的低延遲來自兩方面。首先是數(shù)據(jù)通路完全繞過CPU壓縮數(shù)據(jù)由DMA從內(nèi)存搬運(yùn)到JPEG輸入FIFO解碼后的像素?cái)?shù)據(jù)由另一個(gè)DMA從輸出FIFO搬回內(nèi)存CPU只在中途填充/讀取少量數(shù)據(jù)時(shí)介入。其次是DCT和哈夫曼解碼由專用硬件運(yùn)算單元完成不需要CPU執(zhí)行逐像素的循環(huán)從指令級省掉了上百萬次乘加運(yùn)算。舉個(gè)例子解碼一張800x480的JPEG如果軟件解碼需要做大約50萬次8x8塊的IDCT運(yùn)算一次IDCT涉及上百次乘加硬件只要幾百微秒就能完成。這也是為什么硬件JPEG解碼在H7系列上幾乎成為高分辨率圖像顯示的標(biāo)配能力。3. 寄存器驅(qū)動(dòng)整體架構(gòu)設(shè)計(jì)3.1 外設(shè)基地址與驅(qū)動(dòng)文件結(jié)構(gòu)寄存器庫驅(qū)動(dòng)的核心就是建立一個(gè)與外設(shè)寄存器映射對應(yīng)的結(jié)構(gòu)體然后通過指針訪問。工程中我建議新建jpeg_drv.h和jpeg_drv.c兩個(gè)文件頭文件里只暴露接口源文件里保存寄存器細(xì)節(jié)。驅(qū)動(dòng)代碼第一步先定義外設(shè)寄存器結(jié)構(gòu)體typedef struct { volatile uint32_t CR; /* 0x00 */ volatile uint32_t SR; /* 0x04 */ uint32_t RESERVED0[10]; /* 0x08 - 0x2C */ volatile uint32_t CONFR0; /* 0x30 */ volatile uint32_t CONFR1; /* 0x34 */ volatile uint32_t QUAD; /* 0x38 */ volatile uint32_t HURM; /* 0x3C */ volatile uint32_t PDIR; /* 0x40 */ volatile uint32_t PDOUTR; /* 0x44 */ volatile uint32_t DNTR; /* 0x48 */ } JPEG_TypeDef;基址可以直接用宏定義#define JPEG_BASE_ADDR 0x52006000UL #define JPEG ((JPEG_TypeDef *)JPEG_BASE_ADDR)在寄存器庫工程里你已經(jīng)有了系統(tǒng)頭文件定義的JPEG類型但自己寫結(jié)構(gòu)體可以保證不依賴HAL方便移植到別的H7型號上。另外需要定義狀態(tài)碼和錯(cuò)誤碼方便上層判斷#define JPEG_OK 0 #define JPEG_ERR_PARAM -1 #define JPEG_ERR_TIMEOUT -2 #define JPEG_ERR_FORMAT -33.2 驅(qū)動(dòng)接口分層思路整個(gè)驅(qū)動(dòng)拆成三層底層是寄存器操作封裝中間層負(fù)責(zé)JPEG文件頭解析、硬件表加載、DMA啟動(dòng)上層是給應(yīng)用調(diào)用的解碼接口。底層寄存器操作不外乎set/clear/read幾個(gè)內(nèi)聯(lián)函數(shù)后面代碼會(huì)體現(xiàn)。重點(diǎn)在中間層我設(shè)計(jì)了四個(gè)關(guān)鍵接口jpeg_parse_header()解析JPEG文件頭提取尺寸、量化表、哈夫曼表。jpeg_load_tables()將量化表和哈夫曼表寫入內(nèi)存表區(qū)并配置QUAD和HURM寄存器。jpeg_config_decompress()配置解碼模式、總像素?cái)?shù)、輸出像素格式。jpeg_start_decode()啟動(dòng)DMA和外設(shè)進(jìn)入解碼流程。完成中斷用DMA的回調(diào)通知上層或者在一個(gè)RTOS任務(wù)里輪詢信號量。裸機(jī)環(huán)境下可以輪詢JPEG_SR中的完成位。3.3 內(nèi)存緩沖區(qū)規(guī)劃JPEG解碼要準(zhǔn)備三種緩沖區(qū)輸入緩沖區(qū)存放從文件系統(tǒng)讀出的整個(gè)JPEG文件數(shù)據(jù)建議放SDRAM大小根據(jù)最大圖片規(guī)格本工程分配128KB。量化表和哈夫曼表緩沖區(qū)這個(gè)可以直接放在SRAM32位對齊大小約2KB用于解碼時(shí)給硬件查詢。輸出緩沖區(qū)存放解碼后的原始像素?cái)?shù)據(jù)。800x480的RGB888需要約1.15MB這個(gè)必須放SDRAM。如果輸出RGB565可以壓縮到約768KB但需要硬件或軟件做像素格式轉(zhuǎn)換。實(shí)際項(xiàng)目里輸出緩沖區(qū)使用率最高建議在SDRAM里一次性劃分避免動(dòng)態(tài)分配。在H7上JPEG外設(shè)要求這些緩沖區(qū)的地址是32位對齊的這一點(diǎn)務(wù)必檢查。4. 核心解碼流程實(shí)現(xiàn)4.1 JPEG文件頭解析的細(xì)節(jié)處理解碼的第一步是解析JPEG文件頭。JPEG文件由SOI標(biāo)記(0xFFD8)開始到EOI(0xFFD9)結(jié)束中間穿插各類標(biāo)記段。硬件JPEG外設(shè)本身不處理文件頭需要軟件把尺寸、量化表、哈夫曼表提取出來然后填入外設(shè)要求的位置。一個(gè)baseline JPEG常見的標(biāo)記有SOF00xFFC0基線幀標(biāo)記包含圖像寬度、高度、分量數(shù)、采樣因子。DQT0xFFDB量化表定義可能包含多張表。DHT0xFFC4哈夫曼表定義包含DC表和AC表。SOS0xFFDA掃描開始包含各分量的表選擇。DRI0xFFDD重啟間隔增量編碼用。解析時(shí)建議用一個(gè)循環(huán)掃描標(biāo)記static int jpeg_scan_markers(const uint8_t *buf, uint32_t len, jpeg_info_t *info) { uint32_t pos 0; uint8_t marker; uint16_t seg_len; if (buf[pos] ! 0xFF || buf[pos] ! 0xD8) { return JPEG_ERR_FORMAT; } while (pos 4 len) { while (buf[pos] ! 0xFF) { pos; if (pos len) return JPEG_ERR_FORMAT; } while (buf[pos] 0xFF) pos; marker buf[pos]; if (marker 0xD9) { break; /* EOI */ } if (marker 0xDA) { /* SOS之后是熵編碼數(shù)據(jù)跳過即可 */ seg_len (buf[pos] 8) | buf[pos1]; pos seg_len; /* 后面就是壓縮數(shù)據(jù)區(qū)解析結(jié)束 */ info-compressed_data buf[pos]; break; } if (marker 0xC0 || marker 0xC2) { seg_len (buf[pos] 8) | buf[pos1]; info-precision buf[pos2]; info-height (buf[pos3] 8) | buf[pos4]; info-width (buf[pos5] 8) | buf[pos6]; info-num_components buf[pos7]; pos seg_len; } else if (marker 0xDB) { seg_len (buf[pos] 8) | buf[pos1]; if (info-dqt_len seg_len - 2 sizeof(info-dqt_data)) { memcpy(info-dqt_data[info-dqt_len], buf[pos2], seg_len - 2); info-dqt_len seg_len - 2; } pos seg_len; } else if (marker 0xC4) { seg_len (buf[pos] 8) | buf[pos1]; if (info-dht_len seg_len - 2 sizeof(info-dht_data)) { memcpy(info-dht_data[info-dht_len], buf[pos2], seg_len - 2); info-dht_len seg_len - 2; } pos seg_len; } else { seg_len (buf[pos] 8) | buf[pos1]; pos seg_len; } } return JPEG_OK; }解析過程中有一個(gè)容易踩坑的點(diǎn)DQT和DHT段在一個(gè)JPEG文件里可能有多段特別是相機(jī)輸出的JPEG量化表可能有兩張亮度和色度各一張哈夫曼表可能有四張DC0/AC0/DC1/AC1。采集時(shí)必須把每個(gè)表的ID和表數(shù)據(jù)一起保存硬件解碼時(shí)才能區(qū)分使用哪張表。解析完成后還需要從SOS段讀取每個(gè)分量的DC/AC哈夫曼表選擇信息。因?yàn)橛布﨡PEG外設(shè)需要知道Y分量用哪個(gè)哈夫曼表、Cb/Cr分量用哪個(gè)表。通常Y分量是表0色度分量是表1但不是絕對不能寫死。4.2 量化表與哈夫曼表加載STM32H743的JPEG外設(shè)在解碼前必須先把量化表和哈夫曼表加載到外部內(nèi)存然后把內(nèi)存地址寫入JPEG_QUAD和JPEG_HURM寄存器。表結(jié)構(gòu)有個(gè)固定格式。量化表區(qū)按8x8矩陣存放一個(gè)量化表64字節(jié)多個(gè)表連續(xù)存放。哈夫曼表區(qū)則按硬件規(guī)定的格式組織。以哈夫曼表為例每個(gè)表的數(shù)據(jù)結(jié)構(gòu)是typedef struct { uint8_t identifier; /* 0: DC表0, 1: DC表1, 2: AC表0, 3: AC表1 */ uint8_t nb_symbols; uint8_t symbols[162]; /* 對應(yīng)碼長1~16的符號值 */ uint8_t huffval[162]; /* 符號值表 */ } jpeg_huffman_table_t;給硬件加載時(shí)需要按碼長分組的比特?cái)?shù)表加符號值表的方式排列。這塊如果不確定具體格式可以參考STM32H743參考手冊中Huffman table definition章節(jié)的表格。關(guān)鍵點(diǎn)JPEG外設(shè)對哈夫曼表最多支持4張表存放地址必須32位對齊。加載表之前要確保外設(shè)處于停止?fàn)顟B(tài)否則寫入無效。配置寄存器可以這樣寫void jpeg_set_tables_addr(uint32_t quant_addr, uint32_t huff_addr) { JPEG-QUAD quant_addr; JPEG-HURM huff_addr; }4.3 配置解碼模式并啟動(dòng)DMAH7平臺(tái)上JPEG解碼有兩種常見數(shù)據(jù)搬運(yùn)方式一種是CPU通過PDIR和PDOUTR寄存器手動(dòng)搬運(yùn)另一種是DMA自動(dòng)搬運(yùn)。明顯DMA方式更適合高吞吐場景下面講DMA配置。輸入DMA從SDRAM的JPEG文件緩沖區(qū)搬運(yùn)到外設(shè)基址PDIR偏移的地址每次傳輸4字節(jié)方向?yàn)閮?nèi)存到外設(shè)。配置成普通模式傳輸數(shù)據(jù)量等于JPEG壓縮數(shù)據(jù)總長度。輸出DMA從外設(shè)基址PDOUTR偏移的地址搬運(yùn)到SDRAM輸出緩沖區(qū)每次傳輸4字節(jié)方向?yàn)橥庠O(shè)到內(nèi)存。數(shù)據(jù)長度是圖像寬x高x每個(gè)像素字節(jié)數(shù)。DMA配置核心代碼這里用DMA2的Stream0做輸入Stream1做輸出void jpeg_dma_config(DMA_HandleTypeDef *hdma_in, DMA_HandleTypeDef *hdma_out, uint32_t src_addr, uint32_t dest_addr, uint32_t data_len) { hdma_in-Instance DMA2_Stream0; hdma_in-Init.Request DMA_REQUEST_JPEG_IN; hdma_in-Init.Direction DMA_MEMORY_TO_PERIPH; hdma_in-Init.PeriphInc DMA_PINC_DISABLE; hdma_in-Init.MemInc DMA_MINC_ENABLE; hdma_in-Init.PeriphDataAlignment DMA_PDATAALIGN_WORD; hdma_in-Init.MemDataAlignment DMA_MDATAALIGN_WORD; hdma_in-Init.Mode DMA_NORMAL; hdma_in-Init.Priority DMA_PRIORITY_HIGH; HAL_DMA_Init(hdma_in); /* 配置輸出DMA */ hdma_out-Instance DMA2_Stream1; hdma_out-Init.Request DMA_REQUEST_JPEG_OUT; hdma_out-Init.Direction DMA_PERIPH_TO_MEMORY; hdma_out-Init.PeriphInc DMA_PINC_DISABLE; hdma_out-Init.MemInc DMA_MINC_ENABLE; hdma_out-Init.PeriphDataAlignment DMA_PDATAALIGN_WORD; hdma_out-Init.MemDataAlignment DMA_MDATAALIGN_WORD; hdma_out-Init.Mode DMA_NORMAL; hdma_out-Init.Priority DMA_PRIORITY_HIGH; HAL_DMA_Init(hdma_out); /* 還要注意外設(shè)地址和數(shù)據(jù)長度在啟動(dòng)前設(shè)置 */ }提醒一下這里的DMA配置我用的是HAL庫的DMA句柄但后續(xù)解碼流程全是寄存器操作DMA只承擔(dān)數(shù)據(jù)搬運(yùn)HAL庫的DMA初始化函數(shù)其實(shí)只是方便配置寄存器。如果你連這點(diǎn)也想省可以用寄存器直接寫DMA_SxCR、DMA_SxNDTR等邏輯一樣。實(shí)際啟動(dòng)解碼時(shí)的順序必須嚴(yán)格先讓DMA和外設(shè)都處于復(fù)位狀態(tài)。配置JPEG_CONFR1為總像素?cái)?shù)寬x高。寫入QUAD、HURM寄存器。使能JPEG外設(shè)同時(shí)使能輸入DMA。輸入DMA搬運(yùn)完所有壓縮數(shù)據(jù)后外設(shè)開始解碼。輸出DMA自動(dòng)搬運(yùn)解碼結(jié)果。從JPEG_SR或DMA完成中斷等待完成。4.4 解碼完成中斷與狀態(tài)輪詢我是裸機(jī)系統(tǒng)所以直接在解碼函數(shù)里寫一個(gè)帶超時(shí)的輪詢int jpeg_decode(uint32_t input_buf, uint32_t output_buf, uint32_t input_len, jpeg_info_t *info) { uint32_t timeout 0; /* 重置DMA、JPEG外設(shè) */ JPEG-CR ~JPEG_CR_JCEN; __HAL_RCC_JPEG_CLK_ENABLE(); JPEG-CR 0; /* 延時(shí)確保外設(shè)復(fù)位有效 */ for (volatile int i 0; i 10; i); /* 配置總像素?cái)?shù) */ JPEG-CONFR1 info-width * info-height; /* 設(shè)置表地址 */ JPEG_set_tables_addr((uint32_t)quant_table_buf, (uint32_t)huff_table_buf); /* 啟動(dòng)輸出DMA */ HAL_DMA_Start_IT(hdma_out, (uint32_t)JPEG-PDOUTR, output_buf, info-width * info-height * 2); /* 假設(shè)RGB565或YCbCr422 */ /* 使能JPEG外設(shè) */ JPEG-CR | JPEG_CR_JCEN; /* 啟動(dòng)輸入DMA */ HAL_DMA_Start_IT(hdma_in, input_buf, (uint32_t)JPEG-PDIR, input_len / 4); /* 輪詢完成標(biāo)志 */ while (timeout 0x1000000U) { if ((JPEG-SR JPEG_SR_IFNF) 0) { /* 輸入FIFO非滿繼續(xù)等待 */ } if (JPEG-SR JPEG_SR_IFTF) { /* 輸入FIFO空且輸入DMA完成說明解碼接近結(jié)束 */ } if ((DMA2-LISR DMA_LISR_TCIF1) ! 0) { /* 輸出DMA傳輸完成 */ break; } timeout; } if (timeout 0x1000000U) { return JPEG_ERR_TIMEOUT; } /* 停外設(shè) */ JPEG-CR ~JPEG_CR_JCEN; return JPEG_OK; }狀態(tài)寄存器的判斷方式是硬解調(diào)試驗(yàn)收的重點(diǎn)。JPEG_SR中比較關(guān)鍵的位包括IFNF輸入FIFO非滿、IFTF輸入FIFO空、OFNE輸出FIFO非空、OFRF輸出FIFO滿和完成標(biāo)志。輪詢時(shí)要根據(jù)DMA傳輸模式正確判定不然容易提前退出或死循環(huán)。4.5 YCbCr到RGB的顏色轉(zhuǎn)換STM32H743的JPEG輸出默認(rèn)不是RGB888而是YCbCr格式常見是YCbCr422或YCbCr444。屏幕驅(qū)動(dòng)接口通常要RGB所以解碼后需要轉(zhuǎn)換。如果你的顯示鏈路是LTDCRGB屏有兩種選擇在解碼前配置JPEG外設(shè)的像素?cái)?shù)據(jù)輸出格式為YCbCr422或RGB565部分H7型號支持直接輸出RGB565但寄存器區(qū)別要查手冊。在軟件里做YCbCr到RGB的轉(zhuǎn)換公式不復(fù)雜但逐個(gè)像素乘加比較耗CPU。推薦用查表法把R、G、B分量的系數(shù)預(yù)計(jì)算成表轉(zhuǎn)換一幀800x480也只有幾十ms但對比硬解本身還是能吃不少CPU。實(shí)際項(xiàng)目我直接讓JPEG輸出YCbCr422然后配合LTDC的YCbCr輸入模式省去了轉(zhuǎn)換。若你的屏不支持就得在解碼后做一個(gè)簡單的像素轉(zhuǎn)換函數(shù)注意處理邊界值鉗制到0-255。5. 性能實(shí)測與調(diào)優(yōu)記錄5.1 硬解和軟解的真實(shí)對比為了驗(yàn)證方案效果我拍了一張相機(jī)JPG直接放到SD卡分別用軟解庫和硬件JPEG解碼做對比。測試圖片信息分辨率1920x1080文件大小約780KB質(zhì)量因子大概85基線格式。解碼方式耗時(shí)CPU占用情況軟件解碼TinyJPEG約540ms解碼期間CPU幾乎滿載硬件JPEG寄存器驅(qū)動(dòng)約20ms主要耗時(shí)在DMA搬運(yùn)CPU占用不到30%再把圖片壓縮到800x480、文件大小約120KB硬件解碼耗時(shí)約4ms。這個(gè)數(shù)據(jù)在實(shí)際產(chǎn)品里體驗(yàn)很好輪播切換圖片基本無感知。如果加上JPEG頭解析和表加載時(shí)間整體解碼耗時(shí)也只比純硬件解碼多1ms左右因?yàn)榻馕鲋皇菕呙鑾讉€(gè)字節(jié)的標(biāo)記段不是瓶頸。5.2 內(nèi)存對齊與Cache一致性這是H7上踩得最狠的坑。H7的CPU帶有Cache而DMA傳輸?shù)臄?shù)據(jù)對Cache是不可見的。如果輸出緩沖區(qū)的數(shù)據(jù)被CPU預(yù)先訪問過DMA寫入后CPU再讀讀到的可能是Cache里的舊數(shù)據(jù)。解決辦法有兩種最直接的方法是解碼前將輸出緩沖區(qū)的Cache行無效化解碼完后執(zhí)行Cache CleanSCB_InvalidateDCache_by_Addr((uint32_t *)output_buf, output_size);如果輸出緩沖區(qū)在SDRAM并且在MPU里配置成非Cacheable或Write-Through屬性也可以規(guī)避。但要注意把SDRAM整塊配置成非Cacheable會(huì)拖慢其他需要頻繁訪問的數(shù)據(jù)所以更推薦按解碼緩沖區(qū)單獨(dú)配置MPU區(qū)域。硬件解碼還要求32位對齊訪問。輸入DMA每次都讀4字節(jié)如果JPEG文件數(shù)據(jù)存放在奇數(shù)地址會(huì)導(dǎo)致HardFault或數(shù)據(jù)錯(cuò)亂。建議在準(zhǔn)備文件緩沖區(qū)時(shí)用__attribute__((aligned(32)))或由底層文件系統(tǒng)保證對齊。5.3 DMA帶寬與優(yōu)先級調(diào)整H7的DMA2和MDMA共享總線帶寬如果JPEG輸入DMA和輸出DMA優(yōu)先級設(shè)置不當(dāng)可能會(huì)被其他外設(shè)如以太網(wǎng)DMA搶占導(dǎo)致FIFO上溢或下溢。實(shí)測中把輸入DMA優(yōu)先級設(shè)為最高輸出DMA設(shè)為高再配合JPEG外設(shè)FIFO的中斷閾值解碼1920x1080圖片時(shí)沒有出現(xiàn)丟碼或卡死。另外JPEG外設(shè)內(nèi)部FIFO深度有限輸出DMA的觸發(fā)條件要配置合理。可以在JPEG_CR中設(shè)置輸出FIFO閾值避免FIFO溢出時(shí)丟棄數(shù)據(jù)。這個(gè)值具體是高位還是低位要看參考手冊。5.4 輸出像素格式選擇JPEG外設(shè)支持的輸出格式各系列略有不同H743通常支持RGB565、YCbCr444、YCbCr422、YCbCr420。如果你是接RGB屏最省事是輸出RGB565因?yàn)槊總€(gè)像素2字節(jié)內(nèi)存占用減半且LTDC可以直接顯示。但要注意JPEG硬件輸出RGB565時(shí)顏色空間轉(zhuǎn)換精度有限個(gè)別顏色會(huì)和原圖稍有偏差屬于正?，F(xiàn)象。如果對顏色要求高比如醫(yī)療、印刷預(yù)覽可以配置成YCbCr444然后用高質(zhì)量查表法轉(zhuǎn)RGB888。6. 常見問題與調(diào)試技巧6.1 解碼后圖像整體花屏或顏色錯(cuò)亂排查思路先確認(rèn)JPEG文件是baseline格式不是progressive。H7硬解不支持漸進(jìn)式JPEG遇到這類文件會(huì)解碼出花屏或直接超時(shí)。可以通過解析SOF標(biāo)記判斷如果SOF0變體是SOF20xFFC2那基本可以斷定是漸進(jìn)式。再檢查量化表和哈夫曼表加載是否完整尤其是DHT段里有多個(gè)表時(shí)。我在調(diào)試中打印過加載到內(nèi)存的表數(shù)據(jù)和自己用JPEGsnoop軟件導(dǎo)出的表對比發(fā)現(xiàn)文件頭解析漏掉了第二個(gè)DHT段導(dǎo)致亮度和色度通道用了錯(cuò)誤的哈夫曼表顏色完全亂了。DHT段解析時(shí)一定要兼容多段。6.2 解碼完成中斷一直不觸發(fā)如果輸出DMA配置正常但解碼完成中斷不觸發(fā)優(yōu)先檢查JPEG_SR的狀態(tài)位。正確的啟動(dòng)順序是先啟動(dòng)輸出DMA再使能JPEG外設(shè)最后啟動(dòng)輸入DMA。如果順序反了輸入DMA可能先灌入數(shù)據(jù)外設(shè)還沒就緒直接丟棄表現(xiàn)為解碼無輸出。我自己踩過一個(gè)坑把HAL_DMA_Start_IT輸出放到了JPEG使能之后結(jié)果輸出FIFO溢出解碼卡住。原因是外設(shè)使能后會(huì)立刻開始拉數(shù)據(jù)輸出DMA沒就緒時(shí)數(shù)據(jù)沒地方寫。6.3 第二次解碼時(shí)卡死這個(gè)問題幾乎必踩。原因是JPEG外設(shè)和DMA在第一次解碼完成后內(nèi)部狀態(tài)和標(biāo)志沒有清干凈。第二次啟動(dòng)解碼前至少要做三件事清除DMA傳輸完成標(biāo)志包括直接操作DMA_LIFCR寄存器。復(fù)位JPEG外設(shè)CR寄存器清零必要時(shí)重新使能時(shí)鐘。重新加載量化表和哈夫曼表地址因?yàn)橥庠O(shè)內(nèi)部可能還持有上一次的表指針。我封裝了一個(gè)jpeg_reset()函數(shù)每次解碼前強(qiáng)制調(diào)用之后項(xiàng)目就再?zèng)]出現(xiàn)第二次卡死的問題。6.4 大分辨率圖片解碼失敗H7的JPEG外設(shè)支持的最大圖像尺寸有上限不是理論無限的具體以參考手冊為準(zhǔn)。另外輸出緩沖區(qū)不能放DTCM因?yàn)镈TCM接口不具備DMA訪問能力部分總線矩陣限制所以DMA訪問的緩沖區(qū)必須放在普通SRAM或SDRAM。在H743上DMA1/DMA2訪問DTCM不便這是個(gè)比較隱蔽的坑。如果你的輸出緩沖定義在DTCM區(qū)域DMA傳輸出錯(cuò)解碼結(jié)果全0。解決辦法是把緩沖區(qū)放到SDRAM或AXI SRAM區(qū)域。6.5 JPEG硬件外設(shè)的時(shí)鐘使能寄存器庫驅(qū)動(dòng)最容易漏掉的就是時(shí)鐘使能。用HAL庫時(shí)cubeMX自動(dòng)幫你開了RCC時(shí)鐘寄存器驅(qū)動(dòng)下要手動(dòng)寫__HAL_RCC_JPEG_CLK_ENABLE();如果是純寄存器寫法就是操作RCC_AHB4ENR或RCC_AHB1ENR里對應(yīng)的JPEG位。忘記使能時(shí)鐘的后果是JPEG寄存器讀寫無效狀態(tài)寄存器恒為0看起來像外設(shè)沒工作。6.6 調(diào)試技巧用SR寄存器判斷卡在哪一步我給驅(qū)動(dòng)加了一個(gè)調(diào)試輔助函數(shù)在解碼超時(shí)時(shí)打印JPEG_SR的關(guān)鍵狀態(tài)值。根據(jù)寄存器位可以快速定位卡點(diǎn)SR為0大概率外設(shè)時(shí)鐘沒開或基址錯(cuò)誤。IFNF一直為1且DMA不啟動(dòng)檢查輸入DMA請求號和DMA通道配置。OFNE一直為0輸出FIFO沒有數(shù)據(jù)可能JPEG文件頭解析失敗壓縮數(shù)據(jù)沒進(jìn)來。報(bào)錯(cuò)標(biāo)志置位檢查JPEG文件格式是否兼容。串口打印狀態(tài)碼后再配合常用工具查看解碼輸出整個(gè)調(diào)優(yōu)效率能提高很多。7. 驅(qū)動(dòng)擴(kuò)展與后續(xù)優(yōu)化方向這套寄存器驅(qū)動(dòng)的JPEG解碼目前已經(jīng)穩(wěn)定運(yùn)行在項(xiàng)目里。不過有幾條后續(xù)值得做的方向供你參考。如果項(xiàng)目里是RTOS環(huán)境可以把解碼放到一個(gè)獨(dú)立任務(wù)里用信號量通知解碼完成。解碼期間CPU可以繼續(xù)跑GUI刷新互不阻塞。實(shí)測配合FreeRTOSLVGL輪播圖切換體驗(yàn)比裸機(jī)輪詢好很多。如果解碼圖片來自網(wǎng)絡(luò)或SD卡要注意輸入緩沖區(qū)的生命周期。最好把JPEG文件完整讀入SDRAM后再啟動(dòng)解碼不要在文件流中一邊讀一邊喂給硬件因?yàn)镴PEG解碼有時(shí)序要求數(shù)據(jù)必須連續(xù)。另外這個(gè)外設(shè)也支持硬件JPEG編碼。如果你有截圖或者屏幕內(nèi)容保存需求可以直接用相同外設(shè)把RGB數(shù)據(jù)編碼成JPEG省掉軟件編碼庫速度也快很多。編碼流程和解碼對稱有的代碼可以復(fù)用。最后提一個(gè)關(guān)于功耗的想法硬解省下的CPU時(shí)間讓主控可以更快進(jìn)入睡眠對電池設(shè)備友好。如果你正在做便攜式顯示設(shè)備這個(gè)時(shí)間收益很值得算進(jìn)功耗預(yù)算里。要說我做這個(gè)項(xiàng)目最大的體會(huì)就是別急著給單片機(jī)下結(jié)論說“解碼就得用軟解庫”?，F(xiàn)在的MCU片上外設(shè)集成度比想象中高STM32H7的JPEG Co-processor就是個(gè)典型案例。寄存器驅(qū)動(dòng)看起來多花了一些時(shí)間但換來的是可控的時(shí)序、極小的開銷和真正的實(shí)時(shí)性這在顯示交互場景下非常值得。本文還有配套的精品資源點(diǎn)擊獲取