嵌入式系統硬件抽象層的建立及軟件的可移植性設計
關(guān)鍵詞:設備驅動(dòng)程序 嵌入式系統 軟件設計 可移植性
1 嵌入式系統設計
由于嵌入式系統有著(zhù)體積小、功能集中、可靠性高等優(yōu)點(diǎn),已被廣泛地應用到日常生活的各個(gè)方面,如移動(dòng)通信、工業(yè)控制、醫療器械,家用電器等。如何縮短嵌入式系統的開(kāi)發(fā)周期,降低開(kāi)發(fā)成本,以及提高產(chǎn)品的可靠性已成為嵌入式行業(yè)普遍關(guān)注的問(wèn)題。在嵌入式系統設計中,通常采用以下設計方法。
(1)瀑布模式開(kāi)發(fā)過(guò)程
瀑布模式開(kāi)發(fā)過(guò)程工作模式簡(jiǎn)單,任務(wù)的劃分協(xié)調及人員安排、物質(zhì)材料的分配管理都比較容易。如圖1所示,開(kāi)發(fā)過(guò)程為從硬件到軟件的流水線(xiàn)式進(jìn)行。此類(lèi)開(kāi)發(fā)方式有以下特點(diǎn):
◇ 小系統,如利用8051控制的低速率信號采集等;
◇ 開(kāi)發(fā)所需人力、物力資源有限,一般1個(gè)或幾個(gè)人即可完成;
◇ 要求開(kāi)發(fā)人員對軟、硬件設計和制作都比較熟悉;
◇ 對開(kāi)發(fā)周期要求不高,此類(lèi)開(kāi)發(fā)過(guò)程無(wú)疑會(huì )使用最長(cháng)的開(kāi)發(fā)周期;
◇ 在開(kāi)發(fā)過(guò)程中,任一環(huán)節的阻塞都會(huì )影響其它環(huán)節的開(kāi)發(fā)。
(2)V模式開(kāi)發(fā)過(guò)程
V模式開(kāi)發(fā)過(guò)程為一種并行的工作方式,任務(wù)的劃分協(xié)調及人員安排、物質(zhì)材料的分配都必須考慮不同工作內容,如圖2 所示。
開(kāi)發(fā)過(guò)程為硬件和軟件同時(shí)進(jìn)行,最后聯(lián)合調試。此類(lèi)開(kāi)發(fā)方式有以下特點(diǎn):
◇ 大系統,如利用PowerPC等處理器設計的網(wǎng)絡(luò )交換/訪(fǎng)問(wèn)設備;
◇ 開(kāi)發(fā)人力、物力資源比較豐富;
◇ 開(kāi)發(fā)人員分工比較明確,軟件開(kāi)發(fā)者可不需了解太多的硬件信息,而硬件開(kāi)發(fā)人員對軟件也可不做太多了解;
◇ 有利于縮短開(kāi)發(fā)周期;
◇ 在開(kāi)發(fā)過(guò)程中,軟、硬件設計獨立進(jìn)行。 硬件開(kāi)發(fā)的阻塞不會(huì )影響軟件開(kāi)發(fā)過(guò)程,同樣,軟件開(kāi)發(fā)的阻塞不會(huì )影響硬件的開(kāi)發(fā)過(guò)程。
但在V模式開(kāi)發(fā)過(guò)程中,仍存在以下問(wèn)題:
◇ 設備驅動(dòng)程序的可移值性差,與硬件和操作系統均有密切相關(guān)性;
◇ 軟件測試需要等硬件完成以后才能進(jìn)行;
◇ 對于每個(gè)設備驅動(dòng)程序設計人員都需有軟件和硬件的知識背景;
◇ 在測試過(guò)程中,很難判斷錯誤是由硬件還是由軟件造成的。
為了克服V模式開(kāi)發(fā)過(guò)程中的上述問(wèn)題,本文將V模式開(kāi)發(fā)過(guò)程稍作改進(jìn),增加了硬件抽象層,對系統軟硬件起到隔離作用,從而提高系統軟件的可移值性及有效地利用人力資源、縮短開(kāi)發(fā)周期和提高產(chǎn)品的可靠性。
2 基于硬件抽象層的系統軟件設計特性
(1)包含硬件抽象層的系統結構
比較圖3和圖4,硬件抽象層完全把系統軟件和硬件部分隔離開(kāi)來(lái),這樣就使得系統的設備驅動(dòng)程序與硬件設備無(wú)關(guān),從而大大提高了系統的可移植性。從軟硬件測試角度來(lái)看,軟硬件的測試工作都可分別基于硬件抽象層來(lái)完成,使得軟硬件的測試工作的并行進(jìn)行成為可能。在抽象層的定義方面,需要規定統一的軟硬件接口標準,其設計工作需要基于系統需求來(lái)做,代碼工作可由對硬件比較熟悉的人員來(lái)完成。抽象層一般應包含相關(guān)硬件的初始化、數據的輸入/輸出操作、硬件設備的配置操作等功能。
(2)包含硬件抽象層的系統開(kāi)發(fā)過(guò)程
如圖5給出的包含硬件抽象層V模式開(kāi)發(fā)過(guò)程,在系統需求分析并定義了軟硬件各自的設計要求以后,就需要花費一定的時(shí)間來(lái)定義硬件抽象層的接口,以確保硬件設計和測試與軟件設計和測試工作能夠在相同的接口上進(jìn)行,從而有利于最終的軟硬件集成測試。
從圖5可以看出,在基于硬件抽象層的V模式開(kāi)發(fā)過(guò)程,軟硬件的設計和調試具有無(wú)關(guān)性,并可完全地并行進(jìn)行。硬件的錯誤不會(huì )影響到系統軟件的調試,同樣軟件設計的錯誤也不會(huì )影響硬件的調試工作,這樣就可大大縮短系統的測試周期和提高系統的可靠性。
(3)硬件抽象層的特點(diǎn)
硬件抽象層接口的定義和代碼設計應具有以下特點(diǎn):
◇ 硬件抽象層具有與硬件密切相關(guān)性;
◇ 硬件抽象層具有與操作系統無(wú)關(guān)性;
◇ 接口定義的功能應包含硬件或系統所需硬件支持的所有功能;
◇ 接口定義簡(jiǎn)單明了,太多接口函數會(huì )增加軟件模擬的復雜性;
◇ 具有可測性的接口設計有利于系統的軟硬件測試和集成。
3 硬件抽象層的設計示例
硬件抽象層接口的設計一般應包含以下幾個(gè)步:
◇ 分析接口的數據傳輸特性(雙向/單向數據傳輸,字節型/數據幀型傳輸模式);
◇ 分析接口配置屬性;
◇ 定義接口所需的相關(guān)函數。
下面給出以字符為單位進(jìn)行數據傳輸的UART接口硬件抽象層的接口定義內容:
◇ 設備初始化函數
BOOL InitDevice(Device_Register *regs, Device_Attribute *attr)
① 第一個(gè)參數為指向設備寄存器結構的指針,用來(lái)索引設備的相關(guān)寄存器。
② 第二個(gè)參數為一個(gè)設備屬性的結構,用于描述設備初始化設置的屬性(波特率、校驗位等等)。
③ 函數返回一個(gè)布爾類(lèi)型,用于描述初始化過(guò)程的正確性。
◇ 設備字符輸入
BOOL ReadDevice(Device_Register *regs, unsigned char *c)
① 第一個(gè)參數為指向設備寄存器結構的指針,用來(lái)索引設備的相關(guān)寄存器。
② 第二個(gè)參數為指向字符的地址空間,用于保存設備輸入的字符。
③ 函數返回一個(gè)布爾類(lèi)型,用于描述設備字符輸入的正確性。
◇ 設備字符輸出
BOOL WriteDevice(Device_Register *regs, unsigned char c)
① 第一個(gè)參數為指向設備寄存器結構的指針,用來(lái)索引設備的相關(guān)寄存器。
② 第二個(gè)參數為設備所要輸出的字符。
③ 函數返回一個(gè)布爾類(lèi)型,用于描述設備字符輸出的正確性。
◇ 設備屬性設置
BOOL SetDevice(Device_Register *regs, Device_Attribute *attr)
① 第一個(gè)參數為指向設備寄存器結構的指針,用來(lái)索引設備的相關(guān)寄存器。
② 第二個(gè)參數為一個(gè)設備屬性的結構,用于描述設備初始化設置的屬性(波特率、校驗位等等)。
③ 函數返回一個(gè)布爾類(lèi)型,用于描述設備屬性設置的正確性。
4 結 論
以上所述的是作者在多年嵌入式系統開(kāi)發(fā)中所總結出的開(kāi)發(fā)流程,并在實(shí)踐應用中起到了很好的效果。相信在一個(gè)較為復雜的嵌入式系統開(kāi)發(fā)過(guò)程中,很好地利用上述開(kāi)發(fā)流程,將會(huì )有利于提高系統的可移植性、減少產(chǎn)品的開(kāi)發(fā)和測試周期,并能很好地保證產(chǎn)品的可靠性。
linux操作系統文章專(zhuān)題:linux操作系統詳解(linux不再難懂)
評論