CN114780128A - 嵌入式设备固件更新方法、嵌入式设备及开发端设备 - Google Patents

Abstract

本申请公开了一种嵌入式设备固件更新方法、嵌入式设备、开发端设备以及嵌入式设备固件更新系统，嵌入式设备从源设备获取补丁数据，解压后得到原始差分编码数据；分次获取原始差分编码数据中的数据块，依据用于指示当前所执行操作的状态标识对数据块分别执行对应的操作，直到对原始差分编码数据完成差分解码。本申请可以分次执行差分解码，差分解码后得到的数据可以及时写入指定的存储分区中去，避免了将过多数据暂存到内存中，造成对设备内存的消耗，从而使增量更新方法在资源受限如内存较小的物联网设备上也可以正常运行。并且，本申请提供的增量更新方案中内存消耗可以灵活控制，且可以与各种支持流式解压的算法结合使用，扩展性更好。

Description

嵌入式设备固件更新方法、嵌入式设备及开发端设备

技术领域

本申请涉及嵌入式技术领域，尤其涉及一种嵌入式设备固件更新方法、嵌入式设备、开发端设备以及嵌入式设备固件更新系统。

背景技术

物联网技术的快速发展促进了低成本嵌入式设备的大规模使用，这些低成本嵌入式设备被广泛部署在智能家居、智慧工业和医疗保健等应用场景中，完成智能感知、智能控制、智能组网等功能。在嵌入式设备中，固件通常存储在闪存(Flash)、SD卡和固态硬盘等非易失性存储设备上，设备启动后将存储的固件加载到RAM内存中执行指定的功能。固件定义了产品的主要功能，设备厂商经常通过FOTA(Firmware Over the Air)远程固件更新技术对设备软件进行快速迭代，来满足市场对产品功能的需求，改善用户体验，远程修复固件的安全漏洞。

实现固件更新的基本条件之一是将更新固件数据传输到待更新的设备端。根据对传输的更新固件数据的处理方法，可以将固件更新分为以下几种：

(1)全量更新：该种固件更新方式采用直接将编译生成的更新固件发送到待升级设备；

(2)压缩更新：该种固件更新方式将编译生成的更新固件数据经过压缩算法进行压缩，然后将压缩得到的压缩数据发送到待升级设备；

(3)增量更新(也称为差分更新)：如图1所示，该种固件更新方式可以分为生成补丁数据和应用补丁数据两个过程。在开发端设备，利用更新固件数据、旧固件数据，进行差分得到补丁数据。在嵌入式设备端，通过接收该补丁数据，结合旧固件数据恢复出更新固件数据。

上述方法中，增量更新的固件更新方法比较适合更新固件数据相较于旧固件数据改动较小的使用场景。当更新固件数据和旧固件数据之间的差异较小，如在仅仅更改了部分系统参数、插入一小段代码的情况下，相比较于全量更新和压缩更新，增量更新的固件更新方法需要传输的数据仅仅是更新固件数据和旧固件数据的差异信息，因此需要传输的数据量较小，能够节省固件更新的流量，提高更新成功率，保证物联网系统的稳定性。

然而，由于物联网系统通常由一系列软硬件资源不一样的设备构成，不同设备之间的可用内存大小不一致，导致同样的增量更新方案很难部署到资源不同的设备上使用。另一方面，当前采用增量更新的方法执行固件更新的方法，需要的内存消耗较大，因此导致该增量更新的方法无法运行在资源受限的物联网设备中。

因此，如何设计一套资源消耗可以灵活配置、扩展性良好、能够运行在资源受限的物联网设备的增量更新方案，是本领域中亟待解决的技术问题之一。

应理解，上述所列举的技术问题仅作为示例而非对本发明的限制，本发明并不限于同时解决上述所有技术问题的技术方案。本发明的技术方案可以实施为解决上述或其他技术问题中的一个或多个。

发明内容

为解决上述和其他问题，本申请提供了一种嵌入式设备固件更新方法，应用于所述嵌入式设备，所述方法包括：

从源设备获取补丁数据，所述补丁数据为对原始差分编码数据进行压缩后得到的数据，所述补丁数据为补丁文件中的一部分数据；

对所述补丁数据进行解压，得到所述原始差分编码数据，所述原始差分编码数据为对旧固件数据以及更新固件数据进行差分处理并进行编码后的数据，所述原始差分编码数据包括多段数据块，其中所述多段数据块中的每个包括控制数据、差异数据以及附加数据；

分次获取所述原始差分编码数据中的数据块，依据用于指示当前所执行操作的状态标识对所述数据块分别执行对应的操作，直到对所述原始差分编码数据完成差分解码。

可选地，所述依据用于指示当前所执行操作的状态标识对所述数据块分别执行对应的操作包括：

若所述状态标识为指示执行读取所述控制数据的操作的第一标识时，则读取所述控制数据；

若所述状态标识为指示执行相加所述差异数据的操作的第二标识时，则根据所述控制数据将所述差异数据分次读取到预先分配的缓冲区中执行相加操作，其中，单次执行相加操作的数据长度不超过预设的缓冲区长度；

若所述状态标识为指示执行复制所述附加数据的操作的第三标识时，则根据所述控制数据将所述附加数据分次读取到所述缓冲区中执行复制操作，其中，单次执行复制操作的数据长度不超过所述预设的缓冲区长度；

其中，执行相加操作或复制操作后得到的数据被写入到所述嵌入式设备的存储分区中。

可选地，所述补丁文件还包括文件头信息，在所述从源设备获取补丁数据之后还包括：

从所述补丁文件中读取所述文件头信息；

若所述状态标识为指示执行校验所述文件头信息的第四标识时，则根据所述文件头信息，对所述文件头信息进行校验；

若校验通过，则将所述状态标识由所述第四标识修改为所述第一标识。

可选地，在所述读取所述控制数据之后还包括：

在读取到一个完整的控制数据之后，将所述状态标识由所述第一标识修改为所述第二标识。

可选地，在所述根据所述控制数据将所述差异数据分次读取到预先分配的缓冲区中执行相加操作之后还包括：

基于所述控制数据中指示的该段数据块中差异数据的字节数，判断针对该段数据块的相加操作是否完成；

如果是，则将所述状态标识由所述第二标识修改为所述第三标识。

可选地，在所述根据所述控制数据将所述附加数据分次读取到所述缓冲区中执行复制操作之后还包括：

基于所述控制数据中指示的该段数据块中附加数据的字节数，判断针对该段数据块的复制操作是否完成；

如果是，则将所述状态标识由所述第三标识修改为所述第一标识。

可选地，所述预设的缓冲区长度可根据所述嵌入式设备的实际内存进行调整。

可选地，所述预设的缓冲区长度存储在所述补丁文件的文件头信息中。

可选地，所述状态标识由设置的状态机进行指示。

可选地，所述对所述补丁数据进行解压包括：

采用支持流式解压的解压算法对所述补丁数据进行解压。

本申请还提供了一种嵌入式设备，包括：第一存储器以及第一处理器，所述第一存储器用于存储计算机程序，所述第一处理器用于执行所述计算机程序时实现上述任一种所述的嵌入式设备固件更新方法。

本申请还提供了一种嵌入式设备固件更新方法，应用于开发端设备，所述方法包括：

确定旧固件数据以及更新固件数据的相似匹配区域，将所述相似匹配区域的数据进行差分处理，编码为差异数据；

将两个相似匹配区域之间的数据编码为附加数据；

基于所述差异数据以及所述附加数据，生成控制数据；

将生成的所述控制数据、所述差异数据、所述附加数据写入到数据块中，多段所述数据块排列得到原始差分编码数据；

对所述原始差分编码数据进行压缩，生成供所述嵌入式设备固件更新的补丁数据，所述补丁数据为补丁文件中的一部分数据。

可选地，在所述生成供所述嵌入式设备固件更新的补丁数据之后还包括：

将补丁数据打包生成补丁文件；

将所述补丁文件发送至源设备上进行存储，以便所述嵌入式设备从该源设备上获取所述补丁文件中的补丁数据。

可选地，所述补丁文件还包括文件头信息，所述文件头信息包括所述嵌入式设备要使用的解压算法、解压级别、用于校验的校验信息以及预设的缓冲区长度。

本申请还提供了一种开发端设备，包括：第二存储器以及第二处理器，所述第二存储器用于存储计算机程序，所述第二处理器用于执行所述计算机程序时实现上述任一种所述的嵌入式设备固件更新方法。

本申请还提供了一种嵌入式设备固件更新系统，包括上述所述的嵌入式设备以及源设备；所述源设备存储有供所述嵌入式设备固件更新的补丁文件，所述补丁数据为所述补丁文件中的一部分数据，所述补丁数据为对原始差分编码数据进行压缩后得到的数据。

可选地，所述源设备为开发端设备或云端设备或所述嵌入式设备所在网络中的其他设备。

本申请所提供的嵌入式设备固件更新方法，嵌入式设备从源设备获取补丁数据，对该补丁数据进行解压，得到原始差分编码数据，该原始差分编码数据为对旧固件数据以及更新固件数据进行差分处理并进行编码后的数据，原始差分编码数据包括多段数据块，其中该多段数据块中的每个包括控制数据、差异数据以及附加数据；分次获取原始差分编码数据中的数据块，依据用于指示当前所执行操作的状态标识对数据块分别执行对应的操作，直到对原始差分编码数据完成差分解码。

本申请提供的方案在嵌入式设备进行固件更新时，可以仅获取补丁文件的一部分数据，而不直接去获取完整的补丁文件，避免获取补丁文件需要暂存的数据量较多导致对设备造成过大的存储压力，可以分次获取数据并及时对获取到的数据进行分次处理。通过分次获取原始差分编码数据中的数据块，并且采用状态标识来指示当前所执行的操作，从而可以针对各个数据块中的控制数据、差异数据、附加数据分别执行对应的操作，分次执行差分解码处理，差分解码后得到的数据可以及时写入指定的存储分区中去，而不需要在获取到完整的数据块之后再执行操作，避免了将过多数据暂存到内存中，造成对设备内存的消耗，从而使得该增量更新方法在资源受限如内存较小的物联网设备上也可以正常运行。

进一步地，本申请提供的增量更新方案中内存消耗可以灵活控制，使得增量更新方案不仅可以在内存资源大的设备上运行，而且在内存资源较小的设备上也可以通过设置缓冲区的数值实现。另外，本申请方案还可以与各种支持流式解压的算法结合使用，扩展性更好。

此外，本申请还提供了一种具有上述技术优点的嵌入式设备、开发端设备以及嵌入式设备固件更新系统。

附图说明

在下文中，将基于实施例参考附图进一步解释本申请。

图1示出增量更新方式的过程示意图；

图2示意性地示出本申请所提供的嵌入式设备固件更新方法中嵌入式设备存储分区的设置情况；

图3示意性地示出本申请所提供的嵌入式设备固件更新方法的一种具体实施方式的流程图；

图4示意性地示出生成原始差分编码数据中的差异数据以及附加数据的示意图；

图5示意性地示出原始差分编码数据的一种具体表现形式；

图6示意性地示出基于旧固件数据以及原始差分编码数据生成更新固件数据的示意图；

图7示意性地示出在开发端设备生成补丁数据的过程流程图；

图8示意性地示出在嵌入式设备进行增量固件更新的过程流程图；

图9示意性地示出本申请所提供的嵌入式设备固件更新方法的另一种具体实施方式的流程图；

图10示意性地示出本申请所提供的方法对申请到的内存进行使用的过程示意图；

图11示意性地示出本申请所提供的嵌入式设备固件更新方法的另一种具体实施方式中执行解码的过程示意图；

图12示意性地示出本申请所提供的嵌入式设备的结构框图；

图13示意性地示出本申请所提供的嵌入式设备固件更新方法的又一种具体实施方式的流程图；

图14示意性地示出本申请所提供的开发端设备的结构框图；

图15示意性地示出本申请所提供的嵌入式设备固件更新系统的结构框图。

具体实施方式

以下将结合附图和具体的实施方式，对本申请的方法、设备和系统进行详细说明。应理解，附图所示以及下文所述的实施例仅仅是说明性的，而不作为对本申请的限制。

图2示出本申请所提供的嵌入式设备固件更新方法中嵌入式设备存储分区的设置情况。参照图2，嵌入式设备的存储区中设置有第一固件分区、第二固件分区、引导加载分区以及系统参数分区。

其中，引导加载分区用于存储引导加载(bootloader)程序，用于完成检测系统参数、校验固件和判断加载运行哪个固件的功能。

系统参数分区用于存储系统的配置、网络连接信息、系统引导参数等信息。可以理解的是，该系统参数分区在实际的嵌入式设备中可以划分为多个分区进行管理，在此不做限定。

第一固件分区用于存储第一固件，第二固件分区用于存储第二固件。可以理解的是，每个固件都可以实现本申请所提供的嵌入式设备固件更新方法的功能。

通过第一固件实现嵌入式设备固件更新的实施过程具体为：当嵌入式设备运行第一固件时，通过从源设备获取补丁数据，并结合第一固件中的固件数据，分次恢复更新固件数据，并将更新固件数据写入到第二固件分区中。更改系统参数，将第二固件设置为待引导固件。系统重启，重启后由引导加载程序依据系统参数，加载运行第二固件分区中的更新固件数据。

通过第二固件实现嵌入式设备固件更新的实施过程具体为：当嵌入式设备运行第二固件时，通过从源设备获取补丁数据，并结合第二固件中的固件数据，分次恢复更新固件数据，并将更新固件数据写入到第一固件分区中。更改系统参数，将第一固件设置为待引导固件。系统重启，重启后由引导加载程序依据系统参数，加载运行第一固件分区中的更新固件数据。

采用上述方式，可以实现对嵌入式设备的“乒乓升级”，以便能够稳定地执行对嵌入式设备进行增量更新的功能。

图3示出了本申请所提供的嵌入式设备固件更新方法的一种具体实施方式的流程图。如图3所示，该方法应用于嵌入式设备，具体包括以下步骤：

S101：从源设备获取补丁数据，所述补丁数据为对原始差分编码数据进行压缩后的得到的数据；

在进行固件更新时，嵌入式设备可以从源设备获取补丁数据。应理解，在本文中“源设备”是指向待升级固件的嵌入式设备提供补丁数据的任何计算设备。例如，源设备可以为云服务器、或本地服务器、或mesh网络的节点、或低功耗蓝牙(BLE)网络中的设备。应理解，源设备可以位于云端，也可以位于本地。源设备与嵌入式设备之间可以采用Wi-Fi、蓝牙、ZigBee、以太网等方式进行通信，具体的实现方法兼容各类通信方式，在此不做限定。

补丁数据可以由开发端设备对原始差分编码数据进行压缩后生成，并保存在开发端设备上，也可以将补丁数据发送到源设备上。即，待升级固件的嵌入式设备可以直接从开发端设备获取补丁数据，也可以从其他存储有补丁数据的设备上获取补丁数据，这均不影响本申请的实现。

可以理解的是，补丁文件为对原始差分编码数据进行压缩后得到的完整的数据。而补丁数据为补丁文件中的一部分数据。本申请中嵌入式设备在固件更新时，可以不直接去获取完整的补丁文件，避免获取补丁文件需要暂存的数据量较多，而导致对设备造成过大的存储压力。本申请中通过获取补丁数据，可以及时对获取到的数据进行分次处理。

S102：对补丁数据进行解压，得到原始差分编码数据。

对补丁数据进行解压，得到原始差分编码数据。其中，原始差分编码数据为对旧固件数据以及更新固件数据进行差分处理并进行编码后的数据，该原始差分编码数据包括多段数据块，其中所述多段数据块中的每个包括控制数据、差异数据以及附加数据。

具体地，可以通过确定旧固件数据以及更新固件数据的相似匹配区域，将相似匹配区域的数据进行差分处理，编码为差异数据(diff数据)。将两个相似匹配区域之间的数据编码为附加数据(extra数据)。如图4所示，diff ₁数据、extra ₁数据为第一个相似匹配区域对应的原始差分编码数据。

基于上述差异数据以及附加数据，生成控制数据(ctrl数据)。ctrl数据可以是一个三元数组(x，y，z)中，其中x表示diff数据的字节数，y表示extra数据的字节数，z记录diff数据对应的原始数据在旧固件数据中的偏移地址。

将生成的所述控制数据、所述差异数据、所述附加数据写入到数据块中，多段所述数据块排列生成供所述嵌入式设备固件更新的原始差分编码数据。

作为一种具体实施方式，可以将生成的控制数据、差异数据、附加数据依次写入到数据块中，重复该操作，不断将ctrl_i、diff_i、extra_i(i＝0,1,2...)写入，直到处理完整个更新固件，该原始差分编码数据的一种具体表现形式如图5所示。

S103：分次获取所述原始差分编码数据中的数据块，依据用于指示当前所执行操作的状态标识对所述数据块分别执行对应的操作，直到对所述原始差分编码数据完成差分解码。

分次获取原始差分编码数据中的数据块，依据状态标识对获取到的数据块进行对应的操作。对于原始差分编码数据中的数据块，可以执行边下载边解压边解码的操作。例如，从源设备获取到30字节的数据，可以解压该30字节的数据，若解压后得到60字节的原始差分数据，则使用该60字节的原始差分数据执行差分解码操作。

其中，依据用于指示当前所执行操作的状态标识对所述数据块分别执行对应的操作可以具体包括：

若所述状态标识为指示执行读取所述控制数据的操作的第一标识时，则读取所述控制数据；

若所述状态标识为指示执行相加所述差异数据的操作的第二标识时，则根据所述控制数据将所述差异数据分次读取到预先分配的缓冲区中执行相加操作，其中，单次执行相加操作的数据长度不超过预设的缓冲区长度；

若所述状态标识为指示执行复制所述附加数据的操作的第三标识时，则根据所述控制数据将所述附加数据分次读取到缓冲区中执行复制操作，其中，单次执行复制操作的数据长度不超过所述预设的缓冲区长度。

其中，每次执行相加操作或复制操作后得到的数据被写入到所述嵌入式设备的存储分区中。可以理解的是，所述存储分区为更新固件对应的存储分区中。例如，在运行第一固件时，每次执行相加操作或复制操作后得到的数据被实时写入到第二固件分区中。在运行第二固件时，每次执行相加操作或复制操作后得到的数据被实时写入到第一固件分区中。本申请提供的方案可以及时消耗掉当前存入缓冲区的数据，以便后续能够重复利用缓冲区对下次的数据执行操作。

在一种具体实施方式中，可以首先读取数据块中的ctrl数据。然后，执行相加操作，具体为读取diff数据，依据控制数据中z记录的diff数据对应的原始数据在旧固件数据中的偏移地址，取出旧固件数据。如图6所示，将读取的旧固件数据与diff数据进行相加操作，得到更新固件数据，将得到的更新固件数据写入到嵌入式设备的存储分区中。其次，执行复制操作，具体为，复制数据块中的extra数据，并写入到嵌入式设备的存储分区中。重复上述过程，直到对所有的数据块执行完对应操作，即可在嵌入式设备的存储分区中得到更新固件。

本申请提供的方案在嵌入式设备进行固件更新时，可以仅获取补丁文件的一部分数据，而不直接去获取完整的补丁文件，避免获取补丁文件需要暂存的数据量较多导致对设备造成过大的存储压力，可以分次获取数据并及时对获取到的数据进行分次处理。采用状态标识来指示当前所执行的操作，从而可以针对各个数据块中的控制数据、差异数据、附加数据分别执行对应的操作，分次执行差分解码，差分解码得到的数据可以及时写到指定的存储分区中去，而不需要在获取到完整的数据块之后再执行操作，避免了将过多数据暂存到内存中，造成对设备内存的消耗，从而使得该增量更新方法在资源受限如内存较小的物联网设备上也可以正常运行。

此外，部分现有的增量更新方法只能处理某种嵌入式平台设备对应的固件，需要配合该嵌入式设备的编译技术和固件格式才能正常使用。例如courgette算法和exediff算法分别用于对谷歌浏览器、windows平台下的应用程序完成更新。而本申请所提供的方法与嵌入式设备的架构和编译器无关，因此，可以支持跨平台使用。

另外，在现有的差分升级方案中，一些方案将原始差分编码数据存储下来(包括内存或者物理存储空间)，该方案需要消耗额外的物理存储空间；一些方案需要将接收到的整个原始差分编码数据保存在内存中，来运行增量更新算法，但是当原始差分编码数据过大时，需要的内存空间会很大，可能会无法更新或者需要将本次更新涉及的大的更改分为多次小的更改，多次执行增量更新才能完成最终的更新，导致更新失败或者效率低，且需要扩展物理存储空间(如RAM)，并导致设备成本较高。而本申请所采用的方案，通过记录差分解码过程中的状态标识，及时执行差分解码操作，差分解码的数据可以实时写入到指定的存储分区中，从而避免将过多数据暂存到内存中。与现有的增量更新方案相比，本方案也不需要在物理存储空间里设置额外的补丁数据存储空间。

可以理解的是，补丁数据可以在计算和内存资源丰富的开发端设备中生成。生成的补丁数据可以存储在开发端设备，即开发端设备自身可以作为源设备。或者，生成的补丁数据也可以发送到其他源设备上进行存储，例如云端设备。嵌入式设备可以与源设备进行通信，获取补丁数据。

此外，本申请实施例还可以对压缩后的原始差分编码数据添加文件头信息，如图5所示，在多段数据块之前添加文件头信息。

如图7所示，在开发端设备生成补丁数据的过程可以具体包括：

S201：对旧固件数据以及更新固件数据进行差分处理并进行编码，得到未压缩的原始差分编码数据；

S202：对未压缩的原始差分编码数据进行压缩，得到压缩后的原始差分编码数据；

S203：对压缩后的原始差分编码数据添加文件头信息，得到可供嵌入式设备固件进行增量升级的补丁数据，补丁数据为补丁文件的一部分数据。在生成补丁数据之后还可以包括将补丁数据打包生成补丁文件的操作。

作为一种具体实施方式，文件头信息中可以包括嵌入式设备要使用的解压算法、解压级别、用于校验的校验信息以及预设的缓冲区长度。当然还可以包括其他信息，在此不做限定。

嵌入式设备接收到源设备发送的补丁数据后，对补丁数据进行解压，得到原始差分编码数据，再执行与差分编码相对应的差分解码的操作。此外，在原始差分编码数据中包括文件头信息的基础上，相对应的，在嵌入式设备还可选地包括对文件头信息进行解析的操作，并可以进一步包括对文件头信息进行校验的操作。如图8所示，在嵌入式设备进行增量固件更新的过程可以具体包括：

S301：接收到执行固件增量更新的触发事件后，接收补丁文件中的文件头信息；

其中，触发事件可以为：接收到源设备发送的固件的版本存在更新的推送信息。该推送信息中可以包括更新固件的版本号、更新固件的下载链接、校验数据等信息。此外，该触发事件还可以为：向源设备发送固件的版本是否存在更新的查询请求，并接收源设备发送的版本存在更新的回复信息。嵌入式设备可以定时或者在每次开机时，向源设备主动发送上述查询请求。在接收到该触发事件后，启动对固件增量更新的后续步骤。

S302：读取文件头信息，对文件头信息进行校验；

通过对文件头信息进行校验，用于确认文件头信息数据是否出现错误，从而保证系统的安全性。

S303：从源设备获取补丁数据，所述补丁数据为对原始差分编码数据进行压缩后得到的数据；

S304：对所述补丁数据进行解压，得到所述原始差分编码数据；

其中，对所述补丁数据进行解压包括：采用支持流式解压的解压算法对所述补丁数据进行解压。例如，采用xz算法、lz77算法、lzw算法的任意一种或任意组合。

S305：将原始差分编码数据作为输入，执行差分解码，并将解码得到的数据写入到指定的存储分区中；

S306：判断是否完成固件的更新，如果否，则返回S303；如果是，则结束。

可以理解的是，在嵌入式设备进行增量固件更新的过程中，主要的内存消耗为解压过程以及差分解码过程。其中，解压的内存消耗可以通过调整解压算法的压缩级别或者使用不同的压缩算法进行调整。下表1列出了常见的适合嵌入式平台的压缩算法xz、lzw不同压缩级别对应的解压过程需要的解压内存。在确定解压过程所需的内存后，差分解码过程的内存消耗即为影响嵌入式设备内存消耗的主要因素。

表1

名称	压缩级别	解压内存(KB)
			xz	8	32
xz	9	38
			lzw	4	16
lzw	6	64

参照图9本申请所提供的嵌入式设备固件更新方法的另一种具体实施方式的流程图，其对上述实施例中S305执行解码的过程进行详细阐述，该过程可以具体包括：

S401：读取文件头信息；

S402：若状态标识为指示执行校验所述文件头信息的第四标识时，则根据文件头信息，对文件头信息进行校验；

S403：若校验通过，则将所述状态标识由第四标识修改为第一标识；

S404：读取原始差分编码数据中的数据块的控制数据；

S405：在读取到一个完整的控制数据之后，将所述状态标识由所述第一标识修改为第二标识；

S406：根据所述控制数据将所述差异数据分次读取到缓冲区中执行相加操作，其中，单次执行相加操作的数据长度不超过预设的缓冲区长度；

S407：基于所述控制数据中指示的该段数据块中差异数据的字节数，判断针对该段数据块的相加操作是否完成；

S408：如果是，则将所述状态标识由所述第二标识修改为所述第三标识；

S409：根据所述控制数据将所述附加数据分次读取到缓冲区中执行复制操作，其中，单次执行复制操作的数据长度不超过所述预设的缓冲区长度；

S410：基于所述控制数据中指示的该段数据块中附加数据的字节数，判断针对该段数据块的复制操作是否完成；

S411：如果是，则将所述状态标识由所述第三标识修改为所述第一标识；

S412：判断对原始差分编码数据的所有数据块是否完成差分解码；如果是，则返回S404；如果否，则结束。

其中，每次执行相加操作或复制操作后得到的数据被写入到所述嵌入式设备的存储分区中。

可以理解的是，本申请中缓冲区为从嵌入式设备内存中预先分配的执行运算的软件实体。

缓冲区长度可以预设设置得到。作为一种可选实施方式，可以由开发人员在本地进行模拟OTA测试之后，确定出适合的缓冲区长度进行相应的设置。当然，预设的缓冲区长度也可根据所述嵌入式设备的实际内存进行动态调整，从而充分利用内存的优势。

作为一种具体实施方式，可以在文件头信息中设置要使用的缓冲区长度。通过读取该文件头信息即可得到缓冲区长度的具体数值。

缓冲区长度设置之后，当多段数据块的其中一段中的差异数据或附加数据的长度大于该预设的缓冲区长度之后，对该差异数据或附加数据进行分次处理。具体地，单次执行相加或复制操作的数据长度不超过该预设的缓冲区长度。采用本申请分次处理的方式，可以在即使数据量大的情况下，也可以通过分次处理及时消耗掉接收到的数据，从而保证内存消耗是可控的。

物联网系统通常由一系列软硬件资源不一样的设备构成，不同设备之间的可用内存大小不一致。现有增量更新方法，其内存消耗不方便评估，并且其内存消耗也没办法进行调节，导致一些增量更新算法由于所需要的内存消耗较大，无法在资源受限的物联网设备中运行。而一些增量更新算法虽然所需的内存消耗相对较小，但是其压缩性能受到了较大的限制。而本申请通过该预设的缓冲区长度的设置，可以对嵌入式设备的内存消耗进行具体数值的评估，并且还可以根据嵌入式设备的实际内存进行相应的动态调整，从而充分使用设备的内存资源和计算能力，可以适用于计算资源、内存资源差异较大的各类设备，具有更好的兼容性。

例如，对于1000字节大小的原始差分编码数据，若A设备可使用的内存空间较小，为20KB，此时可以采用相对节省资源的解压算法或将压缩算法的压缩级别设置较小一些，并将执行差分解码的上述预设的缓冲区长度设置为一个较小的数值，假设此时实现增量更新的时间为500ms。若B设备可使用的内存空间较大，为50KB，此时可以采用压缩能力较强或压缩级别更高的算法来生成更小的补丁文件，达到节省更多流量和时间的目的，并且可以将执行差分解码的上述预设的缓冲区长度设置为一个较大的数值，此时可以实现在200ms内接收完补丁数据完成固件的更新。可见，本申请提供的方法针对不同资源的设备，不管是可用内存小还是可用内存大的设备，均可以实现固件的更新。

可以理解的是，将压缩算法的压缩率设置为更高级别，或者使用压缩率更高的压缩算法，都能够增大压缩率，使得生成的补丁文件更小，从而节省了传输的时间和流量。因此，对于内存较为充足的嵌入式设备，开发端设备可以增大压缩率，以节省传输的时间和流量。或者嵌入式设备的预设的缓冲区长度可以设置较大的数值，以减少解码的时间。相应地，对于内存较为紧张的设备，开发端设备可以降低压缩率。或者嵌入式设备的预设的缓冲区长度可以设置较小的数值，以保证在内存不足的情况下也能够实现固件的更新。

例如，对于1000字节的原始差分编码数据，表2示出了在压缩算法为LZW时，设置不同的压缩级别、压缩率、解压内存、差分解码的缓冲区的长度，对应的嵌入式设备接收、解压以及解码所需要的时间情况比较。

表2

下面针对上述实施例中执行差分解码的具体过程进行进一步详细阐述。本实施例中，实现差分解码可以分为两个过程：初始化过程以及执行解码的过程。

其中，初始化过程为后续执行解码的基础，主要是申请设备的内存空间。其可以包括以下对象需要的内存空间：

(1)buffer_a：大小为a，用于记录差分解码的状态标识和补丁文件的文件头信息。其需要的内存空间大小为状态标识以及文件头信息所需的内存空间。其中状态标识用于指示当前解码执行到哪个步骤，可以使用1个字节的全局变量来表示；文件头信息中可以包含更新固件的版本信息、校验数据、嵌入式设备要使用的解压算法、解压级别以及预设的缓冲区长度等信息，其大小可自定义。以包含31个字节的文件头信息为例，则整个记录差分解码的状态标识需要的内存空间为32字节。

(2)buffer_b：大小为b，记录解码需要的ctrl数据。如前所述，ctrl数据可以为一个三元数组(x，y，z)，其中x表示diff数据的字节数，y表示extra数据的字节数，z记录diff数据对应的原始数据在旧固件数据中的偏移地址。在8位或32位处理器中，固件的大小通常不会过大，可以使用3个4字节大小的变量表示该三元数组。更大的固件可以使用8字节的变量表示。本实施例中，以3个4字节的大小的变量为例，则ctrl数据的状态标识的大小为24字节。

(3)两个大小为m，用于暂存解码数据的第一缓冲区(buffer_m1)、第二缓冲区(buffer_m2)，即预设的缓冲区长度为m。例如m＝4KB，则该部分需要的缓冲区空间为8KB。

在初始化时确定所需要的内存的过程具体为：与源设备建立连接，申请大小为p的buffer_p用于存放接收的数据；申请大小为q的buffer_q用于存放解压得到的原始差分编码数据；申请大小为a的buffer_a用于存放状态标识和文件头信息，申请大小为b的buffer_b用于存放解码需要的ctrl数据，申请两个大小为m的buffer_m1以及buffer_m2用于存放解码数据。

参照图10本申请所提供的方法对申请到的内存进行使用的过程示意图，在某次接收到补丁数据时对上述申请到的内存进行使用的过程具体为：

S501：接收补丁数据，将接收到的补丁数据存入到buffer_p；

S502：获取补丁数据，确定对补丁数据进行解压后得到数据的长度；

S503：判断解压后得到数据的长度是否大于buffer_q的长度；如果是，则进入S504；如果否，则进入S505；

S504：解压部分数据，取出不大于q长度的数据存入到buffer_q，进入S506；

S505：解压当前buffer_p的所有数据，存入到buffer_q，进入S506；

S506：对解压得到的原始编码数据进行解码；

S507：判断buffer_p中存放的数据是否全部被解压；如果是，则进入S508；如果否，则返回S504；

S508：请求接收下一包补丁数据，返回S501。

参照图11，执行解码的过程具体包括如下步骤：

S601：获取原始差分编码数据，进入S602；

S602：读取状态标识，进入S603；

本实施例中，可以采用不同的数字标识来指示不同的状态标识。例如，第一标识可以用数字“1”表示，该第一标识用于指示当前所执行的是读取控制数据的阶段。第二标识可以用数字“2”表示，该第二标识用于指示当前所执行的是相加差异数据的阶段。第三标识可以用数字“3”表示，该第三标识用于指示当前所执行的是复制附加数据的阶段。第四标识可以用数字“0”表示，该第四标识用于指示执行校验文件头信息。可以理解的是，状态标识还可以采用其他标识方式，在此不做限定。

作为一种具体实施方式，状态标识由设置的状态机进行指示。

S603：判断状态标识是否为第四标识；如果是，则进入S604；如果否，则进入S605；

S604：读取文件头信息，判断是否从原始差分编码数据中读取到完整的文件头信息；如果是，则进入S606；如果否，则进入S607；

具体地，从原始差分编码数据中读取文件头信息。若读取到完整的文件头信息，则执行文件头信息校验。否则，暂存已经获取的数据，并等待接收更多的数据，直到完全获取到文件头信息。

S605：判断状态标识是否为第一标识；如果是，则进入S610；如果否，则进入S619；

S606：判断文件头信息是否校验通过；如果是，则进入S608；如果否，则进入S609；

S607：将文件头信息存储到缓冲区中，并返回S604；

S608：将第四标识更改为第一标识，进入S610；

具体地，在文件头信息校验通过后，将状态标识由“0”更改为“1”，进入后续读取ctrl数据的步骤。

S609：返回错误码，停止下载和执行固件更新。

S610：接收ctrl数据，判断针对当前处理的数据块是否获取到完整的ctrl数据；如果是，则进入S611；如果否，则进入S612。

S611：将状态标识更改为第二标识，进入S613。

具体地，读取到完整的ctrl数据时，将状态标识的标识由“1”更改为“2”，进入后续对差异数据执行相加操作的步骤。否则，暂存已经获取的数据，并等待接收更多的数据，直至获取到完整的ctrl数据。

S612：将获取到的ctrl数据存储到缓冲区中，并返回S610；

S613：执行相加操作，若当前可用的原始差分编码数据大于m，则分别从旧固件数据、当前可用的原始差分编码数据中读取m个字节的数据到buffer 1、buffer 2，分次执行相加操作，进入S614；

若当前可用的原始差分编码数据大于m，则分别从旧固件数据、当前可用的原始差分编码数据中读取m个字节的数据到buffer 1、buffer 2，分次执行相加操作。否则，直接执行相加操作，并将得到的数据写入到指定的存储分区中。

S614：判断本次相加操作是否执行完毕；如果是，则进入S615；如果否，则返回S613；

S615：将状态标识更改为第三标识，进入S616；

具体地，根据ctrl数据中x的大小，判断本次相加操作是否执行完毕。若执行完毕，则将状态标识的标识由“2”修改为“3”，执行后续对extra数据进行复制操作的步骤。否则，返回等待接收更多的数据，直到执行完本次相加操作。

S616：执行复制操作，若当前可用的原始差分编码数据大于m，则从当前可用的原始差分编码数据中读取m个字节的数据到buffer 1，分次执行复制操作，进入S617；

若当前可用的原始差分编码数据大于m，则从当前可用的原始差分编码数据中读取m个字节的数据到buffer 1，分次执行复制操作，并将写入到buffer 1的数据写入到指定的存储分区中。

S617：判断本次复制操作是否执行完毕；如果是，则进入S618；如果否，则返回S616；

S618：将状态标识更改为第一标识，返回S605；

具体地，可以根据ctrl数据中y的大小，判断本次复制操作是否执行完毕。如果是，则将状态标识由“3”修改为“1”，对下一个数据块的ctrl数据进行读取。否则，返回等待接收更多的数据，直到执行完本次复制操作。

S619：判断状态标识是否为第二标识，如果是，则进入S613；如果否，则进入S620；

S620：判断状态标识是否为第三标识；如果是，则进入S616。

本申请实施例提供的方法，可以及时将相加操作、复制操作得到的数据写入到嵌入式设备的存储分区中，该存储分区可以为指定的非易失性存储设备，如闪存(Flash)，避免了将相加操作、复制操作得到的数据暂存在内存中，对设备内存的消耗。这样，待处理的原始差分解码数据可以立即被执行解码，整个差分解码所需的内存消耗仅为初始化时的内存消耗，即a+b+2m。其中，a+b的内存消耗是可设置的，通常较小。另外，m的大小也可以进行配置，例如某次执行相加操作的差异数据的大小为8192字节，m的大小为4095字节，则本次相加操作可以分两次执行，一次处理4096字节。增大m的大小，会增大内存的消耗，但可以节省因分批处理带来的时间消耗。通过缓冲区可调整的方式，本实施例便于增量更新过程中对内存消耗的评估，并且能够在充分考虑内存空间消耗的情况下，实现对时间消耗的兼顾。

本申请还提供了一种嵌入式设备11，如图12本申请所提供的嵌入式设备的结构框图所示，该嵌入式设备11包括：第一存储器111以及第一处理器112，所述第一存储器111用于存储计算机程序，所述第一处理器112用于执行所述计算机程序时实现上述任一种所述的嵌入式设备固件更新方法。

可以理解的是，该嵌入式设备执行固件更新的过程与上述嵌入式设备固件更新方法相对应，可参照上述内容，在此不再赘述。

本申请还提供了一种嵌入式设备固件更新方法，如图13所示，该方法应用于开发端设备，具体可以包括以下步骤：

S701：确定旧固件数据以及更新固件数据的相似匹配区域，将所述相似匹配区域的数据进行差分处理，编码为差异数据。

具体地，可以采用哈希算法、后缀排序算法等字符串匹配算法查找旧固件数据以及更新固件数据的相似匹配区域。

S702：将两个相似匹配区域之间的数据编码为附加数据；

S703：基于所述差异数据以及所述附加数据，生成控制数据；

S704：将生成的所述控制数据、所述差异数据、所述附加数据写入到数据块中，多段所述数据块排列得到原始差分编码数据；

S705：对所述原始差分编码数据进行压缩，生成供所述嵌入式设备固件更新的补丁数据，补丁数据为补丁文件的一部分数据。

在所述生成供所述嵌入式设备固件更新的补丁文件数据之后还包括：将补丁数据打包生成补丁文件；将所述补丁文件发送至源设备上进行存储，以便所述嵌入式设备从该源设备上获取所述补丁文件中的补丁数据。所述补丁文件还包括文件头信息，所述文件头信息包括所述嵌入式设备要使用的解压算法、解压级别、用于校验的校验信息以及预设的缓冲区长度。

本申请还提供了一种开发端设备12，如图14本申请所提供的开发端设备的结构框图所示，该开发端设备12包括：第二存储器121以及第二处理器122，所述第二存储器121用于存储计算机程序，所述第二处理器122用于执行所述计算机程序时实现上述任一种所述的嵌入式设备固件更新方法。

可以理解的是，该开发端设备可以与上述嵌入式设备固件更新方法相对应，可参照上述内容，在此不再赘述。

本申请还提供了一种嵌入式设备固件更新系统1，如图15本申请所提供的嵌入式设备固件更新系统的结构框图所示，包括上述所述的嵌入式设备11以及源设备13。

其中，源设备存储有供所述嵌入式设备固件更新的补丁文件，所述补丁数据为所述补丁文件中的一部分数据，所述补丁数据为对原始差分编码数据进行压缩后得到的数据。嵌入式设备11与源设备13之间可以通过多种通信协议进行数据传输。源设备13可以为开发端设备或云端设备或嵌入式设备11所在网络中的其他设备。其中，嵌入式设备11可以采用本申请所记载的嵌入式设备固件更新方法进行固件更新，具体实施方式可参照方法内容的记载，在此不再赘述。

虽然出于本公开的目的已经描述了本申请各方面的各种实施例，但是不应理解为将本公开的教导限制于这些实施例。在一个具体实施例中公开的特征并不限于该实施例，而是可以和不同实施例中公开的特征进行组合。例如，在一个实施例中描述的根据本申请的方法的一个或多个特征和/或操作，亦可单独地、组合地或整体地应用在另一实施例中。本领域技术人员应理解，还存在可能的更多可选实施方式和变型，可以对上述系统进行各种改变和修改，而不脱离由本申请权利要求所限定的范围。

Claims (17)

1.一种嵌入式设备固件更新方法，其特征在于，应用于所述嵌入式设备，所述方法包括：

从源设备获取补丁数据，所述补丁数据为对原始差分编码数据进行压缩后得到的数据，所述补丁数据为补丁文件中的一部分数据；

对所述补丁数据进行解压，得到所述原始差分编码数据，所述原始差分编码数据为对旧固件数据以及更新固件数据进行差分处理并进行编码后的数据，所述原始差分编码数据包括多段数据块，其中所述多段数据块中的每个包括控制数据、差异数据以及附加数据；

分次获取所述原始差分编码数据中的数据块，依据用于指示当前所执行操作的状态标识对所述数据块分别执行对应的操作，直到对所述原始差分编码数据完成差分解码。

2.如权利要求1所述的嵌入式设备固件更新方法，其特征在于，所述依据用于指示当前所执行操作的状态标识对所述数据块分别执行对应的操作包括：

若所述状态标识为指示执行读取所述控制数据的操作的第一标识时，则读取所述控制数据；

若所述状态标识为指示执行相加所述差异数据的操作的第二标识时，则根据所述控制数据将所述差异数据分次读取到预先分配的缓冲区中执行相加操作，其中，单次执行相加操作的数据长度不超过预设的缓冲区长度；

若所述状态标识为指示执行复制所述附加数据的操作的第三标识时，则根据所述控制数据将所述附加数据分次读取到所述缓冲区中执行复制操作，其中，单次执行复制操作的数据长度不超过所述预设的缓冲区长度；

其中，执行相加操作或复制操作后得到的数据被写入到所述嵌入式设备的存储分区中。

3.如权利要求2所述的嵌入式设备固件更新方法，其特征在于，所述补丁文件还包括文件头信息，在所述从源设备获取补丁数据之后还包括：

从所述补丁文件中读取所述文件头信息；

若所述状态标识为指示执行校验所述文件头信息的第四标识时，则根据所述文件头信息，对所述文件头信息进行校验；

若校验通过，则将所述状态标识由所述第四标识修改为所述第一标识。

4.如权利要求2所述的嵌入式设备固件更新方法，其特征在于，在所述读取所述控制数据之后还包括：

在读取到一个完整的控制数据之后，将所述状态标识由所述第一标识修改为所述第二标识。

5.如权利要求2所述的嵌入式设备固件更新方法，其特征在于，在所述根据所述控制数据将所述差异数据分次读取到预先分配的缓冲区中执行相加操作之后还包括：

基于所述控制数据中指示的该段数据块中差异数据的字节数，判断针对该段数据块的相加操作是否完成；

如果是，则将所述状态标识由所述第二标识修改为所述第三标识。

6.如权利要求2所述的嵌入式设备固件更新方法，其特征在于，在所述根据所述控制数据将所述附加数据分次读取到所述缓冲区中执行复制操作之后还包括：

基于所述控制数据中指示的该段数据块中附加数据的字节数，判断针对该段数据块的复制操作是否完成；

如果是，则将所述状态标识由所述第三标识修改为所述第一标识。

7.如权利要求2至6任一项所述的嵌入式设备固件更新方法，其特征在于，所述预设的缓冲区长度可根据所述嵌入式设备的实际内存进行调整。

8.如权利要求7所述的嵌入式设备固件更新方法，其特征在于，所述预设的缓冲区长度存储在所述补丁文件的文件头信息中。

9.如权利要求1至6任一项所述的嵌入式设备固件更新方法，其特征在于，所述状态标识由设置的状态机进行指示。

10.如权利要求1至6任一项所述的嵌入式设备固件更新方法，其特征在于，所述对所述补丁数据进行解压包括：

采用支持流式解压的解压算法对所述补丁数据进行解压。

11.一种嵌入式设备，其特征在于，包括：第一存储器以及第一处理器，所述第一存储器用于存储计算机程序，所述第一处理器用于执行所述计算机程序时实现如权利要求1至10任一项所述的嵌入式设备固件更新方法。

12.一种嵌入式设备固件更新方法，其特征在于，应用于开发端设备，所述方法包括：

确定旧固件数据以及更新固件数据的相似匹配区域，将所述相似匹配区域的数据进行差分处理，编码为差异数据；

将两个相似匹配区域之间的数据编码为附加数据；

基于所述差异数据以及所述附加数据，生成控制数据；

将生成的所述控制数据、所述差异数据、所述附加数据写入到数据块中，多段所述数据块排列得到原始差分编码数据；

对所述原始差分编码数据进行压缩，生成供所述嵌入式设备固件更新的补丁数据，所述补丁数据为补丁文件中的一部分数据。

13.如权利要求12所述的嵌入式设备固件更新方法，其特征在于，在所述生成供所述嵌入式设备固件更新的补丁数据之后还包括：

将补丁数据打包生成补丁文件；

将所述补丁文件发送至源设备上进行存储，以便所述嵌入式设备从该源设备上获取所述补丁文件中的补丁数据。

14.如权利要求12所述的嵌入式设备固件更新方法，其特征在于，所述补丁文件还包括文件头信息，所述文件头信息包括所述嵌入式设备要使用的解压算法、解压级别、用于校验的校验信息以及预设的缓冲区长度。

15.一种开发端设备，其特征在于，包括：第二存储器以及第二处理器，所述第二存储器用于存储计算机程序，所述第二处理器用于执行所述计算机程序时实现如权利要求12至14任一项所述的嵌入式设备固件更新方法。

16.一种嵌入式设备固件更新系统，其特征在于，包括如权利要求11所述的嵌入式设备以及源设备；所述源设备存储有供所述嵌入式设备固件更新的补丁文件，所述补丁数据为所述补丁文件中的一部分数据，所述补丁数据为对原始差分编码数据进行压缩后得到的数据。

17.如权利要求16所述的嵌入式设备固件更新系统，其特征在于，所述源设备为开发端设备或云端设备或所述嵌入式设备所在网络中的其他设备。

Images