USB設備枚舉全紀錄

在編寫這部分程序之前，首先需要了解有關USB協議,重點是USB數據通信結構、11條標準請求命令和標準USB描述符。

因為嵌入式設備的軟硬件是密切相關的，所以還需做的準備工作是了解選用的USB芯片及主控MCU的性能。

一.硬件篇

USB芯片

作用:

1.      管理和實現USB物理層的差模信號

2.      以寄存器的形式提供各種端點(如控制端點,中斷端點,大批量傳輸端點,同步傳輸端點)

3.      提供狀態寄存器,配置寄存器,存儲寄存器,中斷寄存器,控制寄存器

4.      電源管理(提供3.3V的電源)

5.      實現某些協議層功能(如CRC校驗/產生,PID校驗/產生,同步模式的識別,并行串行轉換等)

固件就是以這些硬件資源作為基礎來實現USB設備功能的,其中,端點是需要重點學習的對象,需要熟練掌握與之相關的狀態寄存器,配置寄存器,存儲寄存器,中斷寄存器

MCU主控芯片

作用:

1.      實現USB設備的功能

2.      處理USB芯片產生的中斷,解析SETUP包,處理標準請求和廠商請求

二.軟件篇

USB設備端固件程序,枚舉部分是全部程序的基礎和重心,只有主機對設備枚舉成功后,主機才能和設備進行正常的通信

USB的枚舉過程分為4個狀態.

       1.接入態

v主機檢測到USB設備插上,擊活端口,并發送復位命令(保持10ms)

       2.默認態

v主機使用默認地址讀取設備描述符        (GET_DESCRIPTOR)

v主機分配給設備一個總在線的唯一地址    (SET_ADDRESS)

       3.地址態

v主機從新的地址獲取設備描述符(GET_DESCRIPTOR)

v主機獲取所有設備的配置描述符(GET_DESCRIPTOR)

      4.配置態

v主機設置描述符(設備,配置) (SET_CONFIGURATION)

         v主機讀取配置狀態(可選) (GET_CONFIGURATION)

v主機讀取接口狀態(可選) (GET_INTERFACE)

三.實踐篇

在枚舉階段的固件編寫中,我主要參考PHILIPS公司提供的D12型 USB芯片代碼(有參考比自己從零開始要容易很多).由于該代碼是基于51單片機編寫的,與我所用的16位單片機在性能和結構上有較大差異,因此在固件移植過程中,所遇到的問題大多來源于此.

下面是我在移植過程中碰到的四個主要問題。

第一個問題，出現在默認態階段，主機用默認地址讀取設備描述符。當MCU收到USB芯片產生的中斷時，無法正確讀出USB芯片中斷寄存器中的值。

這個問題發生在整個枚舉過程的一開始，準確的說是第一步，所以我開始懷疑MCU與USB芯片的通信是否真正建立；而在此前，我對它們之間的通信能力一直深信不疑；因為我曾經用MCU發出測試專用指令來讀取USB芯片的ID值，并且正確地讀到了USB芯片的ID值，從理論上講MCU與USB的通信已經建立．解決這個問題大約用了半天時間，后來我在MCU讀中斷寄存器命令后加了一段延時程序，問題得到解決，即中斷產生后MCU正確讀出了USB芯片中斷寄存器的值

我分析原因是MCU發送命令的速度太快，當發送了讀USB中斷寄存器值命令后，就迅速發送取數據命令，而USB芯片的速度要慢的多，在MCU讀數據時還未來得及把數據準備好。之前我讀取USB芯片ID值的測試指令是循環發出的，剛開始雖然數據沒準備好，但隨著指令的循環發出，后面指令自然可以把前面指令準備的數據發出。

第二個問題出現在默認態階段，主機用默認地址讀取設備描述符。MCU收到USB芯片產生的中斷，卻無法進入到正確的中斷服務程序。

在第一個問題解決后，立刻又出現了這一問題。通過串口監控，我很快發現，解析中斷信息的程序中，有一段程序的功能是互換一個BYTE數據的高低字節位，這一功能主要是針對51單片機數據存放的結構與USB接口芯片的數據結構高低位顛倒而設置的。通過實驗我發現:這款16位單片機也不具有51單片機的這一特點，所以只要去掉這段高低字節互換的程序，問題就解決了。

第三個問題，出現在地址態階段，主機獲取設備描述符。USB設備響應主機要求，發送16字節的設備描述符給主機，主機不能收到。

因為16字節的數據是通過MCU發送到USB芯片，再由USB芯片發送到

主機的。所以需要判斷數據是在哪一個環節沒有被正確傳輸的。我利用串口監測到: MCU收到主機的讀中斷(讀取設備描述符命令)后，會送出了16字節的設備描述符到USB芯片；但是用BUS HOUND(一種基于主機端的USB總線監視軟件)監視主機端發現:主機并沒有收到這16字節的數據。因此我判斷問題出在數據從MCU到USB芯片這一環節——即由MCU發出的設備描述符沒有被USB芯片接收到。通過實驗，我發現USB芯片沒有接收到MCU發來的數據是因為USB芯片的速度較慢，對它來說，每一筆由MCU發出的數據在數據線上保持的時間太短，以致USB芯片無法將數據存放到其寄存器中。當改變MCU的相關設置，延長數據在數據線上保持的時間后，問題得以解決。

    第四個問題，出現在配置態階段，主機設置描述符。通過BUS HOUND監視，主機在SET_CONFIGURATION后停止枚舉。

    這個問題是我碰到的最難解決的困難，難就難在一直找不出主機停止枚舉的原因，不知道問題產生在哪個環節。通過BUS HOUND可以清楚地看到：主機發出了正確的SET_CONFIGURATION命令，接下來USB設備只需回送一個空包（數據為0）通知主機已收到該命令；可是主機的枚舉過程進行到這里卻戛然而止。為什么?難道是設備沒有發出應答空包，或者是主機沒有收到應答空包，還是設備回送的空包有錯誤?我大約用了5天時間來找支持這些假設的理由。不過，除了證明假設不成立外，一無所獲。

第六天，在一次檢查BUS HOUND的數據時終于有了新發現。我發現：在SET_CONFIGURATION命令之前，主機發出了GET_DESCRIPTOR來獲取全部的描述符合集共46字節數據，設備回復的描述符中在第20多字節時多了一個0字節；不過我并不清楚是否是這個問題對下一步產生了影響，在我看來只要主機在枚舉過程中發出了下一步枚舉命令，那就表明在此之前的枚舉都是正確的(后來的事實證明情況并非如此)，后一步的枚舉不成功應該與前一步無關。但是因為我再也找不到任何可疑之處，所以只好去尋找那一個字節的0是從哪里來的?又經過了一天的摸索，終于找到了問題的癥結。我的描述符數據是以結構體的形勢存放的，當MCU收到主機發出的獲取描述復命令時，就通過指針的指示將結構體中的數據發出。這些數據大多數是CHAR型，少數幾個是INT型(癥結)，對16位單片機來說INT型數據存放是從偶地址開始的，因此，一旦在INT型的數據前有奇數個CHAR型數據，那就天下大亂了，INT型數據會空出一個奇數的地址位，從其后的偶數地址位開始存放數據。這樣中間就多出1位的0字節數據。因此當主機那邊收到時這筆數據時，從這一位起其后的數據就全部錯位了。當我把INT型數據改用2個CHAR型表述時，一切就正常了； 同時，在此之后的SET_CONFIGURATION也能順利進行下去，直到枚舉結束。

看來枚舉的 GET_DESCRIPTOR階段如果主機得不到正確得描述符信息，并不會影響該階段的枚舉，而是對SET_CONFIGURATION階段產生影響，使枚舉無法繼續。我想這應該是由主機端驅動程序來決定的。

非常幸運，利用BUS HOUND觀察到的有限數據中，在最后的幾字就出現了異常，否則，這個問題不知道要困擾我多久(BUS HOUND可以顯示主機端接收到設備發來的數據，但數據的長度僅為32個字節)

寫在最后

對設備端固件開發而言，如果有專用的USB總線分析儀是最好不過了，不但能監視到主機端收發的數據，而且可以監視到設備端收發的數據，這樣，開發的效率會大大提高，開發時間可以大大降低。但如果開發條件像我一樣有限，至少應該保證有串口和BUS HOUND這種USB總線監視工具(從網上可以下載)，其中，串口可以在枚舉的開始階段使用，監控MCU的相關數據；BUS HOUND則可以在枚舉的后期發揮更大的作用，因為此時傳輸的數據量較大，串口已不太適合作為監視工具了。

此外，在USB設備的枚舉程序編寫中，我遇到的最大挑戰來自于8位單片機與16位單片機的結構上的差別，比如數據存取速度，數據高低字節的存放次序，數據類型與存放地址相關的特點等。從我前面列出的問題來看，大部分問題均源自于此；因此在學習某種單片機時，就要準確地掌握不同類型的MCU特性，這樣就一定可以降低開發難度，縮短開發時間。