换了一个硬盘，从Windows2000换到XP，原来在测试的一个数据采集板突然就不能用了。应用板是STM32F103VB，USB口发送采集的数据到PC，偷了一点懒，直接用虚拟串口的例子改的USB通信程序，这部分程序在Window2000下用了两个多月了，一直好好的。
理所当然想到是PC端接收程序的问题，不过PC端程序的资历更老，封装的类已经用了好几年，有四五个Project用过，一直没问题。好在这个也是自己写的，可以改，在UART配置，多线程、Overlapped读写之间钻来钻去，能试的都试过了，就是没有进展。基本的现象，Slave发送的数据包为2176、4352Bytes两种，4352的包只能收到前边的4096Byte，2176的包就收不到，直到后面再发的数据加起来超过4096，又收到一个4096的包，也就是每次只能收4096大小的包。用分散的数据发过来测试，64Byte内可以接收，大于64Byte又会丢数据或者不能及时在Readfile中出现。
折腾了整整10天，实在没脾气了，只能无聊地到应用板这边改一下。STM32这边的数据发送，按虚拟串口Buffer大小，分成64Byte大小的包，最后一包不足64Byte，延时50ms后也自动发出去，发的数据都可以用示波器看到，不会有漏发的。发送每个包之间加上100ms延时，没有作用；把发送包的大小改成62Byte，突然就行了！再试，只要小于64Byte，怎么折腾都没问题！
发送包长还是64Byte，把数据填满4096Byte再发，只要是4096，8192这样的N个4096大小的包，接收都没有问题！
大致总结，虽然都是Win32，Window2000和XP的Readfile流控制机制有不同的，XP总是试图去读满4096Byte(1扇区？)才返回，4096以下，估计又有另一套机制。对于USB虚拟串口，Baud率设置是不起作用的，设定9600也能收115200发的数据，COMM的TimeOut似乎也不起作用，至少不是按传统UART接口那样起作用的。内部还有什么机制，恐怕要看VCPDriver甚至Win32的源码才知道，只能回避这一点，把发送数据包设成小于64Byte，不过发送大量数据（1MB左右）时，明显感到63Byte的包Size，速度要比64Byte低得多，还有必要进一步深入。
精疲力尽不想再挖下去，丢下了一大堆正经活没干，看似最简单不过的串口，也能叫老鸟折戟沉沙。
|
楼主
标题置顶
标题高亮
