|
U盤固件編程之三:合理的USB通訊調(diào)試方法和思路是成功的關鍵 在介紹更多細節(jié)內(nèi)容之前，我不得不談談我對USB調(diào)試方法的理解。 USB通訊過程是一個動態(tài)的過程，是不太好使用硬件仿真器來設斷點調(diào)試的，因為每一次USB的傳輸過程，都有時效要求，等待時間過長，通訊過程也就中止了。但也不排除可以巧妙地使用斷點仿真的方法進行調(diào)試。但個人認為，使用串口輔助編程過程，卻是一種經(jīng)濟有效的方法。 所謂用串口輔助調(diào)試過程，也就是在固件代碼中加入類似于Printf的語句，向串口輸出一些信息。這些信息可以是幾個字符（如A、B、C），或是某個變量或寄存器的值。程序運行到此處時，便會輸出這些信息，借此，便可以知道：1、程序是否運行到此處；2、運行到此處時相應變量或寄存器值。這不就是硬件仿真調(diào)試的功能么？ 如果想使用這種方式來調(diào)試，在硬件上必須增加一個RS232串口電平轉(zhuǎn)換芯片，而且所使用的MCU得要有串口，并且，一般要自己編寫Printf函數(shù)的實現(xiàn)方式。這個翻翻串口控制方面的書籍，很容易就可以搞定。 串口調(diào)試的方法，還可以推廣到其他的單片機應用中，在簡單系統(tǒng)中，它基本可以替代掉硬件仿真器，降低開發(fā)者的門檻和投資。 在USB通訊過程中，有兩個階段，一是通過端點0完成對設備的配置，在此階段，把從USB端點得到的數(shù)據(jù)輸出到串口，就對通訊所處的階段一目了然了。一旦完成配置階段，Bus Hound便可以粉墨登場了，因為此時，Bus Hound中已經(jīng)可以看到設備了，看到設備后，便可以選擇設備，對主機與此設備間的通訊數(shù)據(jù)進行分析和監(jiān)視。 串口調(diào)試和Bus Hound這兩種手段配合使用，可以使USB通訊過程的調(diào)試更加容易。比如，剛開始時，端點0的數(shù)據(jù)量本來就少，因此，使用串口調(diào)試比較方便。而對于Bulk端點的數(shù)據(jù)傳送過程，再使用串口就不太方便了，因為數(shù)據(jù)量大，串口輸出的數(shù)據(jù)太多，延時會比較嚴重，影響USB通訊過程，所以改用BUS HOUND來監(jiān)視USB總線上的數(shù)據(jù)。這個時候很有趣的一件事情是，Bus Hound在PC機上，而串口實際上在單片機端。所以，利用這兩種手段，里應外合，有助于我們確定一方發(fā)時另一方收的數(shù)據(jù)是否正確。比如，單片機上發(fā)出的一組數(shù)，將其輸出到串口，然后看看Bus Hound上是否收到的是這些數(shù)，如果正確，則說明硬件通訊過程沒有問題，如果不正確，則說明通訊的某一方有問題，進一步可以定位此問題，排除之。 正確的調(diào)試思路，將使調(diào)試過程事半功倍。 比如，在調(diào)試端點0 的配置過程時，可以先用Switch...Case語句建立對于端點0的數(shù)據(jù)的分支響應，對照標準請求的數(shù)據(jù)格式，可以得到什么情況下是Get Device Descriptor，什么時候是Get Configuration Descriptor，每個分支處理時對應一個函數(shù)，在這個函數(shù)里向串口標志信息。這個工作完成以后，便一個一個地來處理請求，處理完一個后，主機會自動進入下一個階段，這時，通過串口可以看到相應的狀態(tài)，按步就班地一個一個處理余下的請求，即可完成端點0的設備配置過程的固件程序的編寫。 對于Bulk端點也是一樣，先建立程序框架，然后再一個一個地處理請求。這種自上而下，逐步求精的思路并不稀奇，在USB調(diào)試過程中十分受用。最忌一上來就處理請求，不講求結(jié)構(gòu)，不講求代碼的條理性，最后可能弄得自己都是一頭霧水。 |
|
|
來自： lchjczw > 《USB調(diào)試》
