CDC類虛擬串口固件設(shè)計(jì) 畢業(yè)論文_第1頁
CDC類虛擬串口固件設(shè)計(jì) 畢業(yè)論文_第2頁
CDC類虛擬串口固件設(shè)計(jì) 畢業(yè)論文_第3頁
CDC類虛擬串口固件設(shè)計(jì) 畢業(yè)論文_第4頁
CDC類虛擬串口固件設(shè)計(jì) 畢業(yè)論文_第5頁
已閱讀5頁,還剩36頁未讀, 繼續(xù)免費(fèi)閱讀

下載本文檔

版權(quán)說明:本文檔由用戶提供并上傳,收益歸屬內(nèi)容提供方,若內(nèi)容存在侵權(quán),請進(jìn)行舉報(bào)或認(rèn)領(lǐng)

文檔簡介

1、CDC類虛擬串口固件設(shè)計(jì)學(xué) 院計(jì)算機(jī)學(xué)院專 業(yè)計(jì)算機(jī)科學(xué)與技術(shù)班 級7401101學(xué) 號200704011027姓 名 指導(dǎo)教師 負(fù)責(zé)教師沈陽航空航天大學(xué)2011年6月摘 要在接口技術(shù)高速發(fā)展的今天,串口即將成為歷史。USB等接口將逐步取代串口成為新一代最常用的接口。然而,由于之前串口較為普及,針對串口的應(yīng)用程序也非常多,而且有些功能還非常強(qiáng)大,如何能夠最大限度地減少接口更新對應(yīng)用程序的影響,成為了當(dāng)今接口技術(shù)的一個新課題。本文就基于USB的CDC類,在帶有USB口的C8051F340單片機(jī)上,以開發(fā)USB虛擬串口固件為目標(biāo),通過標(biāo)準(zhǔn)請求、設(shè)備管理、數(shù)據(jù)傳輸?shù)饶K的設(shè)計(jì)與論證,并結(jié)合固件開發(fā)的

2、實(shí)際,完成了USB到虛擬串口的轉(zhuǎn)換的設(shè)計(jì)。本文的核心是建立ACM模型,即抽象控制模型。根據(jù)這個模型,對CDC類下的通信接口類和數(shù)據(jù)接口類進(jìn)行設(shè)計(jì)開發(fā),并著重對通信接口和數(shù)據(jù)接口的各個端點(diǎn)進(jìn)行設(shè)計(jì)論證。在此基礎(chǔ)上,實(shí)現(xiàn)對USB設(shè)備的枚舉,控制以及數(shù)據(jù)傳輸?shù)裙δ?,從而為?shí)現(xiàn)USB到虛擬串口的轉(zhuǎn)換提供了保證。關(guān)鍵詞:USB;虛擬串口;CDC;抽象控制模型The Design of a Virtual Serial Port Firmware Based On Communication Device ClassAbstractNowadays, as the interface technology

3、 develops in a high speed, the serial port is going to be history. Interface such as USB will replace serial port gradually and be the most common one in a new generation. However, since the widely spreading of serial port in past with great deal of development programs of serial port, and some func

4、tions are powerful, it has been a new problem that how to reduce the influence caused by interface update to application program to the maxima limit. The paper focuses on how to convert Universal Serial Bus (USB) to a serial port in the C8051F340 microcontroller with USB port. In order to realize th

5、e function of virtual serial port, we combine with the actual firmware, design and demonstrate the standard request, device management and data transmission moduleThe core of this paper is to establish an ACM , that is the Abstract Control Model. Based on this model, the data communication interface

6、 class and interface class which under the CDC are designed and developed. Focusing on the various endpoints which are included in the communication interface and data interface it has a demonstration. On this basis, it have realized the enumeration and control on the USB device, also, data transfer

7、 capabilities. Thus, it guarantees the alteration from USB to virtual serial port.Keywords: USB; virtual serial port; Abstract Control Model目 錄 TOC t 標(biāo)題_謝辭及參考文獻(xiàn),1,標(biāo)題_附錄,1,第2級標(biāo)題,2,第3級標(biāo)題,3,第1級標(biāo)題,1 1 引言 PAGEREF _Toc297539179 h 1 課題背景 PAGEREF _Toc297539180 h 1 課題要求 PAGEREF _Toc297539181 h 1 課題意義 PAGEREF

8、 _Toc297539182 h 22 相關(guān)技術(shù)及開發(fā)工具 PAGEREF _Toc297539183 h 32.1 CDC類簡述 PAGEREF _Toc297539184 h 32.2 C8051F340單片機(jī)簡介 PAGEREF _Toc297539185 h 3 開發(fā)環(huán)境簡介 PAGEREF _Toc297539186 h 43 總體設(shè)計(jì) PAGEREF _Toc297539187 h 6 應(yīng)用軟件的模塊設(shè)計(jì) PAGEREF _Toc297539188 h 7 應(yīng)用軟件的功能設(shè)計(jì) PAGEREF _Toc297539189 h 74 詳細(xì)設(shè)計(jì) PAGEREF _Toc297539190

9、 h 10 標(biāo)準(zhǔn)請求 PAGEREF _Toc297539191 h 10 設(shè)備描述符 PAGEREF _Toc297539192 h 10 配置描述符 PAGEREF _Toc297539193 h 11 接口描述符 PAGEREF _Toc297539194 h 12 端點(diǎn)描述符 PAGEREF _Toc297539195 h 13 字符串描述符 PAGEREF _Toc297539196 h 14 描述符設(shè)計(jì)要求 PAGEREF _Toc297539197 h 14 標(biāo)準(zhǔn)命令 PAGEREF _Toc297539198 h 15 類請求的實(shí)現(xiàn) PAGEREF _Toc297539199

10、h 174.2.1 SEND_ENCAPSULATED_COMMAND請求 PAGEREF _Toc297539200 h 174.2.2 GET_ENCAPSULATED_RESPONSE請求 PAGEREF _Toc297539201 h 174.2.3 GET_LINE_CODING 請求 PAGEREF _Toc297539202 h 174.2.4 SET_LINE_CODING 請求 PAGEREF _Toc297539203 h 184.2.5 SET_CONTROL_LINE_STATE請求 PAGEREF _Toc297539204 h 19 數(shù)據(jù)傳輸?shù)膶?shí)現(xiàn) PAGEREF

11、_Toc297539205 h 19 令牌包 PAGEREF _Toc297539206 h 19 數(shù)據(jù)包 PAGEREF _Toc297539207 h 20 握手包 PAGEREF _Toc297539208 h 20 數(shù)據(jù)傳輸 PAGEREF _Toc297539209 h 204.4 INF文件的創(chuàng)建 PAGEREF _Toc297539210 h 214.4.2 INF文件的規(guī)范 PAGEREF _Toc297539211 h 234.4.3 INF文件的內(nèi)容 PAGEREF _Toc297539212 h 235 聯(lián)機(jī)調(diào)試 PAGEREF _Toc297539213 h 26 調(diào)試

12、設(shè)置 PAGEREF _Toc297539214 h 26 下載調(diào)試 PAGEREF _Toc297539215 h 266 固件測試及結(jié)論 PAGEREF _Toc297539216 h 30 串口調(diào)試工具設(shè)置 PAGEREF _Toc297539217 h 31 數(shù)據(jù)傳輸測試 PAGEREF _Toc297539218 h 31 結(jié)論 PAGEREF _Toc297539219 h 31參考文獻(xiàn) PAGEREF _Toc297539220 h 33致 謝 PAGEREF _Toc297539221 h 35 引言現(xiàn)代嵌入式系統(tǒng)中,異步串行通信接口往往作為標(biāo)準(zhǔn)外設(shè)出現(xiàn)在單片機(jī)和嵌入式系統(tǒng)中。

13、但是隨著個人計(jì)算機(jī)通用外圍設(shè)備越來越少地使用串口,串口正在逐漸從個人計(jì)算機(jī)特別是便攜式電腦上消失。而現(xiàn)在的個人計(jì)算機(jī)普遍擁有4個以上的USB接口,使用USB接口代替串口,完成PC機(jī)和嵌入式系統(tǒng)的通信也就成為了當(dāng)今接口技術(shù)發(fā)展的一個重要課題。課題背景當(dāng)下越來越多帶USB接口的器件涌現(xiàn)出來,如帶USB接口的單片機(jī),或獨(dú)立的USB接口器件,而且這些器件的成本已經(jīng)很接近于使用RS-232電平轉(zhuǎn)換芯片所帶來的成本。市場上也出現(xiàn)了一些USB接口轉(zhuǎn)串口的芯片,這些芯片一頭為串口,另一頭為USB接口,在其內(nèi)部完成串口到USB協(xié)議的轉(zhuǎn)換。該芯片通過USB口連接到個人計(jì)算機(jī)后,在操作系統(tǒng)中表現(xiàn)為一個串口設(shè)備,這意

14、味著USB接口對于傳統(tǒng)的串口調(diào)試工具(Hyper Terninal)和用戶基于串口的應(yīng)用程序是透明的,開發(fā)人員完全不用更改PC端的調(diào)試和應(yīng)用程序。但是這些器件的USB類不屬于標(biāo)準(zhǔn)的USB設(shè)備類,因此需要在Windows和Linux操作系統(tǒng)上安裝額外的設(shè)備驅(qū)動。另外,由于不是操作系統(tǒng)自帶的設(shè)備驅(qū)動,而且通信經(jīng)過了由串口到串口,從USB設(shè)備到USB主機(jī)的多次轉(zhuǎn)換,當(dāng)調(diào)試遇到問題時(shí)常常無法確定是串口出了問題還是USB出了問題。因此,應(yīng)該使嵌入式系統(tǒng)直接和PC通過USB總線接口連接(通過片上的USB接口或片外USB接口芯片),由單片機(jī)直接完成USB虛擬串口的協(xié)議轉(zhuǎn)換。而現(xiàn)在的個人計(jì)算機(jī)普遍擁有多個US

15、B接口,如能使用USB接口代替串口,則可為PC機(jī)與嵌入式系統(tǒng)之間的通信提供方便。課題要求本課題要求在熟悉C8051F340單片機(jī)工作原理和開發(fā)環(huán)境以及USB通信協(xié)議和CDC類工作原理的基礎(chǔ)上,在帶有USB接口的C8051F340單片機(jī)上實(shí)現(xiàn)基于CDC類的USB虛擬串口功能。此外,要求對這個虛擬串口固件進(jìn)行數(shù)據(jù)傳輸測試,驗(yàn)證其實(shí)用性、準(zhǔn)確性。課題意義在USB標(biāo)準(zhǔn)子類中,有一類稱之為CDC類,可以實(shí)現(xiàn)虛擬串口通信的協(xié)議,而且由于大部分的操作系統(tǒng)(Windows和Linux)都帶有支持CDC類的設(shè)備驅(qū)動程序,可以自動識別CDC類的設(shè)備,免去了寫專用設(shè)備驅(qū)動程序的負(fù)擔(dān),為USB代替串口的實(shí)現(xiàn)提供了可能

16、。在單片機(jī)上實(shí)現(xiàn)基于CDC類的USB虛擬串口很好地適應(yīng)了當(dāng)前計(jì)算機(jī)外設(shè)接口的發(fā)展,同時(shí)因?yàn)檫@樣的接口在PC操作系統(tǒng)中仍然映射為一個串口,所以又避免了大量的PC端調(diào)試程序和應(yīng)用程序的重新編寫。相關(guān)技術(shù)及開發(fā)工具為了更好地進(jìn)行虛擬固件的設(shè)計(jì)開發(fā),在設(shè)計(jì)應(yīng)用軟件設(shè)計(jì)之前,需要對CDC類的原理、C8051F340單片機(jī)的相關(guān)理論以及軟件開發(fā)工具作簡要的敘述。CDC類簡述USB為了實(shí)現(xiàn)不同的應(yīng)用,將具有特定屬性與服務(wù)的一類設(shè)備劃分為一個Class。如果提供相似格式數(shù)據(jù)流或者相似的主從機(jī)交換方式,兩個設(shè)備則被統(tǒng)一在一個Class中。如USB標(biāo)準(zhǔn)就有Audio Class、Communication Dev

17、ice Class、HID Class、Video Class等用于在USB接口上實(shí)現(xiàn)不同設(shè)備接口。在USB標(biāo)準(zhǔn)協(xié)議中,有一類專用于通訊設(shè)備(主要包括電信通信設(shè)備和中速網(wǎng)絡(luò)通信設(shè)備)的CDC協(xié)議,可以通過該協(xié)議實(shí)現(xiàn)將USB接口虛擬為其他通訊接口。USB的CDC類是USB通信設(shè)備類(Communication Device Class)的簡稱。根據(jù)CDC類所針對通信設(shè)備的不同,CDC類又被分成以下不同的模型:USB傳統(tǒng)純 業(yè)務(wù)(POTS)模型,USB ISDN模型和USB網(wǎng)絡(luò)模型。其中,USB傳統(tǒng)純 業(yè)務(wù)模型,又可分為直接線控制模型(Direct Line Control Model)、抽象控制

18、模型(Abstract Control Model)和USB 模型(USB Telephone Model)。本文所討論的虛擬串口就屬于USB傳統(tǒng)純 業(yè)務(wù)模型下的抽象控制模型(Abstract Control Model)。CDC協(xié)議由三個子類組成:通信設(shè)備類(Communication Device Class)、通信接口類(Communication Interface Class)和數(shù)據(jù)接口類(Data Interface Class)。通信設(shè)備類是設(shè)備層次的定義,通常用于標(biāo)示一個通信設(shè)備,該設(shè)備可以提供相應(yīng)的接口。通信接口類則定義了相應(yīng)的通信服務(wù),包括如何對設(shè)備進(jìn)行管理和控制。數(shù)據(jù)接口

19、類則定義了如何傳送數(shù)據(jù)。C8051F340單片機(jī)簡介C8051F340單片機(jī)是美國Silicon Laboratories公司推出的完全集成的混合信號片上系統(tǒng)型MCU。它具有以下特性和資源:高速、流水線結(jié)構(gòu)的8051兼容的微控制器內(nèi)核(可達(dá)48MIPS);全速、非侵入式的在系統(tǒng)調(diào)試接口(片內(nèi));通用串行總線(USB)功能控制器,8個靈活的端點(diǎn)管道,集成收發(fā)器和1K FIFO RAM;10位200ksps的單端/差分ADC,帶模擬多路器;片內(nèi)電壓基準(zhǔn)和溫度傳感器;精確校準(zhǔn)的12MHz內(nèi)部振蕩器和4倍時(shí)鐘乘法器;多達(dá)64KB的片內(nèi)FLASH存儲器;多達(dá)4352字節(jié)片內(nèi)RAM(256+4KB);多達(dá)

20、40個端口I/O(容許5V電壓輸入)。具有片內(nèi)上電復(fù)位、VDD監(jiān)視器、電壓調(diào)整器、看門狗定時(shí)器和時(shí)鐘振蕩器的C8051F340器件是真正能獨(dú)立工作的片上系統(tǒng)。其FLASH存儲器還具有在系統(tǒng)重新編程能力,可用于非易失性數(shù)據(jù)存儲,并允許現(xiàn)場更新8051固件。用戶軟件對所有外設(shè)具有完全的控制,可以關(guān)斷任何一個或所有外設(shè)以節(jié)省功耗。C8051F340單片機(jī)功能框圖開發(fā)環(huán)境簡介Keil C51 是美國Keil Software 公司出品的51 系列兼容單片機(jī)C 語言軟件開發(fā)系統(tǒng),與匯編相比,C 語言在功能上、結(jié)構(gòu)性、可讀性、可維護(hù)性上有明顯的優(yōu)勢,因而易學(xué)易用。用過匯編語言后再使用C語言來開發(fā),體會更加

21、深刻。Keil C51 提供了包括C編譯器、宏匯編、連接器、庫管理和一個功能強(qiáng)大的仿真調(diào)試器等在內(nèi)的完整開發(fā)方案,通過一個集成開發(fā)環(huán)境(uVision)將這些部份組合在一起。軟件除提供豐富的庫函數(shù)和功能強(qiáng)大的集成開發(fā)調(diào)試工具外,又是全Windows界面。另外重要的一點(diǎn),只要看一下編譯后生成的匯編代碼,就能體會到Keil C51生成的目標(biāo)代碼效率非常之高,多數(shù)語句生成的匯編代碼很緊湊,容易理解。在開發(fā)大型軟件時(shí)更能體現(xiàn)高級語言的優(yōu)勢??傮w設(shè)計(jì)按照USB的CDC類協(xié)議,實(shí)現(xiàn)虛擬串口需要建立抽象控制模型(Abstract Control Model),即ACM模型。而這個模型的實(shí)現(xiàn),又需要建立在兩個

22、子類接口上,它們是通信接口類(Communication Interface Class)和數(shù)據(jù)接口類(Data Interface Class)。一個ACM功能設(shè)備,也應(yīng)該具有CDC類應(yīng)該具備的三種基本的職責(zé):(1)設(shè)備管理(Device Management);(2)通話管理(Call Management);(3)數(shù)據(jù)傳輸(Data Transmission)。CDC類設(shè)備通常用通信接口去完成設(shè)備管理,由數(shù)據(jù)接口去完成數(shù)據(jù)傳輸。而通話管理可以由通信接口去完成,也可以由數(shù)據(jù)接口去完成,依具體的情況而定。不過ACM功能大多是通過數(shù)據(jù)接口來完成通話管理的。通過這個模型,我們架構(gòu)出這么一個設(shè)備:

23、這個USB設(shè)備由通信接口類和數(shù)據(jù)接口類組成。通信接口類需要一個控制端點(diǎn)(Control Endpoint)和一個可選的中斷(Interrupt)端點(diǎn),數(shù)據(jù)接口類需要一個方向?yàn)檩斎?IN)的批處理端點(diǎn)和一個方向?yàn)檩敵?OUT)的批處理端點(diǎn)。其中控制端點(diǎn)主要用于USB設(shè)備的枚舉和虛擬串口的波特率和數(shù)據(jù)類型(數(shù)據(jù)位數(shù)、停止位和起始位)設(shè)置的通信。輸出(OUT)方向的批處理端點(diǎn)用于主機(jī)(Host)向從設(shè)備(Device)發(fā)送數(shù)據(jù),相當(dāng)于傳統(tǒng)物理串口中的TXD線;輸入(IN)方向的批處理端點(diǎn)用于從設(shè)備向主機(jī)發(fā)送數(shù)據(jù),相當(dāng)于傳統(tǒng)物理串口中的RXD線。而為了簡化開發(fā)的難度,而又可以不影響功能,故沒有實(shí)現(xiàn)通話

24、管理。在PC端,由于Windows2000以上系統(tǒng)已經(jīng)提供了usbser. sys驅(qū)動去支持CDC類設(shè)備,因此我們只要將設(shè)備按照規(guī)定的類協(xié)議去設(shè)計(jì),驅(qū)動就不需要我們?nèi)ラ_發(fā)了。對于應(yīng)用程序,完全可以移植過來直接使用,我們需要設(shè)置的僅僅是將這個應(yīng)用程序?qū)?yīng)的COM口改為所要實(shí)現(xiàn)的USB設(shè)備在PC端映射的串口即可。不過,由于Windows操作系統(tǒng)的要求,我們還須提供一個INF文件給PC操作系統(tǒng),這樣USB的這個虛擬串口才能安裝在PC機(jī)上。應(yīng)用軟件的模塊設(shè)計(jì)任何一個設(shè)備功能的實(shí)現(xiàn)都必須完成控制傳輸。這種傳輸在USB中是非常重要的,它要保證數(shù)據(jù)的正確性,在設(shè)備的枚舉過程中都是使用控制傳輸??刂苽鬏敯ㄈ?/p>

25、個過程:建立(SETUP)過程、可選的數(shù)據(jù)過程和狀態(tài)過程。建立過程都是由USB主機(jī)發(fā)起的。它開始于一個SETUP令牌包,后面緊跟一個DATA0數(shù)據(jù)包,接著就是數(shù)據(jù)過程。如果是控制讀傳輸,那么數(shù)據(jù)過程就是輸入數(shù)據(jù);如果是控制寫傳輸,那么數(shù)據(jù)過程就是輸出過程。數(shù)據(jù)過程之后是狀態(tài)過程。狀態(tài)過程是用來確認(rèn)所有的數(shù)據(jù)是否都已經(jīng)正常傳輸完成。狀態(tài)過程剛好與數(shù)據(jù)過程的數(shù)據(jù)傳輸方向相反:如果是控制讀傳輸,則狀態(tài)過程是一個輸出數(shù)據(jù)包;如果是控制寫傳輸,則狀態(tài)過程是一個輸入數(shù)據(jù)包。CDC類設(shè)備的實(shí)現(xiàn),除了對設(shè)備進(jìn)行枚舉之外,還需要完成類請求,進(jìn)而完全地實(shí)現(xiàn)虛擬串口的功能。因此,軟件的開發(fā)也涉及到三個模塊,一個模塊

26、用來完成標(biāo)準(zhǔn)請求,一個模塊用來完成設(shè)備管理,一個模塊用來完成串口數(shù)據(jù)傳輸。任何一個USB控制器,都會提供一些中斷寄存器,通過判斷中斷寄存器中相應(yīng)的中斷位,確認(rèn)相應(yīng)的中斷源,進(jìn)而執(zhí)行相應(yīng)的操作。這里,我們沒有采用中斷的方式來判斷USB控制器的中斷寄存器,而是通過輪詢的方式來實(shí)現(xiàn)的,通過不斷地輪詢寄存器獲取中斷的相關(guān)信息。程序流程如圖3.1所示。應(yīng)用軟件的功能設(shè)計(jì)按照CDC類抽象控制模型對端點(diǎn)的需求,將單片機(jī)0號端點(diǎn)和1號端點(diǎn)分配給通信接口子類,分別作為控制端點(diǎn)(完成枚舉和串口參數(shù)設(shè)置)和中斷端點(diǎn),而將2號和3號端點(diǎn)分配給數(shù)據(jù)接口子類,分別作為IN和OUT端點(diǎn),虛擬串口的數(shù)據(jù)主要從這兩端點(diǎn)來進(jìn)行傳

27、送。由于各個端點(diǎn)的行為相對獨(dú)立,對于每個端點(diǎn)的控制過程又有相似性,在這里以2號端點(diǎn)即作為數(shù)據(jù)接口的IN端點(diǎn)為例,說明軟件是如何對端點(diǎn)進(jìn)行操作和控制的,其控制流程圖如圖所示。輪詢方式流程2號端點(diǎn)是一個IN的端點(diǎn),它的主要工作是模擬物理串口的TXD線,向主設(shè)備發(fā)送數(shù)據(jù)。當(dāng)主設(shè)備發(fā)出IN的請求時(shí),如果FIFO不空,就向主設(shè)備發(fā)送FIFO的內(nèi)容;如果FIFO為空,則向主設(shè)備發(fā)送一個空包作為回應(yīng)。C8051F340單片機(jī)在收到IN的請求時(shí),會觸發(fā)USB中斷,在中斷處理程序中,如圖所示,首先判斷中斷的觸發(fā)源是哪個端點(diǎn),如果是2號端點(diǎn),將USB寄存器組映射到2號端點(diǎn)的那一組,然后將需要發(fā)送的串口數(shù)據(jù)填入FI

28、FO寄存器,置TXReady位,表示FIFO中的數(shù)據(jù)已經(jīng)準(zhǔn)備好,這時(shí)USB接口就會自動響應(yīng)IN請求,并將FIFO中的數(shù)據(jù)發(fā)送出去,程序則可退出中斷服務(wù)程序。對于其他的端點(diǎn),其處理過程也是相似的。端點(diǎn)控制流程詳細(xì)設(shè)計(jì)應(yīng)用軟件主要分為三個模塊:標(biāo)準(zhǔn)請求、設(shè)備管理、串口數(shù)據(jù)傳輸。以下就這三個模塊做具體說明。標(biāo)準(zhǔn)請求標(biāo)準(zhǔn)請求主要是按照CDC類協(xié)議上的規(guī)定去設(shè)計(jì)描述符。標(biāo)準(zhǔn)的USB描述符主要有5種,即設(shè)備描述符(Device Descriptor)、配置描述符(Configuration Descriptor)、接口描述符(Interface Descriptor)、端點(diǎn)描述符(Endpoint Des

29、criptor)和字符串描述符(String Descriptor)。每個USB設(shè)備只有一個設(shè)備描述符,而一個設(shè)備中可包含一個或多個配置描述符,即USB設(shè)備可以有多種配置。設(shè)備的每一個配置中又可以包含一個或多個接口描述符,即USB設(shè)備可以支持多種功能(接口)。在接口描述符里又定義了該接口有多少個端點(diǎn),每個端點(diǎn)都有一個端點(diǎn)描述符。端點(diǎn)描述符定義了端點(diǎn)的大小、類型等。如果有類特殊描述符,它就跟在相應(yīng)的接口描述符之后。由此可以看出,USB的描述符之間的關(guān)系是一層一層的,最上一層是設(shè)備描述符,接下來是配置描述符,接著再獲取接口描述符,最下面是端點(diǎn)描述符。在USB主機(jī)訪問USB設(shè)備的描述符時(shí),USB設(shè)備

30、依照設(shè)備描述符、配置描述符、接口描述符、端點(diǎn)描述符、字符串描述符順序?qū)⑺忻枋龇麄鹘o主機(jī)。USB設(shè)備至少要包含設(shè)備描述符、配置描述符和接口描述符,如果USB設(shè)備沒有端點(diǎn)描述符,則它可以通過默認(rèn)管道與主機(jī)進(jìn)行數(shù)據(jù)傳輸。設(shè)備描述符設(shè)備描述符給出了USB設(shè)備的一般信息,包括對設(shè)備及在設(shè)備配置中起全程作用的信息,包括制造商標(biāo)識號ID、產(chǎn)品序列號、所屬設(shè)備類號、默認(rèn)端點(diǎn)的最大包長度和配置描述符的個數(shù)等。一個USB設(shè)備必須有且僅有一個設(shè)備描述符。設(shè)備描述符是設(shè)備連接到總線上時(shí)USB主機(jī)所讀取的第一個描述符,它包含了14個字段,結(jié)構(gòu)如下:struct _ Device Descriptor BYTE bLe

31、ngth; / 設(shè)備描述符的字節(jié)數(shù)大小BYTE bDescriptorType; / 描述符類型編號WORD bcdUSB; / USB版本號,設(shè)置為0 x02BYTE bDeviceClass; / USB分配的設(shè)備類代碼BYTE bDeviceSubClass; / USB分配的子類代碼,值由USB規(guī)定和分配BYTE bDeviceProtocl; / USB分配的設(shè)備協(xié)議代碼BYTE bMaxPacketSize0; / 端點(diǎn)0的最大包的大小 WORD idVendor; / 廠商編號WORD idProduct; / 產(chǎn)品編號 WORD bcdDevice; / 設(shè)備出廠編號 BYTE

32、 iManufacturer; / 描述廠商字符串的索引 BYTE iProduct; / 描述產(chǎn)品字符串的索引 BYTE iSerialNumber; / 描述設(shè)備序列號字符串的索引 BYTE bNumConfiguration;/ 可能的配置數(shù)量 配置描述符配置描述符中包括了描述符的長度(屬于此描述符的所有接口描述符和端點(diǎn)描述符的長度的和)、供電方式(自供電/總線供電)、最大耗電量等。如果主機(jī)發(fā)出USB標(biāo)準(zhǔn)命令Get_Descriptor要求得到設(shè)備的某個配置描述符,那么除了此配置描述符以外,此配置包含的所有接口描述符與端點(diǎn)描述符都將提供給USB主機(jī)。其結(jié)構(gòu)如下: struct _ Con

33、figuration Descriptor BYTE bLength; / 設(shè)備描述符的字節(jié)數(shù)大小BYTE bDescriptorType; / 描述符類型編號WORD wTotalLength; / 配置所返回的所有數(shù)量的大小 BYTE bNumInterface; / 此配置所支持的接口數(shù)量 BYTE bConfigurationVale; / Set_Configuration命令需要的參數(shù)值 BYTE iConfiguration; / 描述該配置的字符串的索引值 BYTE bmAttribute; / 供電模式的選擇 BYTE MaxPower; / 設(shè)備從總線獲取的最大電流 接口描

34、述符配置描述符中包含了一個或多個接口描述符,這里的“接口”并不是指物理存在的接口,在這里把它稱之為“功能”更易理解些。接口描述符主要記錄的信息有:接口的編號、接口的端點(diǎn)數(shù)、接口所使用的類、子類、協(xié)議等。如果一個配置描述符不止支持一個接口描述符,并且每個接口描述符都有一個或多個端點(diǎn)描述符,那么在響應(yīng)USB主機(jī)的配置描述符命令時(shí),USB設(shè)備的端點(diǎn)描述符總是緊跟著相關(guān)的接口描述符后面,作為配置描述符的一部分被返回。接口描述符不可直接用Set_Descriptor和Get_Descriptor來存取。其結(jié)構(gòu)如下:struct _ Interface Descriptor) BYTE bLength;

35、/ 設(shè)備描述符的字節(jié)數(shù)大小 BYTE bDescriptorType; / 描述符類型編號BYTE bInterfaceNunber; / 接口的編號 BYTE bAlternateSetting; / 備用的接口描述符編號 BYTE bNumEndpoints; / 該接口使用端點(diǎn)數(shù),不包括端點(diǎn)0 BYTE bInterfaceClass; / 接口類型 BYTE bInterfaceSubClass; / 接口子類型 BYTE bInterfaceProtocol; / 接口所遵循的協(xié)議BYTE bInterface; / 描述該接口的字符串索引值 端點(diǎn)描述符端點(diǎn)是設(shè)備與主機(jī)之間進(jìn)行數(shù)據(jù)傳

36、輸?shù)倪壿嫿涌?,除配置使用的端點(diǎn)0(控制端點(diǎn),一般一個設(shè)備只有一個控制端點(diǎn))為雙向端口外,其它均為單向。端點(diǎn)描述符描述了數(shù)據(jù)的傳輸類型、傳輸方向、數(shù)據(jù)包大小和端點(diǎn)號(也可稱為端點(diǎn)地址)等。除了描述符中描述的端點(diǎn)外,每個設(shè)備必須要有一個默認(rèn)的控制型端點(diǎn),地址為0,它的數(shù)據(jù)傳輸為雙向,而且沒有專門的描述符,只是在設(shè)備描述符中定義了它的最大包長度。主機(jī)通過此端點(diǎn)向設(shè)備發(fā)送命令,獲得設(shè)備的各種描述符的信息,并通過它來配置設(shè)備。其結(jié)構(gòu)如下:struct _ Endpoint Descriptor BYTE bLength; / 設(shè)備描述符的字節(jié)數(shù)大小BYTE bDescriptorType; / 描述符類

37、型編號BYTE bEndpointAddress; / 端點(diǎn)地址及輸入輸出屬性 BYTE bmAttribute; / 端點(diǎn)的傳輸類型屬性 WORD wMaxPacketSize; / 端點(diǎn)收、發(fā)的最大包的大小 BYTE bInterval; / 主機(jī)查詢端點(diǎn)的時(shí)間間隔 字符串描述符字符串描述符是一種可選的USB標(biāo)準(zhǔn)描述符,描述了如制造商、設(shè)備名稱或序列號等信息。如果一個設(shè)備無字符串描述符,則其它描述符中與字符串有關(guān)的索引值都必須為0。字符串使用的是Unicode編碼。主機(jī)請求得到某個字符串描述符時(shí)一般分成兩步:首先主機(jī)向設(shè)備發(fā)出USB標(biāo)準(zhǔn)命令Get_Descriptor,其中所使用的字符串的

38、索引值為0,設(shè)備返回一個字符串描述符,此描述符的結(jié)構(gòu)如下:struct _ String DescriptorBYTE bLength; / 設(shè)備描述符的字節(jié)數(shù)大小BYTE bDescriptorType; / 描述符類型編號BYTE SomeDescriptor36; / UNICODE編碼的字符串描述符設(shè)計(jì)要求(1)設(shè)備描述符中的設(shè)備類定義必須定義為通信設(shè)備類,子類和遵從協(xié)議可以不定義,但在通信接口中必須定義。(2)配置描述符中的wTotalLength指的是除設(shè)備描述符和字符串描述符之外的所有的描述符之和。(3)VID與PID一定要和INF文件中指定的一致,否則的話,將安裝不了驅(qū)動。(4

39、)CDC類除了以前闡述的五個標(biāo)準(zhǔn)描述符之外,還包括三個功能描述符:Header、ACM和Union(因?yàn)闆]有用到通話管理,所以沒有Call Management描述符)。這是CDC類與其他的USB類設(shè)備的區(qū)別。這三個描述符將通信接口和數(shù)據(jù)接口關(guān)聯(lián)起來,而且還闡述了具體支持類請求命令,因此,合理而且正確的設(shè)置它們將非常關(guān)鍵。此外,描述符的設(shè)計(jì)中,還需要有功能描述符(function-descriptors)的支持;它主要用來描述接口的功能。功能描述符放在CDC接口之后,功能描述符完畢之后就是主接口的端點(diǎn)描述符,再接下去是其它接口以及它們的端點(diǎn)描述符。標(biāo)準(zhǔn)命令在USB規(guī)范中,所有的USB設(shè)備都要求

40、對主機(jī)發(fā)給自己的控制命令作出響應(yīng),USB規(guī)范定義了11個標(biāo)準(zhǔn)命令,它們分別是:Clear_Feature、Get_Configuration、Get_Descriptor、Get_Interface、Get_Status、Set_Address、Set_Configuration、Set_Descriptor、Set_Interface、Set_Feature、Synch_Frame。所有USB設(shè)備都必須支持這些命令(個別命令除外,如Set_Descriptor、Synch_Frame)。所有的命令雖然有不同的數(shù)據(jù)格式和使用目的,但是USB命令結(jié)構(gòu)是一樣的。表所示為USB命令的結(jié)構(gòu)。.USB命

41、令的結(jié)構(gòu)偏移量域長度(字節(jié))值描述0bmRequestType1位圖請求特征:D7:傳輸方向; 0=主機(jī)至設(shè)備; 1=設(shè)備至主機(jī) ;D6.5:種類; 0=標(biāo)準(zhǔn) ;1=類;2=廠商; 3=保留 ;D4.0:接受者; 0=設(shè)備; 1=接口;2=端點(diǎn); 3=其他;1bRequest1值命令類型編碼值(見表4.3)2wValue2值根據(jù)不同的命令,含義也不同4wIndex2索引或偏移根據(jù)不同的命令,含義也不同,主要用于傳送索引或偏移6wLength2如有數(shù)據(jù)傳送階段,此為數(shù)據(jù)字節(jié)數(shù)。列出了USB的11種標(biāo)準(zhǔn)命令。USB的11種標(biāo)準(zhǔn)命令命令bmRequestTypebRequestwValuewInde

42、xwLengthDataClear_Feature00000000B00000001B00000010BCLEAR_FEATURE特性選擇符零接口號端點(diǎn)號零無Get_Configuration10000000BGET_CONFIGURATION零零一配置值Get_Descriptor10000000BGET_DESCRIPTOR描述表種類(高字節(jié))和索引(低字節(jié))零或語言標(biāo)志描述表長描述表表 USB的11種標(biāo)準(zhǔn)命令(續(xù))命令bmRequestTypebRequestwValuewIndexwLengthDataGet_Interface10000001BGET_INTERFACE零接口號一可選

43、設(shè)置Get_Status10000000B10000001B10000010BGET_STATUS零零(返回設(shè)備狀態(tài))接口號(對象是接口時(shí))端點(diǎn)號(對象是端點(diǎn)時(shí))二設(shè)備,接口 ,或 端點(diǎn)狀態(tài)Set_Address00000000BSET_ADDRESS設(shè)備地址零零無Set_Configuration00000000BSET_CONFIGURATION配置值(高字節(jié)為0,低字節(jié)表示要設(shè)置的配置值)零零無Set_Descriptor00000000BSET_DESCRIPTOR描述表種類(高字節(jié))和索引(低字節(jié))零或語言標(biāo)志描述表長描述表Set_Feature00000000B00000001B0

44、0000010BSET_FEATURE特性選擇符(1表示設(shè)備,0表示端點(diǎn))零接口號端點(diǎn)號零無Set_Interface00000001BSET_INTERFACE可選設(shè)置接口號零無Synch_Frame100000010BSYNCH_FRAME零端點(diǎn)號二幀號其中bRequest為命令編碼值,含義如表4.3所示。USB標(biāo)準(zhǔn)命令的編碼值bRequestValueGET_STATUS0CLEAR_FEATURE1為將來保留2SET_FEATURE3為將來保留4SET_ADDRESS5GET_DESCRIPTOR6SET_DESCRIPTOR7GET_CONFIGURATION8SET_CONFIGU

45、RATION9GET_INTERFACE10表4.3 USB標(biāo)準(zhǔn)命令的編碼值(續(xù))bRequestValueSET_INTERFACE11SYNCH_FRAME12類請求的實(shí)現(xiàn)除了標(biāo)準(zhǔn)請求外,我們還需要實(shí)現(xiàn)CDC類的請求,不過它的實(shí)現(xiàn)具體支持什么命令,功能描述符里面會有所闡述,因此,如果功能描述符里面聲明了要支持的命令,一定要支持。以下簡單介紹幾個關(guān)鍵性的請求。SEND_ENCAPSULATED_COMMAND請求SEND_ENCAPSULATED_COMMAND請求是用來發(fā)出在通信類的接口支持控制協(xié)議格式命令。其格式如表所示。SEND_ENCAPSULATED_COMMAND請求的結(jié)構(gòu)bmR

46、equestTypebRequestwValuewIndexwLengthData00100001BSEND_ENCAPSULATED_COMMAND0接口接收者的數(shù)據(jù)量(字節(jié))控制協(xié)議的命令GET_ENCAPSULATED_RESPONSE請求GET_ENCAPSULATED_RESPONSE請求是用于請求在該通信類接口支持控制協(xié)議格式的響應(yīng)。其格式如表所示。GET_ENCAPSULATED_RESPONSE請求的結(jié)構(gòu)bmRequestTypebRequestwValuewIndexwLengthData10100001BGET_ENCAPSULATED_RESPONSE0接口接收者的數(shù)據(jù)量

47、(字節(jié))協(xié)議相關(guān)數(shù)據(jù)GET_LINE_CODING 請求在介紹GET_LINE_CODING 請求之前,我們需要將Line_Coding說明一下。Line_Coding包含了串口的波特率、停止位位數(shù)、奇偶校驗(yàn)位以及數(shù)據(jù)位。表是Line_Coding的結(jié)構(gòu)體說明。Line_Coding結(jié)構(gòu)體偏移量域大小/字節(jié)取值描述0dwDTERate4數(shù)值數(shù)據(jù)終端速率(波特率),比特每秒4bCharFormat11數(shù)值停止位位數(shù)0:1停止位2:2停止位5bParityType1數(shù)值校驗(yàn)類型0:無1:奇數(shù)2:偶數(shù)3:標(biāo)識4:空間6bDataBits1數(shù)值數(shù)據(jù)位位數(shù)(5,6,7,8,或者16)GET_LINE_C

48、ODING 請求是指主機(jī)獲取串口屬性的請求,包括了波特率的設(shè)置、停止位位數(shù)、校驗(yàn)類型以及數(shù)據(jù)位位數(shù),其格式如表所示。GET_LINE_CODING 請求的結(jié)構(gòu)bmRequestTypebRequestwValuewIndexwLengthData10100001BGET_LINE_CODING0接口數(shù)據(jù)結(jié)構(gòu)大小Line Coding數(shù)據(jù)結(jié)構(gòu)SET_LINE_CODING 請求SET_LINE_CODING 請求是用來設(shè)置串口的屬性,跟GET_LINE_CODING是相對的,不過后面所使用的Line_Coding格式是一樣的。該請求將在控制傳輸?shù)臄?shù)據(jù)過程發(fā)送7字節(jié)的Line_Coding數(shù)據(jù),其

49、格式如表所示。SET_LINE_CODING 請求的結(jié)構(gòu)bmRequestTypebRequestwValuewIndexwLengthData00100001BSET_LINE_CODING0接口數(shù)據(jù)結(jié)構(gòu)大小Line Coding數(shù)據(jù)結(jié)構(gòu)SET_CONTROL_LINE_STATE請求SET_CONTROL_LINE_STATE請求沒有數(shù)據(jù)輸出階段,其中wValue字段的D0位表示DTR,D1位表示RTS,其格式如表所示。SET_CONTROL_LINE_STATE請求的結(jié)構(gòu)bmRequestTypebRequestwValuewIndexwLengthData00100001BSET_CO

50、NTROL_LINE_STATE控制信號位圖接口0空數(shù)據(jù)傳輸?shù)膶?shí)現(xiàn)由于USB是串行總線,所以數(shù)據(jù)是一位一位在數(shù)據(jù)線上傳輸?shù)?。既然是一位一位地傳輸,就存在著一個數(shù)據(jù)位先后的問題。USB使用的是LSB在前的方式,即先出來的是最低位數(shù)據(jù),接下去是次低位,最后是最高位(MSB)。一個包,又被分成很多個域(field),而LSB、MSB就是以域?yàn)閱挝粊韯澐值?。USB總線上的傳輸數(shù)據(jù)是以包為基本單位的。不同類型的包有個共同的特點(diǎn),都是要以同步域開始,緊跟著一個包標(biāo)識符,最終以包結(jié)束符EOP來結(jié)束這個包。在介紹數(shù)據(jù)傳輸過程之前,我們先需要對幾個包進(jìn)行理解,以便對數(shù)據(jù)傳輸過程有個明確認(rèn)識。令牌包令牌包是用來啟

51、動一次USB傳輸?shù)?,總是由主機(jī)發(fā)送。主要包括四種:輸出(OUT)、輸入(IN)、建立(SETUP)、幀起始(SOF)。輸出令牌包用來通知設(shè)備將要輸出一個數(shù)據(jù)包;輸入令牌包用來通知設(shè)備返回一個數(shù)據(jù)包;建立令牌包只用在控制傳輸中,它和輸出令牌包的作用一樣,也是通知設(shè)備將要輸出一個數(shù)據(jù)包,兩者的區(qū)別主要在于:SETUP令牌包后只使用DATA0數(shù)據(jù)包,且只能發(fā)到設(shè)備的控制端點(diǎn),并且設(shè)備必須要接收,而OUT令牌包則沒有這樣的限制;幀起始包在每幀開始時(shí)發(fā)送,它以廣播的形式發(fā)送,所有USB全速設(shè)備和高速設(shè)備都可以接收到SOF包。在4個令牌包中,只有SOF令牌包之后不跟隨數(shù)據(jù)傳輸,其他都有數(shù)據(jù)傳輸。數(shù)據(jù)包顧名

52、思義,數(shù)據(jù)包就是用來傳輸數(shù)據(jù)的,可以從主機(jī)到設(shè)備,也可以設(shè)備到主機(jī),其方向由令牌包來指定。在USB2.0協(xié)議中,主要包括四種:DATA0、DATA1、DATA2和MDATA。數(shù)據(jù)包都具有同樣的結(jié)構(gòu):一個同步域,后面跟整數(shù)字節(jié)的數(shù)據(jù),然后是CRC16校驗(yàn),最后是EOP。握手包握手包用來表示一個傳輸是否被對方確認(rèn),它的發(fā)送者通常是數(shù)據(jù)接收者。握手包只有同步域、包標(biāo)識符和包結(jié)束符。主要包括:ACK(表示正確接收數(shù)據(jù),并且有足夠的空間來容納數(shù)據(jù))、NAK(表示沒有數(shù)據(jù)需要返回,或者數(shù)據(jù)正確接收但沒有足夠空間來容納)、STALL(表示設(shè)備無法執(zhí)行這個請求,或者端點(diǎn)已經(jīng)被掛起,它表示一種錯誤的狀態(tài))、NY

53、ET(只在USB2.0的高速設(shè)備輸出事務(wù)中使用,它表示設(shè)備本次數(shù)據(jù)成功接收,但沒有足夠空間來接收下一次數(shù)據(jù))。數(shù)據(jù)傳輸本課題中,我們選用2號端點(diǎn)作為批量傳輸(Bulk)的IN端點(diǎn),向主機(jī)發(fā)送數(shù)據(jù)。當(dāng)主機(jī)先發(fā)出一個IN令牌包,這個令牌包包含了設(shè)備地址、端點(diǎn)號。然后,再發(fā)送一個DATA包,這時(shí)地址和端點(diǎn)匹配的設(shè)備將會收下這個數(shù)據(jù)包。然后主機(jī)切換到接收模式,等待設(shè)備返回握手包。若設(shè)備解碼令牌包和數(shù)據(jù)包都準(zhǔn)確無誤,并且有足夠的緩沖區(qū)來保存數(shù)據(jù)后,就會使用ACK握手包來應(yīng)答主機(jī)。如果沒有足夠的緩沖區(qū)來保存,那么它就返回一個NAK握手包。如果設(shè)備檢測到數(shù)據(jù)準(zhǔn)確,但是端點(diǎn)處于掛起狀態(tài),則返回一個STALL握

54、手包。由于端點(diǎn)本身的緩沖區(qū)容量有限,而實(shí)際中需要傳送的字節(jié)數(shù)也可能遠(yuǎn)遠(yuǎn)大于端點(diǎn)本身的緩沖區(qū),因此,發(fā)送數(shù)據(jù)時(shí)開辟一個buffer緩沖區(qū)非常關(guān)鍵。這個buffer負(fù)責(zé)轉(zhuǎn)存一次傳輸中設(shè)備需要發(fā)送給PC的所有數(shù)據(jù);此外,我們還需要兩個計(jì)數(shù)器對發(fā)送和接收的字節(jié)數(shù)進(jìn)行計(jì)數(shù)。為此我們建立下面四種狀態(tài):(1)CDC_Handle_INT_IN:buffer中沒有緩沖數(shù)據(jù),但是發(fā)送端點(diǎn)本身的緩沖區(qū)為空。(2)CDC_Handle_Bulk_IN:buffer中有數(shù)據(jù),并且發(fā)送端點(diǎn)本身的緩沖區(qū)為空。(3)CDC_Handle_Bulk_IN_ZLP:數(shù)據(jù)已經(jīng)發(fā)送完畢,但是因?yàn)榘l(fā)送的數(shù)據(jù)為整數(shù)倍的最大包長,因此這

55、個時(shí)候需要發(fā)送一個0字節(jié)的包給PC機(jī),表示發(fā)送的完畢。(4)CDC_Handle_Bulk_OUT:數(shù)據(jù)已經(jīng)發(fā)送完畢。發(fā)送數(shù)據(jù)的前臺程序,負(fù)責(zé)將數(shù)據(jù)從開辟的buffer中傳送到端點(diǎn)的緩沖區(qū)中去,進(jìn)而傳送給PC,流程圖如圖4.1所示。數(shù)據(jù)接收過程,在應(yīng)用程序中完成,當(dāng)接收端點(diǎn)有數(shù)據(jù)過來時(shí),控制器的SIE(串行接口引擎)便會置相應(yīng)的中斷標(biāo)志位。因此,應(yīng)用程序只需要根據(jù)中斷標(biāo)志位來判斷是不是需要接收數(shù)據(jù)。INF文件的創(chuàng)建INF是Device Information File的英文縮寫,是Microsoft公司為硬件設(shè)備制造商發(fā)布其驅(qū)動程序推出的一種文件格式,INF文件中包含硬件設(shè)備的信息或腳本以控制

56、硬件操作。在INF文件中指明了硬件驅(qū)動該如何安裝到系統(tǒng)中,源文件在哪里、安裝到哪一個文件夾中、怎樣在注冊表中加入自身相關(guān)信息等等。在安裝監(jiān)視器、調(diào)制解調(diào)器和打印機(jī)等設(shè)備所需的驅(qū)動程序,都是通過INF文件,正是INF的功勞才使得Windows可以找到這些硬件設(shè)備的驅(qū)動并正確安裝。當(dāng)我們通過“開始控制面板添加刪除程序Windows安裝程序”來添加系統(tǒng)組件的時(shí)候,INF文件將會自動被調(diào)用。而在其他場合下,則需要在INF文件上點(diǎn)擊鼠標(biāo)右鍵,然后選擇“安裝”,才能順利安裝應(yīng)用程序。由于Windows2000以上系統(tǒng)已經(jīng)提供了usbser. sys驅(qū)動去支持CDC類設(shè)備,但這個驅(qū)動程序的安裝,就需要相應(yīng)的

57、INF文件的支持。以下就本課題的CDC_ACM.inf文件的創(chuàng)建做簡要介紹。 數(shù)據(jù)傳輸流程圖INF文件的規(guī)范INF文件的創(chuàng)建有一整套的編寫規(guī)則,每一個INF文件都是嚴(yán)格按照這些規(guī)則來編寫的。(1):INF文件是分節(jié)的,每一個INF文件有許多的節(jié)組成,節(jié)名用方括號括起來。這些節(jié)名有些是系統(tǒng)定義好的,有一些是用戶自定義的。(2):在節(jié)與節(jié)之間的內(nèi)容叫條目,每一個節(jié)又是由許多的條目組成的,每一個條目都是由形如“signature=$CHICAGO$”的形式組成的。如果每一個條目的等號后有多個值,則每一個值之間用“,”號分隔開。(3):INF文件對大小寫不敏感。(4):“;”號后面的內(nèi)容為注釋。(5)

58、:如果一個條目的內(nèi)容過多,在一行無法書寫完全,則用“”將一行內(nèi)容書寫為多行。INF文件的內(nèi)容文件的內(nèi)容說明:Version/ Version節(jié),該節(jié)中的條目主要是描述此INF文件支持的設(shè)備類型和適用的操作系統(tǒng)。Signature=$Windows NT$/表示該INF文件適用于Windows 2000/XP/2003操作系統(tǒng)。Class=Ports/表明了設(shè)備的類型。ClassGuid=4D36E978-E325-11CE-BFC1-08002BE10318Provider=%MYCORP%DriverVer=08/06/2011,1.0.1.0Manufacturer/ 該節(jié)中的條目主要是描

59、述INF文件可以識別的所有硬件設(shè)備,其中包含有設(shè)備的生產(chǎn)廠家,以便設(shè)備的正確安裝。%MYCORP%=MYCORPMYCORP%MYDEV000%= MYDEV000,USBVID_16C0&PID_06EA/設(shè)備的VID,PID設(shè)置DestinationDirs / INF文件會指示安裝程序在安裝的過程中,將一些文件復(fù)制到硬盤上,或者將硬盤上的一些文件刪除、重命名等。該節(jié)即指定了為實(shí)現(xiàn)上述目的的文件所在的目的路徑。FakeModemCopyFileSection=12DefaultDestDir = 12MYDEV000.NTCopyFiles=FakeModemCopyFileSection

60、MYDEV000.NT.ServicesAddService = usbser, 0 x00000002, Service_InstService_InstDisplayName = %Serial.SvcDesc%ServiceType = 1 ; SERVICE_KERNEL_DRIVERStartType = 3 ; SERVICE_DEMAND_STARTErrorControl = 1 ; SERVICE_ERROR_NORMALLoadOrderGroup = BaseMYDEV000.NT.AddRegHKR,NTMPDriver,*ntkernHKR,EnumPropPages

溫馨提示

  • 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請下載最新的WinRAR軟件解壓。
  • 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請聯(lián)系上傳者。文件的所有權(quán)益歸上傳用戶所有。
  • 3. 本站RAR壓縮包中若帶圖紙,網(wǎng)頁內(nèi)容里面會有圖紙預(yù)覽,若沒有圖紙預(yù)覽就沒有圖紙。
  • 4. 未經(jīng)權(quán)益所有人同意不得將文件中的內(nèi)容挪作商業(yè)或盈利用途。
  • 5. 人人文庫網(wǎng)僅提供信息存儲空間,僅對用戶上傳內(nèi)容的表現(xiàn)方式做保護(hù)處理,對用戶上傳分享的文檔內(nèi)容本身不做任何修改或編輯,并不能對任何下載內(nèi)容負(fù)責(zé)。
  • 6. 下載文件中如有侵權(quán)或不適當(dāng)內(nèi)容,請與我們聯(lián)系,我們立即糾正。
  • 7. 本站不保證下載資源的準(zhǔn)確性、安全性和完整性, 同時(shí)也不承擔(dān)用戶因使用這些下載資源對自己和他人造成任何形式的傷害或損失。

最新文檔

評論

0/150

提交評論