STM32平台差分升级（增量升级）算法实现详解：基于 DiffIAP 的功能深度解析

1. 引言：为何需要差分升级？

在现代嵌入式系统，尤其是物联网（IoT）、车联网（V2X）和工业智能终端设备中，远程固件升级（OTA）已成为产品生命周期管理的核心能力。然而，传统的整包升级（Full OTA）方式存在显著瓶颈：当固件体积动辄数百KB甚至数MB时，受限于通信带宽（如NB-IoT、LoRa、2G/4G窄带）、设备功耗预算以及Flash存储空间，整包下载不仅耗时长、流量成本高，还可能因传输中断导致升级失败。

为解决这一痛点，差分升级（Differential/Incremental Update）应运而生。其核心思想是：仅传输新旧固件之间的差异部分，从而将升级包体积压缩至原始固件的极小比例（如文档中所示，174KB固件仅因LED频率变更，差分包仅93字节）。

本文将深入剖析一套已在STM32平台上成功落地的开源差分升级方案——DiffIAP。我们将立足于其源代码（code-DiffIAP_V1.3_merged.txt），逐层解读其架构设计、核心算法、关键数据结构与API接口，全面揭示其如何在资源受限的MCU环境中高效、安全地完成增量升级任务。

---

2. 整体架构：双端协同，算法分离

DiffIAP系统由两个逻辑上分离但功能上紧密耦合的部分组成：

• 上位机端（PC/QTCreator）：负责差分包生成。
• 下位机端（STM32 MCU）：负责差分包应用（即“打补丁”）。

这种分离设计使得计算密集型的差分生成过程在PC端完成，而MCU端只需执行轻量级的解压与还原操作，完美适配嵌入式环境。

2.1 上位机端：差分包生成流程

上位机端的核心任务是调用 bsdiff() 和 LZzip() 两个函数，其流程如下：

1. 加载旧固件（old.bin）与新固件（new.bin）至内存。
2. 调用 bsdiff()：该函数基于后缀数组（Suffix Array）算法，高效比对两个二进制文件，找出所有可复用的相同数据块，并将差异部分编码为原始的差分数据流。此过程计算量大，但结果精准。
3. 计算CRC32校验值：分别计算旧固件与新固件的CRC32值，用于后续MCU端的校验。
4. 调用 LZzip()：使用LZ77无损压缩算法对原始差分数据进行压缩。压缩级别（zip_flag）可调，以平衡压缩率与MCU解压时的内存开销。
5. 封装补丁包头：在压缩后的数据前添加20字节的头部信息，包含：
   • 旧/新固件长度（4字节 each）
   • 旧/新固件CRC32（4字节 each）
   • 补丁包自身长度（4字节）
   • 压缩标志（1字节）
6. 输出最终补丁文件（.patch）。

2.2 下位机端：差分包应用流程

MCU端的任务是安全、可靠地将补丁包应用到当前固件上，生成新固件。其核心是三个API函数的调用：

1. Get_PatchFileInfo_Check()：校验与信息提取。
2. do_BsPatch()：核心打补丁执行。
3. do_Get_NewFileCRC()（可选）：结果完整性校验。

整个过程是流式处理的，无需将整个补丁包或新固件加载到RAM中，极大节省了内存。

---

3. 核心功能模块详解

3.1 文件抽象层：FILE_ID 与 file_api.c

为了屏蔽底层存储介质（Flash vs RAM）的差异，DiffIAP设计了 FILE_ID 结构体和一套统一的文件操作API。

• FILE_ID 结构体：封装了文件地址、长度、读写偏移、模式、状态以及一个用于Flash写入的缓存（Flash_Write_Buff）。
• 关键API：
  • file_open/close：资源管理。
  • file_read/write：核心I/O操作。其中 file_write 实现了智能缓存机制，确保写入Flash的数据长度总是符合硬件要求（如4字节对齐），解决了算法输出任意长度数据与Flash硬件限制之间的矛盾。
  • file_lseek：文件指针定位。
  • Get_File_CRC32：基于分块（512字节）的CRC32计算，避免大文件一次性加载。

这一层是移植的关键，它使得上层算法完全不关心数据是来自Flash还是RAM。

3.2 差分还原引擎：bspatch.c

这是MCU端最核心的模块，实现了从补丁包和旧固件重建新固件的完整逻辑。

• Get_PatchFileInfo_Check()：

  • 读取补丁包头，获取新旧固件元数据。
  • 关键安全校验：计算当前Flash中旧固件的CRC32，并与补丁包头中的值比对。只有匹配成功，才允许继续升级，防止因旧固件损坏或版本不匹配导致升级失败。

• do_BsPatch() 与 BsPatch()：

  • 初始化打补丁上下文（dobsPatch_file）。
  • 调用 lz77_UnZip() 进行流式解压，并通过回调函数 UnZipData_Handle 将解压出的每一个字节传递给 Creat_PatchDataPack()。

• Creat_PatchDataPack()：状态机驱动的差分数据解析器。

  • 它维护一个状态机（Patch_Status），逐步解析bspatch的控制指令流。
  • 控制块（Control Block）：包含三个信息：
    • 索引（Index）：指向旧固件中可复用数据块的起始位置。
    • 差分长度（Diff Length）：需要与旧固件对应位置数据相加才能得到新数据的字节数。
    • 额外长度（Extra Length）：新固件中新增的、旧固件没有的数据字节数。
  • 解析出的数据被暂存到 structpatch_data.patchdata 缓冲区中。

• Patchdata_handler()：数据组装与写入。

  • 对于差分块：从旧固件指定位置读取数据，与缓冲区中的差分值相加，得到新数据。
  • 对于额外块：直接从缓冲区写入新固件。
  • 通过 file_write 将组装好的新数据写入目标Flash区域。

3.3 无损解压器：lz_unzip.c

该模块实现了LZ77算法的解压逻辑，并与打补丁引擎通过回调函数解耦。

• lz77_UnZip()：
  • 首先读取补丁包头中的 zip_flag，据此动态申请滑动窗口内存（1KB << zip_flag，默认1KB）。
  • 核心是一个循环，每次从补丁包中读取一个控制字节（ctrl_data），根据其高几位的模式，判断后续数据是字面量（Literal）还是匹配对（Match Pair）。
  • 对于匹配对，计算出在滑动窗口中的回溯位置和匹配长度，从窗口中复制数据。
  • 每解压出一个字节，立即通过 pUnZipData_Handle 回调函数传递给上层（即 Creat_PatchDataPack），实现真正的流式处理。

3.4 内存与Flash接口：移植的基石

DiffIAP的设计哲学是“最小侵入”。移植到任何STM32项目，开发者只需在 flash_api.c/h 中实现四个底层接口：

1. flash_read / flash_write：实现任意长度的Flash读写。内部需处理扇区擦除、对齐等细节。
2. DiffIAP_malloc / DiffIAP_free：重定向至项目自身的内存管理器（如UCOS的内存池）。

这种设计使得DiffIAP可以无缝集成到任何RTOS或裸机项目中。

---

4. 关键特性与优势

1. 极致的资源友好性：

   • RAM占用低：峰值约1.5-2KB（主要为LZ77滑动窗口）。
   • Flash占用合理：算法代码约10-15KB。
   • 流式处理：避免大块内存分配，适合小内存MCU。

2. 强大的安全性与可靠性：

   • 双重CRC32校验：确保旧固件合法、新固件完整。
   • 备份升级机制：推荐将新固件写入独立备份区，校验通过后再切换，避免“变砖”。
   • 原子性操作：通过Flash写入缓存机制，保证写入的原子性。

3. 高度的可移植性与易用性：

   • 纯C语言编写，无平台依赖。
   • 清晰的API：应用层只需调用3个函数即可完成升级。
   • 详细的移植文档：明确指出了需要用户实现的接口。

---

5. 总结

DiffIAP不仅仅是一套差分升级代码，更是一个为嵌入式环境量身定制的、经过深思熟虑的系统工程。它巧妙地将复杂的bsdiff算法与轻量级的LZ77压缩相结合，并通过精心设计的抽象层和流式处理架构，成功地将原本属于桌面系统的功能，完美地移植到了资源受限的STM32单片机上。

对于任何需要在带宽、功耗、存储空间受限的场景下实现高效、安全OTA升级的项目，DiffIAP都提供了一个成熟、可靠且易于集成的解决方案。其代码结构清晰、注释详尽、接口简洁，是学习和实践嵌入式差分升级技术的绝佳范本。