一 PDIUSBD12芯片介紹

進行USB開發之前要根據成本與性能選擇合適的USB接口芯片。目前USB控制器芯片通常可分成3種：

第一種是專為USB設計的芯片，這類芯片的主要來源是CYPRESS的M8系列和ScanLogic的SL11R系列芯片。這種芯片是為了使用在USB應用設備而特別設計的，而不是在舊的結構上改造出來的，因而其功能的實現能夠達到最佳化，但是開發起來比較困難，要學全新的指令集，而且價格較較貴。

第二種是與現有的芯片兼容。大部分和8051系列的芯片兼容，如AMD公司的AM186T和Motorola的68HC05/8。這種芯片的優點是開發者已經熟悉現有芯片的結構和指令集，開發起來會比較容易。

第三種是需要外部微處理器接口的USB芯片。這類芯片只負責處理USB通信，它要和另一塊單片機芯片一起工作。典型的主要有NS公司的USBN9603、NetChip公司的NET2888、Philip公司的PDIUSBD11/12等。使用這樣的芯片的最大的好處是硬件的結構有很大的靈活性，便于發揮單片機的優良性能，同時價格便宜。

綜合考慮了以上幾種芯片后，本課題決定選用Philip公司的PDIUSBD12芯片。這樣可利用對DSP的熟悉的優勢，加快產品的開發進程，同時還能提高系統的可擴展性，便于選擇高性能的單片機。本芯片只支持USB1.1協議，對于速度要求高的系統可采用后文提到的支持USB2.0協議的信號轉換板。

基于USB1.1的Philip公司的PDIUSBD12芯片結構比較簡單，它必須單片機配合才能完成USB通信功能。單片機以讀寫外部存儲器的方式執行PDIUSBD12芯片的通信功能命令。芯片產商將給出其具體的USB操作命令。其管腳圖說明如圖1：

圖1 PDIUSBD12的管腳圖

二 USB-PC104轉換板設計

由于嵌入式主板價格昂貴，而在很多應用場合可以用一個成本低的USB外設替代。這里的USB外設意指嵌入式系統本身不能獨立運行，需要PC機的軟硬件支持。這樣的嵌入式系統最先要解決的問題是開發一塊USB-PC104信號轉換板來替代嵌入式主板。需要轉換USB總線與PC104總線的信號的原因在于這樣可以讓系統既擁有USB設備的優點又有PC104總線設備的高可靠性。采用DSP芯片可以提高系統的速度達到和嵌入式主板總線的要求。

1 硬件設計

硬件設計的主要框圖如圖2所示：

圖2 轉換板硬件主體框圖

它的主要工作原理是：從主機的應用程序發出的訪問PC-104總線設備的命令，經過底層的USB驅動程序將其轉換為相應的USB設備標準要求送到USB接口芯片PDIUSBD12（以下簡稱D12），運行于DSP的固件程序接收到這個要求，就會向PC104總線執行相應的命令，從而達到控制PC-104總線硬件的目的。

2 固件程序的開發

固件程序運行在USB外圍設備的單片機中，由它響應主機發送過來的USB的各種要求和數據傳輸。固件的組成主要有兩大部分，ISR（中斷程序）和主程序。中斷程序運行在后臺，負責USB芯片與單片機MPU的USB要求中斷響應與數據傳輸，中斷程序接收到主機發送來的USB要求和數據后就將它轉送給主程序并設置相應的標志位。主程序運行在前臺，它根據中斷程序傳給它的數據及標志位而進行實際的硬件動作。后臺ISR中斷服務程序和前臺主程序循環之間的數據交換通過事件標志和數據緩沖區來實現的。例如PDIUSBD12的批量輸出端點可使用循環的數據緩沖區，當PDIUSBD12 從USB收到一個數據包那么就對MPU 產生一個中斷請求，MPU立即響應中斷。在ISR中固件將數據包從PDIUSBD12內部緩沖區移到循環數據緩沖區并且隨后清空PDIUSBD12的內部緩沖區以使能接收新的數據包。MPU可以繼續它當前的前臺任務，直到完成任務后返回到主循環。同時檢查循環緩沖區內是否有新的數據并開始其它的前臺任務編寫固件程序可用匯編語言或者C語言，用C語言得有KEIL C編譯器的支持。但總體上它們的程序框架是一樣的。主體程序框架如圖3所示：

圖3 固件主程序框架

3 驅動程序開發

由于現代操作系統對內存、端口等資源均采取了保護措施。一般的應用程序不能夠直接訪問硬件，必須通過設備的驅動程序。設備驅動程序直接和硬件打交道的，并且運行于操作系統核心態，它像操作系統內核一樣具有最高的運行權限，所以它可以直接訪問硬件。

USB設備必須使用WDM（Win32 Driver Model）驅動程序模型，它是Microsoft公司定義的WIN32驅動程序模型。WDM是操作系統發展到現在的一種新型驅動程序模型，現在已經成為Windows操作系統驅動程序的主流。

在Windows系統下，和應用程序打交道主要有五層模型：硬件層、硬件抽象層、驅動程序、IO管理層和用戶運用程序。從用戶應用程序發出的請求一層一層地往下發送。USB的驅動程序還分為客戶驅動程序、根集線器驅動程序和總線驅動程序。用戶主要開發客戶驅動程序即可，蓁其余更底層的操作系統已經為用戶準備好。客戶驅動程序由一系列的例程（也即一般程序的函數）組成，它沒有main（）函數入口點。因此，USB設備和驅動程序打交道必須由操作系統的IO管理層參與，它使用了一種全局量叫作IO請求包即IRP。主要工作原理如下：

（1）開始時用戶應用程序向驅動程序發出請求（Windows API函數），并將相關的數據打包成IRP，IO管理器捕獲這個IRP包并進行相應的處理。

（2）IO管理器向客戶驅動程序發送IRP請求包，請求客戶驅動程序進行相應的處理。

（3）客戶驅動程序處理完接收到的IRP，設好相關環境后將之傳給更底層的驅動程序，最后由總線驅動程序完成對硬件的操作，并將結果返回。

用戶要做的事就是開發客戶驅動程序。本課題用的是基于WIN2000 DDK的DriverWorks驅動程序開發工具，同時還要VC++6.0編譯環境。這種工具可生成驅動程序框架，用戶進行修改并加入自己要實現的功能即可，大大縮短了開發的時間。

4 用戶應用程序

應用程序是實現硬件功能的全部體現。但應用程序不能直接訪問USB設備，它必須先與驅動程序通信，通過驅動程序來訪問USB設備。它的工作是向硬件發送數據或命令，這些數據和命令由驅動程序經過層層處理，最后發送到硬件實現相關的動作。應用程序與驅動程序打交道主要是通過操作系統的API函數。

其工作原理如下：

（1）應用程序通過調用CreateFile API函數取得USB設備的句柄。該符號鏈接包含一個全域惟一標識符（globally unique identifier，GUID）。GUID是一個128位的號碼，Windows用來惟一識別一個設備對象。

（2）通過這個句柄，應用程序通過調用ReadFile和WriteFile API函數來讀寫USB設備，將數據返回到用戶緩沖區。

（3）通過這個句柄，應用程序通過調用DeviceIoControl API函數來向USB設備發出控制命令，以實現特定的要求，這個函數還可能有相應的數據傳輸。

（4）應用程序處理從USB設備接收到的數據，如果出錯，將給出相應的警告，如果成功，處理完后關閉設備的句柄。
責任編輯；zl