我在PC機(jī)端使用了函數(shù)CH375WriteData(ULONG iIndex,PVOID iBuffer,PULONG ioLength);其中ioLength=4096，每次下傳4K的數(shù)據(jù)，在單片機(jī)端，當(dāng)我使用CH372時，接受到數(shù)據(jù)后，會產(chǎn)生中斷，每次包大小為64字節(jié)，讀出一個64后，還會有下一個64包的中斷，直到4K數(shù)據(jù)全部下傳完 問題是：當(dāng)我把372換成了374，PC機(jī)端也調(diào)用同樣的函數(shù)，也是下傳4K的數(shù)據(jù)，可是單片機(jī)端只收到一個64字節(jié)的包后，就沒有中斷了，請問是374不支持這樣的處理嗎？

當(dāng)然支持了,這和你下位機(jī)程序有關(guān),收到數(shù)據(jù)后要應(yīng)答ACK,切換同步標(biāo)志后,才可以的.接收到第一包數(shù)據(jù)后,然后:

Write374Byte( REG_USB_ENDP2, M_SET_EP2_TRAN_ACK( Read374Byte( REG_USB_ENDP2 ) ) ^ BIT_EP2_RECV_TOG ); ,PC收到ACK后繼續(xù)下傳數(shù)據(jù).

我這樣又試了： PC先向下發(fā)送了一個小于64字節(jié)的包，下位機(jī)程序收到后應(yīng)答ACK,即： Write374Byte( REG_USB_ENDP2, M_SET_EP2_TRAN_ACK( Read374Byte( REG_USB_ENDP2 ) ) ^ BIT_EP2_RECV_TOG ); 然后再下傳了一個大于64字節(jié)的包，下位機(jī)程序產(chǎn)生中斷了，但只有一次，應(yīng)該有兩次才對吧？ 如果讓我自己把一個很大的包分成一個個64字節(jié)的小包再向下傳，速度就會影響很大。

發(fā)送一次就產(chǎn)生一次中斷,每次傳輸?shù)臄?shù)據(jù)包不能大于64,因為374的端點只有64.ioLength>64的時候,會分為64個字節(jié)一個包,進(jìn)行傳輸. 為了驗證問題,你用TEST程序進(jìn)行測試,PC發(fā)送的數(shù)據(jù),取反后上傳給PC,下位機(jī)用CH374EVT.ZIP中的DEVICE.C就可以.如果PC沒有接收到正確數(shù)據(jù),說明下位機(jī)代碼有問題. 同時你可以把你的下位機(jī)代碼發(fā)送到tech@wch.cn郵箱,我們看一下

我就是想利用 “ioLength>64的時候,會分為64個字節(jié)一個包,進(jìn)行傳輸 ”我理解這是你們PC機(jī)端的驅(qū)動分的包吧，這樣比我自己分效率要高。 下位機(jī)我用的仿真器，與上位機(jī)對比可以看到下位機(jī)收到的數(shù)據(jù)是正確的，可不知為什么就只產(chǎn)生一次中斷

哦，我發(fā)現(xiàn)在PC機(jī)端CH375WriteData執(zhí)行后，返回的ioLength長度就是64！就是只成功下傳了64個字節(jié)，查看下位機(jī)程序，把設(shè)置的斷點換了個位置，PC機(jī)端返回的ioLength長度就正確了，應(yīng)該是我的斷點延誤了時間，這好像是PC機(jī)端大于64字節(jié)的數(shù)據(jù)分成64字節(jié)下傳也是有時間限制的吧？恩，我就按照這個思路向下調(diào)了，謝謝你！

確實是有時間限制，如果下位機(jī)時單步調(diào)試，那么很容易使上位機(jī)產(chǎn)生超時，從而只產(chǎn)生一次中斷。 調(diào)試USB通訊，仿真器必須全速運行或者脫機(jī)運行?？梢杂么诒O(jiān)視程序運行，但串口波特率要高一些，且數(shù)據(jù)量不能過大，否則也會影響USB通訊 另， （1）下載CH372DBG.ZIP，用于調(diào)試您的下位機(jī) （2）上位機(jī)可用3樓提供程序測試

恩，學(xué)習(xí)了！