U盤固件編程之三:合理的USB通訊調(diào)試方法和思路是成功的關(guān)鍵 - USB固件編程學(xué)習(xí)

　　在介紹更多細(xì)節(jié)內(nèi)容之前，我不得不談?wù)勎覍SB調(diào)試方法的理解。USB通訊過程是一個動態(tài)的過程，是不太好使用硬件仿真器來設(shè)斷點調(diào)試的，因為每一次USB的傳輸過程，都有時效要求，等待時間過長，通訊過程也就中止了。但也不排除可以巧妙地使用斷點仿真的方法進行調(diào)試。但個人認(rèn)為，使用串口輔助編程過程，卻是一種經(jīng)濟有效的方法。所謂用串口輔助調(diào)試過程，也就是在固件代碼中加入類似于Printf的語句，向串口輸出一些信息。這些信息可以是幾個字符(如A、B、C)，或是某個變量或寄存器的值。程序運行到此處時，便會輸出這些信息，借此，便可以知道：1、程序是否運行到此處;2、運行到此處時相應(yīng)變量或寄存器值。這不就是硬件仿真調(diào)試的功能么?如果想使用這種方式來調(diào)試，在硬件上必須增加一個RS232串口電平轉(zhuǎn)換芯片，而且所使用的MCU得要有串口，并且，一般要自己編寫Printf函數(shù)的實現(xiàn)方式。這個翻翻串口控制方面的書籍，很容易就可以搞定。

　　串口調(diào)試的方法，還可以推廣到其他的單片機應(yīng)用中，在簡單系統(tǒng)中，它基本可以替代掉硬件仿真器，降低開發(fā)者的門檻和投資。在USB通訊過程中，有兩個階段，一是通過端點0完成對設(shè)備的配置，在此階段，把從USB端點得到的數(shù)據(jù)輸出到串口，就對通訊所處的階段一目了然了。一旦完成配置階段，Bus Hound便可以粉墨登場了，因為此時，Bus Hound中已經(jīng)可以看到設(shè)備了，看到設(shè)備后，便可以選擇設(shè)備，對主機與此設(shè)備間的通訊數(shù)據(jù)進行分析和監(jiān)視。串口調(diào)試和Bus Hound這兩種手段配合使用，可以使USB通訊過程的調(diào)試更加容易。比如，剛開始時，端點0的數(shù)據(jù)量本來就少，因此，使用串口調(diào)試比較方便。而對于Bulk端點的數(shù)據(jù)傳送過程，再使用串口就不太方便了，因為數(shù)據(jù)量大，串口輸出的數(shù)據(jù)太多，延時會比較嚴(yán)重，影響USB通訊過程，所以改用BUS HOUND來監(jiān)視USB總線上的數(shù)據(jù)。這個時候很有趣的一件事情是，Bus Hound在PC機上，而串口實際上在單片機端。所以，利用這兩種手段，里應(yīng)外合，有助于我們確定一方發(fā)時另一方收的數(shù)據(jù)是否正確。比如，單片機上發(fā)出的一組數(shù)，將其輸出到串口，然后看看Bus Hound上是否收到的是這些數(shù)，如果正確，則說明硬件通訊過程沒有問題，如果不正確，則說明通訊的某一方有問題，進一步可以定位此問題，排除之。正確的調(diào)試思路，將使調(diào)試過程事半功倍。比如，在調(diào)試端點0 的配置過程時，可以先用Switch...Case語句建立對于端點0的數(shù)據(jù)的分支響應(yīng)，對照標(biāo)準(zhǔn)請求的數(shù)據(jù)格式，可以得到什么情況下是Get Device Descriptor，什么時候是Get Configuration Descriptor，每個分支處理時對應(yīng)一個函數(shù)，在這個函數(shù)里向串口標(biāo)志信息。這個工作完成以后，便一個一個地來處理請求，處理完一個后，主機會自動進入下一個階段，這時，通過串口可以看到相應(yīng)的狀態(tài)，按步就班地一個一個處理余下的請求，即可完成端點0的設(shè)備配置過程的固件程序的編寫?！τ贐ulk端點也是一樣，先建立程序框架，然后再一個一個地處理請求。這種自上而下，逐步求精的思路并不稀奇，在USB調(diào)試過程中十分受用。最忌一上來就處理請求，不講求結(jié)構(gòu)，不講求代碼的條理性，最后可能弄得自己都是一頭霧水

　　U盤固件編程之四:玩轉(zhuǎn)你的端點

　　接上面hewx，我來談?wù)劧它c的問題。前面提到過，端點是由USB設(shè)備端的接口芯片決定的。你選擇了什么樣的芯片，那么端點的配置情況屬性就已經(jīng)決定了，你只能使用將就這些特定的情況。這些端點的配置，具體要參考你所使用的接口芯片的芯片資料，比如說，端點0當(dāng)然都為控制端點，其MaxPacketSize可能為8，16，32，64;端點1可能是Bulk-In端點，2是Bulk-Out端點，其字長也有可能是8，16，32，64，但一般是64。其他端點可能有同步端點，或者同一端點既可被配置成同步傳輸方式，也可以工作在Bulk傳輸方式下，等等，不一而足。USB協(xié)議精妙之處就在于枚舉過程。主機最初發(fā)過來的包，一定是8個字符長的。所以，你的端點的MaxPacketSize至少必須是8，能滿足與主機之間最基本的通訊過程。對于主機的第一個請求Get Device Descriptor，你也只用回復(fù)8個字符就OK了，因為主機在第一次只對這8個字符感興趣，在后面逐漸的獲取描述符的過程中，主機逐漸得到設(shè)備使用那些端點，每個端點的最大字長(這些內(nèi)容在Endpoint Descriptor中，通過Configuration Descriptor提供)是多少，等等，總之，通過枚舉，主機便知道你的端點的情況了，以后就會用這些端點來與設(shè)備進行通訊。對于Hewx的問題，我想是你在Endpoint Descriptor中沒有正確進行端點的設(shè)置，因為，如果進行了正確的端點配置，主機是會自動通過Bulk端點來發(fā)Inquiry命令的，而不會從你說的Endpoint1(16B)來發(fā)送這一信息。而且，主機會自動對要發(fā)送的信息進行分割，每次以不高于相應(yīng)端點的MaxPacketSize長度來發(fā)送。除了描述符中要給出正確的端點描述符的描述，有些時候在芯片中也需要設(shè)備相應(yīng)的控制位，在決定你要使用哪些及如何使用這些端點，這個也得根據(jù)具體的芯片資料來設(shè)置。

　　U盤固件編程之四:玩轉(zhuǎn)你的端點(增補)

　　對于某種設(shè)備來說，需要使用到的端點是固定的。比如說，Mass Storage設(shè)備吧，就只需要用到一個Bulk-In端點和一個Bulk-Out端點。而不需要幾個此類端點。至于到底需要幾個端點，完全需要根據(jù)有關(guān)協(xié)議中的說明進行，描述符也據(jù)此進行提供，而不是沒有根據(jù)地在描述符中提供許多端點。至于哪些端點可以做何種方式來使用，這也要看接口芯片的資料，比如，很可能，有的端點只能用作同步方式，那你就不要勉強將其用作批量方式，控制端點就只能用作控制傳輸方式，就不能為同步方式......搞清楚這個概念，在固件編程中才好正確地提供描述符。