用技術(shù)社區(qū)提供的CH559模擬CH9326例程程序，做的USB HID 讀卡器。電腦端口發(fā)送 SET idle 指令，設(shè)備無法識別。

現(xiàn)象：讀卡器插入后，設(shè)備管理器提示輸入設(shè)備，收發(fā)數(shù)據(jù)。過一段時(shí)間讀寫卡，提示描述符錯(cuò)誤，打開設(shè)備類在通用串行總線控制器中設(shè)備有黃色標(biāo)識。

問題如下：CH599如何實(shí)現(xiàn)HID設(shè)備set_idle響應(yīng)？官方例程是否有不完善地方？應(yīng)該怎么解決這個(gè)問題？

屏蔽len = 0xFF; 即可

Many of the examples including also their bootloaders have a bug which results in wrong behavour after an unsuported Setup request. When a Setup ocures any possible Stall from previous requests has to bei cleared. Spec requires that.

From the trace it looks like you run into this case. Idle is not supported and fails. Also the next setup fails. Then it works again....

I reported this bug a long time ago but nothing changed.

Solution:

case SETUP:

? ? ? ? ? UEP0_CTL &= 0xF2;

? ? ? ? ? ......

作為hid設(shè)備不是每條類命令都是強(qiáng)制回復(fù)的，所以例程中只做了標(biāo)準(zhǔn)請求的處理，setidle不回復(fù)也是不影響枚舉過程的。當(dāng)然你在處理非標(biāo)準(zhǔn)請求的過程中將len等于0xff去掉，讓它不回復(fù)stall也可以。這個(gè)例程是做一個(gè)hid轉(zhuǎn)串口功能的簡單實(shí)現(xiàn)。

@WCH-IC

No thats not correct. The spec clearly states that the response to every unknown request has to be a STALL handshake.

When you check the trace you can see a reenumeration of the device? at 787.1.0. At 792.1.0 you can see that Getdesc(HID) fails because of the bug i am describing and therefore reenum fails.

How would you explain the STALL response to SetIdle at 791.2.0 when he never put len=0xFF; in the code.

代碼中做了判斷，如圖

屏蔽len = 0xff之后的抓包數(shù)據(jù)如下：