基于DSP和專用接口芯片的USB實現(xiàn)方案
中斷處理程序
中斷處理程序是整個固件程序設計的重點。將DSP設置為下降沿觸發(fā),當PDIUSBD12接收到主機發(fā)送的信息包時,觸發(fā)DSP進入中斷。首先通過讀取PDIUSBD12的中斷寄存器判斷所發(fā)生中斷的類型,然后根據(jù)具體的中斷類型進入相應的處理子程序。中斷處理程序流程圖如圖3所示。
標準請求處理程序
USB協(xié)議中規(guī)定了11條所有USB設備都必須支持的標準請求,這些請求都是通過端點0發(fā)送的。標準請求處理程序?qū)χ鳈C發(fā)出的標準請求進行響應,獲取設備的性能及狀態(tài),并給設備分配地址且進行相應配置,最終完成枚舉過程。
硬件接口及PDIUSBD12命令操作程序
硬件接口程序集成了DSP對PDIUSBD12的讀寫操作,是整個固件程序中最底層也是使用最頻繁的部分,將它獨立成一個模塊編寫極大地方便了程序在不同硬件平臺上的移植。值得注意的是:PDIUSBD12要求數(shù)據(jù)線上的數(shù)據(jù)建立時間和保持時間必須大于40nS,因此編程時需要插入至少4個軟件等待狀態(tài)。另外,因為PDIUSBD12的最小讀寫周期為500nS,所以在每次對其進行讀寫操作后必須增加適當?shù)难訒r。
數(shù)據(jù)發(fā)送及接收程序
當用戶通過主機端應用程序向設備索要數(shù)據(jù)時,DSP調(diào)用數(shù)據(jù)發(fā)送子程序完成數(shù)據(jù)發(fā)送,針對發(fā)送數(shù)據(jù)量的大小,可以選擇使用端點1或者端點2完成。對于主機發(fā)送數(shù)據(jù)的接收,在端點0及端點1的IN中斷子程序中即可完成。發(fā)送數(shù)據(jù)子程序如下:
調(diào)試
固件程序?qū)r間敏感,所以編程時要特別注意時序問題。由于USB枚舉過程很快,如果連續(xù)三次接收不到應答包就結(jié)束枚舉,所以調(diào)試時要注意不能采用CCS的單步調(diào)試,可以采用斷點調(diào)試。調(diào)試過程之初經(jīng)常會遇到的一種狀況是指示燈閃爍三次以后熄滅,這說明主機檢測到了設備連接,但無法和設備進行對話來了解設備的信息。這表明固件程序還沒有開始正常工作,需仔細檢查程序中的錯誤之處。
調(diào)試過程之初,可以使用以下兩種方法檢測硬件連接是否正確:
1. 使用命令字FDh讀取PDIUSBD12的ID號,正常狀態(tài)下讀出的兩個字節(jié)應該為12H和10H。
2. 通過設置PDIUSBD12工作模式,改變輸出時鐘頻率。在CLKout引腳測量輸出波形,觀察是否與設置值相符。
若以上兩條滿足,則說明硬件連接基本沒有問題。
PC端軟件
PC端軟件包括設備驅(qū)動程序和應用程序兩部分。
系統(tǒng)驅(qū)動程序是基于WDM (Windows Driver Model) 驅(qū)動程序模型設計的,包括四個模塊:初始化模塊、即插即用管理模塊、電源管理模塊和I/O功能模塊。本設計選用輔助工具DriverStudio,它能很好地和DDK結(jié)合,編程思路也比較清晰。首先使用驅(qū)動向?qū)В―riverWizard)建立項目,設置驅(qū)動程序類型,設置USB設備的VID(Vendor ID)和PID(Product ID)及其各端點的屬性。給端點2增加讀寫函數(shù)代碼。這樣就創(chuàng)建了一個驅(qū)動程序的總體框架。再對生成的代碼進行修改編譯和測試,完成USB驅(qū)動程序的開發(fā)。
應用程序是為了實現(xiàn)用戶和設備的接口,基本功能包括檢測USB設備、開啟或閉合USB設備、設置USB數(shù)據(jù)傳輸管道、實時從USB接口采集數(shù)據(jù)以及顯示數(shù)據(jù)等。程序使用VC++編寫,調(diào)用Win32的應用程序接口(API)函數(shù),實現(xiàn)應用程序和設備驅(qū)動的通信。使用PHILIPS公司提供的EasyD12.dll動態(tài)鏈接庫可以使開發(fā)過程更加輕松快捷。
結(jié)束語
系統(tǒng)測試結(jié)果表明:主機與設備間的數(shù)據(jù)傳輸平均速率達到130kb/s,完全可以滿足一般測量儀器的需要。此項接口設計方案具有良好的可移植性,針對不同的硬件平臺僅需做少許修改即可應用。隨著USB技術(shù)的進一步發(fā)展,USB2.0和USB OTG規(guī)范的推出以及無線USB的出現(xiàn),USB儀器將成為測量儀器的發(fā)展方向,并推動傳統(tǒng)儀器向小型化和微型化方向發(fā)展。
評論