简介在嵌入式视觉应用开发中STM32等微控制器因内存与算力有限直接解码JPEG图片往往面临性能瓶颈。这份JPEG图片STM32解码源程序面向需要在裸机或Keil MDK环境中实现图片显示的软硬件工程师提供了一套可移植、可裁剪的完整解码方案。压缩包共2个文件分别是一个C语言解码源文件与一份Word编解码详解文档整体体积仅43KB精简紧凑。C源程序实现了DCT逆变换、反量化、Huffman熵解码等关键环节运行内存开销小于2.6K典型条件下解码800×480彩色图片约6秒适合温控、仪表、门禁等实时性要求不高的场景同时程序不依赖操作系统可配合中断与定时器使用。配套文档对JPEG编码流程、数据结构及STM32移植与优化技巧做了完整阐述便于读者深入理解源码并结合不同图片尺寸、速度要求灵活定制。已有1027人学习下载适合嵌入式入门学习者、产品开发者以及需要快速集成图片解码功能的项目团队参考。1. STM32 为什么需要一份 JPEG 解码源程序做带屏嵌入式设备的人基本都撞过同一堵墙图片资源一多Flash 先爆RAM 也吃紧。早期方案是把图片转成 C 数组一张 320×240 的 RGB565 图片就是 150KB Flash温控面板存个二三十张界面图芯片容量直接翻三倍。JPEG 图片 STM32 解码源程序解决的就是这个痛点让 MCU 直接消费 JPEG 字节流解码过程中只保留几 KB 工作区边解边把像素喂给 LCD而不是把整帧图放在内存里。做温控面板、手持仪表、带屏 IoT 设备、甚至低成本串口屏方案的工程师都值得把这条路径吃透。很多人一听“STM32 上解 JPEG”就觉得不靠谱觉得这是 PC 端 libjpeg 才干的事。实际上以目前的 Cortex-M 主频320×240 的 JPEG 软解在几十毫秒到一两百毫秒级别是可接受的而且很多界面切换场景并不需要高帧率。真正劝退人的不是 CPU 算力而是不会选解码源程序、不会写输入输出回调、不知道缓冲区怎么给最后被花屏和 HardFault 折腾到放弃。这篇文章就把这条路上最关键的选型、移植、内存账和坑一次性讲清楚。2. JPEG 解码在 STM32 上的真实流程它是一条流水线2.1 基线 JPEG 的五个阶段Huffman、反量化、Z 扫描、IDCT 与色度上采样JPEG 不是“打开图片”这种黑匣子操作它在解码器里是一条固定流水线。最常见的是基线 JPEG文件结构从FF D8的 SOI 标记开始接着是 DQT 定义量化表、SOF0 定义宽高和采样因子、DHT 定义 Huffman 表再到 SOS 之后才是真正的压缩数据。解码时压缩数据部分要依次经历五步先做 Huffman 解码还原出量化后的 DCT 系数再做反量化接着按 Z 字扫描把一维系数重排成 8×8 块然后做逆离散余弦变换得到像素差值最后做色度上采样和 YCbCr 到 RGB 的颜色转换。这五步里有三处最容易写错。第一是 Huffman 解码时的位流读取JPEG 的比特流是高位在前而且 Huffman 码长可变一个字节里可能横跨多个码字稍微移动一位整个画面就花掉。第二是 DC 系数的差分恢复每个 8×8 块的 DC 系数存的是与上一个块的差值源程序里通常维护一个last_dc[3]数组分别对应 Y、Cb、Cr 三个分量。第三是 CbCr 的上采样位置4:2:0 采样下 CbCr 的分辨率只有 Y 的四分之一插值时的像素对齐不对就会出现整片偏色。理解这条流水线的意义主要在调 bug。比如花屏时你要判断是位流错位还是颜色转换错偏绿时先怀疑 CbCr 交换而不是去调 LCD 参数。另外JPEG 解码是按 MCU 块推进的MCU 也就是最小编码单元对 4:2:0 来说是 16×16 像素。解码器每解完一个或一行 MCU就会调用一次输出回调把这块 RGB 数据交给用户。后面写输出回调时你会反复用到这个概念。2.2 为什么 STM32 上不能照搬 PC 的解码方式PC 上解 JPEG 一般是 libjpeg 这类成熟库它的调用方式是一次性给整张图的内存地址内部用大堆缓冲处理完整帧解完之后你再拿到整个位图。这套模型搬到 STM32 上立刻崩一张 640×480 的 RGB565 位图就要 600KB RAM很多 MCU 整颗芯片的 SRAM 才 128KB。所以 STM32 上的轻量解码源程序几乎全是“流式”模型库只保留解码当前 MCU 行所需的状态解完一行就通过回调交出去然后缓冲区复用给下一行。内存之外第二道坎是浮点。PC 端 IDCT 用浮点随便算Cortex-M 上大部分型号没有硬件浮点单元纯浮点 IDCT 会吃掉大量 CPU 时间。轻量解码源程序通常采用定点 IDCT或者对 IDCT 结果做移位缩放精度略低于 PC 但人眼看不出差异。你在移植时不需要自己重写 IDCT但要确认源程序里默认用的是定点实现。有些从 Linux 或桌面平台移植过来的代码里面嵌了双精度浮点表在 STM32 上编译能过跑起来慢好几倍。还有一点是字节序。JPEG 文件内部的大多数字段是大端存储STM32 默认小端。好的源程序在解析 DQT、SOF0 这些段时已经做了字节序转换但你如果自己往源程序里加自定义段解析一定要记得手动(buf[0] 8) | buf[1]直接用uint16_t*强转读出来的数永远不对。2.3 软解还是硬件 JPEG 外设按芯片型号选型STM32 家族里有一部分型号内置了硬件 JPEG 编解码器比如 F7 系列和 H7 系列的部分大封装型号。硬件 JPEG 外设支持直接输入 JPEG 码流输出 YCbCr 数据速度比软解快一个数量级而且不占 CPU。同时它也有明显门槛需要 DMA 配合大一点的缓冲区输出格式固定为 YCbCr 4:2:2 或 4:4:4后续还要自己做颜色转换和缩放驱动代码写起来比软解复杂得多。对绝大多数项目硬件外设的收益只在频繁解码大图时才体现得出来。软件解码源程序的适用面就宽多了。STM32F1、F4 这些没有硬件 JPEG 外设的型号只能软解而且软解代码只有几千行、几个 .c 文件交叉编译零依赖一套代码在所有 Cortex-M 上通用。它在解码过程中天然支持输出缩放比如源图是 320×240你只需要 160×120 的缩略图可以按 1/2 或 1/4 缩放直接解出省内存也省时间。我一般选型就一句话主频 72MHz 以上、RAM 还有余量的项目优先软解如果是开机就要秒开好几张大图、CPU 还要同时跑协议栈的项目才考虑硬件 JPEG 外设。方案适用芯片代码复杂度解码速度内存压力主要成本软件解码全系 M3/M4/M7低移植 3 个文件慢但可接受工作区几 KB占 CPU 时间硬件 JPEG 外设部分 F7/H7 型号高需 DMA 和颜色转换快一个数量级需要稍大的 DMA 缓冲驱动调试周期长3. 在 STM32 上跑通 JPEG 解码源程序最小可复现的代码骨架3.1 输入回调解码器只认字节流不认 SD 卡还是 Flash轻量 JPEG 解码源程序的外围接口一般只有两个回调输入回调负责供数输出回调负责收像素。输入回调的典型签名是解码器想要ndata字节你把数据拷到buf返回实际供给的字节数当buf为 NULL 时意思是“跳过这段数据不做拷贝”主要用在跳过 JPEG 的 APP0、注释段这些解码器不关心的内容。我习惯把所有输入抽象成一个小结构体无论图片来自 SD 卡、外部 Flash 还是内存数组都统一走这个接口。typedef struct { const uint8_t *base_addr; /* JPEG 文件内存镜像的起始地址 */ uint32_t file_size; /* 文件总长度 */ uint32_t read_pos; /* 当前读取偏移 */ } jpeg_stream_t; /* 解码器输入回调buf 非空时读取数据buf 为 NULL 时跳过数据 */ uint32_t jpeg_cb_input(JPEG_DEC *dec, uint8_t *buf, uint32_t ndata) { jpeg_stream_t *st (jpeg_stream_t *)dec-user_data; uint32_t remain st-file_size - st-read_pos; if (buf NULL) { /* 跳过场景只把偏移往前推即可 */ if (ndata remain) ndata remain; st-read_pos ndata; return ndata; } if (ndata remain) ndata remain; memcpy(buf, st-base_addr st-read_pos, ndata); st-read_pos ndata; return ndata; }这段代码的关键是buf NULL分支。很多人在移植时报错说解码器反复读取文件却始终不开工就是没处理跳过逻辑。JPEG 文件头部有很多附加段解码器解析段结构时常常要“看一眼再跳过”如果跳过分支持续返回 0解码器会认为数据流断了直接返回格式错误。另外remain的计算一定要用文件大小减去当前位置不要盲目信任源程序会把ndata控制在合法范围内边界溢出最容易出 HardFault。如果图片放在 SD 卡而不是内存镜像思路完全一样buf NULL时调用文件系统的 seek 接口向前移动buf非空时调用 read 接口。唯一要注意的是文件系统读取一般按扇区缓冲每次ndata可能只有几十字节频繁 seek 会把 SD 卡速度拖垮后面踩坑章节会专门讲这个。3.2 输出回调把解码出的 MCU 行变成 LCD 上的像素行输出回调是解码源程序里最核心的落地接口。解码器每完成一个 MCU 或一行 MCU就把一块像素数据放进bitmap同时用一个矩形结构体告诉你这块像素在整张图里的坐标范围。你要做的就是把这块数据写到 LCD 的对应位置。绝大多数 SPI 屏或并口屏都支持先设置显示窗口再连续写像素数据这正好和回调模型匹配。/* 输出回调把解码出来的矩形像素块写入 LCD */ uint32_t jpeg_cb_output(JPEG_DEC *dec, void *bitmap, JRECT *rect) { uint16_t *pixel (uint16_t *)bitmap; /* RGB565 输出格式 */ int width rect-right - rect-left 1; for (int y rect-top; y rect-bottom; y) { lcd_set_window(rect-left, y, rect-right, y); lcd_write_data((uint8_t *)pixel, width * 2); /* LCD 数据按字节写 */ pixel width; } return 1; /* 返回 1 继续解码返回 0 可提前终止 */ }这里的bitmap不是整行像素的数组而是当前 MCU 行的局部数据但它的像素顺序和rect坐标是一一对应的所以按行拷出去即可。width用right - left 1计算不要直接用宏定义里的屏幕宽度因为解码器可能输出的是图片右边缘的不完整块比如图片宽度不是 16 的整数倍时最后一块会比较窄。注意lcd_write_data的类型。如果你的 LCD 驱动是按字写入而这里传的是字节指针一定要做强制转换并明确长度是width * 2。RGB565 一个像素两个字节STM32 小端模式下内存里是高字节在后很多屏控制器恰好要高字节在前这时候花屏不是解码问题而是字节序问题在后面踩坑章节单独说。3.3 主流程查信息、定缩放、开解三个参数决定内存和速度主流程把输入输出回调串起来。常见的轻量解码源程序的调用方式大同小异先 open再取图片信息设置缩放比最后执行解码。open 的时候要传入一块工作缓冲区这个缓冲区供 Huffman 表、反量化表和 MCU 行缓冲复用是整个移植里最需要认真对待的参数。/* 工作缓冲区4 字节对齐大小按实际提示调整 */ static uint8_t work_buf[4096] __attribute__((aligned(4))); static JPEG_DEC jdec; static JPEG_IMAGE_INFO info; static const uint8_t my_jpeg_file[] { /* 这里放一张 JPEG 图片的完整字节流可以在 PC 端转成数组 */ }; int jpeg_display_task(void) { jpeg_stream_t stream { .base_addr my_jpeg_file, .file_size sizeof(my_jpeg_file), .read_pos 0, }; /* 打开解码器传入输入/输出回调和用户上下文 */ if (JPEG_Open(jdec, jpeg_cb_input, jpeg_cb_output, work_buf, sizeof(work_buf), stream) ! 0) { return -1; /* 文件头解析失败或 work_buf 不够 */ } JPEG_GetImageInfo(jdec, info); /* 0原图, 11/2, 21/4, 31/8 缩放解码 */ JPEG_SetScale(jdec, JPEG_SCALE_HALF); if (JPEG_Decode(jdec) ! 0) { return -2; /* 解码中途出错 */ } return 0; }work_buf的大小和缩放比直接决定 RAM 占用。开大一点不会更快开小了解码器会在JPEG_Open阶段直接报错因为 Huffman 表和量化表放不下。我一般做法是先给 4096 字节如果 open 返回缓冲区不足再往上加直到能正常通过。实际项目里可以依据图片最大分辨率算出一个稳定值后面内存章节会讲怎么算。缩放比则是个性价比极高的参数从原图直接解出 1/2 大小的图解码耗时大约降到原来的四分之一因为每个方向的像素都少了一半。4. 内存与存储预算用几 KB 工作区解大图的收支账4.1 按 MCU 行输出而不是整帧输出省下的就是几百 KB很多从 PC 转过来的开发者会下意识找“解码后的完整位图放在哪”这就是思路没转过来。轻量解码源程序的设计目标就是不保留整帧位图它内部只维护当前正在解码的若干个 MCU 行解完一行立即调输出回调调完这块缓冲区就复用给下一行。对这种模型RAM 占用和图片总像素数基本无关只和 MCU 行缓冲大小以及工作区大小有关。比如同样一张 800×480 的图片如果按整帧 RGB565 算需要 768KB RAM大多数 STM32 直接超限。但按 MCU 行输出解码器内部只需要同时保存 Y、Cb、Cr 各一个 MCU 行的数据4:2:0 下一个 MCU 行是 16 像素高、800 像素宽Y 需要 800×16 字节CbCr 各需要 800×8 字节加起来不到 25KB。再算上 Huffman 表和量化表的几千字节总 RAM 占用也就 30KB 级别这在 STM32F4 上完全可行。实际项目中我还会把输出直接导向 LCD 的窗口写入不再额外分配行缓冲。SPI LCD 一次写一个 MCU 行写完继续解下一个假如图片需要从下往上显示只要调整输出回调的写入坐标就行了内存一分钱不用多花。如果屏本身带帧缓冲比如 RGB 接口屏加 SDRAM那可以先把解码输出写到 SDRAM 的帧缓冲里再统一刷新但那是另一种内存模型了。4.2 4:2:0 采样下的隐藏内存结构CbCr 比想象中更省JPEG 的色度子采样对内存占用影响很大。最常见的 4:2:0 采样每 16×16 像素的区域里Y 分量保存 4 个 8×8 块Cb 和 Cr 各只保存 1 个 8×8 块。也就是说解码器的中间缓冲面积是 16×16 的 Y 加 8×8 的 Cb 加 8×8 的 Cr而不是三份同样的 16×16。这意味着大多数情况下内存占用只相当于 YUV444 的一半移植时可以往小了估。但也有反例。有些屏幕截图工具会输出 4:4:4 采样或不做子采样的 JPEG这时每个 8×8 区域里 Y、Cb、Cr 各有一个块中间缓冲直接翻倍。如果你的图片来源不可控建议在解码前用图片信息里的采样因子做个判断遇到 4:4:4 的图就提前把工作区调大否则解码器走到一半可能输出错误或者进入输出回调的数据量超出预期。判断方法很简单SOF0 段里 Y 的采样因子是 2×2CbCr 是 1×1就是 4:2:0CbCr 也是 2×2就是 4:4:4。另一个容易忽略的隐藏开销是源程序内部的“缩放缓冲”。设置 1/2 缩放时解码器通常会先把原始 MCU 解出来再在内部做水平和垂直抽值最后输出缩小后的行。这个中间缓冲不会比原始 MCU 更大所以不会爆内存但耗时是实打实存在的。1/8 缩放看起来最省输出实际上内部还是要解完整的 MCU不要误以为 1/8 缩放能把解码耗时也降到八分之一。4.3 图片放 SD 卡还是外部 Flash流式读取与内存镜像两种姿势图片资源的存放位置影响输入回调的实现方式。放在内存镜像里最简单把整张 JPEG 图用工具转成 C 数组烧进内部 Flash 或外部 SPI Flash输入回调直接拷内存。这种方式适合图不多的小项目一张 320×240 的 JPEG 通常只有十几 KB内部 Flash 塞得下。缺点是大图或图片数量多了以后内存镜像会占掉大量 Flash而且 SD 卡上的图片没法直接这么搞。放在 SD 卡上则要求输入回调里做文件读取。但 SD 卡读取有几个现实问题。轻量解码源的读取请求往往很碎一次只要几十个字节如果每次回调都直接发一条 SPI 或 SDIO 读命令总时间会非常难看。常规做法是在回调里维护一个扇区缓存按 512 字节为单位预读ndata请求命中的时候直接从缓存里拷只有跨扇区才触发一次新的读命令。/* 带扇区缓存的输入回调片段 */ uint32_t jpeg_cb_input_sd(JPEG_DEC *dec, uint8_t *buf, uint32_t ndata) { if (buf NULL) { file_offset ndata; return ndata; } while (ndata 0) { uint32_t sector_off file_offset % 512; uint32_t sector_left 512 - sector_off; uint32_t copy_len (ndata sector_left) ? ndata : sector_left; if (sector_cache_valid ! file_offset / 512) { sd_read_sector(file_offset / 512, sector_cache); sector_cache_valid file_offset / 512; } memcpy(buf, sector_cache sector_off, copy_len); file_offset copy_len; buf copy_len; ndata - copy_len; } return buf 原请求大小; /* 实际代码中要保存原始 ndata */ }扇区缓存这块要注意file_offset是全局或存在上下文里不能被解码器的多次回调打断。我踩过一次坑缓存有效扇区号判断用错了变量导致每读几个字节就重新读一次扇区解码一张 20KB 的图耗时从 200ms 涨到两秒。调试时在输入回调里加个计数器统计调用次数和平均每次请求字节数如果平均请求不到 32 字节就说明扇区缓存没起作用。5. STM32 JPEG 解码源程序踩坑记录花屏、HardFault、打不开图的五种典型状态5.1 彩色花屏且有固定规律先查颜色顺序和字节序现象是画面能看出轮廓但颜色像打翻的调色盘尤其是绿色和紫色大面积错乱或者在 8×8 方块边界处有明显色差。这种花屏十有八九不是解码器算错而是数据走出解码器之后的格式问题。原因有两个一是解码源程序输出的是 RGB888而你按 RGB565 直接丢给 LCD每个像素少了低字节导致颜色错乱二是 RGB565 在内存里的字节顺序和屏控制器期望相反。解决办法是先在解码器初始化前把输出格式固定下来。大多数轻量源程序提供一个颜色转换宏或模式项RGB565 和 RGB888 只能选一个不能靠屏驱动去硬调。确认输出格式后再看 LCD 驱动写入时的字节顺序RGB565 的高低位顺序在 SPI 屏上经常需要做一次交换。用纯红、纯绿、纯蓝三张小图测试是最快的方法纯红图显示成蓝色直接交换字节序。5.2 解码到一半进 HardFault工作缓冲对齐和 DMA 抢内存是两大元凶现象是解码器已经正常打开前几张图也显示了换到某一张图或者解码到某个进度就突然跳进 HardFault。最常见原因是工作缓冲区没有 4 字节对齐。轻量解码源程序内部会把工作区按字对齐拆成多个子块如果数组起始地址不是 4 的倍数内部指针运算会访问未对齐地址在 Cortex-M 上直接触发 HardFault。解决方式是在定义数组时加上__attribute__((aligned(4)))并检查编译器是否把它放到了对的地址。另一个更隐蔽的原因是 DMA。如果输出回调里用 DMA 向 LCD 推数据而 DMA 还没传输完成时解码器又调用了下一次输出回调去写同一块源缓冲区就会出现一边读一边写的竞争。翻车现场往往是时好时坏把优化等级换一下才稳定复现。解决方式有两个方向一是输出回调里等待 DMA 完成标志再返回二是准备两个行缓冲做乒乓切换解码器写 A 时 DMA 读 B下次再交换。5.3 解码一张小图要好几秒输入回调被碎片化读取拖死现象是同一张图在 PC 上秒开烧进 STM32 后按秒计而且换优化等级没有明显改善。不要急着怀疑 IDCT 性能先查输入回调的调用频率。把回调里加个计数打印出总共调了多少次、平均每次读多少字节。如果调用频次几千次且平均字节数很小说明你的读取策略有问题比如 SD 卡每次按单字节读或者扇区缓存失效。解决方式已经在上文说过做扇区级缓冲。对于放在内存镜像里的图片还有另一个加速技巧把base_addr指向的 JPEG 数组直接拷贝到 CCM RAM 或紧耦合内存里再解码。内部 Flash 在 Cortex-M 上读取有等待周期代码和图片数据混在同一个 Flash 总线里解码器频繁读图片数据会跟指令预取抢带宽。把图片放到更快的内存域可以让解码速度提升三四成。5.4 解码器报告格式不支持渐进式和 CMYK JPEG 打不开现象是有些图片解码器 open 失败或者解码到一半返回错误码而同一张图片换一个图片查看器又能正常打开。原因大概率是图片不是基线 JPEG。JPEG 有两种常见编码流程基线顺序编码和渐进式编码很多轻量解码源程序只支持基线。另外商用图库导出的 CMYK JPEG 也会被直接拒绝因为解码器只认 YCbCr 色彩空间。判断方法很直接用十六进制查看 JPEG 文件的 SOF 标记。FF C0是基线 JPEG 的 SOF0FF C2是渐进式 JPEG 的 SOF2FF C1是扩展顺序。如果文件头出现FF C2基本可以认定是渐进式。解决办法是在图片处理环节统一转成基线。各种图片处理软件里找“渐进式”或“Progressive”选项关掉它再另存同时确认色彩模型选 RGB 或 YCbCr不要选 CMYK。5.5 图能显示但位置不对坐标映射和显示方向要一起处理现象是解码正常、颜色正常但图片在 LCD 上显示时上下颠倒、左右镜像或者出现错位拼接。原因在于 JPEG 的坐标原点在左上角而很多 LCD 控制器的扫描方向默认是从右下角开始或者屏的窗口坐标设置对 x、y 有翻转。这是纯坐标映射问题不需要动解码器。解决方式是在输出回调里根据 LCD 的扫描方向做坐标换算。比如屏的扫描方向是自下而上那么rect-top应该映射到LCD_HEIGHT - rect-bottom - 1。不要每行都做for循环里重新计算提前把 x 方向偏移和 y 方向偏移算成四个变量放进一个坐标变换结构体输出回调里直接套公式。注意有些 LCD 驱动在设置了显示窗口后继续写像素是自动连续填充的这时只要保证窗口和像素数据的行顺序一致就不用手动跳来跳去。6. 最后的优化技巧乒乓缓冲推屏加 DWT 计时让解码耗时可见解码速度优化里性价比最高的一招是把输出回调和 LCD 数据传输并行起来。前面说过DMA 在传输时源缓冲区不能被解码器覆盖所以很多人的第一版代码是“回调里等 DMA 传完再返回”这会让解码速度被 LCD 总线速度死死拖住。换成乒乓缓冲后解码器写line_buf[0]时 DMA 传line_buf[1]下一次两者交换感觉上就是把 LCD 传输从解码路径里摘出去了。static uint16_t line_buf[2][320]; /* 两个行缓冲宽度按屏幕最大值 */ static uint8_t lcd_dma_sel 0; static volatile uint8_t lcd_dma_done 1; void lcd_dma_callback(void) { lcd_dma_done 1; } uint32_t jpeg_cb_output_pingpong(JPEG_DEC *dec, void *bitmap, JRECT *rect) { int width rect-right - rect-left 1; int height rect-bottom - rect-top 1; /* 等上一次 DMA 结束再复用当前缓冲 */ while (!lcd_dma_done); memcpy(line_buf[lcd_dma_sel], bitmap, width * height * 2); lcd_set_window(rect-left, rect-top, rect-right, rect-bottom); lcd_dma_start(line_buf[lcd_dma_sel], width * height * 2, lcd_dma_callback); lcd_dma_done 0; lcd_dma_sel ^ 1; return 1; }这段代码里lcd_dma_done标志是关键lcd_dma_start传入 DMA 完成回调回调里置位。因为解码是按顺序推进的DMA 完成标志天然形成了一个简单的生产者消费者同步。千万别在 DMA 没完成时就返回否则 DMA 还在读line_buf[0]解码器已经往里面写新数据了。双缓冲的意义不是消除等待而是把“必须等”的次数减半。验证优化效果别用眼睛估用 DWT 周期计数器。Cortex-M3 及以上的内核自带 DWT 单元可以精确读 CPU 周期数比 systick 的时间戳精度高得多CoreDebug-DEMCR | CoreDebug_DEMCR_TRCENA_Msk; DWT-CYCCNT 0; DWT-CTRL | DWT_CTRL_CYCCNTENA_Msk; uint32_t start DWT-CYCCNT; JPEG_Decode(jdec); uint32_t ms (DWT-CYCCNT - start) / (SystemCoreClock / 1000); printf(decode %lu ms\n, ms);DWT 计数在调试模式下会受仿真器停止影响测出来的数字偏大。正确姿势是脱离调试器、以 release 运行通过串口打印耗时。我自己的习惯是每次改完解码链路先记一组 DWT 数据确认耗时变化来自哪段代码而不是靠“体感流畅”去判断。这组数据会一路跟着你从方案验证走到量产调优比任何玄学都有用。希望这些从选型到落地的踩坑经验能帮你少走一段弯路。本文还有配套的精品资源点击获取