简介：本资源是一套基于STM32H743单片机实现硬件JPEG解码与LCD显示的完整嵌入式开发源码，面向具备C语言基础和STM32外设开发经验的中级以上嵌入式工程师及高校电子类专业学生，解决高性能图像实时解码在资源受限MCU上的落地难题。压缩包共844个文件，含244个C源文件（核心解码与显示驱动逻辑）、298个头文件（硬件抽象与配置定义）、147个IAR链接脚本（.icf）及GCC/Keil适配的分散加载文件（.sct/.ld），另有预编译PDM滤波库（.a）等关键二进制组件，整体大小为9.16MB。目前已有109人学习下载，源码结构清晰，涵盖JPEG硬件加速模块初始化、DMA双缓冲传输、RGB565格式转换、TFT-LCD底层驱动及多分辨率适配逻辑，附带完整工程配置（IAR/MDK/STM32CubeIDE三平台支持），可直接编译运行于典型H743开发板，显著降低图像处理CPU占用率，适用于工业HMI、便携医疗设备等对实时性与功耗敏感的场景。 做带屏嵌入式项目一年多了，只要涉及图片显示，总逃不开一个问题：图片到底怎么从存储介质里的 JPEG 文件，变成屏幕上能看到的一帧像素？大多数人第一反应是直接用软解库，我也这么干过，但在 STM32H743 这种主频 480MHz 的芯片上，软解一张 1280x720 的 JPEG 图片，CPU 基本被吃干抹净，界面一卡，体验非常难受。后来我把方案换成 H743 内置的硬件 JPEG 解码器，情况完全不一样：CPU 参与度极低，解码速度大幅提升，整条图片解码显示链路稳定跑通。这篇文章就把这套基于 STM32H743 的硬件 JPEG 图片解码显示源码拆开讲透，包含显示链路、核心代码、配置细节和调试踩坑记录，给想走同样路线的朋友做一个能直接抄作业的参考。
这套源码我已经整理成了完整的 CubeMX 工程，核心模块包括 JPEG 外设驱动、SDRAM 显存管理、LTDC 显示控制器初始化、SD 卡 FatFS 文件读取，以及一套可以直接跑通的解码-显示流程。适合正在做 HMI 界面、相册类产品、工业显示屏项目，或者准备把 H7 芯片的硬件解码能力用起来的开发者阅读。
1. 为什么偏偏选H743做JPEG解码？——和软解方案的正面较量
1.1 软解在H7上的真实表现和痛点
软件 JPEG 解码，STM32 圈子里用得最多的是 TJpgDec，还有一个是 picojpeg。这两个库在 Cortex-M7 上有一定优化空间，毕竟 H743 带了 DSP 和 FPU，主频也够高，但我不建议对这个“软解效率”抱太大期待。JPEG 解码的运算量很密集，霍夫曼解码、反量化、IDCT、YUV 转 RGB，每一步都在消耗 CPU 周期。
我实测过：480MHz 主频下，用 TJpgDec 软解一张 1280x720 的 JPEG 图片，耗时大概在 90~120ms 浮动，CPU 占用接近 100%。如果只是开机显示一张 logo，这个速度完全够用，但一旦要做相册轮播、多级菜单缩略图、动态图标切换，问题立刻就出来了——解码期间整个界面卡顿，按钮响应停顿，滑动动画掉帧。原因很简单，CPU 在处理图像算法时，完全没有余力去做 UI 渲染、触摸处理、网络通信这些任务。
软解还有个容易被忽略的问题：Flash 占用。TJpgDec 经过裁剪后大概要吃掉 8KB~20KB 代码空间。虽然 H743 有 2MB Flash，大部分时候不紧张，但如果你同时接了 LVGL、FatFS、USB、网络协议栈，Flash 和 RAM 的预算就会变得相当紧张。软解确实“只要一个库就行”，但每一个“方便”背后，都是用性能和资源换来的。
1.2 硬件JPEG解码器到底能减轻多少负担
H743 内置的硬件 JPEG 编解码器是一个独立外设，它支持市面上绝大多数 Baseline JPEG 格式的解码，而且输入输出都走 DMA，CPU 基本可以甩手不管。它能直接把 JPEG 码流解成 YCbCr，也可以直接输出 RGB565 或 RGB888，不需要 CPU 参与颜色空间转换。
同样是 1280x720 的 JPEG 图片，硬件解码在我的板子上大约 8~15ms 就完成，CPU 占用几乎可以忽略，只有搬运数据和切换显存地址时会占一点总线带宽。这个差距意味着什么？如果你要做一个 10 张图的轮播，软解情况下光解码就要占掉 1 秒多，而硬解只需要不到 150ms，剩下的大把时间都可以留给 UI 动画和交互逻辑。
硬件解码还有一个对方案设计很关键的能力：支持 1/2、1/4、1/8 缩放输出。这意味着你可以用一张大图直接生成缩略图，不用为列表页单独存一份小图，省存储空间，也省解码时间。这一点后面我会专门讲怎么用。
不过硬件方案也有它的“脾气”。它只支持 Baseline JPEG，不支持 Progressive JPEG，手机或相机拍出来的图片如果带了渐进式编码，H743 是解不了的。另外输入缓冲区的内存对齐、输出缓冲区的 Cache 一致性管理，都比软解严格得多，这也是我后面要重点讲的踩坑点。
1.3 什么情况下值得用这套方案
我给自己做过一个简单的选型判断标准，分享出来供你参考。
如果只是开机显示静态 logo，或者屏幕分辨率在 480x272 以下，图片素材又都是自己控制的，那软解完全够用，没必要引硬件解码，省得引入内存对齐和 Cache 管理的复杂度。但如果你要做类似相册轮播、拍照预览、HMI 界面、多级菜单缩略图这些，CPU 需要省下来跑 UI 交互，那硬解是更合适的选择。尤其是屏幕上 1024x600 以上的大屏，图像数据量一大，软解很容易遇到内存和速度双重瓶颈。
我最终把项目定在 H743 上，就是因为这套方案能同时满足三个条件：主频高、硬件 JPEG 可用、LTDC 和 DMA2D 齐全。如果你的项目需求和这个类似，可以直接参考这套源码的架构。
2. 整套系统的显示链路：SDRAM、LTDC、DMA2D怎么协作
2.1 为什么必须外挂SDRAM，内部RAM够不够算一笔账
先把内存账算清楚。H743 内置的 RAM 由 DTCM、ITCM、AXI SRAM、SRAM1/2/3 等组成，总容量大约 512KB，其中 AXI SRAM 只有 128KB。这个容量连一张 800x480 的 RGB565 图片都放不下——800 乘以 480 再乘以 2 字节，一帧就要 768KB。
JPEG 解码的完整流程需要三类缓冲区：源 JPEG 文件缓冲区、解码输出缓冲区、显示用 Framebuffer。如果显示分辨率是 1024x600，RGB565 格式，一个 Framebuffer 就要 1024x600x2 字节，约 1.17MB。如果做双缓冲，直接就是 2.35MB。说句不夸张的话，内部 RAM 连零头都不够。
所以外挂 SDRAM 不是可选项，是必选项。H743 的 FMC 接口可以很方便地接 SDRAM，我板子上用的是常见的 W9825G6KH 这类 16MB/32MB SDRAM，32 位数据总线，速度足够支撑 LTDC 刷新。SDRAM 挂到 FMC Bank1，映射地址从 0xC0000000 开始，用 32 位数据宽度，这是经过验证的稳定配置。
2.2 LTDC取图、DMA2D搬运、JPEG输出三者如何衔接
先把三块硬件的分工说清楚，这是理解整套源码的钥匙。
JPEG 解码器负责把 JPEG 码流解成一帧原始像素数据，解码输出可以写到 SDRAM 的指定地址。DMA2D 负责内存到内存的搬运、格式转换、混合和填充，它的核心价值在于不占 CPU，可以把 RGB888 转成 RGB565，也可以把缩略图从解码缓冲搬到显示层的指定窗口。LTDC 是显示控制器，它不断从 SDRAM 里的显存地址读取像素，按屏幕时序刷新到 LCD 面板。
这三者的关系可以这样理解：JPEG 解码器相当于“画画的”，DMA2D 相当于“搬运工”，LTDC 相当于“展示柜”。JPEG 解码输出到的地址，理想情况下可以直接就是 LTDC 的显示地址，关键是像素格式要一致。
我在源码包里用的是最省事的一条链路：JPEG 输出 RGB565，直接写到 SDRAM 显存地址，LTDC Layer0 从显存地址取图。这样解码完成后，不需要任何额外搬运，屏幕自然就显示出来了。同时我也预留了 DMA2D 路径，方便后续做颜色格式转换或者窗口裁剪。
2.3 硬件JPEG的输入输出格式怎么选
H7 硬件 JPEG 可以输出多种格式：YCbCr420、YCbCr422、YCbCr444、RGB565、RGB888、ARGB8888。选择的原则很简单：显示需要什么格式，就尽量让 JPEG 直接输出什么格式，避免二次转换。
RGB565 是嵌入式显示最常用的格式，LTDC 直接支持，总线带宽也只有 RGB888 的一半，我默认推荐这个。如果要做文字叠加、半透明效果，ARGB8888 会更方便，但内存占用翻倍，需要根据实际情况取舍。YCbCr 格式一般不建议直接作为显示格式用，除非你后面的图像处理流程需要原始 YUV 数据。
有个容易踩的误区：JPEG 解码器输出 YCbCr 之后再软件转 RGB，这等于把硬件解码省下来的时间又浪费回去了。硬件 JPEG 本身就能完成颜色空间转换，直接在配置里选好 RGB 输出就行，CPU 完全不用操心。
3. 解码代码核心：从JPEG文件头解析到HAL_JPEG_Decode跑通
3.1 第一步：解析SOF0拿到宽高
JPEG 文件头部不是固定长度，APP0、APPn 这些标记段长度各不相同，所以不能简单地读固定偏移。要拿到图像宽高，必须在文件里扫描标记段，找到 SOF0（FFC0）或 SOF2（FFC2）这类帧头标记，然后解析里面的数据。SOF0 的段结构是：FF C0 + 长度(2字节) + 精度(1字节) + 高度(2字节) + 宽度(2字节)。
这套源码里封装了一个解析函数，代码如下：
#include <stdint.h> int jpeg_get_size(const uint8_t *buf, uint32_t len, uint32_t *w, uint32_t *h) { const uint8_t *p = buf; const uint8_t *end = buf + len; if (p + 2 > end || p[0] != 0xFF || p[1] != 0xD8) { return -1; /* 不是有效的JPEG文件头 */ } p += 2; while (p + 4 <= end) { if (p[0] != 0xFF) { p++; continue; } uint8_t marker = p[1]; if (marker == 0xD8 || marker == 0xD9) { /* SOI或EOI */ p += 2; continue; } uint16_t seg_len = ((uint16_t)p[2] << 8) | p[3]; if (marker == 0xC0 || marker == 0xC1 || marker == 0xC2) { *h = ((uint32_t)p[5] << 8) | p[6]; *w = ((uint32_t)p[7] << 8) | p[8]; return 0; } p += 2 + seg_len; } return -1; }注意这里的高度和宽度顺序，SOF0 里先存高度再存宽度，和常见习惯相反，别搞反了。拿到宽高后，才能正确配置 JPEG 解码句柄的输出图像尺寸。
3.2 第二步：配置JPEG句柄并启动解码
用 CubeMX 生成工程时，JPEG 外设勾选 Enable 即可，HAL 库会自动把相关时钟和中断配置好。关键代码是 JPEG_ConfTypeDef 结构体的配置：
JPEG_HandleTypeDef hjpeg; JPEG_ConfTypeDef jcfg; jcfg.ImageWidth = jpeg_width; jcfg.ImageHeight = jpeg_height; jcfg.ImagePixelFormat = JPEG_RGB565; /* 直接输出RGB565 */ jcfg.ImageFIFOThreshold = 0x00; /* FIFO阈值，默认即可 */ if (HAL_JPEG_ConfigDecode(&hjpeg, &jcfg) != HAL_OK) { Error_Handler(); } /* 阻塞方式解码：把完整JPEG文件数据喂进去，输出到SDRAM显存地址 */ HAL_JPEG_Decode(&hjpeg, jpeg_file_buf, jpeg_file_len, sdram_display_buf);HAL_JPEG_Decode是一个阻塞调用，会一直到整张图片解码完成或者触发错误才返回。第一次跑通项目时，我推荐先用这种简单方式，方便定位问题。等整个流程稳定了，再改成 DMA 非阻塞方式，解码期间 CPU 可以继续跑界面逻辑。
要注意一点：jpeg_file_buf 必须指向包含完整 JPEG 数据的缓冲区，而且这个缓冲区最好 32 字节对齐，我在后面踩坑部分会详细说这个问题的严重性。
3.3 第三步：把解码结果送到显示屏，避免画面撕裂
如果解码输出地址和 LTDC 当前 Layer 的显存地址是同一个，那解码结束后屏幕会直接显示图片。但这里有个隐患：解码期间 LTDC 可能正在从同一个 buffer 读数据，往里面写数据会导致画面撕裂。
解决办法是用双缓冲。解码输出到 buffer A，LTDC 当前显示 buffer B，解码完成后在 LTDC 的垂直同步事件里把显示地址切到 A。这套源码里我是在行中断回调里做的切换：
volatile uint8_t frame_ready = 0; uint8_t active_buf = 0; uint8_t *sdram_display_buf[2]; void HAL_LTDC_LineEvenCallback(LTDC_HandleTypeDef *hltdc) { if (frame_ready) { HAL_LTDC_SetAddress(hltdc, (uint32_t)sdram_display_buf[active_buf], LTDC_LAYER_1); frame_ready = 0; } }解码完成回调里置位frame_ready，然后把 active_buf 切换成刚写完的 buffer。这样切换动作发生在安全的时间窗口，屏幕不会有撕裂。这里必须提醒一句：如果打开了 D-Cache，解码完成后要执行SCB_InvalidateDCache_by_Addr，否则 CPU 从 Cache 里读到的可能还是旧数据，画面切换后依旧花屏。
4. 源码包里踩过的坑：颜色错乱、DMA卡死、Progressive兼容性
4.1 颜色花了的真正原因：像素格式链路不匹配
先给结论：解码出来颜色不对、花屏，第一件事查像素格式链路，不要怀疑屏幕坏了。
有次我调试，JPEG 输出配成 RGB888，LTDC Layer 却配成 RGB565，显示出来整个图像偏紫偏蓝，颜色通道完全错位。原因是硬件解码器直接把 3 字节的 RGB888 数据按 RGB565 的方式解释，每 2 字节一组，高低位顺序全乱，颜色自然全错。解决办法是保证 JPEG 输出、DMA2D 转换、LTDC Layer 三个环节的像素格式完全一致，或者在中间显式用 DMA2D 做格式转换。
另外一次偏色问题更隐蔽，JPEG 输出的 YCbCr 转 RGB 时，硬件使用的转换矩阵默认值和显示屏的色彩特性有细微差别，导致整体饱和度偏高。这个在 H7 的 JPEG 外设里可以通过配置寄存器手动覆盖转换系数，但对大多数项目来说，默认矩阵就够用，不用过度调优。
4.2 输入缓冲不对齐导致的偶发卡死
H743 的 JPEG 模块对输入缓冲地址有对齐要求，官方要求地址至少 4 字节对齐，某些配置下推荐 32 字节对齐。我最早从 SD 卡读文件时用了一个普通数组缓存，编译器默认对齐只有 4 字节，结果解码时偶发死机，概率还很高。
排查方式是用调试器挂住，发现程序死在 JPEG 的 FIFO 写入流程里，错误标志指向输入数据错误。后面把 JPEG 输入缓冲定义改成 32 字节对齐，问题彻底消失。代码可以这样写：
__attribute__((aligned(32))) uint8_t jpeg_file_buf[2][512 * 1024];输出缓冲也建议做同样的对齐处理，尤其是在开启 MPU 和 D-Cache 后，对齐能减少 Cache 管理带来的复杂度，也让 DMA 搬运更高效。
4.3 手机拍出的JPEG解不了？硬件JPEG的格式边界
这是个容易被忽略的兼容性问题。手机或相机拍出来的 JPEG，有很大概率是 Progressive JPEG，这种格式对 H7 硬件 JPEG 解码器来说是无解的，会直接报解码错误。
我的判断方法很简单：在代码里解析 SOF 标记，如果是 FFC0 就是 Baseline，如果是 FFC2 就是 Progressive。如果发现是 Progressive，就明确提示用户图片格式不支持，或者在上位机统一转码。
做成产品时，一定要从源头控制图片素材格式，确保所有图片都是 Baseline JPEG。有些在线图片处理工具生成的 JPEG 带了大量 EXIF、XMP 扩展段，这些不影响解码，硬件 JPEG 会自动跳过。但源文件如果被截断，缺少 EOI 标记（FFD9），解码可能会卡住或输出不完整，所以解码前最好检查文件末尾的 EOI 标记。
4.4 D-Cache使能后的经典翻车：必须Clean和Invalidate
H743 的 Cortex-M7 核心带 D-Cache，很多工程模板默认不开启，但如果你开启了，JPEG 这类外设写内存的场景必须做 Cache 一致性处理，否则会出现各种莫名其妙的问题。
JPEG 解码器通过 DMA 把数据写进 SDRAM 时是绕过 CPU 的，如果 CPU 要读取这些数据，必须先执行 Invalidate，把 Cache 里的旧数据作废，否则 CPU 看到的是 Cache 里的陈旧内容。反向也一样，CPU 往 SDRAM 写入 JPEG 文件数据后，要执行 Clean，把数据真正刷到内存，否则外设读取的可能是残缺数据。
源码包里提供了一个标准的处理方式：
#if defined(__DCACHE_PRESENT) && (__DCACHE_PRESENT == 1U) SCB_CleanDCache_by_Addr((uint32_t *)jpeg_file_buf, jpeg_file_len); SCB_InvalidateDCache_by_Addr((uint32_t *)sdram_display_buf, disp_len); #endif这段代码分别放在解码前和解码后各执行一次，能解决绝大多数外设与 D-Cache 之间的数据一致性问题。如果你发现解码结果经常“时好时坏”，第一反应就应该是查 Cache 操作有没有做对。
5. 额外性能摸底与下一步扩展方向
5.1 一组实测数据：解码耗时与CPU占用
在 480MHz 主频、SDRAM 32 位总线、JPEG 输出 RGB565 的条件下，我这套源码的实测数据大致如下：
| 图片分辨率 | 源文件大小 | 解码耗时 | CPU占用 |
|---|---|---|---|
| 1024x600 | 约120KB | 约9ms | 几乎为0 |
| 1280x720 | 约180KB | 约13ms | 几乎为0 |
| 1920x1080 | 约350KB | 约24ms | 几乎为0 |
作为对比，同样环境下用 TJpgDec 软解1280x720，实测在 110ms 左右，CPU 占用拉满。硬件解码比软件解码快一个数量级，这个结论在我自己的测试环境里非常稳定。不同板子上数据会有浮动，但趋势不会变。
这套性能数据意味着，如果要做图片轮播，每张图解码只需要十几毫秒，加上解码前从 SD 卡读取文件的时间，整体感觉就是“切图几乎无感”。这就是硬件解码最直观的价值。
5.2 多图切换、缩放解码和断点续传的思路
硬件 JPEG 不止能解码，还能编码。比如用摄像头采集实时画面，或者把屏幕内容抓帧，然后把 RGB 数据硬编码成 JPEG 存到 SD 卡，性能也很可观。基于这个能力，可以做一个“拍照+相册”功能：摄像头抓帧 -> JPEG 编码存文件 -> JPEG 解码显示回放，全程 CPU 开销很低。
另一个实用方向是配合 FatFS 做多图列表。把图片路径做成数组，滑动或按键触发下一张解码，解码过程中先显示上一张，解码完成后再在垂直同步里切换显存地址，配合 DMA2D 做淡入淡出效果，这就是一个比较完整的相册应用了。
我还想提一下硬件 JPEG 的缩放输出。给列表页生成 1/4 尺寸缩略图时，可以直接把解码配置里的输出宽高改成原图的 1/4，硬件会自动完成降采样。这样一张源图就能满足“列表+详情”两套显示，不需要为每个尺寸单独存文件，省存储也省解码时间。
最后说一个我自己在调试这套源码时的习惯：每次换屏幕或者换一批 JPEG 素材，第一件事就是确认分辨率和解码格式，然后跑一次解码，看耗时有没突变。解码时间如果突然从 10ms 变成 200ms，不用怀疑，大概率是素材格式不对或者系统时钟被误配。做嵌入式显示，慢和乱都不可怕，可怕的是不知道为什么慢、不知道为什么乱。这套基于 STM32H743 的硬件 JPEG 图片解码显示源码，已经把核心链路都给你搭建好了，剩下的细节，就在自己的板子上慢慢磨吧。
本文还有配套的精品资源，点击获取
