各位高手，我在做CH372芯片連續(xù)發(fā)送接收數(shù)據(jù)時(shí)出現(xiàn)了一點(diǎn)小問題，請(qǐng)教下： 我們運(yùn)用CH372芯片做連續(xù)發(fā)送接收40K的數(shù)據(jù)都沒問題而且速度也很快，但當(dāng)我們把數(shù)據(jù)變成4096以下的是數(shù)據(jù)時(shí)，就變得非常慢（其中我們?cè)O(shè)置的上層接收發(fā)送超時(shí)為2S，結(jié)果下傳10個(gè)數(shù)據(jù)在回讀10個(gè)數(shù)據(jù)要2.5S左右，而將超時(shí)設(shè)置為1ms時(shí)就很快的完成，基本不消耗時(shí)間!）請(qǐng)幫忙解決下這個(gè)問題!謝謝！！

這個(gè)應(yīng)該不是問題,你設(shè)置超時(shí)時(shí)間比較長(zhǎng),會(huì)等到收滿4096才退出.你原來連續(xù)發(fā)送的時(shí)候,最后一個(gè)包也慢如果你設(shè)的超時(shí)時(shí)間也是2S的話,你可以實(shí)驗(yàn)一下. 把時(shí)間設(shè)短一點(diǎn)就可以了.

上傳時(shí)設(shè)置1MS時(shí),你讀的時(shí)候數(shù)據(jù)很有可能沒有到4096,超時(shí)應(yīng)該設(shè)置長(zhǎng)一點(diǎn),在用CH375ReadDate讀數(shù)據(jù)返回的時(shí)候,要判斷一下CH375ReadDate的第三個(gè)參數(shù),這個(gè)參數(shù)會(huì)被修改成實(shí)際讀到的數(shù)據(jù)長(zhǎng)度!

現(xiàn)在我們?cè)O(shè)置傳送數(shù)據(jù)為40930（36894）最后一包不滿，但傳送的結(jié)果和傳40960基本一樣（0.5s左右），都不會(huì)出現(xiàn)當(dāng)發(fā)送數(shù)據(jù)小于4096時(shí)的現(xiàn)象啊?。?/p>

現(xiàn)在我們?cè)跍y(cè)量中發(fā)現(xiàn)不是上傳的問題，上傳數(shù)據(jù)沒問題很快，是下傳時(shí)不夠4096個(gè)數(shù)據(jù)會(huì)超時(shí)。

哦 不好意思

讀寫返回的時(shí)候都要判斷第3個(gè)參數(shù)是不是與調(diào)用前一樣,返回后的值是實(shí)際讀寫到的數(shù)據(jù)長(zhǎng)度. 是不是只要發(fā)4096以下的數(shù)據(jù)都會(huì)超時(shí),如果是,可能要查一下下位機(jī).

我們已經(jīng)對(duì)于數(shù)據(jù)長(zhǎng)度已經(jīng)和第三個(gè)參數(shù)進(jìn)行了判斷?，F(xiàn)在的具體現(xiàn)象是這樣的： 1） 只要下傳數(shù)據(jù)超出4096，不會(huì)受超時(shí)設(shè)置參數(shù)影響，下傳數(shù)據(jù)長(zhǎng)度我們用30、64、4096、40126、36894、40960，均試驗(yàn)過，得到的結(jié)果就是低于4096(不含)則設(shè)置的超時(shí)參數(shù)就是我們的下傳、接收時(shí)間間隔(加上傳輸時(shí)間)； 2） 超時(shí)設(shè)置接口時(shí)間的參數(shù)讀寫超時(shí)，你們的接口說明可能是說反了，前一個(gè)應(yīng)該是讀數(shù)據(jù)超時(shí)參數(shù)，后一個(gè)應(yīng)該是寫數(shù)據(jù)超時(shí)，因?yàn)槲覀冏鲈囼?yàn)的時(shí)候，將前一個(gè)數(shù)據(jù)改短，對(duì)于測(cè)試速度不受影響，后一個(gè)改短則速度受影響。下面我會(huì)將理由說明。當(dāng)然可能有我們對(duì)于超時(shí)理解的偏差，如果是，還請(qǐng)指正。 3）我們?cè)谟布显O(shè)置了4個(gè)發(fā)光二極管，下位機(jī)接收數(shù)據(jù)時(shí)2、4燈亮，下位機(jī)發(fā)送數(shù)據(jù)時(shí)1、3燈亮，全速運(yùn)行(上層下傳數(shù)據(jù)、然后再將發(fā)送的數(shù)據(jù)上傳回來，循環(huán)進(jìn)行該過程)，結(jié)果是2、4燈幾乎常亮，這說明底層上傳數(shù)據(jù)時(shí)時(shí)間極短，才會(huì)造成該現(xiàn)象，因此我們可以確定是下傳時(shí)不足4096字節(jié)時(shí)速度受到影響，而再2）中對(duì)此有影響的是讀超時(shí)參數(shù)。 4）4096個(gè)數(shù)據(jù)應(yīng)該是上層接口使用的緩沖區(qū)，和下位機(jī)應(yīng)該沒有關(guān)系，下位機(jī)每次最多只接收64字節(jié)，如此循環(huán)，因此應(yīng)該和下位機(jī)軟件無關(guān)。不知道這個(gè)分析是否正確？

讀寫最大緩沖區(qū)是4096!不要超過4096!

BOOL WINAPI CH375SetTimeout( // 設(shè)置USB數(shù)據(jù)讀寫的超時(shí) ULONG iIndex, // 指定CH375設(shè)備序號(hào) ULONG iWriteTimeout, // 指定USB寫出數(shù)據(jù)塊的超時(shí)時(shí)間,以毫秒mS為單位,0xFFFFFFFF指定不超時(shí)(默認(rèn)值) ULONG iReadTimeout ); // 指定USB讀取數(shù)據(jù)塊的超時(shí)時(shí)間,以毫秒mS為單位,0xFFFFFFFF指定不超時(shí)(默認(rèn)值)

我們?cè)诎l(fā)送與接收超過4096的數(shù)據(jù)是將其分成多個(gè)4096數(shù)據(jù)下傳的，例如40960我們分成10個(gè)4096下傳。 超時(shí)iWriteTimeout，iReadTimeout的設(shè)置與我在7樓中提到的恰好相反，我們通過LED觀察到的是下傳時(shí)超時(shí)，可是我們將iReadTimeout改小后會(huì)影響接收與發(fā)送的時(shí)間，而改變iWriteTimeout卻沒什么影響。

CH375SetTimeout第2個(gè)參數(shù)是設(shè)置寫超時(shí),第3個(gè)參數(shù)是設(shè)置讀超時(shí),這個(gè)是正確的! "iReadTimeout改小后會(huì)影響接收與發(fā)送的時(shí)間",你們這個(gè)時(shí)間是怎么計(jì)算的?是讀寫的總時(shí)間?如寫沒有問題,讀有問題,那肯定就是iReadTimeout會(huì)"影響接收與發(fā)送的時(shí)間".

時(shí)間是完成下傳與上傳1次后取下系統(tǒng)時(shí)間并顯示出來。 以下是我底層的主循環(huán)程序： LOOP: MOV.W R1,#0005H CALL WRITELED ;點(diǎn)亮LED2，4 MOV.W R3,#DATA_BUFFER ;接收首地址 CALL CH372RECEIVE ;接收

MOV.W R1,#000AH CALL WRITELED ;點(diǎn)亮LED1,3

MOV.W R3,#DATA_BUFFER ;發(fā)送首地址 CALL CH372SEND

JMP LOOP

程序如此，所以我們的LED用來指示底層處于何種狀態(tài)，我們?cè)谶B續(xù)下傳、上傳小于 4096個(gè)數(shù)據(jù)時(shí)，LED2、4基本常亮，而LED1、3偶爾才會(huì)閃下，從燈指示的情況是上層在向下傳送數(shù)據(jù)時(shí)出現(xiàn)問題了，可是我們?cè)诟淖僫ReadTimeout時(shí)，會(huì)影響完成一次接收與發(fā)送的總時(shí)間。

LOOP: .... JMP LOOP 這個(gè)是你的主程序嗎? CH372RECEIVE里是怎么接受的?一般的下傳數(shù)據(jù)的流程:如上位機(jī)在發(fā)送1024個(gè)數(shù)據(jù)的時(shí)候,驅(qū)動(dòng)是把1024分成16個(gè)64字節(jié)數(shù)據(jù)包來發(fā)送的,下位機(jī)在接受到下傳成功中斷信號(hào)(如果用查尋,要去查詢這個(gè)中斷信號(hào))后,去取數(shù)據(jù),然后解鎖,解完鎖后,上位機(jī)才開始發(fā)下個(gè)數(shù)據(jù)包.你看看你的流程是否正確?

這個(gè)時(shí)我們測(cè)試時(shí)用的主循環(huán)程序。 我們循環(huán)測(cè)試40K的數(shù)據(jù)都沒問題，底層的流程向您說的應(yīng)該不會(huì)有問題。 我們是自己規(guī)定的頭連個(gè)字節(jié)為傳送的長(zhǎng)度，例如下傳數(shù)據(jù)，上位機(jī)先把數(shù)據(jù)長(zhǎng)度發(fā)下來然后發(fā)數(shù)據(jù)，下位機(jī)先讀出頭兩字節(jié)（接收的數(shù)據(jù)長(zhǎng)度）然后根據(jù)這個(gè)長(zhǎng)度判斷我下位機(jī)要接多少包，最后一包如果不滿會(huì)自己讀完然后釋放緩沖區(qū)。 上層在讀CH372芯片數(shù)據(jù)時(shí)，是必須讀滿4096么？我們發(fā)送4094個(gè)數(shù)據(jù)（發(fā)送與接收1次總時(shí)間就是超時(shí)加傳送時(shí)間）而發(fā)送4097個(gè)數(shù)據(jù)時(shí)就只是上傳與下傳的時(shí)間（與超時(shí)時(shí)間設(shè)置無關(guān)了）。

十分的感謝zyw與紅桃六?。「兄x你們對(duì)我的幫助，這次的問題處在我們上層編寫的一個(gè)小失誤上，很對(duì)不住，給你們帶來了這么多麻煩！道個(gè)歉，見諒哦，呵呵。