一种轻量化的有线Mesh组网设计方法

技术领域

本发明涉及网络通信技术技术领域，特别涉及一种轻量化的有线Mesh组网设计方法。

背景技术

在工业互联网等嵌入式应用场景当中，单个局域网内包含大量的传感器、控制器和执行器等设备，对于组网的灵活性、鲁棒性和成本等都提出了新的要求。传统的以路由器或网关为中心的星形组网方式在灵活性、鲁棒性和成本上都存在明显劣势，当前的Mesh组网则存在开发和维护复杂、成本高等问题。以上问题限制了工业互联网等新兴技术的产业化进程。

发明内容

本发明的目的在于提供一种轻量化的有线Mesh组网设计方法，以克服现有技术中的不足。

为实现上述目的，本发明提供如下技术方案：

本申请公开了一种轻量化的有线Mesh组网设计方法，其特征在于，所述轻量化的有线Mesh组网由若干个设备组成，每个设备上设有若干个用于接收或发送轻量化的有线Mesh消息的端口，所述设备之间通过端口相互连接，所述设计方法具体如下步骤：

S1、设计轻量化有线Mesh网络消息的协议格式：所述轻量化有线Mesh网络消息包括消息头和消息体；

S2、设计轻量化有线Mesh网络消息的输入解析模块：所述输入解析模块用于输入接收到轻量化有线Mesh网络消息，获取轻量化有线Mesh网络消息的消息头中的消息类型的字段，根据该字段的值，调用不同的处理函数对轻量化有线Mesh网络消息进行处理；

S3、设计轻量化有线Mesh组网中设备之间的心跳逻辑模块；

S4、设计轻量化有线Mesh组网中网络的路由管理模块；

S5、设计轻量化有线Mesh网络消息的转发和处理模块；

S6、设计底层硬件接口管理模块。

作为优选，所述步骤S1的具体设计如下：所述消息头长度为14字节，所述消息头的前6字节的值均为固定的0xff；所述消息头的第7和第8字节分别为目的设备ID的高8位和低8位；所述消息头的第9和第10字节分别为轻量化有线Mesh网络消息整体长度的高8位和低8位；所述消息头的第11和第12字节为轻量化有线Mesh网络消息最大转发数的高8位和低8位；所述消息头的第13和14字节为消息类型的高8位和低8位；

作为优选，所述步骤S2中所述的消息类型包括但不限于心跳类型网络消息、路由管理类网络消息和用户业务消息，所述处理函数包括但不限于心跳类型网络消息处理函数、路由管理类网络消息处理函数和业务消息处理函数。

作为优选，所述步骤S3具体包括以下子步骤：

S31、设计配置接口：用于配置心跳循环时间和心跳超时时间；

S32、设计心跳类型网络消息的收发机制：心跳类型网络消息的收发只维护在端口直接相连的设备之间，通过中间设备的端口间接相连的设备之间接收不到对方发送的心跳类型网络消息；

S33、设计发送心跳超时表和接收心跳超时表：发送心跳超时表用于记录距离上一次向相邻端口发出心跳类型网络消息的时间，若时间超过配置的心跳循环时间，则需要重新发送一次心跳类型网络消息；接收心跳超时表用于记录距离上一次接收到相邻端口心跳类型网络消息的时间，若时间超过配置的心跳超时时间，则判定该相邻端口的设备掉线。

作为优选，所述步骤S31中设计配置接口的方式为以下方式中的一种：

S311、用户通过配置文件作为接口；

S312、设计专门的配置接口由用户将配置数据进行传入；

S313、默认心跳循环时间为2s，心跳超时时间为1min。

作为优选，所述步骤S4具体包括以下子步骤：

S41、设计配置接口：选择当前轻量化的有线Mesh网络组网当中最大设备数量，选择的范围是128、256、512和1024四个档位中的一种；

S42、设计端口相对目的设备ID的跳数表：所述跳数表的数量与设备的有线网络端口数相同，每个跳数表的长度等于用户配置的最大组网设备数；所述跳数表用于记录各个端口相对于各个设备的跳数；

S43、设计设备相对目的设备ID的跳数二表：所述跳数二表用于记录当前设备相对目的设备的最小跳数，所述跳数二表的长度等于用户配置的当前组网当中最大设备数；

S44、设计心跳类型网络消息的收发机制：路由管理类的网络消息只在端口直接相连的设备之间进行收发，通过中间设备端口间接相连的设备之间接收不到对方发送的路由管理类型的网络消息；

S45、设计路由管理类型网络消息的回复和重发机制：设备接收到路由管理类型的消息后需要回复；设备发送路由管理类型的消息后若没有收到回复，则周期性重发，直到判定设备掉线或扫描到端口未连接，更新路由信息。

作为优选，所述步骤S41中设计配置接口的方式为以下方式中的一种：

S411、用户通过配置文件作为接口；

S412、设计专门的配置接口由用户将配置数据进行传入；

S413、默认最大设备数量为256。

作为优选，所述步骤S5中具体包括如下步骤：

S51、获取轻量化有线Mesh网络消息的消息头当中的目的设备ID的字段，与自身设备ID进行比较；

S52、若匹配，则调用业务逻辑处理接口对轻量化有线Mesh网络消息进行处理；若不匹配，则根据目的设备ID检索跳数表，获取最短跳数的对应的端口，将消息从该端口转发出去；所述业务逻辑处理接口包括标准接口和用户自定义的接口。

S53若获取端口失败，则更新路由信息，并向相邻端口发送路由更新的消息，从而回溯路由表，修正轻量化的有线Mesh组网中各个端口的路由信息。

作为优选，所述步骤S6中具体包括以下子步骤：

S61、设计必选硬件接口管理模块，提供用户针对必选硬件接口的注册功能，所述必选硬件接口包括硬件初始化接口、消息发送接口、消息接收接口、连接状态查询接口；

S62、设计可选硬件接口管理模块，提供用户针对可选硬件接口的注册功能，所述可选硬件接口包括连接速率查询接口、硬件包过滤配置接口、CRC校验配置接口。

本发明的有益效果：与现有技术相比，本发明提供一种轻量化的有线Mesh组网设计方法，以解决现有存在的传统星形网络灵活性、鲁棒性不强，无线Mesh等组网方式成本高、开发与维护难度大等问题，本发明可以极其突出“轻量化”的特征，以C语言实现基本功能只需代码1K行左右，运行时内存数据空间占用<5K，可以在市面上绝大多数常用MCU/FPGA当中移植，本发明可以满足Mesh组网的去中心化、每个节点都是路由两大特征，极大提高组网的灵活性、鲁棒性，在工业冗余组网等场景有明显的优势。

本发明的特征及优点将通过实施例结合附图进行详细说明。

附图说明

图1是本发明实施例提供的一种轻量化的有线Mesh组网设计方法的流程图。

图2是轻量化有线Mesh网络消息的协议格式示意图。

图3是以C语言作为编程语言实施本发明的轻量化有线Mesh网络消息的协议格式的结构体设计。

图4是轻量化有线Mesh网络消息的输入解析模块流程图。

图5是一种轻量化有线Mesh网络的组网结构图。

图6是轻量化的有线Mesh组网设计中路由管理类型的网络消息的消息结构示意图。

图7是业务逻辑消息的处理和转发流程图。

具体实施方式

为使本发明的目的、技术方案和优点更加清楚明了，下面通过附图及实施例，对本发明进行进一步详细说明。但是应该理解，此处所描述的具体实施例仅仅用以解释本发明，并不用于限制本发明的范围。此外，在以下说明中，省略了对公知结构和技术的描述，以避免不必要地混淆本发明的概念。

参考图1，本发明实施例提供一种轻量化的有线Mesh组网设计方法，包括：

步骤S1，设计轻量化有线Mesh网络消息的协议格式：

具体的，参考图2，轻量化有线Mesh网络消息分为消息头和消息体，其中消息头长度为14字节，消息头的前6字节的值均为固定的0xff，目的是大多数底层网口驱动芯片的驱动程序默认mac地址过滤，采用广播地址可以避免消息包被过滤，消息头的第7和第8字节分别为目的设备ID的高8位和低8位，16位的设备ID可以支持最多65536个设备同时组网，消息头的第9和第10字节分别为消息包整体长度的高8位和低8位，一般嵌入式网络协议栈的单个包长度为1500字节，16位的消息长度字段可以覆盖这些包长度的标识需求，消息头的第11和第12字节为消息包最大转发数的高8位和低8位，一般情况下消息包的最大转发数与当前组网的最大设备数相同，因而该字段的长度与目的设备ID字段的长度保持一致，消息头的第13和14字节为消息类型的高8位和低8位，轻量化有线Mesh组网当中基本功能的实现需要心跳消息、路由管理消息、业务消息三种类型，用户可以根据自身的业务需求对这些消息类型进行扩展，消息体从网络消息包的第15字节开始。

以C语言作为编程语言来实施本发明，可以如参考图3所示，以结构体的形式设计和定义轻量化有线Mesh网络消息的消息结构。

以上的网络消息协议将传统的二层网络消息头进行改造，以2字节的设备ID代替6字节的mac地址作为设备标识，从而节省出4个字节用于标识其他信息，为有线Mesh组网的轻量化特性打下基础。

步骤S2，设计轻量化有线Mesh网络消息的输入解析模块：

具体的，参考图4，输入解析模块用于输入接收到的网络消息包，获取轻量化有线Mesh网络消息的消息头当中消息类型字段，根据该字段的值，调用不同的处理函数对消息包进行处理。

实现轻量化有线Mesh组网的基本功能只需要对心跳类型网络消息、路由管理类网络消息和用户业务消息这三类消息进行处理，相应的通过消息头当中的消息类型字段，分别调用心跳类型网络消息处理函数、路由管理类网络消息处理函数和业务消息处理函数等等。以C语言作为编程语言来实施本发明，可以参考图4右上方的代码，以switch-case语句配合msg_type的枚举变量轻易实现。若用户的业务消息不止一种，可以对msg_type枚举变量进行扩展，相应的在数据解析模块的switch-case语句当中增加扩展后的业务逻辑处理函数即可。

步骤S3，设计轻量化有线Mesh组网设备之间的心跳逻辑模块，具体包括以下子步骤：

步骤S31，设计配置接口，用于配置心跳循环时间和心跳超时时间；具体的，用户配置可以通过配置文件（如内容为json格式的文本文件）作为接口，也可以设计专门的配置接口由用户将配置数据进行传入，若用户未对该项目进行配置，则心跳循环时间的默认值为2s，心跳超时时间的默认值为1min。

步骤S32，设计心跳类型网络消息的收发机制，心跳类型网络消息的收发只维护在端口直接相连的设备之间，通过中间设备的端口间接相连的设备之间接收不到对方发送的心跳类型网络消息；具体的，参考图5，设备0与设备1直连，设备1与设备2直连，设备0仅需要维护跟设备1之间的心跳收发。设备0不会收到设备2发送的心跳消息，也不会向设备2发送心跳消息，也不需要判断设备2是否在线。

以C语言作为编程语言来实施本发明，则发送心跳消息时只需要填充图3所示的msgtype字段，将其赋值为心跳消息的枚举值。消息头的前6字节默认为6个0xff，从而防止接收端对MAC地址过滤。其他字段均可以不填充，保持默认值。心跳消息没有目的地址和源地址之分，它只跟端口绑定，从而极大简化了心跳交互机制，进一步强化本发明的轻量化特征。

步骤S33，设计两个心跳超时表，一个为发送心跳超时表，另一个为接收心跳超时表；发送心跳超时表用于记录距离上一次向相邻端口发出心跳类型网络消息的时间，若时间超过用户设定的心跳循环时间，则需要重新发送一次心跳消息；接收心跳超时表用于记录距离上一次接收到相邻端口心跳类型网络消息的时间，若时间超过用户设定的心跳超时时间，则判定该相邻端口的设备掉线。

具体的，以C语言作为编程语言来实施本发明，则心跳超时表可以用数组来实现，数组的长度等于设备的有线网络端口数。参考图5，设备1有两个端口，则它的接收心跳超时表和发送心跳超时表的长度均为2，对应端口0和端口1。通过毫秒定时器中断，每毫秒给各个心跳超时表当中的各个项+1，并判断当前项是否超时。若设备1的发送心跳超时表当中的第0项超时，则需要调用步骤S1032当中所述的心跳发送接口，从设备1的端口0发出心跳消息，消息发送完成后将表中的该项清零。若设备1从端口0接收到心跳消息，则将接收心跳超时表当中的第0项清零；若持续未接收到心跳消息，当心跳超时表当中的第0项超时，则判定设备0掉线，然后调用一系列的掉线逻辑处理函数，比如更新路由信息等等。

步骤S4，设计轻量化有线Mesh网络的路由管理模块，具体包含以下子步骤：

步骤S41，设计配置接口，选择当前轻量化的有线Mesh网络组网当中最大设备数量，选择的范围是128、256、512和1024四个档位；具体的，用户通过配置文件（如内容为json格式的文本文件）作为接口，也可以设计专门的配置接口由用户将配置数据进行传入。若用户未对该项目进行配置，则组网当中最大设备数量默认值为256；之所以选择128、256、512、1024四个值，是为了在配套相应的内存资源时保持4字节对齐。

以C语言作为编程语言实施本发明，则需要通过配置文件，将用户选择的最大设备数作为编译宏传入代码工程当中，代码编译完成后可以通过相应工具获得代码资源的使用情况，如占用的ROM大小、RAM大小等等，以此作为参考来对比设备本身的资源，看设备能否支持用户设定的档位，若不支持则需要将档位调小。

步骤S42，设计端口相对目的设备ID的跳数表，跳数表的数量等于设备的有线网络端口数，每个表的长度等于用户配置的最大组网设备数；跳数表用于记录各个端口相对于各个设备的跳数，端口相对自身备身的跳数为0，相对于直连于该端口上的临近设备的跳数为1，每经过一个设备，跳数加1；设备上电后，各个端口相对于自身设备ID的跳数初始化为0，相对于其他设备ID的跳数初始化为用户配置的当前组网当中最大设备数；具体的，以C语言作为编程语言实施本发明，可以通过二维数组hops[port][dstDevId]作为跳数表；参考图5，假设用户配置最大设备数量为128，当前共四个设备在线，设备0只有1个端口，故实际上是一个一维数组，在初始化时，设备0的跳数表初始值为hops[1][128] = {0, 128, 128,…}；数组当中第一个跳数值为0，是因为该值是设备0相对于自身的跳数；参考图5，假设用户配置最大设备数量为128，当前共四个设备在线，设备2和设备3都有2个端口，在初始化时，设备2的跳数表初始值为hops[2][128] = {{128, 0, 128, 128, …}, {128, 0, 128,128, …}}，每个端口对应的一维数组当中第二个跳数值为0，是因为该值是设备1相对于自身的跳数，设备1和设备3的跳数表初始值可以以此类推。

步骤S43，设计设备相对目的设备ID的跳数二表，用于记录当前设备相对目的设备的最小跳数，跳数二表的长度等于用户配置的当前组网当中最大设备数，当前设备相对目的设备的最小跳数等于当前设备的各个端口相对于目的设备的跳数的最小值。

具体的，以C语言作为编程语言实施本发明，可以通过一维数组shortestHops[dstDevId]作为跳数二表。该跳数二表与步骤S42当中跳数表的关系是：shortestHops[dstDevId] = min{hops[0][ dstDevId], hops[1][ dstDevId], …}，即当前设备相对目标设备的最小跳数，等于当前设备的各个端口相对目标设备的跳数当中的最小值。

步骤S44，设计路由管理类型网络消息的收发机制，路由管理类网络消息的消息体包含了发送该消息的设备相对当前组网当中其他设备的最小跳数的信息，设备通过收发路由管理类型的网络消息进行跳数表和跳数二表当中跳数的更新和同步；路由管理类的网络消息只在直接相连的设备之间进行收发，通过中间设备端口间接相连的设备之间接收不到对方发送的路由管理类型的网络消息。

具体的，参考图6，以C语言作为编程语言实施本发明，则可以直接将步骤S1043当中描述的一维数组shortestHops[128] 拷贝到消息体当中。为了保证路由管理类型的网络消息的“新鲜度”，需要在消息体的末尾添加序列号或者时间戳，消息的接收方可以通过该序列号或者时间戳，判断是否为最新的路由管理类型的网络消息。

由上述说明可以得出，当用户设定了最大设备数以后，路由管理类型的网络消息体的长度就是确定的，通过判断路由管理类型的网络消息的长度，可以得到用户设定的最大设备数，这样即使同一组网当中用户对不同设备配置的最大设备数并不一致，整体的组网功能也可以兼容，只是某些设备可能不可达。例如设备0上设置了最大设备数为128，则设备129是不可达的，即使设备0与设备129之间有物理线路的连接。

设备通过收发路由管理类型的网络消息进行跳数表和跳数二表当中跳数的更新和同步，具体的，参考图5，假设用户配置最大设备数量为128，设备0上电初始化完成后，它会周期性扫描端口0的连接状态，当发现端口0从无连接状态变为有连接状态，则会构造如上所述的路由管理类型的网络消息，从自身的端口0发送出去。 设备1从自身的端口0接收到路由管理类型的网络消息后，会更新hops[3][128]这个数组，由于是从自身端口0接收到的消息，因而hops[0][128]更新为{1, 0, 128, 128, …}，第一个值为1是因为设备1的端口0相对于设备0的跳数为1，第二个值为0是因为相对于自身的跳数为0；此时设备1的shortestHops[128]这个数组也会随之更新，由初始化状态下的{128, 0, 128, …}更新为{1, 0, 128, …}。

触发路由管理类型的网络消息的开关有四个：1）设备上电后默认各个端口的状态为无连接，上电初始化完成后循环扫描各个端口的连接状态，当端口从无连接变换为有连接，则主动向该端口发送路由管理类型的网络消息；2）设备接收到某个端口发来的路由管理类型的网络消息后，发现自身的shortestHops[maxDevNum]表有了更新，则将更新完成后的跳数表放到消息体中，从其他有连接的端口发送出去（前述接收消息的端口不发送，防止成环），从而“扩散”式地将整个组网当中的路由信息进行更新和同步；3）通过步骤S3当中描述的心跳逻辑模块检测到某个端口连接的设备掉线，则更新自身的hops[port][dstDevId]数组以及shortestHops[dstDevId]数组，将更新后的跳数表从其他有连接的端口发送出去；4）当设备检测到“坏路由”，会主动发出路由管理类型的网络消息让其他组网设备同步路由信息，“坏路由”的检测方式由后文步骤S5当中具体描述。

参考图5，设备0仅与设备1直连，因而设备0仅针对设备1收发路由管理类型的网络消息，设备0与设备2或者设备3之间不会有路由管理类型的网络消息的交互。

以往的路由策略需要发送大量的广播包来进行交互，同时需要各种复杂的算法防止成环导致广播包无限制发送，由以上所述的轻量化有线Mesh组网方法当中的路由管理类型的网络消息的收发机制来看，通过取消组播，以“扩散”的方式代替组播，可以直接避免成环。同时，由于限制了当前组网当中的最大设备数量，所以该路由更新和同步方法可以实现快速收敛。

步骤S45，设计路由管理类型网络消息的回复和重发机制，路由管理类型的网络消息的消息体当中包含序列号信息，防止过期消息的干扰；接收到路由管理类型的消息后需要回复；发送路由管理类型的消息后若没有收到回复，则周期性重发，直到判定设备掉线或扫描到有线端口未连接。

具体的，参考图6，序列号可以是每发送一次路由管理消息后加1的编号，也可以直接用时间戳作为序列号，该序列号通过路由管理类型的网络消息在发送方和接收方之间同步，若设备接收到过期序列号的路由管理类型的网络消息，则直接丢弃。

具体的，为了防止路由管理类型的消息丢包，设备在发送完路由管理类型的网络消息后会启动一个计时器，若超过10ms未接收到路由管理消息的回复，则需要重发该消息。该重发机制只针对最新的路由管理类型的网络消息，若设备重发消息之前，自身的shortestHops[maxDevNum]表又有了更新，则只要求接收方针对最新的消息进行重发。

路由管理类型的网络消息的回复机制有多种实现方式，本实施例提供极简单的一种。参考图5，设备0发送路由管理类型的网络消息给设备1，设备1会原封不动得将该消息包回复给设备0；设备0接收到路由管理类型的网络消息后，从消息体当中的shortestHops[0]=0即可得知该消息为回复消息（设备1的shortestHops[0]=1），从而停止重发计时器。通过此种方式，无需构造新的交互消息类型，体现了“轻量化”的特征。

步骤S5，设计轻量化有线Mesh网络消息的转发和处理模块，包括：

S51、获取轻量化有线Mesh网络消息的消息头当中的目的设备ID字段，与自身设备ID进行比较；

S52、若匹配，则调用业务逻辑处理接口对消息包进行处理；若不匹配，则根据目的设备ID检索跳数表，获取最佳路由对应的网络端口，将消息从该网络端口转发出去；

S53、若获取端口失败，则更新路由信息，并向相邻端口发送路由更新的消息，从而回溯路由表，修正轻量化的有线Mesh组网中各个端口的路由信息。

具体的，步骤S2所述的消息输入解析模块通过消息头当中的消息类型字段，判断该消息为业务逻辑消息时，会调用有线Mesh网络消息的转发和处理模块的接口，后续的具体处理流程参考图7。业务逻辑消息输入后，会从消息头当中提取目标设备ID字段，跟自身ID进行比对，若比对成功，则调用业务逻辑处理接口，根据消息体当中的内容进行相关的业务逻辑处理。

此处的业务逻辑处理接口可以包含一些标准接口，例如modbus协议控制IO等等，也包含用户自定义的接口。这种用户自定义有多种实施方式，最简单的是直接开放头文件和源文件给用户自行开发，也可以参考UDP客户端的方式，提供接口给用户注册。

当接收到的业务逻辑消息当中，目标设备ID与自身设备ID不匹配，则需要转发这个消息包。转发的路由策略是一种递归的思想，每次需要转发消息时，设备都是选择最佳路由的网络端口发送出去，因而到达每一个节点的需要转发的业务逻辑消息，其前序路径都可以视为最佳的，设备只需要结合自身的shortestHops[maxDevNum]和hops[port][dstDevId]选出最佳端口，则可以保证后续的链路也都是最佳的。需要注意的是，此处的“最佳”是以最短跳数作为衡量标准。

若获取后的端口是无效的，则说明出现了“坏路由”，需要启动步骤S104当中描述的路由管理模块，再次更新和同步整体组网的路由信息和路由状态。端口的“无效”有两个判断标准：1）在检索跳数表时，目标设备ID对应的跳数≥当前组网设备的最大值，说明目标设备不可达；2）检索完跳数表后，获取到的发送端口与该条业务逻辑消息的输入端口是同一个，说明出现了转发环路。无论是哪种原因，“坏路由”都是由于组网当中路由信息不同步导致的，因而需要发起路由管理功能，重新同步路由信息。

步骤S6，设计底层硬件接口管理模块，包括以下子步骤：

步骤S61，设计必选硬件接口管理模块，提供用户针对必选硬件接口的注册功能，其中必选接口包括硬件初始化接口、消息发送接口、消息接收接口、连接状态查询接口。

步骤S62，设计可选硬件接口管理模块，提供用户针对可选硬件接口的注册功能，其中可选接口包括连接速率查询接口、硬件包过滤配置接口、CRC校验配置接口。

具体的，设计统一的底层硬件接口模块，可以方便其他模块直接调用底层硬件资源，减少中间的封装层，从而节省内存空间的占用，突出“轻量化”的特征。设计标准的底层硬件接口管理模块，也方便在不同平台上的移植，大大提高通用性。

接口模块的管理分为必选接口和可选接口，其中必选接口是实现轻量化有线Mesh组网所必需的一些功能，包括硬件初始化、消息发送、消息接口和连接状态查询接口。其中硬件初始化接口需要出入Mac地址、单双工工作模式、速率配置等信息。可选接口则是一些额外的功能相关，这些功能通过编译宏进行隔离。

以C语言作为编程语言实施该发明，硬件接口管理模块的具体实施方式也有很多种，最简单的一种是直接对用户开发头文件和源文件，头文件当中定义好标准硬件接口封装格式，由用户或者设备厂商实现接口的具体内容。许多智能家居平台就是以这种方式来实施底层硬件接口的标准化。

以上所述的轻量化有线Mesh组网方法的具体实施例，可以满足Mesh组网的两大特征：1）去中心化；2）每个节点都是路由。通过“扩散”“回溯”“限制广播”等一系列巧妙的方式，避免了复杂路由算法对资源的消耗，组网灵活性极强，也易于维护。以最大512个设备、每个设备最多4个端口的组网条件，以C语言作为编程语言，整个轻量化有线Mesh组网方法的实现，基本功能只需要1000行左右的代码即可，考虑到各种用户特定场景、代码安全等方面，整体代码量也不会超过10000行，运行时对于内存数据空间的占用小于5K，真正做到“轻量化”，从而做到低成本，可以在当前市面上任意一款常用的MCU/FPGA当中实现和移植。

以上所述仅为本发明的较佳实施例而已，并不用以限制本发明，凡在本发明的精神和原则之内所作的任何修改、等同替换或改进等，均应包含在本发明的保护范围之内。