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