类串口设备的驱动模型及驱动系统的制作方法

本发明涉及终端技术领域，具体而言，涉及一种类串口设备的驱动模型及驱动系统。

背景技术：

类串口设备是一类可串行读数据和写数据的实体设备或虚拟设备，如键盘或温度传感器等实体设备，及文件读写或远端文件操作等虚拟设备。应用程序需通过类串口设备的设备驱动来调用和管理类串口设备。

当前，相关技术中提供了一种类串口设备的驱动方法，包括：当应用程序需调用某类串口设备时，在应用程序中加入该类串口设备对应的驱动组件，应用程序直接通过该驱动组件与该类串口设备进行通信，实现对该类串口设备的控制和管理。若应用程序需调用其他类串口设备，则同样在应用程序中加入其他类串口设备对应的驱动组件，以实现对其他类串口设备的控制和管理。

但上述相关技术中只要增加新的类串口设备，或者原有的类串口设备的协议改变，都需要对应用程序重新进行开发和编译，导致开发成本增加。且应用程序包括的驱动组件越多，应用程序的维护难度越大，导致应用程序的兼容性和扩展性很差。

技术实现要素：

有鉴于此，本发明实施例的目的在于提供一种类串口设备的驱动模型及驱动系统，通过基于组件的软件分层结构来管理类串口设备，不需要对应用程序进行任何修改，即可实现应用程序与不同类串口设备之间的通信，不会增加应用程序的维护难度，提高了应用程序的兼容性和扩展性。

第一方面，本发明实施例提供了一种类串口设备的驱动模型，所述驱动模型包括设备驱动层和控制翻译层；

所述控制翻译层为应用程序提供统一控制接口，且包括一个或多个类串口设备对应的驱动组件；

所述设备驱动层分别与所述一个或多个类串口设备及所述控制翻译层连接，所述控制翻译层与所述应用程序连接。

结合第一方面，本发明实施例提供了上述第一方面的第一种可能的实现方式，其中，当所述应用程序向所述类串口设备发送设备控制信息时，

所述控制翻译层接收所述应用程序发送的设备控制信息，确定所述设备控制信息包括的设备标识对应的驱动组件，通过确定的所述驱动组件将所述设备控制信息的格式转换为所述设备标识对应的特定格式，通过所述设备驱动层传输所述特定格式的所述设备控制信息给所述设备标识对应的类串口设备。

结合第一方面的第一种可能的实现方式，本发明实施例提供了上述第一方面的第二种可能的实现方式，其中，当所述类串口设备向所述应用程序发送设备输入信息时，

所述设备驱动层接收所述类串口设备发送的所述设备输入信息，传输所述设备输入信息给所述控制翻译层；

所述控制翻译层确定所述设备输入信息包括的设备标识对应的驱动组件，通过确定的所述驱动组件将所述设备输入信息的格式转换为标准格式，传输所述标准格式的所述设备输入信息给所述应用程序。

结合第一方面，本发明实施例提供了上述第一方面的第三种可能的实现方式，其中，所述控制翻译层包括设备控制层、隔离层和设备访问层；

所述隔离层为所述应用程序提供所述统一控制接口；所述设备访问层包括所述一个或多个类串口设备对应的驱动组件；

所述设备控制层分别与所述应用程序、所述隔离层和所述设备驱动层连接，所述隔离层与所述设备访问层连接。

结合第一方面的第三种可能的实现方式，本发明实施例提供了上述第一方面的第四种可能的实现方式，其中，当所述应用程序向所述类串口设备发送设备控制信息时，

所述设备控制层接收所述应用程序发送的所述设备控制信息，根据所述设备控制信息包括的设备标识，通过所述统一控制接口，将所述设备控制信息传输给所述设备访问层中所述设备标识对应的驱动组件；

所述设备标识对应的驱动组件将所述设备控制信息的格式转换为所述设备标识对应的特定格式，将所述特定格式的所述设备控制信息通过所述统一控制接口传输给所述设备控制层；

所述设备控制层通过所述设备驱动层将所述特定格式的所述设备控制信息传输给所述设备标识对应的类串口设备。

结合第一方面的第三种可能的实现方式，本发明实施例提供了上述第一方面的第五种可能的实现方式，其中，当所述类串口设备向所述应用程序发送设备输入信息时，

所述设备驱动层接收所述类串口设备发送的所述设备输入信息，通过所述设备控制层传输所述设备输入信息给所述隔离层；

所述隔离层根据所述设备输入信息包括的设备标识，通过所述统一控制接口，将所述设备输入信息传输给所述设备访问层中所述设备标识对应的驱动组件；

所述设备标识对应的驱动组件将所述设备输入信息的格式转换为标准格式，将所述标准格式的所述设备输入信息通过所述隔离层及所述设备控制层传输给所述应用程序。

结合第一方面及第一方面的第一至第五种可能的实现方式，本发明实施例提供了上述第一方面的第六种可能的实现方式，其中，

所述设备驱动层支持的设备驱动应用程序编程接口API包括串口API、网络通信API和虚拟设备API。

结合第一方面及第一方面的第一至第五种可能的实现方式，本发明实施例提供了上述第一方面的第七种可能的实现方式，其中，

所述统一控制接口包括创建接口、删除接口、用于向设备写信息的接口和用于从设备读取信息的接口。

结合第一方面的第六种可能的实现方式，本发明实施例提供了上述第一方面的第八种可能的实现方式，其中，

当接入一个新的类串口设备时，通过所述设备驱动层中所述新的类串口设备需使用的设备驱动API连接所述新的类串口设备；

所述设备控制层通过所述设备驱动层获取所述新的类串口设备的设备标识和设备协议；根据所述设备标识和所述设备协议，通过驱动组件接口函数在所述设备访问层中添加所述设备标识对应的驱动组件。

第二方面，本发明实施例提供了一种类串口设备的驱动系统，所述驱动系统包括：应用层、设备层及上述第一方面所述的驱动模型；

所述应用层包括一个或多个应用程序，所述设备层包括一个或多个类串口设备；

所述应用层中的应用程序通过所述驱动模型与所述设备层中的类串口设备进行通信。

在本发明实施例提供的驱动模型及驱动系统中，该驱动模型包括设备驱动层和控制翻译层；控制翻译层为应用程序提供统一控制接口，且包括一个或多个类串口设备对应的驱动组件；设备驱动层分别与一个或多个类串口设备及控制翻译层连接，控制翻译层与应用程序连接。本发明提供的驱动模型通过统一控制接口来隔离不同类串口设备的特殊性，使得应用程序能够通过统一控制接口实现对不同类串口设备的控制管理。驱动模型中包括类串口设备对应的驱动组件，通过基于组件的软件分层结构，不需要对应用程序进行任何修改，即可实现应用程序与不同类串口设备之间的通信，不会增加应用程序的维护难度，提高了应用程序的兼容性和扩展性。

为使本发明的上述目的、特征和优点能更明显易懂，下文特举较佳实施例，并配合所附附图，作详细说明如下。

附图说明

为了更清楚地说明本发明实施例的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，应当理解，以下附图仅示出了本发明的某些实施例，因此不应被看作是对范围的限定，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他相关的附图。

图1示出了本发明实施例1所提供的一种类串口设备的驱动模型的示意图；

图2示出了本发明实施例1所提供的另一种类串口设备的驱动模型的示意图；

图3示出了本发明实施例1所提供的一种类串口设备控制流程图；

图4示出了本发明实施例1所提供的另一种类串口设备控制流程图；

图5示出了本发明实施例2所提供的一种类串口设备的驱动系统的示意图。

具体实施方式

为使本发明实施例的目的、技术方案和优点更加清楚，下面将结合本发明实施例中附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。通常在此处附图中描述和示出的本发明实施例的组件可以以各种不同的配置来布置和设计。因此，以下对在附图中提供的本发明的实施例的详细描述并非旨在限制要求保护的本发明的范围，而是仅仅表示本发明的选定实施例。基于本发明的实施例，本领域技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例，都属于本发明保护的范围。

考虑到相关技术中只要增加新的类串口设备，或者原有的类串口设备的协议改变，都需要对应用程序重新进行开发和编译，导致开发成本增加。且应用程序包括的驱动组件越多，应用程序的维护难度越大，导致应用程序的兼容性和扩展性很差。基于此，本发明实施例提供了一种类串口设备的驱动模型及驱动系统，下面通过实施例进行描述。

实施例1

参见图1，本发明实施例提供了一种类串口设备的驱动模型，该驱动模型包括设备驱动层1和控制翻译层2；

控制翻译层2为应用程序提供统一控制接口，且包括一个或多个类串口设备对应的驱动组件；

设备驱动层1分别与一个或多个类串口设备及控制翻译层2连接，控制翻译层2与应用程序连接。

上述设备驱动层1是驱动模型的最底层，支持各种设备驱动API(Application Programming Interface,应用程序编程接口)，包括串口API、网络通信API和虚拟设备API。另外，除串口API、网络通信API和虚拟设备API以外，还可以通过定义实现其他通信协议对应的驱动API。设备驱动层1与类串口设备及控制翻译层2连接，负责将控制翻译层2传输的设备控制信息传送到类串口设备，或者负责从类串口设备读取设备输入信息发送给控制翻译层2，对控制翻译层2的驱动开发提供可移植的基本支撑，设备驱动层1可以根据实现需求开发新的驱动API，具有很好的扩容性。

其中，在实现其他通信协议对应的驱动API时需在类串口设备对应的驱动组件中设置该驱动API对应的接口类型。

设备驱动层1所支持的上述每种设备驱动API都提供一套编程接口，控制翻译层2就是通过这些编程接口与类串口设备进行通信。本发明实施例以串口API为例进行说明，串口API提供一套一致的串口编程接口，这些串口编程接口主要用于开发挂接在串口上的类串口设备的设备驱动。具体地，串口API包括以下接口：用于获得串口对象的接口、用于释放串口对象的接口、用于向串口写信息的接口以及用于设置当串口数据到达时进行回调的接口。控制翻译层2可以在任意线程上下文发起串口API函数调用这些接口，通过这些接口与类串口设备进行通信。

在本发明实施例中，驱动模型不仅适用于对串口设备进行管理，还同样适用于网络串口设备以及虚拟设备的管理，具有很好的扩展性。对于网络串口设备，设备驱动层1中加载网络通信API，控制翻译层2中的驱动组件中设备驱动API的类型指定为网络API即可。应用程序向网络串口设备发送信息时，控制翻译层2会调用网络通信API和网络串口设备通信。对于像文件读写这种虚拟设备，将驱动组件中设备驱动API类型定义为虚拟设备，具体功能的实现需要在驱动组件中完成。对于其他通信协议通过定义实现对应的驱动API，在对应的驱动组件中制定驱动API类型即可完成。

上述控制翻译层2为应用程序提供统一控制接口，统一控制接口包括创建接口、删除接口、用于向设备写信息的接口和用于从设备读取信息的接口。另外，统一控制接口还包括用于获取设备信息的接口和用于控制类串口设备的设备控制接口。控制翻译层2负责类串口设备的创建、删除、信息的分发和获取，以及解释处理设备协议。统一控制接口在类串口设备和应用程序之间起到隔离的作用，为应用程序隔离了各个类串口设备的特殊性，使得应用程序能够通过统一控制接口对多个类串口设备进行统一管理和控制。

控制翻译层2中包括一个或多个类串口设备对应的驱动组件。当控制翻译层2中的一个类串口设备对应的驱动组件接收到应用程序发送的设备控制信息时，该设备控制信息的格式为应用程序默认的标准格式，该驱动组件将该设备控制信息的格式转换为该类串口设备对应的特定格式，即将该设备控制信息翻译为该类串口设备能够识别的信息。当控制翻译层2接收到设备驱动层1传输的来自类串口设备的设备输入信息时，将该设备输入信息分配给该类串口设备对应的驱动组件，该驱动组件将该设备输入信息的格式转换为标准格式，即将该设备输入信息翻译为应用程序能够识别的信息。

例如，假设应用程序需要控制管理的类串口设备包括报警盒和键盘，则控制翻译层2中包括报警盒驱动组件及键盘驱动组件。当应用程序发送设备控制信息给键盘时，控制翻译层2接收应用程序发送的设备控制信息，通过键盘驱动组件将该设备控制信息翻译为键盘能够识别的特定格式的设备控制信息，将翻译操作后的设备控制信息通过设备驱动层1发送给键盘。当键盘发送设备输入信息给应用程序时，设备驱动层1接收键盘发送的设备输入信息，并转发给控制翻译层2，控制翻译层2通过键盘驱动组件将设备输入信息翻译为标准格式的设备输入信息，然后将标准格式的设备输入信息发送给应用程序。

在本发明实施例中，统一控制接口通过类串口设备的设备标识来查找类串口设备对应的驱动组件。设备标识可以为能够唯一标识类串口设备的设备型号或设备序列号等。本发明实施例中，将设备型号作为设备标识，类串口设备的设备型号是一个32位的值，设备型号的高8位表示类串口设备的驱动类型，低24位是由16位厂家编号和8位产品编号组成。

控制翻译层2加载设备驱动后，可以在任意线程上下文发起统一控制接口函数。其中，统一控制接口的接口定义如下所示：

(1)获取设备信息

处理：返回设备信息DRIVER_INFO。

设备信息DRIVER_INFO的结构：

(2)创建设备

创建接口的接口函数为fcreate()，函数fcreate()的输入参数为类串口设备接入设备驱动层1所使用的串口号和类串口设备的地址码。函数fcreate()用于创建类串口设备对应的驱动对象，并返回对象句柄。

(3)删除设备

删除接口的接口函数为fdelete()，函数fdelete()的输入参数为需删除的类串口设备的对象句柄。函数fdelete()用于删除类串口设备对应的驱动对象。

(4)向设备写

用于向设备写信息的接口对应的接口函数为fwrite()，函数fwrite()的输入参数为类串口设备的对象句柄、需写入的数据及该数据的数据长度。函数fwrite()用于调用类串口设备对应的用于向设备写信息的接口，向类串口设备中写入信息。

(5)设置设备读取回掉函数

用于从设备读取信息的接口对应的接口函数为fsetcallback()，函数fsetcallback()的输入参数为类串口设备的对象句柄及回掉函数。函数fsetcallback()用于调用类串口设备对应的用于从设备读取信息的接口，从类串口设备中读取信息。

(6)设备控制

用于控制类串口设备的设备控制接口对应的接口函数为fcontrol()，函数fcontrol()的输入参数为类串口设备的对象句柄、控制命令、控制参数及数据长度。函数fcontrol()用于调用类串口设备对应的设备控制接口，控制该类串口设备。

在本发明实施例中，控制翻译层2根据类串口设备的设备标识，通过统一控制接口中的用于获取设备信息的接口来查找该类串口设备对应的驱动组件。以及通过该类串口设备提供的设备驱动协议，实现该类串口设备对应的驱动组件的驱动动作。本发明实施例在实现该类串口设备对应的驱动组件时，能够在Windows(窗口)系统和Linux系统等不同操作系统之间实现源代码可移植。

由于类串口设备对应的驱动组件的接口由统一控制接口调用，所以驱动组件的接口与统一控制接口的定义一致，也提供了上述统一控制接口中的创建接口、删除接口、用于向设备写信息的接口、设备控制接口及用于从设备读取信息的接口等。

在本发明实施例中，当接入一个新的类串口设备时，通过设备驱动层1中新的类串口设备需使用的设备驱动API连接新的类串口设备；控制翻译层2通过设备驱动层1获取新的类串口设备的设备标识和设备协议；根据设备标识和设备协议，通过驱动组件接口函数添加设备标识对应的驱动组件。

即在接入一个新的类串口设备时，需确定该新的类串口设备对应的设备标识，确定需使用的设备驱动API，即确定使用串口API、网络通信API还是虚拟设备API等。确定需使用的设备驱动API后，将该新的类串口设备连接到设备驱动层1，控制翻译层2通过统一控制接口中的用于获取设备信息的接口来获取该新的类串口设备的设备标识和设备协议，然后通过统一控制接口中的创建接口调用驱动组件接口函数，添加并实现该新的类串口设备对应的驱动组件。在控制翻译层2添加该新的类串口设备对应的驱动组件后，编译生成该新的类串口设备对应的独立的动态库，将该独立的动态库配置到应用程序的驱动目录下，如此应用程序不用作任何处理，即可实现通过驱动模型来控制和管理该新的类串口设备，实现过程非常简单，且便于系统的扩展和维护。

当在终端中加载了本发明实施例提供的驱动模型后，终端上的应用程序都可以通过该驱动模型与类串口设备进行通信。

当应用程序向类串口设备发送设备控制信息时，控制翻译层2接收应用程序发送的设备控制信息，确定设备控制信息包括的设备标识对应的驱动组件，通过确定的驱动组件将设备控制信息的格式转换为设备标识对应的特定格式，通过设备驱动层1传输特定格式的设备控制信息给设备标识对应的类串口设备。

当类串口设备向应用程序发送设备输入信息时，设备驱动层1接收类串口设备发送的设备输入信息，传输设备输入信息给控制翻译层2；控制翻译层2确定设备输入信息包括的设备标识对应的驱动组件，通过确定的驱动组件将设备输入信息的格式转换为标准格式，传输标准格式的设备输入信息给应用程序。

如图2所示，本发明实施例中，控制翻译层2包括设备控制层21、隔离层22和设备访问层23；

隔离层22为应用程序提供统一控制接口；设备访问层23包括一个或多个类串口设备对应的驱动组件；

设备控制层21分别与应用程序、隔离层22和设备驱动层1连接，隔离层22与设备访问层23连接。

其中，设备控制层21负责将来自应用程序的设备控制信息通过隔离层22传输给设备访问层23中特定的驱动组件，或者将来自类串口设备的信息分发到一个或多个应用程序，另外还解释处理相应的协议。

如图2所示，隔离层22为应用程序提供统一控制接口，统一控制接口包括用于创建设备的创建接口、用于删除设备的删除接口、设备控制接口、用于向设备写信息的接口、用于从设备读取信息的接口以及用于获取设备信息的接口，隔离层22主要负责类串口设备的创建、删除、信息的分发和获取，以及为上层提供统一的编程接口，方便设备控制层21的统一使用。

当接入一个新的类串口设备时，通过设备驱动层1中新的类串口设备需使用的设备驱动API连接新的类串口设备；设备控制层21通过设备驱动层1获取新的类串口设备的设备标识和设备协议；根据设备标识和设备协议，通过驱动组件接口函数在设备访问层23中添加设备标识对应的驱动组件。

当在终端中加载驱动模型后，终端上的应用程序都可以通过该驱动模型与类串口设备进行通信。如图3所示的类串口设备的控制流程，图3中箭头上的数字表示信息的传输顺序。当应用程序向类串口设备发送设备控制信息时，设备控制层21接收应用程序发送的设备控制信息，根据设备控制信息包括的设备标识，通过统一控制接口，将设备控制信息传输给设备访问层23中设备标识对应的驱动组件；设备标识对应的驱动组件将设备控制信息的格式转换为设备标识对应的特定格式，将特定格式的设备控制信息通过统一控制接口传输给设备控制层21；设备控制层21通过设备驱动层1将特定格式的设备控制信息传输给设备标识对应的类串口设备。

如图4所示的类串口设备的控制流程，图4中箭头上的数字表示信息的传输顺序。当类串口设备向应用程序发送设备输入信息时，设备驱动层1接收类串口设备发送的设备输入信息，通过设备控制层21传输设备输入信息给隔离层22；隔离层22根据设备输入信息包括的设备标识，通过统一控制接口，将设备输入信息传输给设备访问层23中设备标识对应的驱动组件；设备标识对应的驱动组件将设备输入信息的格式转换为标准格式，将标准格式的设备输入信息通过隔离层22及设备控制层21传输给应用程序。

本发明实施例提供的驱动模型，对类串口设备管理时使用基于组件的软件分层结构，便于系统的功能扩展。利用统一控制接口隔离不同类串口设备的特殊性，便于上层应用程序对不同类串口设备的控制和管理。且不仅支持实体的类串口设备，也能够实现应用程序对文件读写及远端文件操作等虚拟设备的控制和管理。该驱动模型适用于不同的系统平台，如Windows系统和Linux系统，系统兼容性好。采用基于组件的分层结构，增强了上层应用程序的代码扩展性，在新的驱动组件接入时，不需要修改上层应用程序。

在本发明实施例中，驱动模型包括设备驱动层和控制翻译层；控制翻译层为应用程序提供统一控制接口，且包括一个或多个类串口设备对应的驱动组件；设备驱动层分别与一个或多个类串口设备及控制翻译层连接，控制翻译层与应用程序连接。本发明提供的驱动模型通过统一控制接口来隔离不同类串口设备的特殊性，使得应用程序能够通过统一控制接口实现对不同类串口设备的控制管理。驱动模型中包括类串口设备对应的驱动组件，通过基于组件的软件分层结构，不需要对应用程序进行任何修改，即可实现应用程序与不同类串口设备之间的通信，不会增加应用程序的维护难度，提高了应用程序的兼容性和扩展性。

实施例2

参见图5，本发明实施例提供了一种类串口设备的驱动系统，该驱动系统包括：应用层201、设备层202及上述实施例1所提供的驱动模型203；

应用层包括一个或多个应用程序，设备层包括一个或多个类串口设备；

应用层中的应用程序通过驱动模型与设备层中的类串口设备进行通信。

上述驱动模型的具体结构与实施例1中所提及的驱动模型的结构相同，本发明实施例中驱动模型的各组成部分及各组成部分的功能均可参考实施例1。

在本发明实施例中，该驱动模型包括设备驱动层和控制翻译层；控制翻译层为应用程序提供统一控制接口，且包括一个或多个类串口设备对应的驱动组件；设备驱动层分别与一个或多个类串口设备及控制翻译层连接，控制翻译层与应用程序连接。本发明提供的驱动模型通过统一控制接口来隔离不同类串口设备的特殊性，使得应用程序能够通过统一控制接口实现对不同类串口设备的控制管理。驱动模型中包括类串口设备对应的驱动组件，通过基于组件的软件分层结构，不需要对应用程序进行任何修改，即可实现应用程序与不同类串口设备之间的通信，不会增加应用程序的维护难度，提高了应用程序的兼容性和扩展性。

本发明实施例所提供的驱动模型可以为设备上的特定硬件或者安装于设备上的软件或固件等。本发明实施例所提供的驱动系统中包括的驱动模型，其实现原理及产生的技术效果和前述驱动模型的实施例相同，为简要描述，驱动系统的实施例部分未提及之处，可参考前述驱动模型的实施例中的相应内容。所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，前述描述的驱动系统中应用程序通过驱动模型与类串口设备之间的通信的具体过程，均可以参考上述驱动模型的实施例中的对应过程，在此不再赘述。

在本发明所提供的实施例中，应该理解到，所揭露驱动模型和驱动系统，可以通过其它的方式实现。以上所描述的驱动模型和驱动系统的实施例仅仅是示意性的，例如，驱动模型中层级的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，又例如，多个层可以结合或者可以集成到另一个层中，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的连接可以是通过一些通信接口，装置或单元的间接通信连接，可以是电性，机械或其它的形式。

另外，在本发明提供的实施例中的各层可以集成在一个层中，也可以是各个层单独物理存在，也可以两个或两个以上层集成在一个层中。

所述功能如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本发明各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的介质。

应注意到：相似的标号和字母在下面的附图中表示类似项，因此，一旦某一项在一个附图中被定义，则在随后的附图中不需要对其进行进一步定义和解释，此外，术语“第一”、“第二”、“第三”等仅用于区分描述，而不能理解为指示或暗示相对重要性。

最后应说明的是：以上所述实施例，仅为本发明的具体实施方式，用以说明本发明的技术方案，而非对其限制，本发明的保护范围并不局限于此，尽管参照前述实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：任何熟悉本技术领域的技术人员在本发明揭露的技术范围内，其依然可以对前述实施例所记载的技术方案进行修改或可轻易想到变化，或者对其中部分技术特征进行等同替换；而这些修改、变化或者替换，并不使相应技术方案的本质脱离本发明实施例技术方案的精神和范围。都应涵盖在本发明的保护范围之内。因此，本发明的保护范围应以所述权利要求的保护范围为准。