STM32H743硬件JPEG解码实战：从SD卡到LCD的显示链路优化

简介：本资源是一套基于STM32H743单片机实现硬件JPEG解码与LCD显示的完整嵌入式开发源码，面向具备C语言基础与STM32外设开发经验的中级以上嵌入式工程师及高校电子类专业学生，解决高分辨率图像在资源受限MCU上实时解码与高效显示的核心难题。压缩包共844个文件，主体为244个C源文件与298个头文件（.h），涵盖JPEG硬件解码驱动、LCD显示控制、DMA传输配置及多平台编译支持（含IAR/GCC/ARMCC适配的.a静态库与.icf/ld/sct链接脚本），辅以HTML文档与PNG示意图，整体大小9.16MB。已有109人学习下载，资源结构清晰分层——包含HAL库适配层、JPEG硬件加速模块封装、RGB565/YUV422格式转换逻辑及TFT屏驱动例程，可直接移植至带DCMI或SPI Flash存储JPEG数据的硬件平台，显著降低CPU负载并提升图像处理实时性。 最近在调一个需要频繁显示图片的嵌入式项目，原来用软解JPEG，一张800x600的图在72MHz的MCU上要跑一两秒，卡得没法看。后来换到STM32H743，用内置的硬件JPEG解码器，速度直接拉满，解码一张同分辨率图片基本在几十毫秒量级，CPU还能腾出来干别的。今天就把这个项目的完整思路和实操细节整理一下，包括为什么选H743、硬件解码器的底层机制、整个解码显示链路的代码怎么组织，以及我踩过的几个印象很深的坑。

先交代一下项目背景，方便你对号入座：主控是STM32H743IIT6，外部接了SDRAM（W9825G6KH）作为帧缓存，SD卡存放JPEG图片，屏幕是一块4.3寸RGB接口的LCD，分辨率800x480，通过LTDC驱动。软件部分用STM32CubeMX生成基础工程，HAL库开发，IDE是Keil MDK。代码模块上拆成了sd_card.c、jpeg_decode.c、lcd_display.c三个部分，源码结构也按这个思路组织。

如果你手头的板子也是H7系列，或者正在纠结“为什么我 JPEG 解码这么慢、CPU占用这么高”，这篇东西应该能给你省不少时间。

1. 项目整体设计与方案选型

1.1 为什么选STM32H743做JPEG解码

先看性能账。STM32H743这颗料，主频最高能跑到480MHz，Cortex-M7内核带双精度FPU和L1 Cache（I-Cache 16KB，D-Cache 16KB），内置2MB Flash和1MB RAM。但真正让它适合做图像处理的，是内部集成的一个硬件JPEG编解码器（Hardware JPEG Codec）。

这个硬件JPEG模块不是摆设，它支持JPEG编码和解码，解码方面支持基线格式（Baseline）JPEG，采样格式覆盖YUV420、YUV422、YUV444，输出可以是YUV或者RGB888/RGB565。关键是它全程硬件处理，基本不占CPU，只需要配置寄存器、准备好输入输出缓冲区、触发传输就行。

拿我的实际数据来说：一张640x480的JPEG图，软解（用libjpeg移植版）在H743上大约耗时200ms左右，CPU占用率几乎是100%；切到硬件JPEG后，解码时间稳定在25ms到35ms之间，CPU占用率不到10%。这个差距在需要连续翻页、预览缩略图的场景里体感非常明显。

如果你只是偶尔解一张小图，软解完全够用，没必要上H743。但如果你要做相册预览、图片浏览器、带GUI的证书拍照预览、广告机换画这类应用，硬件JPEG带来的流畅度提升是质变的。

1.2 方案对比：硬件JPEG解码 vs 软件解码 vs 外部芯片

项目选型阶段，我对比了三条路线，这里直接列个表格给你参考：

软件解码里TjpgDec是专门为嵌入式优化的，Flash占用小，但速度就是慢，因为JPEG解码涉及大量的Huffman解码、反量化、逆DCT、色彩空间转换，在通用MCU上算纯算力活。硬件JPEG解码器本质上是把这几步全部做成专用电路，自然快出一个数量级。

外部解码芯片方案我也调研过，比如某些视频解码芯片自带JPEG硬件解，它们确实快，但芯片物料、PCB面积都会涨，而且这类芯片的资料和供货稳定性是个风险点。对多数中小批量产品来说，直接用H743内置的硬件JPEG是最平衡的——少一颗芯片，功耗更低，代码量也不大。

1.3 整体数据流：从SD卡到LCD屏幕

在整个项目里，图片数据流是这样一个链路：

SD卡(JPEG文件) -> FATFS读取 -> SDRAM输入缓冲区 -> 硬件JPEG解码器 -> 输出RGB数据到SDRAM帧缓存 -> LTDC从帧缓存读取 -> LCD屏幕显示

听起来简单，但里面的细节比想象中多。SD卡读取是IO密集操作，解码器是硬件加速但需要喂数据，LTDC刷新是一刻不停的DMA传输，三者之间是“生产者-消费者”关系，任意一环阻塞都会掉帧。

我的做法是把整个过程拆成两个阶段。第一阶段是从SD卡把JPEG文件完整读入SDRAM的输入缓冲区，读完以后关闭文件。第二阶段，启动硬件JPEG解码器，让它在SDRAM的输入缓冲区和输出缓冲区之间做解码，这里的关键是用MDMA（Master DMA）来搬运数据，而不是用CPU逐字节搬。CPU只在开始和结束时介入，中间完全异步。

具体代码里，我定义了一个结构体来管理解码任务，后面所有模块都围绕这个结构体工作：

typedef struct { uint32_t input_addr; // JPEG文件数据所在地址 uint32_t input_size; // 文件字节数 uint32_t output_width; // 解码输出宽度（像素） uint32_t output_height; // 解码输出高度（像素） uint32_t output_fmt; // 输出格式：JPEG_RGB888 / JPEG_RGB565 uint16_t jpeg_sampling; // 采样格式：YUV420/422/444 uint8_t decode_done; // 解码完成标志 uint8_t decode_error; // 解码错误标志 } jpeg_decode_task_t;

后面所有解码操作都通过这个结构体驱动，读文件、配解码器、启动传输、等待完成，逻辑非常清晰，排查问题也方便。

2. 硬件JPEG解码器核心机制，配置前必须搞懂的底层原理

2.1 JPEG格式与硬件解码器的对应关系

JPEG本身不是一种简单的“图片格式”，而是一套编码标准。里面有几个关键概念：色彩空间转换（RGB转YCbCr）、离散余弦变换（DCT）、量化、Huffman编码。编码时，图像先分块（一般是8x8像素），逐块做DCT，然后量化、熵编码，最终写成JPEG文件。解码过程反过来。

STM32H743的硬件JPEG解码器，对外呈现为一个寄存器组和一组状态位。它的输入是一段完整的JPEG码流，输出是解码后的YUV或RGB像素数据。芯片内部自动完成Huffman解码、反量化、逆DCT、上采样（如果采样格式是YUV420还要恢复UV分量）等全部步骤。

但这里有个限制：硬件JPEG只支持Baseline JPEG（基线）标准，不支持Progressive JPEG，也不支持算术编码。很多开源工具生成的JPEG默认就是Baseline，但如果你在Photoshop里选择“连续”（Progressive）模式导出，硬件解码器会直接报错。

所以我在项目里加了一个简单的文件头检查，直接看SOF0（Start of Frame 0）和SOF2（Start of Frame 2）标记。SOF0是Baseline，SOF2是Progressive。判断逻辑很简单：

// 简化版：扫描JPEG标记，确认是否Baseline uint8_t check_jpeg_baseline(uint8_t* buf, uint32_t size) { uint32_t i = 2; // 跳过SOI标记 0xFFD8 while (i < size - 1) { if (buf[i] == 0xFF) { uint8_t marker = buf[i + 1]; if (marker == 0xC0) { // SOF0: Baseline return 1; } else if (marker == 0xC2) { // SOF2: Progressive return 0; } } i++; } return 0; // 未识别，保守起见不支持 }

这个检查放在解码之前，能避免后面解到一半才发现不支持，省了很多调试时间。

2.2 寄存器配置核心：JPEG_CR、JPEG_CFR、JPEG_CONFR

配置硬件JPEG解码器的核心是几个关键寄存器，如果你用HAL库的话就是一堆参数结构体，但理解底层寄存器有助于排查问题，尤其是当你直接看参考手册时不会懵。

首先，JPEG_CR（控制寄存器）需要配置操作模式。对于解码，设置JPEG_EN位为1使能JPEG模块，JPEG_OP位设为解码模式。这里有一个细节：JPEG模块默认是编码模式，不是解码模式，必须显式切换（参考手册状态机部分有说明）。

其次，JPEG_CFR（配置寄存器）是核心中的核心。它配置的是编码时的参数，但是解码时也需要读取它来获取输入图像的帧信息。具体来说，解码时你会先通过JPEG_CONFR(配置帧寄存器)读取JPEG头解析出的宽度（JPG_WIDTH）和高度（JPG_HEIGHT）字段，还有采样格式（YUV_COF等）。

然后关键的是输出格式。在JPEG_CFR里可以配置解码输出是RGB565还是RGB888，字段是COLOR_SPACE和OUT_FMT。RGB565输出每个像素占2字节，RGB888占3字节。LCD如果是RGB565接口，直接输出RGB565省去一次格式转换，但如果你的LCD控制器需要RGB888（比如某些RGB888并口屏），就需要选RGB888。

实际配置顺序是：先使能JPEG外设时钟，然后设置输入输出缓冲区地址和大小，接着把JPEG码流喂给解码器，最后启动解码。HAL库对这套流程封装成了HAL_JPEG_Decode()和HAL_JPEG_Decode_DMA()两个函数，推荐用DMA版本，把搬运和计算都交给硬件。

2.3 MDMA在这里扮演的角色

很多第一次用H7系列的人会对MDMA（Master DMA）感到陌生，它和普通DMA的区别在于：普通DMA负责外设和内存之间的搬运，而MDMA可以在两个内存区域之间搬运，也可以做内存到外设、外设到内存的搬运，支持更高的位宽和链式传输。

在JPEG解码场景里，MDMA起到的作用有两个：

1. 把JPEG码流从SDRAM的输入缓冲区搬进JPEG模块的输入FIFO。
2. JPED模块解码输出到输出FIFO后，把数据从输出FIFO搬回SDRAM的输出缓冲区。

注意，JPEG模块内部有FIFO，不能直接用普通DMA的Memory-to-Memory模式绕过FIFO把数据塞进去。必须让MDMA配合JPEG模块的输入/输出FIFO标志位工作，典型的做法是用MDMA的linked-list模式，把输入和输出通道配置成两个链表节点，让硬件自动处理数据传输。

用HAL_JPEG_Decode_DMA时，库函数内部会做这些事，你只需要传入输入缓冲指针、输出缓冲指针、数据大小和解码格式参数。它自动配置MDMA并在完成后触发回调。我实际测过，对于100KB左右的JPEG文件，MDMA搬运耗时几乎可以忽略，主要时间还是花在JPEG模块本身的解码计算上。

这里提醒一下，MDMA的配置优先级和Cache策略要特别留意。默认情况下，MDMA不经过CPU的Cache，所以如果输出缓冲区在D-Cache管理的区域，解码完成后CPU直接读到的可能是Cache里的旧数据。解决方案是对输出缓冲区执行SCB_CleanDCache或SCB_InvalidateDCache。我在项目里是直接做了一次Invalidate，因为输出缓冲区是SDRAM，不开启Cache，所以问题不明显，但如果你用内部SRAM做输出缓冲就必须要处理。

3. 内存管理策略与DMA传输链路设计

3.1 输入、输出缓冲区的分配原则（SRAM vs SDRAM）

H743的内存布局比较复杂，片上RAM分成好几个域：DTCM（Data TCM）、ITCM、AXI SRAM（D1域）、SRAM1/2/3（D2域）、SRAM4（D3域）。从JPEG解码的角度看，不同的RAM区域对性能和稳定性的影响不一样。

DTCM是直接连到内核的总线，速度最快，但DMA访问不到（H7系列这一点很坑）。ITCM一般放指令，不用于数据。AXI SRAM挂在D1域，总线带宽最高，适合显示相关的数据。D2域的SRAM1/2/3和D3域的SRAM4对DMA访问兼容性好，是比较稳妥的选择。

我的分配策略是：

• JPEG码流输入缓冲区：放在D2域的SRAM1，因为MDMA/DMA访问D2域没有总线仲裁冲突，而且这部分数据是顺序读，不会频繁命中Cache。
• 解码输出RGB缓冲区：放在外部SDRAM，因为解码后的RGB数据量远大于JPEG码流（一张800x480的RGB565图约768KB，RGB888约1.15MB），内部RAM放不下，必须外挂SDRAM。
• LCD的LTDC显存：同样放在SDRAM，和JPEG输出缓冲区规划在不同地址段，避免覆盖。我习惯是SDRAM前4MB给LTDC帧缓存，后面4MB给JPEG输出和其他用途。

SDRAM的初始化在H743上有讲究：H743的FMC-SDRAM控制器需要通过HAL_SDRAM_Init和HAL_SDRAM_SendCommand两条通路初始化，时序参数要根据SDRAM的datasheet配置。我用的W9825G6KH是常见的2MB x 4bank x 16bit，初始化时CAS延迟设为3，刷新周期设为较保守的64ms。

3.2 从SD卡读取JPEG文件的完整流程

SD卡部分我用的FATFS文件系统，H743自带的SDMMC1接口。读取流程图大致是：

FRESULT load_jpeg_from_sd(const char* filename, uint32_t* dst_addr, uint32_t* out_size) { FIL file; UINT bytes_read; FRESULT res = f_open(&file, filename, FA_READ); if (res != FR_OK) return res; // 获取文件大小 *out_size = f_size(&file); // 检查缓冲区是否够存 if (*out_size > JPEG_INPUT_BUF_SIZE) { f_close(&file); return FR_INVALID_PARAMETER; } // 一次性读取到缓冲区 res = f_read(&file, (void*)JPEG_INPUT_ADDR, *out_size, &bytes_read); f_close(&file); return res; }

有几个细节需要注意。第一，FATFS和SDMMC的DMA需要缓冲区地址对齐，SDMMC内部要求4字节对齐，为了保险我直接把输入缓冲区地址放到32字节对齐的位置。第二，如果SD卡速度较慢，或者FATFS配置了摩擦扇区，读取时间可能比解码还长，所以我在文件读取阶段加了进度标志，UI层面可以显示“正在加载”而不是卡死。第三，不要用f_gets或f_scanf边读边解，一次性整体读入最稳，因为硬件JPEG需要完整的码流才能正确开始处理。

3.3 DMA传输链路的实际配置与关键参数

H7系列的MDMA配置比普通DMA复杂，建议直接使用CubeMX生成，手写配置容易出错。我贴一下工程里MDMA的关键参数：

MDA_HandleTypeDef hdma_jpeg_in; MDA_HandleTypeDef hdma_jpeg_out; // MDMA输入通道配置 hdma_jpeg_in.Init.Request = DMA_REQUEST_JPEG_IN; hdma_jpeg_in.Init.Direction = DMA_MEMORY_TO_PERIPH; hdma_jpeg_in.Init.PeriphInc = DMA_PINC_DISABLE; hdma_jpeg_in.Init.MemInc = DMA_MINC_ENABLE; hdma_jpeg_in.Init.PeriphDataAlignment = DMA_PDATAALIGN_WORD; hdma_jpeg_in.Init.MemDataAlignment = DMA_MDATAALIGN_WORD; hdma_jpeg_in.Init.Mode = DMA_NORMAL; hdma_jpeg_in.Init.Priority = DMA_PRIORITY_LOW;

PeriphDataAlignment和MemDataAlignment设成字（32位）对齐，是因为JPEG模块的FIFO是32位接口，而MDMA也建议4字节对齐以发挥最高带宽。输入侧Direction是Memory到Peripheral，输出侧反过来是Peripheral到Memory。

DMA传输完成后会进入HAL_JPEG_DecodeCpltCallback回调函数里，我在里面置位decode_done标志，主循环轮询这个标志来触发显示刷新。

4. 解码显示链路与LCD对接

4.1 LTDC配置：让屏幕无闪烁显示

LTDC（LCD-TFT控制器）部分，我用的是RGB888配置，屏是800x480。LTDC核心配置包括显示时序参数Hsync、Vsync、HBP、HBP、VBP、VFP，这些参数直接参考屏厂的datasheet。配置错了最常见的表现是画面偏移、闪烁、撕裂。

LTDC从SDRAM帧缓存取数据的地址设置成LTDC_Layer1->CFBAR寄存器，这个地址必须是32字节对齐的。帧缓存的格式要和JPEG输出格式保持一致：LTDC_PIXEL_FORMAT_RGB888对应JPEG的RGB888输出，LTDC_PIXEL_FORMAT_RGB565对应RGB565输出。

帧缓存大小、行宽、行距这三个参数容易搞混。LCD_PIXEL_FORMAT是像素格式，LCD_FRAME_BUFFER是显存地址，LCD_LL_LCD_PIXEL_FORMAT是LTDC的格式定义，在CubeMX里需要一致。行距（Pitch）尤其要注意，它不一定等于宽度乘以像素字节数，因为有对齐要求，我一般直接把行距设为和LCD_PIXEL_WIDTH一致，不用额外的对齐填充，简单可靠。

刷新率上，800x480@60Hz，像素时钟约33MHz，LTDC会持续从SDRAM读数据，带宽占用大约为33MB/s（RGB888），SDRAM的带宽完全能扛住，同时MDMA做JPEG解码时也不会有明显冲突。实测下来没有出现撕裂（tearing），因为我在每次解码完成后只更新显存里的图片区域，不会在LTDC刷屏过程中去写正在显示的帧，除非开了多帧缓冲做撕裂防止，但那样内存占用会翻倍。

4.2 从JPEG解码输出到LCD：RGB888 vs RGB565的选择

这一步是关键决策：JPEG硬件解码器的输出格式应该选RGB888还是RGB565？

我的项目屏是RGB888并口屏，所以JPEG输出格式也选择了RGB888，这样从解码到显示不需要任何转换，直接拷进帧缓存即可。但如果你用的是常见的1.8寸或2.4寸ST7735、ILI9341等SPI接口屏，或者RGB565接口的RGB屏，更推荐JPEG输出RGB565，省一半显存，显示也快。

需要说明的是，JPEG解码器输出RGB565时，它的字节序定义是RGB565（低位在前），而LTDC的RGB565格式通常是高位在前，具体是哪种你最好查一下参考手册的像素格式定义。我在调试时被这个字节序坑过一次，画面整体颜色偏蓝偏绿，排查了很久，最后是把JPEG输出的每个像素的低字节和高字节交换了才正常。如果不想做字节交换，可以在LTDC的配置里把FIFO的字节序统一切换，但那样会影响其他图层的显示方式，不如直接改数据。

如果你最终必须做RGB888转RGB565，转换公式很简单，但要注意写法效率：

static inline uint16_t rgb888_to_rgb565(uint8_t r, uint8_t g, uint8_t b) { return ((r & 0xF8) << 8) | ((g & 0xFC) << 3) | (b >> 3); }

这个转换如果放在主循环里逐像素做会吃掉大量CPU时间，805x480的图有38万多个像素，每个像素三次移位和三次按位与，百万级操作对MCU来说是负担。我是用MDMA把JPEG输出的RGB888数据搬到SDRAM的临时区域，再用DMA2D（H743内置的2D图形加速器）做色彩格式转换，DMA2D硬件完成这个转换非常快。如果你的项目里也有这类重复转换需求，建议优先考虑DMA2D。

4.3 解码流程主函数实操示例

下面是我项目里解码并显示一张图片的核心流程，整理成完整代码方便你直接参考：

void jpeg_show_image(const char* filename) { // 1. 从SD卡读JPEG文件 if (load_jpeg_from_sd(filename, (uint32_t*)JPEG_INPUT_ADDR, &jpeg_file_size) != FR_OK) { printf("JPEG file load failed\r\n"); return; } // 2. 检查JPEG格式，确保是Baseline if (check_jpeg_baseline((uint8_t*)JPEG_INPUT_ADDR, jpeg_file_size) == 0) { printf("Not baseline JPEG, unsupported\r\n"); return; } // 3. 配置硬件JPEG解码参数 JPEG_HandleTypeDef hjpeg; hjpeg.Instance = JPEG; hjpeg.Init.ColorSpace = JPEG_YCBCR_COLORSPACE; // JPEG内部分量是YCbCr hjpeg.Init.ImageHeight = jpeg_height; // 从JPEG头解析 hjpeg.Init.ImageWidth = jpeg_width; // 从JPEG头解析 hjpeg.Init.InputDataFormat = JPEG_DATA_FORMAT_RAW; hjpeg.Init.OutputFormat = JPEG_RGB888_OUT; // 输出RGB888 hjpeg.Init.JPEGSampling = jpeg_sampling; // YUV420/422/444 HAL_JPEG_Init(&hjpeg); // 4. 启动DMA解码 HAL_JPEG_Decode_DMA(&hjpeg, (uint8_t*)JPEG_INPUT_ADDR, // 输入码流 (uint8_t*)JPEG_OUTPUT_ADDR, // 输出RGB jpeg_file_size, jpeg_output_size); // 5. 等待解码完成回调 uint32_t timeout = HAL_GetTick(); while (decode_done_flag == 0) { if (HAL_GetTick() - timeout > 500) { printf("JPEG decode timeout\r\n"); HAL_JPEG_DeInit(&hjpeg); return; } } // 6. 将解码后的RGB数据复制到LTDC帧缓存 memcpy((void*)LCD_FRAME_BUFFER, (void*)JPEG_OUTPUT_ADDR, jpeg_width * jpeg_height * 3); // 7. 完成，清标志 decode_done_flag = 0; HAL_JPEG_DeInit(&hjpeg); }

流程很简单，但这里面的“配置解码参数”前提是你要提前解析出图片的宽、高、采样格式。我是在第3步之前额外写了一个JPEG头解析函数，读取SOF0中的宽高字段和采样因子，这个信息在JPEG的帧头里。

如果解码过程中发现文件损坏或者格式不支持，硬件JPEG的JPEG_SR状态寄存器会置错误标志，HAL库会在回调函数HAL_JPEG_ErrorCallback里上报。我的做法是在这个回调里打印错误码并置decode_error标志，主流程据此弹出提示。

5. 调试技巧与踩坑实录，硬编码经验指南

5.1 常见错误码与定位方式

STM32H743的JPEG外设报错时，状态寄存器会给出相对具体的原因。常见错误码和排查思路我整理了一个速查表：

遇到错误，第一件事不是看代码，而是确认JPEG文件本身是好的。很多“解码失败”其实是文件在SD卡复制过程中损坏了。我习惯在调试阶段用PC端先打开同一张JPEG，确认能正常显示，再放到板子上跑。

5.2 解码卡死、输出图像错乱等实际问题

实际调试中我遇到过三种最典型的问题，逐一说说原因和解决方式。

第一个是图像颜色整体偏色。前面提到过，RGB565的字节序问题会导致红蓝交换或高低字节颠倒。我的解决方法是先输出一张纯色的JPEG图（比如纯红、纯绿、纯蓝），观察屏上显示的颜色，然后根据偏移方向调整字节序或LTDC配置。这个方法比盯着代码猜快得多。

第二个是图像错位、花屏，但颜色正常。多半是行宽（Pitch）配置不对，或者JPEG解码输出的大小和LTDC层设置的宽度不一致。比如一张800宽度的图，LTDC层配置成800，但JPEG解码时因为对齐原因输出每行可能多几个像素的填充，如果不跳过填充直接拷贝到帧缓存，下一行就会错位。我的解决方式是每次都拿JPEG_DecodeDMA输出回调里的OutputWidth和OutputHeight参数做一次校验，不一致就报警提示。

第三个是解码卡死，decode_done_flag迟迟不置位。排查时发现是MPU配置问题。H743的D-Cache是写回（write-back）策略，如果输入缓冲区被设置为Cacheable，DMA从SDRAM读到的可能是 Cache 里的陈旧内容，导致JPEG模块收到的码流是错的，然后一直卡在等待状态。解决方案很直接：把JPEG输入、输出缓冲区的MPU区域配置为Non-cacheable，或者在使用前执行SCB_CleanDCache确保数据回写到物理内存。具体配置在MPU寄存器里设置Region号为1，属性设为Normal, Non-Cacheable即可。

5.3 性能实测：这套方案到底能跑多快？

最后放一组我在H743IIT6，主频480MHz、SDRAM 16bit、SD卡Class 10的实测数据，供你做性能预算参考：

全流程里SD卡读取占了相当大的比重，尤其是文件较小时，FATFS的打开、读取、关闭操作固定开销明显。如果你对启动速度有极端要求，可以考虑把部分小图直接放到内部Flash做一个资源表，免去读SD卡的时间，或者用文件系统预读机制。

实际项目里，800x480分辨率下做到90ms左右的刷新率，对照片浏览类应用来说体感已经非常流畅，翻页没有明显延迟，CPU也还有余力跑GUI绘制和其他逻辑。如果是触摸屏翻页、缩放场景，可以把解码流程放到后台线程，UI线程只负责显示，体验会更好。

我在整个项目中最深的一点体会是：STM32H743的硬件JPEG解码器是一个“外设能力不等于产品体验”的典型案例。你能让它解出来，不代表你能让它流畅稳定地工作。真正决定项目成败的，往往是把输入输出缓冲区放到哪里、MPU怎么配置、DMA链路怎么组织这些看起来不起眼的细节。希望这篇拆解能让你少走一些我走过的弯路。如果你也在调H743的JPEG解码，遇到具体问题，欢迎在评论区聊一聊，说不定你踩的那个坑我也踩过。

本文还有配套的精品资源，点击获取