CN1484139A

CN1484139A - 共同控制设备驱动器的方法

Info

Publication number: CN1484139A
Application number: CNA031277128A
Authority: CN
Inventors: 李亨均
Original assignee: Samsung Electronics Co Ltd
Current assignee: Samsung Electronics Co Ltd
Priority date: 2002-08-08
Filing date: 2003-08-08
Publication date: 2004-03-24
Anticipated expiration: 2023-08-08
Also published as: US7437737B2; CN1241113C; KR20040013703A; JP2004070964A; US20040030415A1; CA2434869A1; KR100464349B1

Abstract

共同控制设备驱动器的技术包括在应用程序层和设备驱动器层之间安排DIA(设备独立访问层)，DIA层的标准化原则用于应用程序层和设备驱动器层，通过DIA层的标准化原则，允许应用程序层和设备驱动器层分别访问设备驱动器层和应用程序层。

Description

共同控制设备驱动器的方法

技术领域

本发明涉及通讯系统，特别是硬件芯片等级的共同控制设备驱动器的方法。

背景技术

当前，高-端应用程序和低-端设备驱动器的制造商互相独立的开发它们的产品。现在，不同的供应商提供大量的设备驱动器。这意味着高-端应用程序和低-端设备驱动器的制造商之间沟通的缺乏变得严重。常规的，API(应用程序接口)是基于高-端应用程序和低-端设备驱动器的各自的标准制作的。因此，高-端应用程序和低-端设备驱动器能做得符合彼此的标准。

在设备驱动器不能满足高-端应用程序要求的地方，应该纠正影响高-端应用程序的编码或结构的问题。此时，高-端应用程序和设备驱动器应该重-校验。

如果改变特殊的部分，其中涉及共同应用程序的第一设备改变为第二设备或两个应用程序使用一个共同的设备驱动器，高-端应用程序和低-端设备驱动器应该重-校验。由于增加了产品研发所需要的时间，重-校验的要求负面的影响产品的研发和减小产品的竞争性。

发明内容

因此，考虑到上面的和其它的问题，本发明的目的是提供能独立的和共同的使用高-端应用程序层和和低-端设备驱动器的方法，为了在通讯系统中建立共有的界面，由安排在高-端应用程序层和低-端设备驱动器之间的DIA(设备独立访问)层作为中间体。

本发明的另一目的是提供能独立的和共同的在通讯系统中使用低-端设备驱动器层的方法。

本发明另一目的是提供能独立的和共同的在通讯系统中使用高-端应用程序层的方法。

根据本发明，由提供的共同的控制设备驱动器的方法能完成上面的和其它目的，包括：在应用程序层和设备驱动器层之间安排DIA(设备独立访问)层，对应用程序层和设备驱动器层使用DIA层的标准化规则；通过DIA层的标准化规则，允许应用程序层和设备驱动器层分别访问设备驱动器层和应用程序层。

附图说明

参考附图及下面详细的描述，本发明的优势会显得清晰，图中相同的参考符号表示同样的或相似的部件，其中：

图1是设备A变为有关共同应用程序的设备B的视图；

图2是说明两种应用程序使用共同的设备驱动器的情况的视图；

图3是说明根据本发明实施例的共同的控制设备驱动器的概念的视图；

图4是说明设备驱动器控制公共化的访问视图；

图5是说明在呼叫API(应用程序接口)“Dia_InitDevice”作设备初始化后，DCB(设备控制块)的连接结构的视图；

图6是说明最后的DCB在等级1的初始化步骤的视图；

图7是说明当具有相当于等级2的四个端口的HDLC(高-等级数据连接控制)设备初始化时，DCB的连接结构的视图；

图8是说明当通道初始化时，DCB的连接结构的视图；

图9是说明事件表结构的视图；

图10是说明根据本发明实施例的设备驱动器改变(或替代)的情况的视图；

图11是说明以常规技术改变高-端应用程序的情况的视图；

图12是说明以常规技术改变低-端设备的情况的视图；

图13是说明根据本发明实施例改变高-端应用程序(程序)的情况的视图；

图14是说明根据本发明实施例改变低-端设备的情况的视图；

具体实施方式

现在转到图例，图1说明涉及共同应用程序的设备A变为设备B的情况。图2说明两种使用共同的设备驱动器的情况。

参考图1，涉及共同的应用程序2为高-端应用程序2的设备A变为设备B时，设备-A驱动器4也变为设备-B驱动器6，其中设备A和设备-B驱动器4和6是低-端设备驱动器。如果这样，API具有与驱动器A和B相关的不同特性。因此，高-端应用程序2也应该根据设备和设备驱动器的改变而改变。当设备驱动器改变时，与改变了的低-端设备驱动器连接的所有的API应该重新校验。换言之，根据改变了的设备驱动器，不管API是否运行适当，都应该校验。此外，与改变了的低-端设备驱动器连接的所有高-端应用程序不管是否影响其它的，都应该核对。

下-步，参考图2，高-端应用程序-A10和高-端应用程序-B12使用共同的设备驱动器14。高-端应用程序-A和B10和12需要与设备驱动器14不同的格式。例如，高-端应用程序-A10需要从设备驱动器14提供的两个格式A-1和A-2。另外，高-端应用程序-B12需要从设备驱动器14提供的三个格式B-1，B-2和B-3。这种情况的发生是因为对应用程序之间的格式协议还没有一致。因此，响应从高-端应用程序-A和B10和12的不同要求，设备驱动器14应该改变格式，因此API应该改变和加上。设备驱动器不能满足高-端应用程序要求的地方，应该纠正影响高-端应用程序的编码或结构的问题。此时，高-端应用程序和设备驱动器应该重-校验。

如图1和图2描述的，如果特殊的部分改变，其中涉及共同应用程序的或两个应用程序使用一个共同的设备驱动器的第一设备改变为第二设备，高-端应用程序和低-端设备驱动器应该重-校验。由于增加了产品研发所需要的时间，重-校验的要求负面的影响了产品的研发和减小了产品的竞争性。

本发明在通讯系统中，在高-端应用程序层和低-端设备驱动器层之间安排DIA(设备独立访问)层，防止了高-端应用程序层和低-端设备驱动器层的直接互相访问，因此，基于DIA的标准化规则，通过DIA高-端应用程序层和低-端设备驱动器层能分别访问低-端设备驱动器层和高-端应用程序层。因为基于DIA的标准化规则，高-端应用程序层和低-端设备驱动器层分别访问低-端设备驱动器层和高-端应用程序层，产品开发所需要的时间段和产品开发的费用可以降低，产品开发的效率可以改善。

现在，参考附图详细描述本发明优选的实施例。在下面的描述中，为使本发明更加清楚，在这里省略了已知功能和相关结构的详细描述。

图3是说明本发明实施例的共同的控制设备驱动器的概念的视图。参考图3，根据本发明的实施例，在通讯系统中，DIA(设备独立访问)层22安排在高-端应用程序20和设备驱动器24和26之间。基于DIA层22的标准化规则，高-端应用程序20通过DIA层22访问设备驱动器24和26。同样的，基于DIA层22的标准化规则，设备驱动器24和26通过DIA层22访问高-端应用程序20。这将参考图4详细描述。

图4是说明设备驱动器控制公共化访问的视图。参考图4，当高-端应用程序20请求DIA层22提供与基于标准化的共同格式的LOS(信号的损失)状态相关的信息，DIA层22把该请求转换为设备-A本地格式，然后请求设备-A驱动器24提供LOS状态信息。因此，设备-A驱动器24向DIA层22提供基于设备-A本地格式的LOS状态信息。DIA层22转换基于设备-A本地格式的LOS状态信息为标准共同格式，然后向高-端应用程序20提供基于标准共同格式的LOS状态信息。另一方面，如果设备A改变为设备B，设备-A驱动器也改变为设备-B驱动器。不管设备的变化，高-端应用程序20请求DIA层22提供基于标准共同格式的LOS状态信息。此外，DIA层22把请求转换为设备-B本地格式，然后请求设备-B驱动器26提供LOS状态信息。因此，设备-B驱动器26向DIA层22提供基于设备-B本地格式的LOS状态信息。DIA层22转换基于设备-B本地格式的LOS状态信息为基于标准共同格式的LOS状态信息，然后向高-端应用程序20提供基于标准共同格式的LOS状态信息。如上所描述的，DIA层22安排在低-端设备驱动器24和26之间提供基于标准规则的共有的接口。根据应用程序或设备的变化，不需要高-端应用程序和设备驱动器的校验。

为了在高-端应用程序20和低-端设备驱动器24和26之间提供基于标准规则的共有的接口，DIA层22从DDCB(设备驱动器控制块)读取数据，并用标准规则定义的功能访问低-端设备驱动器。定义DDCB公共化各自的设备驱动器，然后提供与相应功能的存在和相应功能的位置联系的信息。

在本发明的实施例中，在国际组织如ITU/RFC(国际电讯联盟/请求评论)等定义和标准化的功能块的功能中，在功能表中只定义相应于设备驱动器可用到的功能。本发明使用国际组织制定的标准化文件中定义的所有功能块，国际组织如ITU(国际电讯联盟)，IETE(因特网工程任务组)，ETSI(欧洲电讯标准化学院)，ATM(异步传输模式)论坛，ADSL(非对称数字用户环线)论坛，等等。在本发明的实施例中，在国际组织定义的所有功能块的功能中，为了标准化在功能表中只重定义相应于设备驱动器可用到的功能。

在本发明的实施例中，DIA层22使用基于标准化的数据格式的设备处理器ID(标识符)，因此高-端应用程序的研发商容易控制设备。设备处理器ID有根据本发明的实施例的标准化的数据格式，和相应于各自设备的唯一的标识符。在相应设备初始化时DIA层22向高-端应用程序20提供设备处理器ID。高-端应用程序20存储设备处理器ID并用相应设备处理器ID呼叫相应的设备，在那里ID是呼叫相应设备必需的。因此，DIA层22根据设备处理器ID决定一些设备是否应该呼叫，然后，根据决定呼叫设备驱动器。

下文中，参考图5到8，给出为唯一标识符的设备处理器ID和产生的命令控制表，并由DIA层22提供给高-端应用程序20的详细描述。此外，参考图5到8，详细描述相应的事件表和在本发明的实施例中提到的相应设备模型的简介。

图5是说明为了设备初始化，在应用用户呼叫DIA层22的API“Dia_InitDevice”后，DCB(设备控制块)的连接结构视图。图6是说明在等级1的初始化阶段最后的DCB的视图。图7是说明当具有相当于等级2的四个端口的HDLC(高-等级数据连接控制)设备初始化时，DCB的连接结构的视图。图8是说明当通道初始化时，DCB的连接结构的视图。

首先，详细描述设备处理器ID。

例如，由DIA层22产生的相应设备的设备处理器ID，表示为示于图5的“DCBhandler Id[1.0.0]”。设备处理器ID由与等级1、等级2和通道联系的三个无符号的整数组成，在系统中有唯一值。设备处理器ID由x1.x2.x3组成，其中x1，x2或.x3是无符号的整数。设备处理器ID表示为“DCBhandlerId[x1.x2.x3]”。这里，x1指设备ID的等级1的值，x2指相应设备的逻辑或物理组数量的等级2的值，.x3指相应设备或组的通道数量的通道的值。如果x1，x2和.x3的值是“0”，这意味无相应等级或通道。当设备初始化时，如图6到8所示x1的整数值从“1”顺序增加。不存在有等级1，即x1＝“1”的值的处理器。这意味等级1的值没初始化。

如在图5中所示，如果等级1的值初始化，基于本发明实施例的标准化规则，DCB32包含的由设备呼叫的元素是动态的分配的。元素包括各种不同的指针和功能指针，执行在DIA层22的标准化规则。当等级1的值初始化时，DCB32的元素包括“^*pHandler”，“^*fpInitDevice”，“^*fpOpenChannel”，“^*fpCloseChannel”，“^*fpRead”，“^*fpWrite”，“^*fpReset”，“^*pControlTable”，“^*pDDCB”，“^*pEvent”和“^*pAnchor”。“^*pHandler”是当设备初始化时指出给定初始化简介的指针，“^*fpInitDevice”是当设备初始化时使用的功能指针。“^*fpOpenChannel”是当通道打开时使用的功能指针。“^*fpCloseChannel”是当通道关闭时使用的功能指针。“^*fpRead”是当读打开的通道时使用的功能指针。“^*fpWrite”是当写打开的通道时使用的功能指针。“^*fpReset”是当设备复位时使用的功能指针。“^*pControlTable”是指出命令控制表位置的指针。“^*pDDCB”是指出设备驱动器控制表36的位置的指针。“^*pEvent”是指出事件表38位置的指针。“^*pAnchor”是指出下一等级的指针。

所有设备初始化后，DIA层22向高-端应用程序20提供产生的设备处理器ID。高-端应用程序20初始化相应的设备，然后仅存储给定的设备处理器ID。如果呼叫设备处理器，DIA层22接受设备处理器ID，决定一些设备驱动器是否必须呼叫，并根据决定呼叫设备驱动器。

下一步，描述作为功能表的标准化命令控制表。

标准化命令控制表使用功能块和与相应功能块联系的元素，功能块由国际组织如ITU，IETE，ETSI，ATM论坛，ADSL论坛等等定义。如果有另外的要求，可选择性的加到标准化命令控制表。例如，本发明者组织关于超高速通讯的信息为表。所制的表存在相应的存储器部分。此外，如果需要可选择性的加上其它功能。

如在图5中所示的，标准化命令控制表34位于由相应的DCB的“pControlTable”的指针指出在存储器部分中。标准化命令控制表34的命令ID，并定义为唯一值。命令ID映射到相应命令功能的“fpCommandFn”的功能指针。

根据本发明的实施例的标准化命令控制表34的结构如下。

《标准化命令控制表的结构》

typedefenum

    {

     D_SDH_COMMAND ID START＝0x2000000

     D_SDH_SPI_COMMAND_ID_START＝0x2000100

     D_SDH_SPI_SET_ALS，

     D_SDH_SPI_GET_ALS，

     …

     D_SDH_COMMAND_ID_END

    }DIA_COMMAND_ID_SDH_E；

在上面描述的标准化命令控制表34的结构中，基于字段，标准化命令“typedef enum”如“DIA_COMMAND_ID_SDH_E”以“DIA_COMMAND_ID_PDH_E”，“DIA_COMMAND_ID_ATM_E”等存在。不同的命令功能可随意的加入标准化命令控制表34。高-端应用程序的用户通过准化命令控制表34可随意的呼叫相应的设备驱动器。虽然设备驱动器改变，相应的标准化命令控制表维持原有的。当相应的设备驱动器执行相应的命令，只有功能指针变化。当设备初始化时，功能指针由设备驱动器提供给DIA层22。高-端应用程序的用户通过API“Dia_Control”呼叫命令。当高-端应用程序的用户通过特别的控制命令呼叫API“Dia_Control”时，仅改变位于DIA层22下面的设备驱动器。

下一步，参考图5，描述本发明实施例的设备驱动器的控制表36。在图5中，设备驱动器的控制表36是“pDDCB”的指针指出的表。设备驱动器的控制表36包含功能指针，“^*fp”，指出“InitLevel1”，“InitLevel2”的位置，“OpenChannel”，“CloseChannel”，控制表，事件表等，如，“^*fpInitLevel1”，“^*fpInitLevel2”，“^*fpOpenChannel”，“^*fpCloseChannel”，“^*fpControlTable(没有显示)”，“^*fpEventTable(没有显示)”，等。此外，设备驱动器的控制表36包含指出初始化功能数量，与设备相连的端口数量和通道数量的信息(没有显示)。设备驱动器的控制表36定义为设备驱动器的公共化控制，并相应于DDCB(设备驱动器控制块)，提供与相应功能的存在和相应功能的位置相联系的信息。设备驱动器的控制表36包含“^*fpInitLevel1”，“^*fpInitLevel2”，“^*fpOpenChannel”，“^*fpCloseChannel”，“^*fpControlTable(没有显示)”，“^*fpEventTable(没有显示)”，等。当设备初始化时，作为DDCB的设备驱动器的控制表36由指针“^*pDDCB”定位。“^*InitLevel1”，“^*InitLevel2”，“^*OpenChannel”，“^*fpCloseChannel”，“^*fpControlTable(没有显示)”，“^*fpEventTable(没有显示)”，等的资料填充为DCB32分配的信息。

下一步，描述与本发明的实施例相关的事件表。

示于图5的事件表38是位于由相应DCB的“^*pEventTable”的指针指定的位置的结构，DCB只在如果需要才产生的。当事件表不用时，显示为空。事件表38包括“EventId”的事件ID和“^*pEventList”的事件目录结构指针。各事件目录是如示于图9的连接目录。因此，大量的位置可指为一个事件，并能呼叫“Call-backFn”的回叫功能。事件表38最初包括“EventId”的事件ID，“^*pEventList”的指针最初指为空。当高-端应用程序20的用户使用相应的事件时，高-端应用程序20用API”Dia_Register”能与事件目录结构的指针连接。

根据本发明的实施例的事件表38的结构如下。

《事件表的结构》

typedef struct
        <!-- SIPO <DP n="8"> -->
        <dp n="d8"/>
    {

     EXECFUNC        pCallBackFunc；

     EXACTLY_INT32_T   *pNext CallBack；

    }DIA_EVENT_CONFIG_T；

    typedef struct

    {

     EXACTLY_UNIT32_T  eventId；

     DIA_EVENT_CONFIG_T  *pEventList；

    }DIA_EVENT_TABLE_T；

以下描述与本发明实施例相关的设备模块的概要。

当相应于示于图5的DCB的“fpInitDevice”功能指针执行时，需要的输入参数有结构指针的形式。在特殊情况中，可定义相应设备的结构。然而，在常规情况中，共同的结构包括在初始化等级1的值时的基本地址，相应于等级2的组ID和在初始化通道时使用的通道ID。

根据本发明的实施例的设备模块的概要的共同结构如下。

《设备模块的概要的共同结构》

typedef struct

    {

　　EXACTLY_UNIT32_T baseAddress1；

　　EXACTLY_UNIT32_T numExtraBaseAddresss；

　　EXACTLY_UNIT32_T *pExtraBaseAddresss；

　　}DIA_BASE_ADDR_T；

　　typedef struct

　　{

　　 DIA_BASE_ADDR_T baseAddress；

　　 EXACTLY_UNIT_32_T  *pUserDefine；

　　}DIA_COMMON_LEVEL1_PROFILE_T；
        <!-- SIPO <DP n="9"> -->
        <dp n="d9"/>
　　typedef struct

　　 {

　　  EXACTLY_INT32_T  groupNo；

　　  EXACTLY_UNIT32_T  *pUserDefine；

　　 }DIA_COMMON_LEVEL2_PROFILE_T；

　　typedef struct　
　　 {

　　  EXACTLY_INT32_T  channelNo；

　　  EXACTLY_UNIT_32_T  *pUserDefine；

　　 }DIA_COMMON_CHANNEL_PROFILE_T；

下文中，根据本发明的实施例的运行的详细描述如下。

当高-端应用程序20呼叫要用的功能块的功能时，用具有指出相应功能表的存在和位置信息的DDCB，DIA层22从功能表识别相应功能的存在。如果相应的功能表存在，呼叫相应的功能。为了呼叫功能，当相应的设备初始化时，DIA层22通知设备处理器ID的高-端应用程序20，然后高-端应用程序20用设备处理器ID访问低-端设备驱动器。

首先，在初始化设备时的运行如下。

当高-端应用程序20的用户呼叫API”Dia_InitDevice”时，DIA层22动态的分配DCB32，包含与功能块(如，控制表，事件表等)相联系的指针，高-端应用程序20通过具有指出相应功能表信息的DDCB使用的各功能块。

呼叫API”Dia_InitDevice”后，参考图2到8详细的描述DCB的连接。根据基本的流程形式，描述附加的数据库结构。

(1)等级1初始化

要初始化的设备有等级1，等级2和通道。当等级1初始化时，动态的分配作为设备的最高-端块的DCB32。其后，由与等级1相联的DCB32的“pAnchor”的停泊指针指定设备的等级2。因为在各卡中使用的设备数是已知值，假设最高-端数据库与指向示于图5的设备ID的“^*DCB”的指针定义为全局变量和DCB32。

初始化等级1时的形式与图5一样。此外，在等级1初始化时，最后的DCB示于图6。不管何时产生示于图5的DCB32，如图6所示DIA层22把相应于各DCB32的“DCBHandler[x1.x2.x3]”的唯一设备处理器ID值回到高-端应用程序20。即，根据设备等级1的初始化顺序x1的值从“1”顺序增加时，DIA层22给出“DCBHandler[x1.x2.x3]”的设备处理器ID值。参考图6，HDLC(高等级数据连接控制)的设备处理器ID值回到“DCBHandler[1.0.0]”。LAN(局域网)的设备处理器ID值回到“DCBHandler[3.0.0]”。UTOPIA(ATM的通用试验 & 运行物理层接口)的设备处理器ID值回到“DCBHandler[4.0.0]”。

高-端应用程序20应该管理“DCBHandler[x1.x2.x3]”返回设备处理器ID值。高-端应用程序20的用户能用“DCBHandler[x1.x2.x3]”返回的设备处理器ID值呼叫相应的功能。此外，因为基于设备初始化的顺序给予相应于设备的设备处理器ID，高-端应用程序20的用户应该识别相应于返回设备处理器ID的任何设备。例如，当有三个设备HDLC 1，HDLC2，HDLC3时，设备HDLC3初始化时设备HDLC3的x1值成为“1”。

(2)等级2初始化

在等级1初始化后执行等级2初始化。此时，使用的信息包括在等级2中与DDCB(具有唯一初始化功能，和关于端口或通道数目的信息)相关的可允许数目(端口数目)的信息。例如，分配停泊，因此参考与相应设备联系的端口数目执行等级2初始化。此外，DIA层22指派在等级1停泊产生的DCB32的地址，因此能涉及等级2需要的DCB32。

图7是说明当具有相当于等级2的四个端口的HDLC设备初始化时，DCB的连接结构的视图。参考图7，指派给四个端口的“Anchor1”，“Anchor2”，“Anchor3”和“Anchor4”的停泊分别相应于“DCBHandler[1.0.0]”，“DCBHandler[2.0.0]”，“DCBHandler[3.0.0]”和“DCBHandler[4.0.0]”的设备处理器ID值。例如，如果有四个端口“port1”，“port2”，“port3”和“port4”，“Anchor1”，“Anchor2”，“Anchor3”和“Anchor4”的停泊分别指派个给四个端口“port1”，“port2”，“port3”和“port4”。“DCBHandler[1.1.0]”，“DCBHandler[1.2.0]”，“DCBHandler1.3.0]”和“DCBHandler[1.4.0]”的设备处理器ID值分别给四个端口“port1”，“port2”，“port3”和“port4”。

(3)通道初始化

仅在如果需要时产生与通道相关的DCB。DCB只与等级2无关的通道连接，如图8所示“Anchor0”的停泊与DCB连接。

相似于图7如图8中所示的通道初始化的连接结构中，分配与通道数一致的停泊，各停泊与DCB连接。此时，返回设备处理器ID值。相应于“Anchor1”停泊的端口与四个通道“channel1”，“channel2”，“channel3”和“channel4”连接。当“channel3”的通道开启时，开启“channel3”通道的“DCBHandler[2.1.1]”根据初始化的顺序返回。高-端应用程序20的用户应该管理相应的通道和根据初始化的顺序映射到通道的设备处理器ID值。

设备初始化后，高-端应用程序20用作为标准化标识符的“DCBHandler[x1.x2.x3]”的设备处理器ID值呼叫功能块的功能。因此，DIA层22用具有指出相应功能表位置信息的DDCB，从相应设备驱动器的功能表中识别相应功能的存在。如果相应的功能存在，呼叫功能。

图10是说明根据本发明实施例的设备驱动器改变(或替代)的情况的视图。

参考图10，虽然由DIA层22设备驱动器A改变为设备驱动器B，设备HDLC的“DCBHandler[1.0.0]”的设备处理器ID值不再改变。改变的仅是：在DIA层22的控制下低-端设备驱动器和DCB32的指针(地址)指向新的设备。因此，虽然低-端设备驱动器A改变为低-端设备驱动器B，高-端应用程序20执行同样的功能。

图11到14是说明常规技术与高-端应用程序或低-端设备改变的本发明实施例比较的视图。

图11和图13是说明高-端应用程序改变的情况的视图。图11是说明以常规技术改变高-端应用程序(程序)的情况的视图。图13是说明根据本发明实施例改变高-端应用程序(程序)的情况的视图。

首先，参考图11，当高-端应用程序A以常规技术改变为高-端应用程序B时，不仅高-端应用程序应该改变低-端设备驱动器也应该改变。为何高-端应用程序和低-端设备驱动器应该改变的原因是与高-端应用程序A及B联系的结构和API是不同的，然后低-端设备驱动器应该提供所要求的API的改变的形式。因此，应该对预先存在的低-端设备驱动器使用增加，删除或修正的操作。改变部分应重新校验。当然，高-端应用程序B应重新校验。

为了弥补示于图11的常规技术的缺点，根据本发明的实施例，如图13所示DIA层22安排在高-端应用程序层和低-端设备驱动器层之间。如果DIA层22安排在高-端应用程序层和低-端设备驱动器层之间，虽然高-端应用程序A和B改变，高-端应用程序A及B能使用基于DIA′s标准化的原则的同样的控制命令ControlA，ControlB和ControlC。高-端应用程序不直接控制设备驱动器，但通过DIA层22用包括在设备中的控制命令非直接的控制设备驱动器。参考图13，高-端应用程序A和B使用的基于标准化公共格式的控制命令ControlA，ControlB和ControlC的由DIA层22各自转换为用于设备1的各控制命令ControlA-1，ControlB-1和ControlC-1。控制命令ControlA-1，ControlB-1和ControlC-1提供给设备-1驱动器。因此，高-端应用程序不特别依赖于低-端设备驱动器，虽然它会改变。

图12和图14是说明高-端应用程序不改变而低-端设备改变的情况的视图。图12是说明低-端设备以常规技术改变的情况的视图。图14是说明根据本发明的实施例改变低-端设备的情况的视图。

首先，参考图12，当高-端应用程序不改变而低-端设备驱动器以常规技术改变时，低-端设备驱动器的API改变。同样的，为了使用改变了的低-端设备驱动器的API，改变高-端应用程序。即，部分高-端应用程序应该删除或修改或另一部分应该增加。如果这样，高-端应用程序和改变了的低-端设备驱动器应该程序校验。

另一方面，如在图14所示的，如果根据本发明的实施例的DIA层22安排在高-端应用程序层和低-端设备驱动器层之间，高-端应用程序层不改变仅低-端设备驱动器根据DIA层22改变。因此，只需要低-端设备驱动器的校验。参考图14，高-端应用程序A使用的基于标准化公共格式的ControlA，ControlB和ControlC的的控制命令，由DIA层22各自转换为包含在设备1中的各控制命令ControlA-1，ControlB-1和ControlC-1。控制命令ControlA-1，ControlB-1和ControlC-1提供给设备-1驱动器。然而，如果低-端设备驱动器从设备-1驱动器改变为设备-2驱动器，设备-2驱动器通知DIA层22，使于设备-2中的控制命令是ControlA-2，ControlB-2和ControlC-2。因此，DIA层22各自转换高-端应用程序A使用的基于标准化公共格式控制命令ControlA，ControlB和ControlC为用于设备-2的ControlA-2，ControlB-2和ControlC-2的其它控制命令。

本发明在通讯系统中在高-端应用程序层和低-端设备驱动器层之间安排DIA(设备独立访问)层22，阻止了高-端应用程序层和低-端设备驱动器层互相直接访问。因此，基于DIA′s的标准化原则，高-端应用程序层和低-端设备驱动器层通过DIA能分别访问低-端设备驱动器层和高-端应用程序层。因为基于DIA′s的标准化原则高-端应用程序层和低-端设备驱动器层通过DIA能分别访问低-端设备驱动器层和高-端应用程序层，产品开发所需要的时间，产品开发费用减小，可以改善产品开发的效率。

虽然为了说明，公开了本发明的较好的实施例，本领域技术人员在不偏离本发明的范围作各种可能的修改，增加和删除。因此，本发明不限于以上描述的实施例，本发明的保护范围由权利要求所确定的范围确定。

Claims

1.一种共同控制设备驱动器的方法，包括步骤：

在应用程序层和设备驱动器层之间安排设备独立访问层，设备独立访问层的标准化原则用于应用程序层和设备驱动器层；

通过设备独立访问层的标准化原则，允许应用程序层和设备驱动器层分别访问设备驱动器层和应用程序层。

2.按权利要求1所述的方法，其特征在于允许应用程序层和设备驱动器层访问的步骤，包括步骤：

允许应用程序层向设备独立访问层发送相应于设备驱动器的基于标准化共同格式的控制命令，允许设备独立访问层把控制命令转换为基于本地格式其它控制命令，并把转换了的控制命令发送到设备驱动器；

允许设备驱动器对设备独立访问层给出基于本地格式的转换了的控制命令响应，允许设备独立访问层把从设备驱动器的响应转换为基于标准化共同格式的响应，基于标准化共同格式的响应发送到应用程序层。

3.一种共同控制设备驱动器的方法，包括步骤：

在应用程序层和设备驱动器层之间安排设备独立访问层；

定义可利用的功能，这是相应于设备驱动器的在功能表中的功能块的功能中可利用的功能；

当设备初始化时，允许设备独立访问层产生基于设备的标准化数据格式的设备处理器标识符，并向高端应用程序层发送产生的设备处理器标识符；

允许高-端应用程序层用设备处理器标识符呼叫预先确定的设备，允许设备独立访问层用设备处理器标识符从功能表中识别相应设备驱动器的功能，并呼叫相应设备驱动器的功能。

4.按权利要求3所述的方法，其特征在于表示为DCBHandlerId[x1.x2.x3]的设备处理器标识符，其中x1，x2或.x3是无符号的整数，x1指设备ID的等级1的值，x2指相应设备的逻辑或物理组数量的等级2的值，x3指相应于设备或组的通道数量的通道的值。

5.按权利要求4所述的方法，其特征在于x1，x2和x3的值是“0”，相应于无对应的等级或通道，当设备初始化时，x1的值从“1”顺序增加。

6.一种共同控制设备驱动器的方法，包括步骤：

在应用程序层和设备驱动器层之间安排设备独立访问层；

当设备初始化由应用程序层控制时，允许设备独立访问层执行等级1初始化、等级2初始化和通道初始化，并产生基于设备的标准化数据格式的设备处理器标识符；

允许设备独立访问层动态分配设备控制块，包括执行标准化原则的元素，此元素相应于设备处理器标识符；

允许设备独立访问层向应用程序层提供设备处理器标识符；

允许应用程序层通过设备独立访问层用设备处理器标识符呼叫预先确定的设备。

7.按权利要求6所述的方法，其特征在于设备控制块的元素包括“pControlTable”的指针指出命令控制表的位置，命令控制表包括有标准化的唯一值的命令标识符和映射到命令标识符的命令功能指针，“^*pDDCB”的指针指出设备驱动器控制表的位置，通过此表识别相应功能的存在和位置，“^*pAnchor”指针指出下一等级。

8.按权利要求6所述的方法，其特征在于设备控制块的元素包括“^*pHandler”的指针指出当设备初始化时给出的初始化概要的位置，当设备初始化时使用“^*fpInitDevice”的功能指针，当通道打开时使用“^*fpOpenChannel”的功能指针，当通道关闭时使用“^*fpCloseChannel”的功能指针，当读打开的通道时使用“^*fpRead”的功能指针，当写打开的通道时使用“^*fpWrite”的功能指针，当设备复位时使用“^*fpReset”的功能指针，“^*pControlTable”的指针指出命令控制表的位置，它包括有标准化唯一值的命令标识符和映射到命令标识符的命令功能指针，“^*pDDCB”的指针指出设备驱动器控制表的位置，通过此表识别相应功能的存在和位置，“^*pEventTable”的指针指出事件表的位置，“^*pAnchor”的指针指出下一等级。

9.按权利要求6所述的方法，其特征在于等级1的设备初始化这样作，基于等级1初始化的顺序，给于各设备的设备标识符x1为唯一值，设备驱动标识符表示为DCBhandlerId[x1.x2.x3]其中x1，x2或x3是无符号的整数。

10.按权利要求9所述的方法，其特征在于等级2的设备初始化这样作，参考逻辑或物理组数，分配停泊，给于在设备驱动标识符表示为DCBhandlerId[x1.x2.x3]的各停泊的组值x2为唯一值，其中x1，x2或x3是无符号的整数。

11.按权利要求10所述方法，其特征在于等级3的设备初始化这样作，根据表示为DCBhandlerId[x1.x2.x3]，其中x1，x2或x3是无符号的整数的设备驱动标识符中的开启通道的顺序，给予属于设备和设备中组的各通道的通道值x3。

12.一种方法，包括：

根据应用程序对设备独立访问层的标准化的公共格式，请求信号状态信息的损失；

把来自应用程序的请求转换成第一设备本地格式，并请求第一设备驱动器把信号状态信息的损失提供给设备独立访问层；

基于第一设备本地格式响应信号状态信息损失的请求；

根据标准化公共格式，为信号状态信息损失设备独立访问层响应应用程序。

13.按权利要求12所述的方法，其特征在于转换来自应用程序的请求步骤，还包括请求转换成第二设备本地格式，当第一设备变化到第二设备和第一设备驱动器变化到第二设备驱动器时，请求第二设备驱动器根据第二设备本地格式把信号状态信息的损失提供给设备独立访问层。

14.按权利要求13所述的方法，其特征在于还包括：转换基于标准化的公共格式的控制命令为提供给设备驱动器的控制命令，以适应应用程序到第二应用程序的改变而不改变提供给设备驱动器的控制命令。

15.按权利要求14所述的方法，其特征在于还包括：由设备独立访问层从设备驱动器控制块读出数据，提供应用程序和第一、第二设备驱动器直接的共有的接口，并用预先确定的功能访问第一、第二设备驱动器。

16.按权利要求15所述的方法，其特征在于还包括：设备独立访问层使用基于标准化数据格式的设备处理器标识符，设备处理器标识符相应于各自的设备。

17.按权利要求16所述的方法，其特征在于还包括：

提供设备处理器标识符，在相应设备初始化时，设备独立访问层向应用程序提供设备处理器标识符；

由应用程序存储设备处理器标识符，用相应的设备处理器标识符呼叫相应的设备。

18.按权利要求17所述的方法，其特征在于还包括：设备独立访问层根据设备处理器标识符决定是否应该呼叫某一设备驱动器，根据决定呼叫确定的设备驱动器。

19.按权利要求18所述的方法，其特征在于设备独立访问层使用确定的指针和功能指针在设备独立访问层中执行的标准化的公共格式。

20.按权利要求19所述的方法，其特征在于还包括：当应用程序呼叫所用的功能块的功能时，设备独立访问层从功能表中识别相应功能的存在，并使用设备处理器标识符通知设备驱动器的初始化以适应应用程序使用设备处理器标识符访问设备驱动器。

21.按权利要求19所述的方法，其特征在于还包括：当第一设备驱动器改变为第二设备驱动器时，设备的设备处理器标识符值不变。

22.按权利要求21所述的方法，其特征在于还包括：当第一设备驱动器改变为第二设备驱动器时，在设备独立访问层的控制下，改变指针地址。