在編寫這部分程序之前，首先需要了解有關USB協(xié)議,重點是USB數據通信結構、11條標準請求命令和標準USB描述符。
因為嵌入式設備的軟硬件是密切相關的，所以還需做的準備工作是了解選用的USB芯片及主控MCU的性能。
一.硬件篇
USB芯片
作用:
1. 管理和實現USB物理層的差模信號
2. 以寄存器的形式提供各種端點(如控制端點,中斷端點,大批量傳輸端點,同步傳輸端點)
3. 提供狀態(tài)寄存器,配置寄存器,存儲寄存器,中斷寄存器,控制寄存器
4. 電源管理(提供3.3V的電源)
5. 實現某些協(xié)議層功能(如CRC校驗/產生,PID校驗/產生,同步模式的識別,并行串行轉換等)
固件就是以這些硬件資源作為基礎來實現USB設備功能的,其中,端點是需要重點學習的對象,需要熟練掌握與之相關的狀態(tài)寄存器,配置寄存器,存儲寄存器,中斷寄存器
MCU主控芯片
作用:
1. 實現USB設備的功能
2. 處理USB芯片產生的中斷,解析SETUP包,處理標準請求和廠商請求
二.軟件篇
USB設備端固件程序,枚舉部分是全部程序的基礎和重心,只有主機對設備枚舉成功后,主機才能和設備進行正常的通信
USB的枚舉過程分為4個狀態(tài).
1.接入態(tài)
v主機檢測到USB設備插上,擊活端口,并發(fā)送復位命令(保持10ms)
2.默認態(tài)
v主機使用默認地址讀取設備描述符 (GET_DESCRIPTOR)
v主機分配給設備一個總在線的唯一地址 (SET_ADDRESS)
3.地址態(tài)
v主機從新的地址獲取設備描述符(GET_DESCRIPTOR)
v主機獲取所有設備的配置描述符(GET_DESCRIPTOR)
4.配置態(tài)
v主機設置描述符(設備,配置) (SET_CONFIGURATION)
v主機讀取配置狀態(tài)(可選) (GET_CONFIGURATION)
v主機讀取接口狀態(tài)(可選) (GET_INTERFACE)
三.實踐篇
在枚舉階段的固件編寫中,我主要參考PHILIPS公司提供的D12型 USB芯片代碼(有參考比自己從零開始要容易很多).由于該代碼是基于51單片機編寫的,與我所用的16位單片機在性能和結構上有較大差異,因此在固件移植過程中,所遇到的問題大多來源于此.
下面是我在移植過程中碰到的四個主要問題。
第一個問題，出現在默認態(tài)階段，主機用默認地址讀取設備描述符。當MCU收到USB芯片產生的中斷時，無法正確讀出USB芯片中斷寄存器中的值。
這個問題發(fā)生在整個枚舉過程的一開始，準確的說是第一步，所以我開始懷疑MCU與USB芯片的通信是否真正建立；而在此前，我對它們之間的通信能力一直深信不疑；因為我曾經用MCU發(fā)出測試專用指令來讀取USB芯片的ID值，并且正確地讀到了USB芯片的ID值，從理論上講MCU與USB的通信已經建立．解決這個問題大約用了半天時間，后來我在MCU讀中斷寄存器命令后加了一段延時程序，問題得到解決，即中斷產生后MCU正確讀出了USB芯片中斷寄存器的值
我分析原因是MCU發(fā)送命令的速度太快，當發(fā)送了讀USB中斷寄存器值命令后，就迅速發(fā)送取數據命令，而USB芯片的速度要慢的多，在MCU讀數據時還未來得及把數據準備好。之前我讀取USB芯片ID值的測試指令是循環(huán)發(fā)出的，剛開始雖然數據沒準備好，但隨著指令的循環(huán)發(fā)出，后面指令自然可以把前面指令準備的數據發(fā)出。
第二個問題出現在默認態(tài)階段，主機用默認地址讀取設備描述符。MCU收到USB芯片產生的中斷，卻無法進入到正確的中斷服務程序。
在第一個問題解決后，立刻又出現了這一問題。通過串口監(jiān)控，我很快發(fā)現，解析中斷信息的程序中，有一段程序的功能是互換一個BYTE數據的高低字節(jié)位，這一功能主要是針對51單片機數據存放的結構與USB接口芯片的數據結構高低位顛倒而設置的。通過實驗我發(fā)現:這款16位單片機也不具有51單片機的這一特點，所以只要去掉這段高低字節(jié)互換的程序，問題就解決了。
第三個問題，出現在地址態(tài)階段，主機獲取設備描述符。USB設備響應主機要求，發(fā)送16字節(jié)的設備描述符給主機，主機不能收到。
因為16字節(jié)的數據是通過MCU發(fā)送到USB芯片，再由USB芯片發(fā)送到
主機的。所以需要判斷數據是在哪一個環(huán)節(jié)沒有被正確傳輸的。我利用串口監(jiān)測到: MCU收到主機的讀中斷(讀取設備描述符命令)后，會送出了16字節(jié)的設備描述符到USB芯片；但是用BUS HOUND(一種基于主機端的USB總線監(jiān)視軟件)監(jiān)視主機端發(fā)現:主機并沒有收到這16字節(jié)的數據。因此我判斷問題出在數據從MCU到USB芯片這一環(huán)節(jié)——即由MCU發(fā)出的設備描述符沒有被USB芯片接收到。通過實驗，我發(fā)現USB芯片沒有接收到MCU發(fā)來的數據是因為USB芯片的速度較慢，對它來說，每一筆由MCU發(fā)出的數據在數據線上保持的時間太短，以致USB芯片無法將數據存放到其寄存器中。當改變MCU的相關設置，延長數據在數據線上保持的時間后，問題得以解決。
第四個問題，出現在配置態(tài)階段，主機設置描述符。通過BUS HOUND監(jiān)視，主機在SET_CONFIGURATION后停止枚舉。
這個問題是我碰到的最難解決的困難，難就難在一直找不出主機停止枚舉的原因，不知道問題產生在哪個環(huán)節(jié)。通過BUS HOUND可以清楚地看到：主機發(fā)出了正確的SET_CONFIGURATION命令，接下來USB設備只需回送一個空包（數據為0）通知主機已收到該命令；可是主機的枚舉過程進行到這里卻戛然而止。為什么?難道是設備沒有發(fā)出應答空包，或者是主機沒有收到應答空包，還是設備回送的空包有錯誤?我大約用了5天時間來找支持這些假設的理由。不過，除了證明假設不成立外，一無所獲。
第六天，在一次檢查BUS HOUND的數據時終于有了新發(fā)現。我發(fā)現：在SET_CONFIGURATION命令之前，主機發(fā)出了GET_DESCRIPTOR來獲取全部的描述符合集共46字節(jié)數據，設備回復的描述符中在第20多字節(jié)時多了一個0字節(jié)；不過我并不清楚是否是這個問題對下一步產生了影響，在我看來只要主機在枚舉過程中發(fā)出了下一步枚舉命令，那就表明在此之前的枚舉都是正確的(后來的事實證明情況并非如此)，后一步的枚舉不成功應該與前一步無關。但是因為我再也找不到任何可疑之處，所以只好去尋找那一個字節(jié)的0是從哪里來的?又經過了一天的摸索，終于找到了問題的癥結。我的描述符數據是以結構體的形勢存放的，當MCU收到主機發(fā)出的獲取描述復命令時，就通過指針的指示將結構體中的數據發(fā)出。這些數據大多數是CHAR型，少數幾個是INT型(癥結)，對16位單片機來說INT型數據存放是從偶地址開始的，因此，一旦在INT型的數據前有奇數個CHAR型數據，那就天下大亂了，INT型數據會空出一個奇數的地址位，從其后的偶數地址位開始存放數據。這樣中間就多出1位的0字節(jié)數據。因此當主機那邊收到時這筆數據時，從這一位起其后的數據就全部錯位了。當我把INT型數據改用2個CHAR型表述時，一切就正常了； 同時，在此之后的SET_CONFIGURATION也能順利進行下去，直到枚舉結束。
看來枚舉的 GET_DESCRIPTOR階段如果主機得不到正確得描述符信息，并不會影響該階段的枚舉，而是對SET_CONFIGURATION階段產生影響，使枚舉無法繼續(xù)。我想這應該是由主機端驅動程序來決定的。
非常幸運，利用BUS HOUND觀察到的有限數據中，在最后的幾字就出現了異常，否則，這個問題不知道要困擾我多久(BUS HOUND可以顯示主機端接收到設備發(fā)來的數據，但數據的長度僅為32個字節(jié))
寫在最后
對設備端固件開發(fā)而言，如果有專用的USB總線分析儀是最好不過了，不但能監(jiān)視到主機端收發(fā)的數據，而且可以監(jiān)視到設備端收發(fā)的數據，這樣，開發(fā)的效率會大大提高，開發(fā)時間可以大大降低。但如果開發(fā)條件像我一樣有限，至少應該保證有串口和BUS HOUND這種USB總線監(jiān)視工具(從網上可以下載)，其中，串口可以在枚舉的開始階段使用，監(jiān)控MCU的相關數據；BUS HOUND則可以在枚舉的后期發(fā)揮更大的作用，因為此時傳輸的數據量較大，串口已不太適合作為監(jiān)視工具了。
此外，在USB設備的枚舉程序編寫中，我遇到的最大挑戰(zhàn)來自于8位單片機與16位單片機的結構上的差別，比如數據存取速度，數據高低字節(jié)的存放次序，數據類型與存放地址相關的特點等。從我前面列出的問題來看，大部分問題均源自于此；因此在學習某種單片機時，就要準確地掌握不同類型的MCU特性，這樣就一定可以降低開發(fā)難度，縮短開發(fā)時間
