大家讨论下下啦

你是问BC 的问题？对吗

我现在有点头绪，应该说怎么知道 问题在那里了， 你看我下面，你觉得我分析是不是这样，但我不知道怎么解决

往372发送数据的程序是这样写的（部分中主要的） //测试用的

if(CH375WriteData(index,sent,&len)) Form1->Shape2->Brush->Color=clRed; //发送成功指示灯变红 下位机显示已经接受到数据（我这里接受到数据时，下位机液晶显示downok) 也就是说 CH375WriteData(index,sent,&len)已经成功 可是Form1->Shape2->Brush->Color=clRed；没有运行，所以发送成功指示灯没有亮， 我怀疑，程序一直都是运行CH375WriteData(index,sent,&len)语句，无法退出这个死循环， 一旦把设备拔出之后，发送成功指示灯就亮，也就是说，你拔出后， Form1->Shape2->Brush->Color=clRed; 才运行， 接受的也是这样， 所以我认为，我们调用公司用VC编写编写的动态连接库有问题，可是我现在不知道到底怎么解决这个

有QQ吗 ？你可以加我的，我的是290180666 我一般都在线，这段时间，你可以给我留言

我对具体VB/VC/BC语言不了解,我只将多所了解的通讯原理说一下.USB传输是64字节一个包. 如果上位机一个读写操作未返回,说明下位机正忙,如果上位机打算下传120字节,而下位机收到前64字节后,单片机没有读出数据,那么CH372就不收后面的56字节,那么上位机就会认为下位机忙而一直等待不返回API, (不过,当设置USB写超时后也会返回,但那是非正常返回) 如果下位机读出了数据,那么上位机的写API必然返回. 如果上位机打算上传n字节,如果下位机没有返回或者返回长度不足并且没有用短包终止(0到63字节称为短包),那么上位机的读API会不返回(除非设置超时) 实际的情况往往是,下传总是没什么问题的,上传可能因为下位机程序未设计好而可能无返回或者返回不足 那么可以用公司提供的CH372驱动的另一种工作方式:缓冲上传(前面说的上传方式是直接上传) 缓冲上传是指CH372驱动中用一个线程主动不断的接收数据放在计算机内存缓冲区中,应用程序随时需要时用读API取用.有数据则返回,没有数据则返回0长度,所以读API总是能够立即返回 还有一种情况会导致下传或者上传API不返回,即同步操作的句柄争用, 公司设计的DLL定义为同步操作,所以用CreateFile和OpenDevice产生的一个句柄同一时候只能用于一个API,如果一个API用了句柄,那么另外一个线程不宜同时使用同一句柄调用API, 如果是多线程应用程序,必须每个线程使用一个专用的句柄,参考DEBUG372工具程序就是这样多句柄多线程

我的情况是： 用Ch375ReadData能读到数据，但常常不完整。比如：我要读128字节，常常读到64字节 是不是单片机中程序效率太差，导致第二个64字节还没上传，CH375ReadData就已经读取，并以为读到0，而返回呢？