大家討論下下啦

你是問BC 的問題？對嗎

我現(xiàn)在有點(diǎn)頭緒，應(yīng)該說怎么知道 問題在那里了， 你看我下面，你覺得我分析是不是這樣，但我不知道怎么解決

往372發(fā)送數(shù)據(jù)的程序是這樣寫的（部分中主要的） //測試用的

if(CH375WriteData(index,sent,&len)) Form1->Shape2->Brush->Color=clRed; //發(fā)送成功指示燈變紅 下位機(jī)顯示已經(jīng)接受到數(shù)據(jù)（我這里接受到數(shù)據(jù)時，下位機(jī)液晶顯示downok) 也就是說 CH375WriteData(index,sent,&len)已經(jīng)成功 可是Form1->Shape2->Brush->Color=clRed；沒有運(yùn)行，所以發(fā)送成功指示燈沒有亮， 我懷疑，程序一直都是運(yùn)行CH375WriteData(index,sent,&len)語句，無法退出這個死循環(huán)， 一旦把設(shè)備拔出之后，發(fā)送成功指示燈就亮，也就是說，你拔出后， Form1->Shape2->Brush->Color=clRed; 才運(yùn)行， 接受的也是這樣， 所以我認(rèn)為，我們調(diào)用公司用VC編寫編寫的動態(tài)連接庫有問題，可是我現(xiàn)在不知道到底怎么解決這個

有QQ嗎 ？你可以加我的，我的是290180666 我一般都在線，這段時間，你可以給我留言

我對具體VB/VC/BC語言不了解,我只將多所了解的通訊原理說一下.USB傳輸是64字節(jié)一個包. 如果上位機(jī)一個讀寫操作未返回,說明下位機(jī)正忙,如果上位機(jī)打算下傳120字節(jié),而下位機(jī)收到前64字節(jié)后,單片機(jī)沒有讀出數(shù)據(jù),那么CH372就不收后面的56字節(jié),那么上位機(jī)就會認(rèn)為下位機(jī)忙而一直等待不返回API, (不過,當(dāng)設(shè)置USB寫超時后也會返回,但那是非正常返回) 如果下位機(jī)讀出了數(shù)據(jù),那么上位機(jī)的寫API必然返回. 如果上位機(jī)打算上傳n字節(jié),如果下位機(jī)沒有返回或者返回長度不足并且沒有用短包終止(0到63字節(jié)稱為短包),那么上位機(jī)的讀API會不返回(除非設(shè)置超時) 實(shí)際的情況往往是,下傳總是沒什么問題的,上傳可能因?yàn)橄挛粰C(jī)程序未設(shè)計好而可能無返回或者返回不足 那么可以用公司提供的CH372驅(qū)動的另一種工作方式:緩沖上傳(前面說的上傳方式是直接上傳) 緩沖上傳是指CH372驅(qū)動中用一個線程主動不斷的接收數(shù)據(jù)放在計算機(jī)內(nèi)存緩沖區(qū)中,應(yīng)用程序隨時需要時用讀API取用.有數(shù)據(jù)則返回,沒有數(shù)據(jù)則返回0長度,所以讀API總是能夠立即返回 還有一種情況會導(dǎo)致下傳或者上傳API不返回,即同步操作的句柄爭用, 公司設(shè)計的DLL定義為同步操作,所以用CreateFile和OpenDevice產(chǎn)生的一個句柄同一時候只能用于一個API,如果一個API用了句柄,那么另外一個線程不宜同時使用同一句柄調(diào)用API, 如果是多線程應(yīng)用程序,必須每個線程使用一個專用的句柄,參考DEBUG372工具程序就是這樣多句柄多線程

我的情況是： 用Ch375ReadData能讀到數(shù)據(jù)，但常常不完整。比如：我要讀128字節(jié)，常常讀到64字節(jié) 是不是單片機(jī)中程序效率太差，導(dǎo)致第二個64字節(jié)還沒上傳，CH375ReadData就已經(jīng)讀取，并以為讀到0，而返回呢？