摘要： 本文介紹一種基于DSP平臺，以USB接口方式實現用于繼電器檢測與保護裝置的通信方式的實現。它采用Philips公司的ISP1581_BD接口芯片，實現DSP數據采集與PC機的高速傳輸。并介紹了在設計開發USB外設時主機應用程序及設備驅動程序的方法及代碼。 關鍵詞：USB設備驅動程序 ISP1581_BD 1 引言 ISP1581 是一種價格低、功能強的通用串行總線（USB）接口器件，它完全符合USB 2.0 規范，并為基于微控制器或微處理器的系統提供了高速USB 通信能力。ISP1581與系統的微控制器/微處理器的通信是通過一個高速的通用并行接口來實現的。它符合現有的大多數器件的分類規格，比如：成像類、海量存儲器件、通信器件、打印設備以及人機接口設備。 內部通用DMA 模塊使得數據流很方便的集成。另外，多種結構的DMA模塊實現了海量存儲的應用。這種實現USB 接口的標準組件使得使用者可以在各種不同類型的微控制器中選擇出一種最合適的微控制器。通過使用已有的結構和減少固件上的投資縮短了開發時間、減少了開發風險和費用。從而用最快捷的方法實現了最經濟的USB外設的解決方案。ISP1581可理想地用于許多外設，例如：打印機、掃描儀、MO、CD、DVD 和Zip/Jaz 驅動器、數碼相機、USB和以太網的鏈接、電纜和DSL調制解調器等等。另外，ISP1581 所具有的低掛起功耗還可以滿足ACPITM,OnNOWTM和USB電源管理的要求。此外，ISP1581內部還集成了許多特性，包括SoftConnectTM、低頻晶體振蕩器和集成的終止寄存器。所有這些特性都為系統大大節約了成本，同時使強大的USB功能很容易地用于PC機外設。 2 系統設計 系統設計包括硬件方案設計與USB設備的軟件設計。而USB設備的軟件設計主要包括兩部分：一是USB設備端的軟件，主要完成USB協議處理與數據交換（多數情況下是一個中斷子程序）以及其它應用功能程序；二是PC端的程序，由USB通信程序和用戶服務程序兩部分組成，用戶服務程序通過USB通信程序與系統USBDI(USB設備接口)通信，USB通信程序開發難度比較大，可用DDK或DriverWork等開發工具開發。 2.1 USB芯片與DSP的硬件連接 本方案以TI公司的TMS320C5XX作為微控制器，采用外部供電方式，連接電路如圖1所示。 ISP1581的16根數據線直接與DSP的數據線相連，存儲管理單元(MMU)和集成RAM作為USB的緩沖區，允許微控制器以自己的速率對USB信息包進行讀寫。D+，D-信號線上串接18Ω電阻。XTAL1接12MHz晶振。 2.2 固件程序設計 由于采用的是不帶微控制器內核的USB接口芯片，所以關于USB2.0協議規范的實現都必須靠DSP控制ISP1581芯片來完成。固件的主要設計任務是：在DSP的平臺上編寫程序，以完成USB2.0規范所要求的標準請求及用戶根據產品需要自己定義的請求。為了不影響程序的執行效率，本方案采用中斷方式完成固件的編寫，同時，為了保證程序的模塊化及良好的可移植性，在設計中采用分層結構進行固件的編寫。詳細方法可參見文獻 。 在本方案中，采用端點2以批量方式來與上位機進行通信，采用端點0來進行除設備枚舉之外的設備命令控制字的處理，這在下面的設備驅動程序中將會談到。因為對于繼電器來說，有很多標志位需要傳送；且因USB是單向控制的，故在每次讀寫數據時均需首先發送一命令控制字，然后再通過API讀寫函數進行雙方通信。所以我在此設一個IO請求結構：struct IOREQ{unsigned int wValue;unsigned int wIndex;},wValue代表16位標志位，wIndex代表需傳送的字節數，這個結構命令傳送的驅動需要自己在設備驅動程序中實現（通過設備類請求的方式，見2.3述），且在上層應用程序中通過DeviceIoControl(…)函數，通過驅動的類請求傳給USB設備端點0，USB設備則以類設備請求方式處理這個設備控制命令。 本驅動中采用0x00作為USB設備寫命令的請求類型號，0x01作為USB設備讀命令的請求類型號，設備固件中處理IO控制請求的代碼如下： unsigned char type, req; type = ControlData.DeviceRequest.bmRequestType & 0x60;//請求類型 req = ControlData.DeviceRequest.bRequest & 0x0F;//請求號 if (type == 0x00) (*StandardDeviceRequest[req])();//調用標準請求 else if (type ==0x40)//類請求 {if (req==0x00) Handle_Write_DeviceIo();//處理寫控制命令 if(req==0x01) Handle_Read_DeviceIo();//處理讀控制命令 } 2.3 PC端的USB驅動程序設計 DriverStudio 是一套用來簡化微軟Windows 平臺下設備驅動程序的開發、調試和測試的工具包。DriverStudio 當前的版本包括DriverWorks、SoftICE及其它工具模塊。DriverWorks：對于Windows NT下和 Windows 98與Windows 2000/XP共同支持的Win32驅動模型(WDM)設備驅動程序的開發提供完全的支持。DriverWorks中包含一個非常完善的源代碼生成工具(DriverWizard)以及相應的類庫和驅動程序樣本，它提供了在C++下進行設備驅動程序開發的支持。SoftICE：SoftICE 是一個功能極其強大的內核模式調試器，它支持在配置一臺單獨的計算機或兩臺計算機下進行設備驅動程序的調試。DriverWorks提供了三個與USB直接相關的類：UsbLowerDevice,KUsbInterface和KUsbPipe類，用于實現USB設備操作。KUsbLowerDevice類用于邏輯設備的編程，KUsbInterface類用于接口的編程，KUsbPipe類用于管道的編程。最基本的例程有設備的啟動，停止，卸載，讀寫，設備控制等例程 。 DriverStudio本身提供了一個設備驅動的框架，且可自動生成端點2的各種傳輸方式的源代碼，故在此不討論。對于設備控制命令傳送的驅動則需根據實際應用具體實現如下：采用設備類請求函數 PURB BuildVendorRequest( PUCHAR TransferBuffer,//為驅動程序存放傳輸數據的內存區 ULONG TransferBufferLength,//傳輸的字節數，對應于類請求的wLength UCHAR RequestTypeReservedBits,//為類請求字節中的保留位 UCHAR Request,//具體請求數值，對應于類請求的bRequest USHORT Value,//對應于類請求的wValue BOOLEAN bIn=FALSE,//TRUE為輸入：設備->主機，FALSE為輸出：主機->設備 BOOLEAN bShortOk=FALSE,//TRUE表示設備傳輸的字節數，可少于指定的字節數 PURB Link=NULL,//為下一個傳輸的URB UCHAR Index=0, //對應于類請求的wIndex USHORT Function=URB_FUNCTION_VENTOR_DEVICE,//類別的請求 PURB pUrb=NULL//指向一存在的URB ); 實現的方法是對于讀請求IOCTL_READ及寫請求IOCTL_WRITE, 將相應的類別代碼通過此成員函數傳送給底層驅動，實現IO控制命令請求。代碼實現如下： NTSTATUS USBDRIVERDevice::DeviceControl(KIrp I) { NTSTATUS status; PURB pUrb; struct IOREQ* Ioctrl; switch (I.IoctlCode()) { case IOCTL_READ://處理IO讀請求 PIRP pIrp=(PIRP)I; Ioctrl=(struct IOREQ*)pIrp->AssociatedIrp.SystemBuffer;//取緩沖區數據 pUrb=m_Lower.BuildVendorRequest(NULL,0,0,0,Ioctrl->wvalue,TRUE,TRUE,NULL, Ioctrl->wIndex,URB_FUNCTION_VENDOR_DEVICE);//類請求：讀請求 if(pUrb==NULL) status=STATUS_INSUFFICIENT_RESOURCES; else {status=m_Lower.SubmitUrb(pUrb);delete pUrb;} break; case IOCTL_WRITE: PIRP pIrp=(PIRP)I; Ioctrl=(struct IOREQ*)pIrp->AssociatedIrp.SystemBuffer; //取緩沖區數據 pUrb=m_Lower.BuildVendorRequest(NULL,0,0,1,Ioctrl->wvalue,TRUE,TRUE,NULL, Ioctrl->wIndex,URB_FUNCTION_VENDOR_DEVICE); //類請求：寫請求 if(pUrb==NULL) status=STATUS_INSUFFICIENT_RESOURCES; else {status=m_Lower.SubmitUrb(pUrb);delete pUrb;} break; default: status = STATUS_INVALID_PARAMETER; break; } if (status == STATUS_PENDING) return status; else return I.PnpComplete(this, status);//成功，提交URB } 另外，對于設備驅動的安裝，還應修改設備配置文件中的安裝程序類別和GUID：Class=USB，ClassGUID={36FC9E60-C465-11CF-8056-444553540000}，否則將無法識別出是USB設備 。 2.4 PC端的應用程序設計 通過調用API函數編寫PC的應用程序。函數有CreateFile(),CloseHandle(), DeviceIOControl(),ReadFile(),WriteFile()。其中DeviceIOControl()用于PC（主機）向DSP發送請求，ReadFile()和WriteFile()分別用于從USB設備中讀出數據以及向USB設備中寫入數據。在設計過程中必須注意的問題是：由于USB接口是主-從方式的接口，它的一切傳輸過程都必須通過主機向外設發送請求后才可以開始，所以在使用ReadFile()、WriteFile()讀寫數據之前，必須先通過DeviceIOControl()向USB設備發送請求，而且還須采用異步IO方式。例如，讀數據的部分代碼為： struct IOREQ Ioctrl;//IO請求的結構 OVERLAPPED ov;//異步IO memset(&ov,0,sizeof(OVERLAPPED)); ov.hEvent=CreateEvent(NULL,TRUE,FALSE,NULL);//創建一事件 ResetEvent(ov.hEvent);//復位事件 unsigned long nBytes; Ioctrl.wvalue=xx; Ioctrl.wIndex=xx;// 傳送的標志位及要傳輸的字節數 bResult = DeviceIoControl(hDevice,IOCTL_READ,&Ioctrl,8,NULL,0,&nBytes,&ov);//啟動 //讀命令， if (bResult != TRUE) { if(GetLastError()!=ERROR_IO_PENDING)//IO錯誤 { MessageBox("請求數據傳送失敗! 已放棄", "錯誤"); return 0; } switch(::WaitForSingleObject(ov.hEvent,20))//等待20ms { case WAIT_OBJECT_0: if(!::GetOverlappedResult(hDevice,&ov,&nBytes,TRUE)) return 0; break; case WAIT_TIMEOUT://超時錯誤 ::CancelIo(hDevice); return 0; default: return 0; } } bResult = ReadFile(hDevice,…,&ov);// 從設備讀數據 if (bResult != TRUE) {…//同上} 3 系統測試及結果 繼電器測試與保護裝置的交流實驗部分測試結果如下圖所示。實驗證明，利用USB傳輸響應時間完全達到設定要求，即使在有10路AD數據的情況下也反應靈敏，特別地，用USB傳輸方式，有效的解決了現場作業方便性的問題。 ４ 結束語 本文以一實際開發的項目為例，對以DSP芯片為控制器的USB傳輸系統具體的硬件和軟件實現進行了闡述，特別地詳述了適用于具體應用的設備驅動的開發，此設備驅動也已成功應用于USB接口的圖像傳輸，具有一定的通用性。 參考文獻 [1]周立功等. PDIUSBD12 USB固件編程與驅動開發[M]. 北京:北京航空航天大學出版社,2003,2 [2]武安河等. Windows 2000/XP WDM設備驅動程序開發[M]. 北京：電子工業出版社，2003，4 [3]施諾等[譯]. Windows 2000 設備驅動程序設計指南[M]. 北京：機械工業出版社，2001，9