沁恒USB2.0使用指北

遇到反饋最多的問(wèn)題是收不了數據,發(fā)不了數據。

?

多半是不清楚USB數據收發(fā)的機制導致。這里不做教學(xué),只講怎么用起來(lái)。

以CH554EVT.ZIP為代碼基礎,寄存器說(shuō)明參考CH554DS1.PDF

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

?

先總結:

?

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

?

因為這個(gè)被動(dòng),就會(huì )產(chǎn)生問(wèn)題:

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

2、上傳數據不能夠在主循環(huán)中拼命執行,因為可能上一包數據并沒(méi)有成功發(fā)送。





一、上傳

參考CH554EVT中CompatibilityHID.C

代碼功能是Ep2InKey為0就上傳固定數據,Ep2InKey為0就是P1.5接地。

為了實(shí)現穩定上傳,引入了Endp2Busy這一個(gè)全局變量(全局標志),該標志必須使用。

image.png

原因:USB是有應答的,USB設備作為“被動(dòng)的”一方,需要等主機把數據取走了之后才能發(fā)送下一包數據。所以在調用Enp2BlukIn();的同時(shí)置位標志,防止這次的上傳還沒(méi)有結束,下一

次循環(huán)又處理了緩沖區數據。


image.png

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

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



二、下傳

1、參考CH554EVT中VendorDefinedDev.C

2、代碼功能:主循環(huán)判斷從串口收一字節數據,對數據處理后通過(guò)端點(diǎn)1上傳。端點(diǎn)2可以接收USB主機下發(fā)的數據,對收到的數據取反然后上傳。即:

?

①由代碼實(shí)現的,端點(diǎn)2支持且支持:下傳上傳下傳上傳下傳上傳下傳上傳

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

端點(diǎn)應答狀態(tài)的寄存器說(shuō)明見(jiàn)下圖。

image.png

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


第一包數據下傳之后,下一包數據的上傳在下圖紅框處處理:

先是將數據填充到Ep2Buffer[MAX_PACKET_SIZE]處

然后將上傳數據包長(cháng)度填到UEP2_T_LEN寄存器

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

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

image.png

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

image.png

②由代碼實(shí)現的,端點(diǎn)1支持且支持:上傳上傳上傳上傳上傳上傳上傳上傳

這個(gè)端點(diǎn)1上傳功能類(lèi)似CompatibilityHID.C中的上傳,但是這里沒(méi)有加上全局標志,只要getkey()函數有返回值,就一直會(huì )刷新Ep1Buffer。所以這個(gè)上傳可能會(huì )出現上一包還沒(méi)有被電腦取走,下一包數據就又填到緩沖區里了,導致類(lèi)似數據出錯、錯位的問(wèn)題。

image.png


①端點(diǎn)2支持且支持:下傳上傳下傳上傳下傳上傳下傳上傳

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

怎么改善呢,CDC例程中使用其他端點(diǎn)可行嗎? 我用的芯片是CH571/573,感謝答復?。。?!


代碼實(shí)現效果,并非芯片硬件特性


只有登錄才能回復,可以選擇微信賬號登錄
97精品依人久久久大香线蕉97-亚洲欧美日韩一区二区三区-国产亚洲欧美精品久久久-久久99精品久久久大学生-亚洲成a人片在线不卡一二三区 97精品依人久久久大香线蕉97-亚洲欧美日韩一区二区三区-国产亚洲欧美精品久久久-久久99精品久久久大学生-亚洲成a人片在线不卡一二三区