简介：面向嵌入式开发者的STM32平台JPEG解码参考实现，针对资源受限微控制器上图像数据难以高效处理的问题，提供可直接移植的裸机解码方案。压缩包共2个文件，含1个C源程序与1份DOC技术文档，整体约43KB，源码实现DCT变换、量化与Huffman熵编码等关键环节，将JPEG二进制数据还原为RGB像素，运行开销小于2.6K，在Keil MDK下无需操作系统即可编译运行，解码一幅800×480彩色图片约需6秒。配套文档深入讲解JPEG编码标准流程、各阶段数据结构及在STM32上的实现技巧，便于理解源码逻辑并灵活定制。已有1027人学习，适合工业控制、智能家居、物联网设备等对实时性要求不高的嵌入式视觉场景开发者参考借鉴。
1. 一块只有 64KB RAM 的板子，怎么把一张 JPEG 显示到屏上
手里有块 STM32，屏幕也点起来了，想把一张 JPEG 图片直接显示上去，结果发现事情没那么简单：JPEG 是压缩格式，不能像 BMP 那样按像素直接往显存里怼，必须先解码。而解码一张 800×480 的图，光是 RGB888 的原始数据就要 1.1MB，可很多 STM32 型号的 SRAM 只有 64KB 到 192KB，连整帧都放不下。这份「JPEG图片STM32解码源程序」解决的正是这个矛盾——它把 JPEG 解码算法移植到 MCU 上，配合分块输出和行缓冲，让资源受限的芯片也能把 JPEG 解出来送屏。适合正在做嵌入式显示、想搞懂 JPEG 解码在裸机环境怎么落地的人，也适合手里有屏、有图、就是卡在解码这一步的开发者。
2. 解码器架构拆解：从文件头到像素行的完整链路
2.1 整体分层：文件解析、熵解码、IDCT、色彩转换
这套源码的结构基本遵循 JPEG 解码的标准流水线，只是每一层都针对 MCU 做了裁剪。最上层是文件解析，负责读 SOI、APPn、DQT、SOF0、DHT、SOS 这些标记段，把量化表、霍夫曼表、图像宽高、采样因子填进一个上下文结构体。中间层是熵解码，按 MCU 逐个读比特流，用霍夫曼表解出 DC 系数和 AC 系数，再反量化。底层是 IDCT（离散余弦逆变换）和色彩空间转换，把 8×8 的系数块还原成 YCbCr 像素，再转成 RGB 送显示。
分层的好处是每层可以单独替换。比如你的屏是 RGB565，就只改色彩转换那一层；如果你的图都是 4:2:0 采样，可以砍掉 4:4:4 的分支省 Flash。常见做法是把解码器做成一个.c加一个.h，对外只暴露三个函数：初始化、解码一帧、释放。源码里一般会有一个类似jpeg_decode_init、jpeg_decode_mcu、jpeg_decode_deinit的接口集合，调用方不需要知道内部霍夫曼表怎么建。
2.2 关键数据结构：上下文结构体里装了什么
解码器的状态几乎全在一个结构体里，这是裸机上最省事的做法，避免全局变量满天飞。典型字段包括图像宽高、采样因子、量化表指针、霍夫曼表、当前 MCU 坐标、比特流缓冲和行缓冲指针。下面是一个贴近源码风格的简化定义：
typedef struct { uint16_t width; /* 图像宽度，像素 */ uint16_t height; /* 图像高度，像素 */ uint8_t comp_num; /* 分量数：1=灰度，3=YCbCr */ uint8_t h_samp[3]; /* 各分量水平采样因子 */ uint8_t v_samp[3]; /* 各分量垂直采样因子 */ const uint8_t *qt[4]; /* 量化表，指向文件内数据 */ jpeg_huff_t huff_dc[4]; /* DC 霍夫曼表 */ jpeg_huff_t huff_ac[4]; /* AC 霍夫曼表 */ uint8_t *line_buf; /* 行缓冲，宽度 * 3 字节 */ uint32_t bit_buf; /* 比特流缓存 */ uint8_t bit_cnt; /* 缓存中有效位数 */ } jpeg_ctx_t;line_buf是整个设计的关键。它只存一行解码后的 RGB 数据，宽度乘 3 字节，800 像素的屏也就 2.4KB。每解完一个 MCU 行就 flush 一次到屏幕，内存占用和图像高度无关。bit_buf和bit_cnt是熵解码的取比特机制，JPEG 的霍夫曼码是变长的，必须用位缓冲逐位喂。qt和huff_*直接指向文件缓冲区里的表数据，不复制，省 RAM，但要求文件缓冲区在整帧解码期间不能被释放。
2.3 内存账本：为什么必须分块而不是整帧
算一笔账就明白为什么不能整帧解。一张 640×480 的 YCbCr 4:2:0 图，Y 分量 640×480=307200 字节，两个色度分量各 640×480/4=76800 字节，合计约 460KB。这还没算 IDCT 的中间块和输出 RGB。多数 Cortex-M3/M4 的 SRAM 在 64KB 到 256KB 之间，整帧方案直接出局。
分块方案的内存占用大致是：文件读缓冲（可以流式读，几百字节）、一行 YCbCr 或 RGB 行缓冲（宽度×3）、每个分量的 8×8 系数块（64×2 字节）、IDCT 临时数组（64×4 字节）。加起来通常不到 8KB，剩下的 RAM 全留给应用。代价是解码器必须支持「按 MCU 行推进」的状态机，不能一次性解完。源码里一般用一个decode_mcu_row之类的函数，每次处理一行 MCU，返回后由调用方决定是否送屏。
提示：如果你的图是渐进式 JPEG（progressive），这套按行推进的基线解码器解不了。选图时确认是 baseline，用常见图像工具另存时选「基线」或「标准」即可。
3. 跑起来：从源码到屏幕点亮的最小闭环
3.1 工程搭建与文件组织
拿到源码后先别急着编译，先看清楚文件构成。这类工程通常包含解码核心（jpeg_dec.c/.h）、一个平台适配层（负责读文件、写屏、提供内存）、以及一个main.c演示。适配层是移植的关键，它把「从哪读 JPEG 字节」和「往哪写 RGB 像素」抽象成几个函数，解码核心不直接碰硬件。
建议的目录组织如下，把核心和适配分开，换平台时只动适配层：
project/ ├── core/ │ ├── jpeg_dec.c # 解码核心，与硬件无关 │ └── jpeg_dec.h ├── port/ │ ├── jpeg_port.c # 读文件、写屏、内存申请 │ └── jpeg_port.h ├── app/ │ └── main.c # 演示：读图 -> 解码 -> 送屏 └── res/ └── test.jpg # 基线 JPEG 测试图移植时先实现jpeg_port.h里声明的几个函数：port_read（从 Flash 或 SD 卡读指定偏移的字节）、port_write_line（把一行 RGB 写到屏幕指定行）、port_malloc/port_free（如果解码器需要动态分配行缓冲）。读文件这块，如果图放在外部 Flash，用 QSPI 或 SPI 读；放 SD 卡就走 FatFs 的f_read。写屏则对接你的 LCD 驱动，注意颜色格式要和解码输出一致。
3.2 解码主循环：一次解一行 MCU
主循环的骨架很固定：打开文件、解析头、按 MCU 行循环、每行输出、收尾。下面这段是演示代码的典型形态：
jpeg_ctx_t ctx; uint8_t ret; /* 1. 初始化，传入读文件回调 */ ret = jpeg_decode_init(&ctx, port_read, file_base); if (ret != JPEG_OK) { printf("init fail: %d\n", ret); /* 常见：不是 baseline 或表缺失 */ return; } /* 2. 按 MCU 行推进，每行解完立即送屏 */ while (jpeg_decode_mcu_row(&ctx) == JPEG_OK) { port_write_line(ctx.cur_y, ctx.line_buf, ctx.width); } /* 3. 释放内部资源 */ jpeg_decode_deinit(&ctx);jpeg_decode_init里做的是扫描标记段、建霍夫曼查找表、分配行缓冲。jpeg_decode_mcu_row每次解一行 MCU，内部对每个 MCU 做熵解码、反量化、IDCT、上采样、色彩转换，结果写进line_buf，同时更新cur_y。port_write_line把这一行写到屏幕对应行。循环直到cur_y到达图像高度，函数返回结束码。
参数上要留意file_base，它是 JPEG 数据在存储介质里的起始偏移。如果图嵌在固件里，就是数组地址；如果在文件系统里，就是文件起始扇区换算出的偏移。port_read的签名一般是int port_read(void *buf, uint32_t offset, uint32_t len)，返回实际读到的字节数，解码器靠它做流式读取，不需要把整个文件读进 RAM。
3.3 验证：先灰度后彩色，先小图后大图
第一次跑别直接上大彩图，容易一屏花屏还找不到原因。按这个顺序验证：先解一张 64×64 的灰度 JPEG，确认能出图且形状正确，说明文件解析、熵解码、IDCT 这条链路通了；再换 64×64 彩色，验证色彩转换和采样因子处理；最后上目标分辨率。每步失败时看返回值，解码器一般会区分「头解析失败」「霍夫曼码非法」「数据截断」几类错误，对着返回值定位比盲猜快得多。
如果屏幕是 RGB565，而解码器输出 RGB888，中间要做一次转换。转换放在port_write_line里最省事，逐像素(r>>3)<<11 | (g>>2)<<5 | (b>>3)。注意字节序，有些屏驱动要高低字节交换，花屏但形状对，八成是这里。
4. 核心代码逐段讲：熵解码、IDCT 与色彩转换
4.1 霍夫曼解码：变长码怎么快速查表
JPEG 的霍夫曼码最长 16 位，逐位比较会很慢。常见做法是建一张查找表，用比特流的前 N 位直接索引，一次拿到码长和符号。源码里一般有一个huff_decode函数，配合bit_buf取位：
/* 从比特流取 n 位，不足则从 port_read 续读 */ static uint32_t get_bits(jpeg_ctx_t *ctx, uint8_t n) { while (ctx->bit_cnt < n) { uint8_t b = port_read_byte(ctx); /* 流式读一个字节 */ ctx->bit_buf = (ctx->bit_buf << 8) | b; ctx->bit_cnt += 8; } ctx->bit_cnt -= n; return (ctx->bit_buf >> ctx->bit_cnt) & ((1u << n) - 1); } /* 解一个霍夫曼符号：先查表拿码长，再取附加位 */ static int huff_decode(jpeg_ctx_t *ctx, const jpeg_huff_t *h) { uint16_t code = 0; for (uint8_t len = 1; len <= 16; len++) { code = (code << 1) | get_bits(ctx, 1); if (h->valid[len] && code < h->maxcode[len]) return h->val[h->offset[len] + code]; } return -1; /* 非法码，数据损坏或表错 */ }get_bits是位缓冲的核心，bit_buf左移补新字节，bit_cnt记录有效位数，取位时右移掉多余位再掩码。huff_decode用逐位累积加maxcode比较的方式，虽然不如大查找表快，但代码小、RAM 省，适合 Flash 紧张的型号。valid[len]标记该长度是否有码字，offset[len]是该长度码字在val数组里的起始下标。如果返回 -1，先查文件是不是被截断，再查 DHT 段是否完整。
4.2 反量化与 IDCT：8×8 块的定点实现
熵解码拿到的是量化后的系数，要先乘量化表还原，再做 IDCT。MCU 上一般用定点整数 IDCT，避免浮点开销。源码里常见的是 AAN 或基于整数近似的快速 IDCT，核心是把 8×8 的二维变换拆成两次一维变换，中间结果用int32_t防溢出：
/* 简化示意：先反量化，再对每行做一维 IDCT，最后转置再对列做一次 */ static void idct_block(const int16_t *coef, const uint8_t *qt, uint8_t *out) { int32_t tmp[64]; for (int i = 0; i < 64; i++) tmp[i] = (int32_t)coef[i] * qt[i]; /* 反量化 */ idct_1d_rows(tmp); /* 行方向一维 IDCT */ idct_1d_cols(tmp); /* 列方向一维 IDCT */ for (int i = 0; i < 64; i++) { int32_t v = (tmp[i] >> 3) + 128; /* 加偏置，缩放 */ out[i] = v < 0 ? 0 : (v > 255 ? 255 : v); /* 钳位到 0~255 */ } }coef是熵解码出来的 64 个系数，按 zigzag 顺序，进 IDCT 前要先还原成自然顺序。qt是量化表，逐元素相乘完成反量化。两次一维 IDCT 之间要做转置，或者直接写一个行列通用的内核。最后的>>3是缩放因子，具体位数取决于所用 IDCT 算法的定点精度，改这里会导致整体亮度偏移，别乱动。钳位不能省，否则溢出会在图上表现为亮斑或暗斑。
4.3 上采样与 YCbCr 转 RGB：4:2:0 怎么补像素
4:2:0 采样下，色度分量只有亮度的一半宽高，一个色度像素对应 2×2 的亮度像素。上采样就是把色度值复制或插值到对应位置。简单做法是最近邻复制，画质一般但快；好一点用双线性插值。源码里通常按 MCU 处理，一个 16×16 的 MCU 里 Y 是 4 个 8×8 块，Cb 和 Cr 各 1 个 8×8 块。
色彩转换用标准公式，定点化后大致是：
/* YCbCr -> RGB，输入已减 128 的色度 */ r = y + ((91881 * cr) >> 16); g = y - ((22554 * cb + 46802 * cr) >> 16); b = y + ((116130 * cb) >> 16);系数是标准转换矩阵乘 65536 再取整的结果，>>16还原。cb、cr要先减 128 变成有符号。算完同样要钳位到 0~255。如果出图整体偏绿或偏紫，先查这里是不是漏了减 128，或者系数抄错。上采样和色彩转换通常合在一个循环里做，逐像素算完直接写进line_buf，省一次遍历。
5. 避坑与排查：花屏、卡死、颜色错位的真实原因
5.1 现象：屏幕花屏但能看出图像轮廓
原因多半是字节序或颜色格式不匹配。解码器输出 RGB888，屏驱动按 RGB565 收，或者高低字节反了，就会出现轮廓在但颜色乱。解决：在port_write_line里确认转换公式和字节序，RGB565 下逐像素拼(r>>3)<<11 | (g>>2)<<5 | (b>>3)，若屏要大端就交换高低字节。先用纯色测试图验证写屏函数本身没问题，再排查解码输出。
5.2 现象：解到一半卡死或 HardFault
原因通常是行缓冲越界或比特流读越界。line_buf按width*3分配，但某些采样因子下每行 MCU 数向上取整，实际写入可能多出几个像素。解决：分配时按((width+15)/16)*16*3留余量，或在写line_buf前做边界判断。另外检查port_read在文件末尾的返回值，解码器读到 EOF 还继续取位就会读飞。
5.3 现象：图像整体偏亮、偏暗或发灰
原因在 IDCT 的缩放因子或电平偏置。JPEG 的 DCT 系数是围绕 0 的，IDCT 后要加 128 偏置才是像素值。如果>>3的位数和算法不匹配，或者漏加 128，整体亮度就错。解决：用一张已知的灰度渐变图对比，逐段检查反量化、IDCT 缩放、偏置三个环节，别同时改多处。
5.4 现象：只有部分图像显示，下半截空白
原因可能是 MCU 行循环提前退出，或者cur_y更新逻辑有误。检查jpeg_decode_mcu_row的返回条件，以及cur_y是按 MCU 行递增还是按像素行递增，两者混淆会导致只写了上半部分。解决：打印每行cur_y和返回值，确认循环次数等于(height+15)/16向上取整。
5.5 现象：换一张图就解不了
原因多半是这张图不是 baseline，或者用了算术编码、多扫描。这套解码器只认基线霍夫曼编码。解决：用图像工具确认编码方式，另存为基线 JPEG；同时检查是否带 EXIF 缩略图，某些文件在 SOS 前有额外段，解析时要能跳过未知 APPn 段而不是报错退出。
6. 二次开发：把解码器改成适合自己板子的形态
改造的第一步是砍。如果你的产品只显示固定尺寸的图，可以把解码器里所有和尺寸无关的分支去掉，比如固定 4:2:0、固定单张量化表、去掉 4:4:4 和灰度路径，Flash 能省下不少。我一般会先编译看 map 文件，找出解码核心占了多少，再决定砍哪块。砍完用同一组测试图回归，确保输出逐像素一致。
第二步是接 DMA。现在port_write_line是 CPU 逐像素写屏，800 像素一行要写 2400 字节，占不少时间。如果屏接口支持 DMA，把line_buf的地址直接交给 DMA，CPU 去解下一行，解码和送屏就能重叠。注意双缓冲：DMA 在写 A 缓冲时，解码器写 B 缓冲，写完交换。行缓冲从一份变两份，内存多几百字节，换来的帧率提升很明显。
第三步是缓存常用图。如果设备反复显示同一批图，可以把解码后的 RGB 数据按行压缩存进外部 Flash，下次直接读，跳过解码。或者更简单，把解码结果转成 RGB565 存起来，一张 320×240 的图约 150KB，外部 Flash 放几十张没问题。改造时把「解码」和「取像素」抽象成两个函数指针，运行时按图源切换，代码不用大改。
| 改造方向 | 改动点 | 收益 | 风险 |
|---|---|---|---|
| 裁剪功能 | 去掉非 4:2:0 分支 | Flash 减小 | 换图源需重新编译 |
| DMA 送屏 | 双行缓冲 + DMA 回调 | 帧率提升 | 缓冲同步要仔细 |
| 解码结果缓存 | 外部 Flash 存 RGB565 | 重复显示零解码 | 占存储空间 |
验证方法很直接：改完跑一遍原测试图，用逐像素比对工具确认和改前一致；再测帧率和 RAM 占用，确认没有回退。有一次我为了省事把行缓冲改成按 MCU 块输出，结果上采样时跨块边界取错色度，图上出现一条条竖纹，查了半天才发现是缓冲边界没对齐。从那以后我每次改缓冲策略，都先用一张纯红纯蓝的棋盘图跑一遍，边界问题一眼就能看出来。希望帮到你。
本文还有配套的精品资源，点击获取
