我在應(yīng)用CH372中遇到了如下附件中的問題，請幫忙解決下！UploadImages/200961917362414.doc

延時(shí)肯定是不用加的，應(yīng)該是程序上的問題了，關(guān)于速度的，可參考\CH372EVT\PUB\CH375451.PDF：⑸、參考資料及例子 下載CH372EVT.ZIP，參考\CH372EVT\PUB\BULK下的上下位機(jī)測速程序流程

這個(gè)是流程出現(xiàn)問題了,你不需要主動(dòng)的去讀USB數(shù)據(jù),因?yàn)镸CU不知道什么時(shí)候數(shù)據(jù)會(huì)來,正確的方式是等待中斷,每次產(chǎn)生USB_INT_EP2_OUT:的中斷狀態(tài)就說明有數(shù)據(jù)了,需要去讀.所以您說的延時(shí)是不對的，所以基本可以判斷是您下位機(jī)出現(xiàn)問題了． 至于另外３６Ｓ哪去了，是因?yàn)槟挥?jì)算了延時(shí)，沒有計(jì)算數(shù)據(jù)通訊也是需要時(shí)間的． 至于數(shù)據(jù)沒有發(fā)完就返回了，就是因?yàn)樯衔粰C(jī)超時(shí)退出了，所以最小包是不確定的． . 為了能夠及時(shí)的給您解決問題您可以撥打電話:02552638370(下位機(jī)),02552638376(上位機(jī))

我看到了公司給提供的MCU程序，是采用中斷方式處理的?？墒俏覀兝习逶谠O(shè)計(jì)的系統(tǒng)中不允許中斷（為了不影響其他功能）所以采用的是查詢方式。而且我看了CH372 芯片資料上也支持查詢方式呀。我們設(shè)計(jì)的是上位機(jī)通過命令控制下位機(jī)工作，所以下位機(jī)初始時(shí)就是等待上位機(jī)發(fā)送命令，然后執(zhí)行相應(yīng)的操作（包括執(zhí)行各功能或返回?cái)?shù)據(jù)等，其中可能會(huì)有64K字節(jié)數(shù)據(jù)需要傳送）

理解上有問題,中斷方式和查詢方式?jīng)]有什么本質(zhì)區(qū)別.就是查詢一個(gè)引腳.是支持查詢方式,CH372有中斷事件就是把INT引腳拉低,至于你MCU里面是查詢還是中斷CH372不可能去關(guān)心的. 你必須查詢這個(gè)INT引腳是否有低電平,有低電平就說明有中斷,然后去處理中斷就可以了.肯定是你MCU端程序有問題.按照我們提供的中斷函數(shù)來寫,以免產(chǎn)生不必要的麻煩.

您好現(xiàn)在我由PC機(jī)下傳128個(gè)數(shù)據(jù)，用示波器測量CH372的INT引腳，發(fā)現(xiàn)始終為低電平導(dǎo)致程序陷入死循環(huán)。 在向CH372發(fā)送CMD_GET_STATUS命令后，INT引腳會(huì)自動(dòng)恢復(fù)高電平吧？INT引腳是在接到這個(gè)命令后就恢復(fù)還是要等待發(fā)送的數(shù)據(jù)（1包）完畢后在恢復(fù)呢？

發(fā)送CMD_GET_STATUS命令之后INT#引腳自動(dòng)拉高.如果是下傳128個(gè)數(shù)據(jù)的話,那么會(huì)產(chǎn)生2次中斷.每次中斷狀態(tài)都應(yīng)該為批量端點(diǎn)下傳數(shù)據(jù).

在發(fā)送128字節(jié)時(shí)測INT引腳始終為低電平，發(fā)送CMD_GET_STATUS命令后也不恢復(fù)，請幫忙解決下！十分感謝！ 這是我寫的初始化和接收程序，我們用的時(shí)philips的XA芯片 ;************************************************************** ;檢測ch372與ch372初始化程序：用到資源r0,r1,r3,r5,r6 ;r0發(fā)送測試數(shù)據(jù),r3回讀數(shù)據(jù)，r5數(shù)據(jù)端口地址,r6命令端口地址 ;************************************************************** ch372_check: push.w r0 push.w r1 push.w r3 push.w r5 push.w r6 push.b ES mov.b ES,#SYS_SEG

ch372_check1: mov.w r6,#USB_WR_CMD mov.w [r6],#CMD_CHECK_EXIST ;命令 mov.w r5,#USB_DATA_ACCESS mov.w r0,#0055h ;測試數(shù)據(jù) mov.w [r5],r0 ;發(fā)送數(shù)據(jù) mov.w r3,[r5] cpl.w r0 cmp.b r3l,r0l beq check jmp CH372_RESET check: jmp check_ok mov.b r1l,#50h ;用于多次重發(fā)命令 CH372_RESET: mov.w [r6],#CMD_RESET_ALL ;復(fù)位命令 ;加延時(shí)40ms djnz r1,CH372_RESET ;試驗(yàn)檢測能夠通過，所以沒加延時(shí) call point_led5 ;等閃爍指示CHECK沒通過 jmp ch372_check1

check_ok: pop.b ES pop.w r6 pop.w r5 pop.w r3 pop.w r1 pop.w r0 ret

;*********************************************************************** ;CH372初始化程序：所用資源：r5,r6,r0 ;r5數(shù)據(jù)端口地址，r6命令端口地址，r0回讀狀態(tài)數(shù)據(jù) ;*********************************************************************** ch372_init: push.w r5 push.w r6 push.b ES mov.b ES,#SYS_SEG mov.w r6,#USB_WR_CMD mov.w r5,#USB_DATA_ACCESS mov.w [r6],#CMD_SET_USB_MODE mov.w [r5],#02h ;發(fā)送工作模式 ch372_init1: mov.w r0,[r5] cmp.b r0l,#CMD_RET_SUCCESS ;初始化成功判斷 bne ch372_init1 pop.b ES pop.w r6 pop.w r5 ret

;******************************************************************* ;接收中斷:所用資源:r0,r1,r3,r4,r5,r6 ;r0讀回地址狀態(tài)數(shù)據(jù)以及接收數(shù)據(jù)長度，r3發(fā)送數(shù)據(jù)首地址 ;r4讀INTU數(shù)據(jù)地址，r5數(shù)據(jù)端口地址，r6命令端口地址 ;******************************************************************* my_receive: push.w r0 push.w r1 push.w r2 push.w r3 push.w r4 push.w r5 push.w r6 mov.b ES,#SYS_SEG mov.w r6,#USB_WR_CMD mov.w r5,#,#USB_DATA_ACCESS mov.w r4,#000eh ;掃描INT引腳的地址

mov.w r2,#1ffeh ;接收長度保存地址 mov.w [r2],#0000h ;先清零

receive1: mov.w r0,[r4] ;讀取該地址的內(nèi)容給r0，r0.0為int引腳 jb r0.0, receive1 ;不斷掃描int引腳 mov.w [r6],#CMD_GET_STATUS nop nop nop nop nop nop mov.w r0,[r5] ;讀回狀態(tài)判斷是什么中斷 nop nop nop nop cjne.b r0l, #USB_EP2_OUT, receive1 ;USB_EP2_OUT

ch372_down_ok: mov.w [r6],#CMD_RD_USB_DATA nop nop nop nop nop mov.w r0, [r5] mov.b r0h, #00h cmp.b r0l, #00h beq receive1 ;發(fā)送長度為0重新等待接收 mov.w r2, #1ffeh add.w [r2], r0 ;保存接收數(shù)據(jù)長度（1ffeh） ch372_down_1: mov.w r1, [r5] ;接受數(shù)據(jù) mov.b [r3+], r1l djnz.b r0l, ch372_down_1

call delay_30ms ;我們這里測試中要加入這段延時(shí)程序才能正常接收大于64字節(jié)的數(shù)據(jù)，不明白為什么？ mov.w r4, #000eh mov.w r0, [r4] ;接收后繼續(xù)判斷是否仍有接收的數(shù)據(jù)未完成 jb r0.0, receive_ret mov.w [r6],#CMD_GET_STATUS nop nop nop nop nop nop mov.w r0,[r5] ;讀回狀態(tài)判斷是什么中斷 nop nop nop nop cjne.b r0l,#02h,receive_ret ;USB_EP2_OUT jmp ch372_down_ok ;仍有數(shù)據(jù)繼續(xù)接收，否則推出 receive_ret: pop.w r6 pop.w r5 pop.w r4 pop.w r3 pop.w r2 pop.w r1 pop.w r0 ret

這是我在試驗(yàn)中編寫的程序，我們是不斷搜索INT引腳，不去響應(yīng)其他請求。幫忙看看由什么不對活不足之處，謝謝！?。。?/p>

首先如果你可以檢測到INT#引腳為低電平的話,那么,你就在那邊循環(huán)的發(fā)送0X22的命令(獲取中斷狀態(tài)命令),不去做任何事情,這樣你在看下INT#引腳會(huì)拉成高電平嗎?如果沒有的話,建議你還是先做測試命令,先發(fā)0X55數(shù)據(jù),看下返回的是否為0XAA,在發(fā)送0XAA數(shù)據(jù),看是否返回0X55.這樣才能確保你的并口硬件沒有任何問題

call delay_30ms 我們這里測試中要加入這段延時(shí)程序才能正常接收大于64字節(jié)的數(shù)據(jù)，不明白為什么？ mov.w r4, #000eh mov.w r0, [r4] ;接收后繼續(xù)判斷是否仍有接收的數(shù)據(jù)未完成 jb r0.0, receive_ret

發(fā)送128個(gè)字節(jié)應(yīng)該有兩次中斷產(chǎn)生的,不應(yīng)該接收完本次64字節(jié),然后馬上在取下面64字節(jié),我們在上面已經(jīng)說明了,你應(yīng)該不斷的去查詢INT腳,有中斷則去處理中斷,中斷中去讀取數(shù)據(jù),不應(yīng)該主動(dòng)的去讀數(shù)據(jù),而是有數(shù)據(jù)了才去讀,有數(shù)據(jù)過來,會(huì)中斷通知的.因?yàn)閿?shù)據(jù)過來是不定時(shí)的,可能會(huì)慢也可能會(huì)快,這跟總線空閑是有關(guān)系的.

看到樓主帖子中的實(shí)際需要，建議樓主考慮改用CH341，既可以大大地簡化程序，又能夠有效地解決實(shí)質(zhì)問題。

先謝謝各位，這幾天發(fā)現(xiàn)是硬件的有些問題，MCU晶振有點(diǎn)高導(dǎo)致讀寫地址時(shí)出錯(cuò)了，非常感謝各位！