很多STM32開發者在實現CDC類虛擬串口與PC主機通信過程中，有時會遇到點麻煩而不得其解。那就是當主機端單次發送的數據不超過64字節時，接收正常。一旦發送數據量大于64字節時就接收失敗，總是出現丟包現象，似乎只能接收64字節以內的數據。網上有人干脆建議主機每次發送不要超過64字節，當然，也有人提及要作分包處理但沒具體實現代碼可以參考。

作為CDC類的USB設備，到底能不能正確接收來自主機64字節以上的批量數據呢？

其實是可以的，只是當我們一次傳輸的數據大于當前端點所支持的最大包長時【這里端點使用BULK傳輸，一般最大包長默認設置為64字節】，USB模塊會做分包傳輸，將一批數據傳輸分成多個處理[或稱事務]，即多個transaction來完成，每個Transaction里的數據包傳輸的最大數據量為64字節。

原理性的東西，這里不多啰嗦了，網上有成堆的介紹資料【當然，或許有點亂】。當我們弄清整個原理后，就可以自行組織接收處理代碼了。下面我利用HAL庫，基于STM32F429芯片演示實現過程，重點在接收處理代碼。我使用STM32F429Discovery開發板，使用HSUSB模塊并令其工作在FSMODE，這樣我們就可以方便地使用片內USBFS PHY。

我使用STM32CubeMx工具進行配置，生成基于STM32 HAL庫的工程。使用ST提供的STM32CubeIDE進行編譯調試。有關配置就不截圖了。

另外，我還配置了1個按鍵并開啟相應外部中斷。每發生按鍵事件時，F429USB設備向PC主機發送一段打招呼的字符串，并通過串口助手顯示出來。如下圖所示：

我在main.c文件里額外定義了下面幾個變量：

其中，Flag_KeyPressed和Flag_DataReceived分別表示按鍵操作和收到從主機發過來的數據的情況。Rx_buffer【】數組用來存放接收來自主機的全部數據，這里的定義長度為512字節【你具體使用時按需設置】。下圖是Main.c里的主循環代碼截圖：

主循環里檢查按鍵標志和收到數據的標志，如有按鍵發生，則向主機發送前面提到的打招呼的字符串；如有收到來自主機的數據，則向主機回送過去。

今天的重點是討論USB設備如何從主機接收64字節以上的數據。基于現有HAL庫，對于USB設備的接收，我們只需關注一個USB中斷接收回調函數，那就是CDC_Receive_HS（）函數。該函數在usbd_cdc_if.c文件里。我具體編寫的函數代碼如下面兩幅截圖所示。

代碼很簡單。 我在庫代碼的基礎上增加了橙色方框內的代碼。基本功能就是，先讀取當前收到的數據長度【SinglePackLength】，分整包和非整包兩種情況鑒別后再處理。若是接收的整包數據，繼續等待接收下一包；若是非整包，視為此次傳輸結束，并設置收到標志Flag_DataReceived為非0值，然后在主循環里將收到的數據回送給主機。

其中，Max_Pack_Size是當前CDC類BULK傳輸端點的最大傳輸包長，這里為64字節。

Num_Rx_Data表示接收到數據個數，Num_Out_Pack表示接收到的數據包個數，Num_Packet跟Num_Out_Pack內容一樣，不過，Num_Packet等于0還表示準備開始新一輪傳輸的接收。這里多定義Num_Out_Pack，一個重要目的是便于調試時查看結果。

基于上面的接收處理代碼，我們來驗證結果：

借助PC端的串口助手向STM32F429 USB設備發送了5個字符，我們通過STM32CubeIDE調試環境可以清晰地從上圖看到設備收到的數據個數為5，數據包個數為1。顯然沒問題。那個Rx_buffer數組是我用來存放接收數據的，若在調試窗口打開，數據較多列表顯示會很長，這里就沒打開了。事實上接收的數據內容也是沒問題的。

下圖是借助PC端的串口助手向STM32F429 USB設備發送了305個字符的接收情況：

顯然，對于305個字符，PC主機端要分成5包才能發送完畢，即4整包【每包64字節】再加1個非完整包。所以USB設備接收結果也正好是5包，即上圖中Num_Out_pack的數據，接收到的數據量為305，即上圖中Num_Rx_Data的數據。同樣，結果OK。

下圖是PC端剛好發送一個完整包64字節數據的USB設備接收情況，也一切正常。

也就是說，使用我上面編寫的接收處理代碼，對主機發送的數據的個數不再局限于64字節以內了。當然，具體應用時我們還可以根據主機端單次傳輸數據的大小情況及提取數據的方式適當調整這里的Rx_buffer[]數組大小。【注：上面測試時我臨時關閉了設備端的數據回送功能，是為了避免截圖里的數據混亂，讓人分不清原數據和回顯數據】

有人可能在上面的接收代碼里看到了一個變量Wait_Rx_Dly。剛開始，代碼里是沒有這個變量的。后來我在測試主機發送64字節整包數據時，發現了一個小問題【最終到底算不算問題，或許要視具體應用場景而定，我這里稍作了點處理】。

問題是這樣的：

主機每發送1包64字節數據時,設備端接收沒有問題，但只要主機端每次發送64字節完整數據包過來，不論相隔時間多久，設備端依然接收，且總在前次結果上累加，除非主機端發一個非64字節數據包過來，設備接收就總是視為同一次傳輸。比方像下面截圖所示：

上圖就是PC主機端借助串口助手分四次且每次發送64字節數據時USB設備的接收情況。從圖上不難看出，4次數據都匯集在一起了，關鍵還沒完，還在等待后續數據過來。我是希望一次傳輸做一次處理，于是我讓設備每收到一個完整數據包，就重新給定一個延時，比方3~5ms，用變量Wait_Rx_Dly來記錄延時值，在某毫秒定時中斷里對該變量做減1操作。若延時到了還沒有收到數據或延時過程中收到非完整包則視為本次傳輸結束，然后去處理剛才收到的數據。

我順便使用了HAL庫里自帶的systick中斷函數來做這個延時管理。當接收處理代碼加上這個延時管理后，就不會出現不同傳輸批次的數據擠在一塊了。問題得以解決。

另外，我上面分享的接收處理代碼也有很好的通用性，并不局限于Bulk傳輸。我們知道，不同傳輸類型的端點的最大包長往往并不一樣，如果使用上面的參考代碼，我們只需調整那個最大包長參數【Max_Pack_Size】，并適當調整Rx_buffer[]數組的大小就可以使用了。數據個數、傳輸包個數這些變量都可以保留使用。

那段接收處理代碼很簡單，看懂了都可以自行組織編寫。順便說下，我使用的STM32F4系列的Cube庫版本為STM32F4xx HALV1.8.1。好，今天的話題就分享到這里，希望幫到有需要的人。祝君好運！

審核編輯：湯梓紅