一种嵌入式终端远程软件更新方法

技术领域

本发明涉及软件开发与调试技术领域，具体涉及一种嵌入式终端远程软件更新方法。

背景技术

软件更新作为集成开发环境的核心功能，是开发者所编写的软件在嵌入式终端得以运行的主要方式。在嵌入式终端远程在线开发背景下，终端节点需要具备远程更新代码的能力，来对节点进行灵活地配置和升级以适应环境变化。

传统的开发模式下，开发者往往会针对具体的应用场景事先选取一种通信方式，并将对应的通信模组驱动构件和软件更新代码固化于BIOS程序中，以此来完成针对后续User程序的开发和更新。然而这样的开发模式往往具有以下两个弊端：

(1)程序可移植、可复用性差。这样的开发模式下，每当因为不同的场景需求选取了不同的通信模组后，先前的BIOS程序便在很大程度上失去了移植和复用的价值，针对不同通信模组的BIOS程序的开发会带来毫无意义的重复劳动，降低整体的开发效率、延长开发周期。

(2)通信方式的升级受阻。当前通信模组的发展和演化速度极快，无论是针对通信模组本身的替换还是针对同一通信模组的固件更新，在嵌入式终端的工作周期内都可能存在需求。然而传统的开发模式下，通信模组相关构件已被固化于BIOS内，难以满足更替和升级需求。

因此提出一种通信模组自适应的软件更新方法就显得尤为重要。同时，在嵌入式终端的开发过程中，针对用户程序的更新需求往往更为庞大。

发明内容

本发明的目的是通过以下技术方案实现的。

本申请针对通信模组自适应的程序更新这一关键技术，提出了嵌入式终端远程软件更新方法，以此来适应不同应用场景下的软件更新需求并兼顾系统框架本身的可移植可复用性。动态命令作为主要载体，为软件更新功能提供灵活性和适应性支撑。

具体的，本发明提供一种嵌入式终端远程软件更新方法，包括：

向用户串口发送动态命令数据，并由用户程序写入；

向用户串口发送程序跳转的系统指令，用户程序在接收到指令后，跳转至BIOS；

BIOS启动过程中默认调用动态命令函数；在动态命令内首先修改程序运行状态，完成BIOS的驻留；其次完成用户串口的初始化和中断使能；并设置BIOS程序中断向量表内对应于用户串口的中断服务例程地址为动态命令函数；最后告知上位机，相关初始化步骤已执行完毕，开始程序更新；

上位机开始向用户串口发送用户程序数据帧，终端通过用户串口的动态命令完成接收、校验和写入；

当用户串口的动态命令完成最后一帧数据的处理工作时，修改程序运行状态，复位BIOS，由BIOS基础运行流程完成针对用户程序的后续引导。

进一步地，所述用户串口的最外层帧结构为通信层的组帧结构，包含帧头、帧尾、数据长度、通信层数据和校验位。

进一步地，所述动态命令函数的建立过程如下：

修改链接文件，在MEMORY字段和SECTIONS字段增加对应于动态命令的FLASH空间；

增加动态命令函数的声明和定义，函数体为空，并使用attribute语法将动态命令函数放置于所述FLASH空间；

在通信模组接收数据的中断处理程序中预留两个帧标识分别用于接收动态命令函数的机器码和执行动态命令函数；

在更新状态判断函数中增加动态命令执行分支；

在按键复位中增加动态命令重置步骤。

进一步地，进一步包括：

所述BIOS进行自更新：通过系统指令完成动态命令的写入和程序跳转，借助动态命令完成通信模组的接管，然后开始进行BIOS自更新流程，先接收新版BIOS的机器码并存放在当前BIOS机器码的后方，在新BIOS的机器码接收完并通过校验后，逐扇区将旧BIOS的机器码替换更新为新BIOS的机器码。

进一步地，所述BIOS自更新的步骤如下：

(1)编写相关函数制作动态命令代码；

(2)向目标芯片用户程序发送BIOS自更新的动态命令安装包，目标芯片接收到后写入动态命令区；

(3)向目标芯片用户程序发送系统指令，使之跳转并驻留至BIOS内；

(4)BIOS调用动态命令，完成用户通信模组的接管；

(5)开始向目标芯片发送新BIOS工程的机器码，逐帧校验后保存在当前BIOS存储空间的后方，并针对最后一帧数据给出相应的帧头；

(6)目标芯片检测到最后一帧数据并校验存储后，不立即退出中断，进入中断内的数据搬迁工作，使得新BIOS正式取代旧BIOS，搬迁完毕后进行软复位，开始执行新的BIOS流程。

进一步地，所述动态命令能够简化为动态构件库，包括：构件函数列表区和构件函数代码区，其中构件函数列表区用于存放构件的函数指针和必要参数，构件函数代码区用于存放构件内各个函数的具体实现，由动态命令函数负责对这两块区域数据的管理。

进一步地，所述动态命令能够对各个构件、函数进行查询操作，并结合构件函数代码区进行增加、修改和删除的操作。

进一步地，所述查询操作过程包括：依靠动态命令读取构件函数列表区的数据并回发至上位机，由上位机解析。

进一步地，所述增加的操作过程包括：在增加一个构件时，首先要根据构件函数列表区的下一个可用编号字段来确定当前构件的总体信息在构件函数列表区的记录位置，并在记录完毕后修改下一个可用编号字段，并根据函数代码区下一次可写地址字段来确定构件机器码的写入地址，并在写入完毕后相应的修改函数代码区下一次可写地址和函数代码区已用空间字段值。

进一步地，所述动态构件库内的Flash负载均衡方法如下：

(1)对于删除的操作，不擦除原本所占据的空间，仅修改构件函数列表区的函数代码区已用空间参数；

(2)对于修改的操作，同样不擦除原本所占据的空间，直接寻找下一个可存储的空间写入，函数存储空间大小的绝对变化记录在函数代码区已用空间参数，其中(1)(2)中产生的废弃代码数据所占据的空间称为Flash碎片；

(3)在进行增加操作和修改过程中的增加操作时，如若找不到可以容纳构件的连续存储空间，则根据函数代码区已用空间、函数代码区首地址和函数代码区尾地址这三个参数，计算剩余连续空闲空间和由(1)(2)产生的所有Flash碎片总和是否可以容纳该构件，若不能，则返回相应的存储空间告急提示信息，若能，一次性清理所有扇区，将所有构件整理为前后紧密连续存储，并告知对应上位机本次操作将有一定耗时。

本发明的优点在于：

本发明以串行通信这一通信方式作为通信模组自适应的前导研究，并基于此总结出通信模组自适应的User程序更新方法。并针对实现过程中的动态命令空间问题，给出动态构件库的解决方案，在化简动态命令的同时也具有一定的开发实用性，对于动态构件库内的Flash负载均衡问题也提供了完善的解决方案。

附图说明

通过阅读下文优选实施方式的详细描述，各种其他的优点和益处对于本领域普通技术人员将变得清楚明了。附图仅用于示出优选实施方式的目的，而并不认为是对本发明的限制。而且在整个附图中，用相同的参考符号表示相同的部件。在附图中：

附图1示出了根据本发明实施方式的用户串口的帧结构示意图。

附图2示出了根据本发明实施方式的基于用户串口User程序更新的动态命令执行流程图。

附图3示出了根据本发明实施方式的错误的函数依赖示意图。

附图4示出了根据本发明实施方式的针对函数依赖问题的函数重写示意图。

附图5示出了根据本发明实施方式的BIOS自更新动态命令函数依赖关系示意图。

附图6示出了根据本发明实施方式的紧凑原则下各扇区的擦除频率和使用寿命趋势示意图。

附图7示出了根据本发明实施方式的Flash碎片整理示意图。

具体实施方式

下面将参照附图更详细地描述本公开的示例性实施方式。虽然附图中显示了本公开的示例性实施方式，然而应当理解，可以以各种形式实现本公开而不应被这里阐述的实施方式所限制。相反，提供这些实施方式是为了能够更透彻地理解本公开，并且能够将本公开的范围完整的传达给本领域的技术人员。

本发明提出了一种嵌入式终端远程软件更新方法，以此来适应不同应用场景下的软件更新需求并兼顾系统框架本身的可移植可复用性。动态命令作为主要载体，为软件更新功能提供灵活性和适应性支撑。本发明以串行通信这一通信方式作为通信模组自适应的前导研究，并基于此总结出通信模组自适应的User程序更新和BIOS自更新方法。并针对实现过程中的动态命令空间问题，给出动态构件库的解决方案，在化简动态命令的同时也具有一定的开发实用性，对于动态构件库内的Flash负载均衡问题也提供了完善的解决方案。本发明选取相对固定BIOS程序来负责适应不同的通信模组，由用户程序来承载变化的通信模组驱动构件。由此，这种软件更新方法下的基础软件架构得以确定。

嵌入式应用开发中选取的通信模组，往往不具备与对应的嵌入式终端直接通信的能力，一般的解决方案是借助嵌入式终端中固有的通信方式作为桥梁，以此达成两者之间的数据交互。此外通信模组自适应软件更新的核心问题是BIOS借助User的通信模组实现程序更新。因此作为前导研究，应当挑选较为简单的通信方式，串行通信作为MCU常见外设接口，通信速度、安全性有一定保障，且通过简单的外设电路可方便转换为RS485/RS232接口，进一步保证通信稳定性与传输距离。故选择串行通信作为User的通信方式来研究针对User程序更新方式的实现，为总结出通信模组自适应软件更新的一般方法做准备。

1基本要点和设计思路

基于用户串口的用户(User)程序更新并不是一个频繁的需求，并且考虑到后续的程序更新可能不局限于串行通信，应当结合动态命令来将基于用户串口的User程序更新作为一个临时的功能处理。此外程序更新的主体对象仍然是用户程序，因此较为简便的实现方法仍然是将BIOS程序作为执行更新的主要场所，故存在一个User程序和BIOS程序相互跳转的环节。而所有数据的收发均基于用户程序的串口，这就意味着User程序中应当向BIOS动态命令区中写入动态命令，且考虑到数据的收发仍然主要由BIOS程序进行，因此BIOS程序要进行用户串口的接管。

1.基本设计要点

(1)程序的跳转。用户串口的程序更新场景下，目标嵌入式终端中必然已经存在一个版本的User程序正在运行，因此程序的跳转首先是由User程序向BIOS程序的跳转。

由User程序向BIOS程序的跳转依然是由用户串口接收数据决定的，因此在对用户串口接收数据的解析中，需要保留一定关键字，用于标识这帧数据为系统指令，需要进行程序的跳转。

而在新版本用户程序的数据接收完毕后，从BIOS程序跳转至User程序的步骤就比较简单，沿用通用嵌入式计算机框架下(以下简称GEC框架)基本的User程序引导方式即可。

(2)用户程序中动态命令体系的建立。同样的，动态命令的具体功能由用户串口接收并写入，而动态命令的执行仍然由BIOS程序进行，因此与上文中的程序跳转一样，在系统指令下，同样需要预留一个关键字用于引导动态命令的写入。

(3)BIOS程序对用户串口的接管。BIOS程序对用户串口的接管除了需要初始化用户串口并中断使能以外，还需要重定向用户串口的中断处理程序。而针对这些BIOS程序中并不存在的功能，利用动态命令来实现即可。

2.主要设计思路

综合前文所述，基于用户串口的User程序更新主要设计思路如下：

(1)向用户程序串口发送动态命令数据，并由User程序写入。

(2)向用户程序串口发送程序跳转的系统指令。User程序在接收到指令后，跳转至BIOS。

(3)BIOS启动过程中默认调用动态命令函数。在动态命令内首先修改程序运行状态，完成BIOS的驻留；其次完成用户串口的初始化和中断使能；并设置BIOS程序中断向量表内对应于用户串口的中断服务例程地址为动态命令函数；最后告知上位机，相关初始化步骤已执行完毕，可以开始程序更新。

(4)上位机开始向用户串口发送User程序数据帧，终端通过用户串口的中断服务例程(即动态命令)完成接收、校验和写入。

(5)当用户串口的中断服务例程(即动态命令)完成最后一帧数据的处理工作时，修改程序运行状态，复位BIOS，由BIOS基础运行流程完成针对User程序的后续引导。

2具体实现方式

在给出基本设计思路后，接下来进行基于用户串口User程序更新具体实现的阐述，主要围绕用户串口的帧结构和动态命令体系展开。

1.用户串口的帧结构

用户串口的最外层帧结构为通信层的组帧结构，可能包含帧头、帧尾、数据长度、通信层数据和校验位等内容。在通信层数据内的帧结构应当预留设备唯一序列号和软件版本号等内容，来协助判断某些广播场景下的数据帧取舍。而通信层数据内的有效数据帧结构则是由开发者自行定义的，但是为了完成诸如通信模组自适应的软件更新，需要预留一个关键字作为系统指令的帧标识，来提供丰富的预设功能，如程序跳转、设备序列号查询等。用户串口的帧结构如图1所示。

2.GEC下动态命令体系的建立

GEC下动态命令体系的建立，同样要从BIOS工程和User工程两个角度来考虑。

(1)BIOS工程内动态命令体系的建立。动态命令体系的软件基础为P

步骤一：修改链接文件，在MEMORY字段和SECTIONS字段增加对应于动态命令的FLASH空间。

步骤二：增加动态命令函数的声明和定义，函数体为空，并使用attribute语法将动态命令函数放置于步骤一中的FLASH空间。

步骤三：在通信模组接收数据的中断处理程序中预留两个帧标识分别用于接收动态命令函数的机器码和执行动态命令函数。

步骤四：在更新状态判断函数中增加动态命令执行分支。

步骤五：在按键复位中增加动态命令重置步骤。这里的重置是指将动态命令的功能还原至空函数，即复位后的机器码对应于C语言代码的“return 0；”。

(2)User工程中动态命令体系的接入。在BIOS工程内建立动态命令体系后，已经可以满足绝大部分的临时功能添加需求。然而针对一些特殊的临时功能，特别是那些需要借助User工程内资源实现的功能，就必须在User工程中接入动态命令体系。基于用户通信模组的User程序更新就是一个典型的例子。

与在BIOS工程中建立动态命令体系不同的是，在User工程中只需要进行动态命令体系的接入，动态命令存储的空间不变仍然位于BIOS内，只是为User工程提供动态命令写入的方式，即两个工程共同维护一块动态命令空间。

User工程作为开发者的主要开发场所，具体的通信模组由开发者自行决定，而动态命令体系必然依赖于通信模组数据的收发，因此要将动态命令的写入功能放置于系统指令内，而系统指令则作为User工程模板的固定文件，这样就可以实现不同通信模组中动态命令体系的接入。

3.基于动态命令的开发流程

接下来给出基于动态命令体系的开发流程。

(1)P

(2)动态命令的编写、校验和提取。首先在P

(3)动态命令与上位机软件的融合。根据运行结果，确认动态命令制作无误后，根据需要将动态命令机器码的提取、发送和运行加入指定上位机窗口的事件内。由此来实现依靠上位机使得运行着P

4.动态命令的具体设计

前文已经提到动态命令的具体内容应该分为两部分。其中第一部分应该是在BIOS程序的默认调用处执行的，主要完成对用户串口的初始化、中断使能和接管用户串口中断，并预留配合后续更新的代码；第二部分则是用户串口中断处理程序的具体内容。其中，在接管用户串口中断时需要注册用户串口中断服务例程函数，这里直接选取动态命令地址即可，而针对动态命令的两部分内容，以是否触发通信模组中断为条件将动态命令一分为二来保证两部分内容互不干扰。基于用户串口User程序更新的动态命令执行流程如图2所示。

通信模组自适应的User程序更新方法

嵌入式应用开发中选取的外部通信模组，往往需要借助嵌入式终端中固有的通讯模组来进行数据连接的建立。后文将以串行通信为例，使之作为连接嵌入式终端与外部通信模组的桥梁，因此外部通讯模组在具体工程内的构件设计可以理解为基于上行通信的上层构件设计。

通过深入分析前文基于用户串口的User程序更新方法，总结并提取出涉及串行通信的主要工作，主要包括：串行通信的初始化、中断使能、中断服务例程地址的指定、数据的发送和数据的接收。由此在通信模组自适应的程序更新方法中，抽象出通信模组的公共要素为：通信模组的初始化、中断使能、中断服务例程地址的指定、数据的发送和数据的接收。

由此通信模组自适应的User程序更新设计方法就变得相对清晰，通信模组的相关工作只在User程序的对应中断和动态命令内进行，因此针对两者给出详细的设计方法即可。

User程序内的通信模组数据接收中断

针对User程序内的通信模组数据接收中断，主要从数据帧来说明。

通信模组的数据帧并不随着通信模组的改变而发生结构上的变动，因此具体的帧结构仍然采用图1所示的用户串口帧结构设计方法即可。

并且同样的，由于通信模组自适应的User程序更新本质上还是BIOS程序对User程序的更新，因此数据帧内的系统指令标识中，仍然需要预留程序跳转指令，用于将目标终端的程序运行状态从User拉回至BIOS。

此外由于通信模组驱动构件的依赖和程序执行流程的需要，系统指令标识中仍然需要接入动态命令体系，向User程序提供动态命令的写入接口。

动态命令的设计

通信模组自适应下的动态命令主要功能包含：通信模组的初始化、通信模组的中断使能、通信模组中断服务例程的重定向、基于通信模组的更新流程和BIOS中断向量表的复原等。主要决策算法如下。

整体流程设计

通信模组自适应的User程序更新整体流程设计如下：

(1)向通信模组发送动态命令数据，并由User程序写入。

(2)向通信模组发送程序跳转的系统指令。User程序接收指令，跳转至BIOS。

(3)BIOS启动过程中默认调用动态命令函数。

(4)在动态命令内首先修改程序运行状态，完成BIOS的驻留；其次完成通信模组的初始化和中断使能；并设置BIOS程序中断向量表内对应于通信模组的中断服务例程地址为动态命令函数；最后告知上位机，相关初始化步骤已执行完毕，可以开始程序更新。

(5)上位机开始向通信模组发送User程序数据帧，终端通过通信模组的中断服务例程(即动态命令)完成接收、校验和写入。

(6)当通信模组的中断服务例程(即动态命令)完成最后一帧数据的处理工作时，修改程序运行状态，复位BIOS，由BIOS基础运行流程完成针对User程序的后续引导。

通信模组自适应的BIOS自更新方法

保证嵌入式终端软件框架稳定性的重要前提是BIOS工程的稳定，在当发现BIOS存在致命隐患的情况下急需一种BIOS自我更新的机制，动态命令的支撑使得BIOS自更新得以实现。

主要方法设计

与User程序的更新类似，通信模组自适应的BIOS自更新大致思想是：通过系统指令完成动态命令的写入和程序跳转，借助动态命令完成通信模组的接管，然后开始进行BIOS自更新流程，先接收新版BIOS的机器码并存放在当前BIOS机器码的后方，在新BIOS的机器码接收完并通过校验后，逐扇区将旧BIOS的机器码替换更新为新BIOS的机器码。BIOS自更新的主要步骤如下：

(1)编写相关函数制作动态命令代码。

(2)向目标芯片User程序发送BIOS自更新的动态命令安装包，目标芯片接收到后写入动态命令区。

(3)向目标芯片User程序发送系统指令，使之跳转并驻留至BIOS内。

(4)BIOS调用动态命令，完成用户通信模组的接管。

(5)开始向目标芯片发送新BIOS工程的机器码，逐帧校验后保存在当前BIOS存储空间的后方，并针对最后一帧数据给出特殊的帧头。

(6)目标芯片检测到最后一帧数据并校验存储后，不立即退出中断，进入中断内的数据搬迁工作，使得新BIOS正式取代旧BIOS，搬迁完毕后进行软复位，开始执行新的BIOS流程。

动态命令内的主要决策算法如下所示。

函数依赖问题

在逐扇区替换旧BIOS的过程中，遇到的关键问题是：在使用旧BIOS中Flash构件的擦除函数进行旧BIOS的擦除时，当擦除函数试图对擦除函数本身所在扇区进行擦除时必然会出现致命错误，也会导致后续旧BIOS中Flash构件的其他函数无法使用，如图3所示。

为了避免对旧BIOS的函数依赖，采取的初步策略是在动态命令函数中重写整个更新过程中的会使用到的Flash构件函数，并且BIOS自更新的区域跳过动态命令函数区域，如图4所示。

由于动态命令本质上是在中断内被调用，在动态命令接收到新BIOS的最后一帧数据后，使得程序不从动态命令中跳出回到旧BIOS的主函数，而是继续停留在动态命令区域进行新旧BIOS的逐扇区替换，这样也就不存在想要跳回主程序但主程序已被擦除的问题了，只需当动态命令完成新旧BIOS的逐扇区替换后进行一次软件复位即可。

进一步分析以上问题可以发现，针对欲擦除代码的函数依赖问题只开始于逐扇区替换旧BIOS数据这一过程，因此一个更加简易的应对策略是，只需要针对从这一过程开始的、具有依赖问题的函数进行重写即可。BIOS自更新动态命令函数依赖关系如图5所示。

动态命令的化简：动态构件库

前文给出的一系列程序更新方式，都是依赖动态命令来完成核心功能的实现。然而动态命令的初衷是通过多个临时功能对一块小区域空间的共同使用，达到有限空间内多种功能动态加载的效果。前文中的程序更新场景下，由于通信模组在软件框架内隶属于User程序的资源，这样就使得向BIOS传输通信模组相关功能的动态命令时，需要在动态命令内重写一个通信模组的函数副本或将通信模组函数展开。由此必然导致动态命令的代码量过大，甚至在面对实现方式复杂的通信模组，可能会出现空间不足的问题。

动态构件库的提出

在动态命令由于大量的函数依赖问题而进行函数重写和展开的情况下，动态命令本身的存储空间可能不足以容纳庞大的代码，因此急需一种方法来进行函数、构件的集中管理存储，以便动态命令调用。此外，GEC软件框架中的BIOS工程在开发者获取到嵌入式终端时，就已经被固化在芯片内部，由GEC框架开发者维护，因此GEC框架也存在发布稳定的构件供开发者使用的需求，并且需要一种不泄露源代码的发布方式。由此引入基于动态命令的动态构件库技术。

动态构件库是BIOS提供的一种构件管理模式，该模式下由动态命令负责构件的增、删、查、改等工作，结合上位机生成对应的构件头文件供用户使用。

动态构件库的设计方法

动态构件库的设计主要依靠在BIOS链接文件中开辟的两块区域：构件函数列表区和构件函数代码区，其中构件函数列表区用于存放构件的函数指针和其他必要参数，构件函数代码区用于存放构件内各个函数的具体实现，此外由动态命令函数来负责对这两块区域数据的管理，User工程对动态构件库内函数的使用则通过BIOS工程提供的API(Application Programming Interface)接口。

1.构件函数列表区的设计

构件函数列表区的编程形式为指针类型(32位)的数组，主要划分为三个区域：构件库参数区、系统相关区和构件区，主要组织形式及对应参数的功能如表3-1所示。

表3-1构件函数列表区的设计

2.主要管理方式的初步设计

有了构件函数列表区的索引和相关参数，动态命令就可以很方便的对各个构件、甚至是各个函数，进行查询操作，并结合构件函数代码区进行增加、修改和删除的操作。

(1)查询。构件函数列表区针对构件库本身的所有数据给出了详细的记录，因此在出现相应信息的查询需求时，只需依靠动态命令读取构件函数列表区的数据并回发至上位机，由上位机解析即可。

(2)增加。在增加一个构件时，首先要根据构件函数列表区的“下一个可用编号”字段来确定当前构件的总体信息在构件函数列表区的记录位置，并在记录完毕后修改“下一个可用编号”字段。此外还需根据“函数代码区下一次可写地址”字段来确定构件机器码的写入地址，并在写入完毕后相应的修改“函数代码区下一次可写地址”和“函数代码区已用空间”字段值。

(3)删除。在存在构件删除需求时，首先要根据构件函数列表区内各区域的“区域占用编号”字段依次链式查询构件名，在定位到欲删除构件时，删除对应的构件函数列表区和构件函数代码区的数据，并修改“下一个可用编号”、“函数代码区下一次可写地址”和“函数代码区已用空间”字段。

(4)修改。由于Flash以扇区为最小擦除单位的机制，针对构件的修改操作可以简单的拆解为先删除后添加。不同的是在删除后不立即进行两个区域的Flash写入操作，而是在进行增加操作后一同写入。具体方法已在(2)(3)中阐述。

得益于动态命令本身的机制，这些操作不会影响系统当前的运行状态，也不会过多的影响实时性，免去了停机和重复烧写程序的繁琐。

Flash负载均衡

考虑到Flash本身的使用寿命，如果在多次的构件增删改操作中，每一次操作都保证构件函数代码区的紧凑，那么这些操作往往会导致构件函数代码区寿命的两极分化严重，这是因为常规场景下，构件函数代码区的实际使用占比不会接近100％，以50％的平均实际使用空间为例，构件函数代码区的各扇区的擦除频率及对应的寿命将大致呈现如图6的分布。且构件函数代码区的平均实际使用空间占比越小、构件增删改操作的次数越多，这样的两级分化将越严重。

针对这个问题，本申请提出了一种Flash负载均衡方案：

(1)对于删除的操作，不擦除原本所占据的空间，仅修改构件函数列表区的“函数代码区已用空间”这一参数；

(2)对于修改的操作，同样不擦除原本所占据的空间，改而直接寻找下一个可存储的空间写入，该函数存储空间大小的绝对变化记录在“函数代码区已用空间”这一参数。(1)(2)中产生的废弃代码数据所占据的空间以下称为Flash碎片。

(3)在进行增加操作和修改过程中的增加操作时，如若找不到可以容纳该构件的连续存储空间，则根据“函数代码区已用空间”、“函数代码区首地址”和“函数代码区尾地址”这三个参数，计算剩余连续空闲空间和由(1)(2)产生的所有Flash碎片总和是否可以容纳该构件，若不能，则返回相应的存储空间告急提示信息，若能，一次性清理所有扇区，将所有构件整理为前后紧密连续存储如图7所示，并告知对应上位机本次操作将有一定耗时。

该方案的核心思想是，在存储空间足够的情况下，优先使用后方空闲的存储空间，在提升尾部扇区的使用率的同时，很大程度上避免了擦除Flash操作，直至空闲存储空间不足时，才考虑对Flash碎片进行整体的处理。详细的算法表示如下：

以上所述，仅为本发明较佳的具体实施方式，但本发明的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本发明揭露的技术范围内，可轻易想到的变化或替换，都应涵盖在本发明的保护范围之内。因此，本发明的保护范围应以所述权利要求的保护范围为准。