專利名稱：共同控制設備驅動器的方法
技術領域：
本發明涉及通訊系統，特別是硬件芯片等級的共同控制設備驅動器的方法。
背景技術：
當前，高-端應用程序和低-端設備驅動器的制造商互相獨立的開發它們的產品。現在，不同的供應商提供大量的設備驅動器。這意味著高-端應用程序和低-端設備驅動器的制造商之間溝通的缺乏變得嚴重。常規的，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的結構如下。
《標準化命令控制表的結構》<pre listing-type="program-listing">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；</pre>在上面描述的標準化命令控制表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的結構如下。
《事件表的結構》<pre listing-type="program-listing">typedef struct<!-- SIPO <DP n="8"> --><dp n="d8"/>{ EXECFUNCpCallBackFunc； EXACTLY_INT32_T *pNext CallBack；}DIA_EVENT_CONFIG_T；typedef struct{ EXACTLY_UNIT32_T eventId； DIA_EVENT_CONFIG_T *pEventList；}DIA_EVENT_TABLE_T；</pre>以下描述與本發明實施例相關的設備模塊的概要。
當相應于示于圖5的DCB的“fpInitDevice”功能指針執行時，需要的輸入參數有結構指針的形式。在特殊情況中，可定義相應設備的結構。然而，在常規情況中，共同的結構包括在初始化等級1的值時的基本地址，相應于等級2的組ID和在初始化通道時使用的通道ID。
根據本發明的實施例的設備模塊的概要的共同結構如下。
《設備模塊的概要的共同結構》<pre listing-type="program-listing">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；</pre>下文中，根據本發明的實施例的運行的詳細描述如下。
當高-端應用程序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能分別訪問低-端設備驅動器層和高-端應用程序層，產品開發所需要的時間，產品開發費用減小，可以改善產品開發的效率。
雖然為了說明，公開了本發明的較好的實施例，本領域技術人員在不偏離本發明的范圍作各種可能的修改，增加和刪除。因此，本發明不限于以上描述的實施例，本發明的保護范圍由權利要求所確定的范圍確定。
權利要求
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所述的方法，其特征在于還包括當第一設備驅動器改變為第二設備驅動器時，在設備獨立訪問層的控制下，改變指針地址。
全文摘要
共同控制設備驅動器的技術包括在應用程序層和設備驅動器層之間安排DIA(設備獨立訪問層)，DIA層的標準化原則用于應用程序層和設備驅動器層，通過DIA層的標準化原則，允許應用程序層和設備驅動器層分別訪問設備驅動器層和應用程序層。
文檔編號G05B19/042GK1484139SQ0312771
公開日2004年3月24日 申請日期2003年8月8日 優先權日2002年8月8日
發明者李亨均 申請人:三星電子株式會社