我的單片機(jī)程序里采用了以偽中斷方式上傳數(shù)據(jù)。 首先我根據(jù)一個(gè)標(biāo)志位判斷是否執(zhí)行以下程序，其中該標(biāo)志位是在中斷程序中讀到批量 端點(diǎn)上傳成功時(shí)被置1的。 清標(biāo)志位； CH375_WR_CMD (CMD_WR_USB_DATA7 );//向USB端點(diǎn)2的發(fā)送緩沖區(qū)寫入數(shù)據(jù)塊 CH375_WR_DAT( 2 ); //數(shù)據(jù)長(zhǎng)度 CH375_WR_DAT(data1); //數(shù)據(jù) CH375_WR_DAT(data2); //數(shù)據(jù) CH375_WR_CMD (CMD_WR_USB_DATA5 ); //向USB端點(diǎn)1的發(fā)送緩沖區(qū)寫入數(shù)據(jù)塊 CH375_WR_DAT(1); //數(shù)據(jù)長(zhǎng)度 CH375_WR_DAT(0x55); //USB中斷狀態(tài)碼 按上面這種程序，我的設(shè)想是單片機(jī)一直以偽中斷方式上傳數(shù)據(jù)，但現(xiàn)在的問題是數(shù)據(jù)上傳3，4次后，單片機(jī)中斷里沒讀到批量端點(diǎn)上傳成功，導(dǎo)致標(biāo)志位無法及時(shí)置1，所以后面的上傳程序無法被執(zhí)行了。請(qǐng)問這個(gè)問題會(huì)出在哪？

　最好把你的上位機(jī)程序貼出來看看

而且你說的這種方式,要先傳端點(diǎn)1的數(shù)據(jù),端點(diǎn)1上傳成功之后在上傳端點(diǎn)2的數(shù)據(jù),端點(diǎn)2上傳成功之后再傳端點(diǎn)1的數(shù)據(jù)

上傳數(shù)據(jù)流以偽中斷方式發(fā)起的系統(tǒng)中，計(jì)算機(jī)應(yīng)用層初始化時(shí)設(shè)置一個(gè)偽中斷服務(wù)程序，然后 應(yīng)用層就不需要再涉及到上傳數(shù)據(jù)流。當(dāng)單片機(jī)需要上傳數(shù)據(jù)時(shí)，首先將數(shù)據(jù)寫入批量端點(diǎn)的上傳緩 沖區(qū)中，然后將中斷特征數(shù)據(jù)寫入中斷端點(diǎn)的上傳緩沖區(qū)中。在1 毫秒之內(nèi)（理論值），與中斷特征 數(shù)據(jù)對(duì)應(yīng)的偽中斷服務(wù)程序被激活，偽中斷服務(wù)程序通知主程序調(diào)用數(shù)據(jù)上傳API獲得上傳數(shù)據(jù)塊。 在此期間，單片機(jī)將會(huì)收到CH372 芯片通知的兩次中斷，首先是中斷端點(diǎn)上傳成功中斷，然后是批量 端點(diǎn)上傳成功中斷。

我的程序是按上面說的方式發(fā)生數(shù)據(jù)的，現(xiàn)在主要是單片機(jī)收到CH372芯片的中斷不是很穩(wěn)定，有時(shí)候會(huì)收不到中斷

首先是通過中斷端點(diǎn)(端點(diǎn)1)傳數(shù)據(jù),中斷端點(diǎn)上傳成功中斷之后，然后再往批量端點(diǎn)寫數(shù)據(jù),等到批量端點(diǎn)上傳成功之后再傳下一次數(shù)據(jù),還有PC機(jī)中的中斷服務(wù)程序不要做太多費(fèi)時(shí)的操作,一般都是發(fā)個(gè)消息,然后在消息響應(yīng)中做相應(yīng)處理(一般是讀端點(diǎn)2的數(shù)據(jù))

首先是通過中斷端點(diǎn)(端點(diǎn)1)傳數(shù)據(jù),中斷端點(diǎn)上傳成功中斷之后，然后再往批量端點(diǎn)寫數(shù)據(jù),等到批量端點(diǎn)上傳成功之后再傳下一次數(shù)據(jù),還有PC機(jī)中的中斷服務(wù)程序不要做太多費(fèi)時(shí)的操作,一般都是發(fā)個(gè)消息,然后在消息響應(yīng)中做相應(yīng)處理(一般是讀端點(diǎn)2的數(shù)據(jù))

謝謝樓上的兄弟，請(qǐng)問PC機(jī)中的中斷服務(wù)程序發(fā)消息怎么發(fā)啊，我VC++用的不熟，能貼下源碼嗎

如果用vc的話,可以使用多線程查詢的方式,這樣效率高.下面這個(gè)是中斷回調(diào)的方式 UploadImages/20091138452752.rar

謝謝，先學(xué)習(xí)下

我按 首先是通過中斷端點(diǎn)(端點(diǎn)1)傳數(shù)據(jù),中斷端點(diǎn)上傳成功中斷之后，然后再往批量端點(diǎn)寫數(shù)據(jù),等到批量端點(diǎn)上傳成功之后再傳下一次數(shù)據(jù),還有PC機(jī)中的中斷服務(wù)程序不要做太多費(fèi)時(shí)的操作,一般都是發(fā)個(gè)消息,然后在消息響應(yīng)中做相應(yīng)處理(一般是讀端點(diǎn)2的數(shù)據(jù)) 這個(gè)方法試驗(yàn)了下，發(fā)現(xiàn)CH372產(chǎn)生的中斷還是很沒規(guī)律，有時(shí)候會(huì)中斷，有時(shí)候死活都不中斷，導(dǎo)致無法判斷是否發(fā)送成功，郁悶啊

上傳數(shù)據(jù)流以偽中斷方式發(fā)起的系統(tǒng)中，計(jì)算機(jī)應(yīng)用層初始化時(shí)設(shè)置一個(gè)偽中斷服務(wù)程序，然后 應(yīng)用層就不需要再涉及到上傳數(shù)據(jù)流。當(dāng)單片機(jī)需要上傳數(shù)據(jù)時(shí)，首先將數(shù)據(jù)寫入批量端點(diǎn)的上傳緩 沖區(qū)中，然后將中斷特征數(shù)據(jù)寫入中斷端點(diǎn)的上傳緩沖區(qū)中。在1 毫秒之內(nèi)（理論值），與中斷特征 數(shù)據(jù)對(duì)應(yīng)的偽中斷服務(wù)程序被激活，偽中斷服務(wù)程序通知主程序調(diào)用數(shù)據(jù)上傳API獲得上傳數(shù)據(jù)塊。 在此期間，單片機(jī)將會(huì)收到CH372 芯片通知的兩次中斷，首先是中斷端點(diǎn)上傳成功中斷，然后是批量 端點(diǎn)上傳成功中斷。 這里提到的“CH372 芯片通知的兩次中斷”，我覺得這兩次中斷很不穩(wěn)定

首先,CH372 芯片通知的兩次中斷,是CH372向指單片機(jī)產(chǎn)生的兩次中斷,一個(gè)是中斷端點(diǎn)(端點(diǎn)1)上傳成功,一個(gè)是批量端點(diǎn)(端點(diǎn)2)上傳成功;上位機(jī)的偽中斷其實(shí)并不是中斷,只是下位機(jī)向上位機(jī)通報(bào)有數(shù)據(jù)到來的一種機(jī)制,其實(shí)現(xiàn)原理是,CH375SetIntRoutine在動(dòng)態(tài)庫中創(chuàng)建了一個(gè)優(yōu)先級(jí)比較高的線程在不停的讀端點(diǎn)1的數(shù)據(jù),如果這個(gè)線程讀到端點(diǎn)1數(shù)據(jù)的的話,那么他將調(diào)用CH375SetIntRoutine設(shè)置的中斷服務(wù)回調(diào)函數(shù),CH372向端點(diǎn)1中寫數(shù)據(jù),其實(shí)就是向pc通知有數(shù)據(jù)到了,向端點(diǎn)2寫的數(shù)據(jù)一般就是所要上傳的數(shù)據(jù),所以上位機(jī)讀到端點(diǎn)1的數(shù)據(jù)就會(huì)調(diào)用設(shè)置的回調(diào)函數(shù).回調(diào)函數(shù)其實(shí)是在CH375SetIntRoutine創(chuàng)建的線程中執(zhí)行的,而線程的優(yōu)先級(jí)比較高不易做費(fèi)時(shí)的操作,一般就是發(fā)送消息或是激活系統(tǒng)的事件,這樣在消息的處理中做一些讀端點(diǎn)2的操作和對(duì)數(shù)據(jù)的處理,第8樓中的例子中有上位機(jī)和下位機(jī)的代碼,可以參考一下.

CH372 中斷問題搞了好久還是沒能搞定，崩潰了， 幫幫看看我的程序倒底哪錯(cuò)了。 我的目的很簡(jiǎn)單，下位機(jī)以偽中斷方式通知PC機(jī)接數(shù)據(jù)，可就是不穩(wěn)定，有時(shí)可以收到數(shù)據(jù)，有時(shí)上位提示設(shè)備拔出。 批量下傳和上傳都沒問題，線沒問題。

MCU STC12C5410AD 24M晶振

附件：下位機(jī)程序keil C 和 VB上位機(jī)程序 UploadImages/20091151545622.zip

搞定了，搞定了是時(shí)序問題

請(qǐng)問你說的時(shí)序問題是怎么回事？能不能詳細(xì)解釋一下？謝謝