各位高手，我在做CH372芯片连续发送接收数据时出现了一点小问题，请教下： 我们运用CH372芯片做连续发送接收40K的数据都没问题而且速度也很快，但当我们把数据变成4096以下的是数据时，就变得非常慢（其中我们设置的上层接收发送超时为2S，结果下传10个数据在回读10个数据要2.5S左右，而将超时设置为1ms时就很快的完成，基本不消耗时间!）请帮忙解决下这个问题!谢谢！！

这个应该不是问题,你设置超时时间比较长,会等到收满4096才退出.你原来连续发送的时候,最后一个包也慢如果你设的超时时间也是2S的话,你可以实验一下. 把时间设短一点就可以了.

上传时设置1MS时,你读的时候数据很有可能没有到4096,超时应该设置长一点,在用CH375ReadDate读数据返回的时候,要判断一下CH375ReadDate的第三个参数,这个参数会被修改成实际读到的数据长度!

现在我们设置传送数据为40930（36894）最后一包不满，但传送的结果和传40960基本一样（0.5s左右），都不会出现当发送数据小于4096时的现象啊！！

现在我们在测量中发现不是上传的问题，上传数据没问题很快，是下传时不够4096个数据会超时。

哦 不好意思

读写返回的时候都要判断第3个参数是不是与调用前一样,返回后的值是实际读写到的数据长度. 是不是只要发4096以下的数据都会超时,如果是,可能要查一下下位机.

我们已经对于数据长度已经和第三个参数进行了判断。现在的具体现象是这样的： 1） 只要下传数据超出4096，不会受超时设置参数影响，下传数据长度我们用30、64、4096、40126、36894、40960，均试验过，得到的结果就是低于4096(不含)则设置的超时参数就是我们的下传、接收时间间隔(加上传输时间)； 2） 超时设置接口时间的参数读写超时，你们的接口说明可能是说反了，前一个应该是读数据超时参数，后一个应该是写数据超时，因为我们做试验的时候，将前一个数据改短，对于测试速度不受影响，后一个改短则速度受影响。下面我会将理由说明。当然可能有我们对于超时理解的偏差，如果是，还请指正。 3）我们在硬件上设置了4个发光二极管，下位机接收数据时2、4灯亮，下位机发送数据时1、3灯亮，全速运行(上层下传数据、然后再将发送的数据上传回来，循环进行该过程)，结果是2、4灯几乎常亮，这说明底层上传数据时时间极短，才会造成该现象，因此我们可以确定是下传时不足4096字节时速度受到影响，而再2）中对此有影响的是读超时参数。 4）4096个数据应该是上层接口使用的缓冲区，和下位机应该没有关系，下位机每次最多只接收64字节，如此循环，因此应该和下位机软件无关。不知道这个分析是否正确？

读写最大缓冲区是4096!不要超过4096!

BOOL WINAPI CH375SetTimeout( // 设置USB数据读写的超时 ULONG iIndex, // 指定CH375设备序号 ULONG iWriteTimeout, // 指定USB写出数据块的超时时间,以毫秒mS为单位,0xFFFFFFFF指定不超时(默认值) ULONG iReadTimeout ); // 指定USB读取数据块的超时时间,以毫秒mS为单位,0xFFFFFFFF指定不超时(默认值)

我们在发送与接收超过4096的数据是将其分成多个4096数据下传的，例如40960我们分成10个4096下传。 超时iWriteTimeout，iReadTimeout的设置与我在7楼中提到的恰好相反，我们通过LED观察到的是下传时超时，可是我们将iReadTimeout改小后会影响接收与发送的时间，而改变iWriteTimeout却没什么影响。

CH375SetTimeout第2个参数是设置写超时,第3个参数是设置读超时,这个是正确的! "iReadTimeout改小后会影响接收与发送的时间",你们这个时间是怎么计算的?是读写的总时间?如写没有问题,读有问题,那肯定就是iReadTimeout会"影响接收与发送的时间".

时间是完成下传与上传1次后取下系统时间并显示出来。 以下是我底层的主循环程序： LOOP: MOV.W R1,#0005H CALL WRITELED ;点亮LED2，4 MOV.W R3,#DATA_BUFFER ;接收首地址 CALL CH372RECEIVE ;接收

MOV.W R1,#000AH CALL WRITELED ;点亮LED1,3

MOV.W R3,#DATA_BUFFER ;发送首地址 CALL CH372SEND

JMP LOOP

程序如此，所以我们的LED用来指示底层处于何种状态，我们在连续下传、上传小于 4096个数据时，LED2、4基本常亮，而LED1、3偶尔才会闪下，从灯指示的情况是上层在向下传送数据时出现问题了，可是我们在改变iReadTimeout时，会影响完成一次接收与发送的总时间。

LOOP: .... JMP LOOP 这个是你的主程序吗? CH372RECEIVE里是怎么接受的?一般的下传数据的流程:如上位机在发送1024个数据的时候,驱动是把1024分成16个64字节数据包来发送的,下位机在接受到下传成功中断信号(如果用查寻,要去查询这个中断信号)后,去取数据,然后解锁,解完锁后,上位机才开始发下个数据包.你看看你的流程是否正确?

这个时我们测试时用的主循环程序。 我们循环测试40K的数据都没问题，底层的流程向您说的应该不会有问题。 我们是自己规定的头连个字节为传送的长度，例如下传数据，上位机先把数据长度发下来然后发数据，下位机先读出头两字节（接收的数据长度）然后根据这个长度判断我下位机要接多少包，最后一包如果不满会自己读完然后释放缓冲区。 上层在读CH372芯片数据时，是必须读满4096么？我们发送4094个数据（发送与接收1次总时间就是超时加传送时间）而发送4097个数据时就只是上传与下传的时间（与超时时间设置无关了）。

十分的感谢zyw与红桃六！！感谢你们对我的帮助，这次的问题处在我们上层编写的一个小失误上，很对不住，给你们带来了这么多麻烦！道个歉，见谅哦，呵呵。