遇到反饋最多的問題是收不了數(shù)據(jù)，發(fā)不了數(shù)據(jù)。

?

多半是不清楚USB數(shù)據(jù)收發(fā)的機(jī)制導(dǎo)致。這里不做教學(xué)，只講怎么用起來。

以CH554EVT.ZIP為代碼基礎(chǔ)，寄存器說明參考CH554DS1.PDF

文中所有提到的代碼均以偽代碼形式，便于理解。

?

先總結(jié)：

?

USB設(shè)備片面的理解是“被動的”。USB主要就是上傳（IN事務(wù)，DEVICE->HOST）和下傳（OUT事務(wù)，HOST->DEVICE）。上傳的被動體現(xiàn)在設(shè)備準(zhǔn)備好需要上傳的數(shù)據(jù)之后，等著主機(jī)來將數(shù)據(jù)取走。下傳的被動體現(xiàn)在設(shè)備需要準(zhǔn)備好空閑的緩沖區(qū)，等著主機(jī)將數(shù)據(jù)發(fā)下來。數(shù)據(jù)什么時候流動，流動方向是什么，完全取決于主機(jī)，主機(jī)怎么控制數(shù)據(jù)流，取決于協(xié)議（這個協(xié)議包括標(biāo)準(zhǔn)USB CLASS協(xié)議，還有用戶自定交互流程）。

?

因為這個被動，就會產(chǎn)生問題：

1、什么時候才表示主機(jī)將數(shù)據(jù)取走了、什么時候主機(jī)已經(jīng)把數(shù)據(jù)發(fā)下來了。

2、上傳數(shù)據(jù)不能夠在主循環(huán)中拼命執(zhí)行，因為可能上一包數(shù)據(jù)并沒有成功發(fā)送。

一、上傳

參考CH554EVT中CompatibilityHID.C

代碼功能是Ep2InKey為0就上傳固定數(shù)據(jù)，Ep2InKey為0就是P1.5接地。

為了實現(xiàn)穩(wěn)定上傳，引入了Endp2Busy這一個全局變量（全局標(biāo)志），該標(biāo)志必須使用。

原因：USB是有應(yīng)答的，USB設(shè)備作為“被動的”一方，需要等主機(jī)把數(shù)據(jù)取走了之后才能發(fā)送下一包數(shù)據(jù)。所以在調(diào)用Enp2BlukIn();的同時置位標(biāo)志，防止這次的上傳還沒有結(jié)束,下一

次循環(huán)又處理了緩沖區(qū)數(shù)據(jù)。

在USB中斷函數(shù)中的case UIS_TOKEN_IN | 2:?? 處將標(biāo)志清除，也就是USB外設(shè)產(chǎn)生中斷，并且成功進(jìn)入這個case就表示2號端點的IN事務(wù)完成。

且代碼131行處，可以看到將端點2的發(fā)送（設(shè)備->主機(jī)）響應(yīng)狀態(tài)改成了NAK，這樣可以防止非主動的數(shù)據(jù)上傳。直到數(shù)據(jù)準(zhǔn)備好，我們會在主循環(huán)中調(diào)用Enp2BulkIn( )，將響應(yīng)狀態(tài)改成ACK，然后等著主機(jī)將數(shù)據(jù)取走。

二、下傳

1、參考CH554EVT中VendorDefinedDev.C

2、代碼功能：主循環(huán)判斷從串口收一字節(jié)數(shù)據(jù)，對數(shù)據(jù)處理后通過端點1上傳。端點2可以接收USB主機(jī)下發(fā)的數(shù)據(jù)，對收到的數(shù)據(jù)取反然后上傳。即：

?

①由代碼實現(xiàn)的，端點2支持且僅支持：下傳上傳下傳上傳下傳上傳下傳上傳

因為USB設(shè)備是“被動的”，所以只能等著主機(jī)在某個時候下傳數(shù)據(jù)，需要提前準(zhǔn)備好。初始化完確保UEP2_CTRL 寄存器對OUT事務(wù)的應(yīng)答狀態(tài)為“ACK”。只有響應(yīng)狀態(tài)為ACK，此時電腦嘗試下傳數(shù)據(jù)才能成功。?

端點應(yīng)答狀態(tài)的寄存器說明見下圖。

第一包數(shù)據(jù)主機(jī)下發(fā)成功之后，才會進(jìn)到USB中斷函數(shù)。

第一包數(shù)據(jù)下傳之后，下一包數(shù)據(jù)的上傳在下圖紅框處處理：

先是將數(shù)據(jù)填充到Ep2Buffer[MAX_PACKET_SIZE]處

然后將上傳數(shù)據(jù)包長度填到UEP2_T_LEN寄存器

最后將UEP2_CTRL寄存器的IN事務(wù)響應(yīng)狀態(tài)改成“ACK”

執(zhí)行完以上操作，接下來就是等著下一次進(jìn)USB中斷，正常情況下下一次進(jìn)USB中斷函數(shù)會進(jìn)入case UIS_TOKEN_IN | 2:???? 進(jìn)入這里表示完成了一次IN事務(wù)。

這樣的交互流程一定程度上做到了“同步”，也能夠保證持續(xù)的傳輸。所以，一發(fā)一收的流程絕對不能亂，不然就可能傳輸卡住。

②由代碼實現(xiàn)的，端點1支持且僅支持：上傳上傳上傳上傳上傳上傳上傳上傳

這個端點1上傳功能類似CompatibilityHID.C中的上傳，但是這里沒有加上全局標(biāo)志，只要getkey（）函數(shù)有返回值，就一直會刷新Ep1Buffer。所以這個上傳可能會出現(xiàn)上一包還沒有被電腦取走，下一包數(shù)據(jù)就又填到緩沖區(qū)里了，導(dǎo)致類似數(shù)據(jù)出錯、錯位的問題。

①端點2支持且僅支持：下傳上傳下傳上傳下傳上傳下傳上傳

這個手冊中有說明嗎？這樣的特性是不是意味著設(shè)備不能連續(xù)2次進(jìn)行IN操作，進(jìn)行一次IN操作后要主機(jī)觸發(fā)一次OUT操作，才能進(jìn)行下一下IN操作？ 我看cdc例程就是用的端點2，也就是設(shè)備端不能連續(xù)給PC發(fā)送報文是吧？

怎么改善呢，CDC例程中使用其他端點可行嗎？ 我用的芯片是CH571/573,感謝答復(fù)?。。?！

代碼實現(xiàn)效果，并非芯片硬件特性

USB\USBFS\DEVICE\CompatibilityHID

你好，我在使用CH32V307的這個例程，通過USB與上位機(jī)收發(fā)數(shù)據(jù)，發(fā)現(xiàn)每次只能收發(fā)64字節(jié)，這個可以改為任意長度嗎？比如上位機(jī)下發(fā)8字節(jié)，下位機(jī)上傳23字節(jié)。

如果有相關(guān)例程，請麻煩發(fā)我一份。個人信息保護(hù)，已隱藏