|
阅读：2077回复：19
请问USB上位机读数据的问题
我怎么突然发现usb的上位机读数据的速度很慢！下位机除了发送数据之外，什么事情都不做，上位机不停地读，我用timeGetTime（）计算每次读书的时间，可是我发现每读一次（32B），有时候时间很短，有时候要15或是16ms的时间，请问这是为什么呢？我得usb芯片是D12的，用的是厂家提供的驱动，会不会是驱动有问题啊？请各位大侠帮忙了！
|
|
|
沙发#
发布于：2003-07-23 11:12
D12就是这样了，不要要求太高，你必须自己改驱动才可以有提高的。
|
|
|
板凳#
发布于：2003-07-23 11:17
但是这个速度也慢得太离谱了呀！16ms读一次！只有2k/s阿，也不至于把？这个速度也太慢了阿
|
|
|
地板#
发布于：2003-07-23 11:56
一般几百k/s比较正常的。你的是慢了些。估计不是驱动的事，看看其他配置吧。
|
|
|
地下室#
发布于：2003-07-23 12:23
我要求的是有实时数据需要上传，而且时不时还有一些其他的数据要上传，而且还有数据下传，是不是就因该用等时传输和批量传输啊？
怎么突然感觉很麻烦啊？我以前用的是批量传输，看来是不是不行啊？ |
|
|
5楼#
发布于：2003-07-23 12:27
从理论上讲应该是没有问题的。
|
|
|
6楼#
发布于：2003-07-23 18:44
可是我改了iso传输方式之后还是不行啊，而且每次接受数据的时间都是10ms左右，怎么这个时间就这么有规律那？是不是哪个地方设置有问题啊？有没有做过iso传输的，介绍一点经验了！多谢了!
|
|
|
7楼#
发布于：2003-07-23 20:49
还有上位机如果要读大于端点长度的数据的话，是不是可以在readfile中输入长度，驱动直接将这个长度分割啊？可是我用的为是那么就不行呢？是不是在驱动中要进行什么处理阿？或者是只能循环调用readfile函数那？
|
|
|
8楼#
发布于：2003-07-24 12:53
怎么就没有人回答我得问题啊？郁闷！急啊！
|
|
|
9楼#
发布于：2003-07-24 14:14
把你的硬件配置部分贴出来，看看是否有问题，
还有，你的硬件性能是不是就只支持这么大呀 |
|
|
|
10楼#
发布于：2003-07-24 15:16
硬件确实是存在一些问题，下位机有很多事情要处理，我记算了一下，留给usb传递数据的时间是很少的了！可是usb传递一次数据的话，不管数据有多少，协议的处理就很麻烦了！这是影响速度的原因。其实我得数据就不是大批传送的，都是周期性，而且每次数据又很少的。老板就是要这样，没办法！
|
|
|
11楼#
发布于：2003-07-24 15:20
还有上位机如果要读大于端点长度的数据的话，是不是可以在readfile中输入长度，驱动直接将这个长度分割啊？可是我用的为是那么就不行呢？是不是在驱动中要进行什么处理阿？或者是只能循环调用readfile函数那？ 有驱动程序源代码的话到下面这个地方去看看是不是你设置的有问题： Pipes.MaximumTransferSize = 64*1024； 你在工程里搜一下MaximumTransferSize字符串，就是它管每次传输的大小的，前面那个设置的是64k |
|
|
12楼#
发布于：2003-07-24 17:05
这个是好的阿。没有问题的，我想可能是下位机的原因了
|
|
|
13楼#
发布于：2003-07-24 19:43
你在固件方编个小的测试程序，只要端电非空就往端点里写一些数据，比如从1写到64什么的，然后再主机方一直读（每次读都多于一个包），看行不行
|
|
|
14楼#
发布于：2003-07-24 20:48
我做过了，不过我是在厂商请求里面做的，只要上微机发命令过来，我就给端点发数据，结果我在上位机一次读取720个字节，时间是30ms左右，这个时间也太长了啊，现在想想，是不是上位机在等待下位机向端点写数数据啊？我明天试试看，也许有这个可能了，是把？
|
|
|
15楼#
发布于：2003-07-27 18:29
可能驱动真的需要修改啊，反正周立功的东西真的是很烂！
|
|
|
16楼#
发布于：2003-07-27 18:42
不要用厂商请求，厂商请求是控制传输，控制传输由三个阶段组成，当然很慢了，用bulk传输！
|
|
|
17楼#
发布于：2003-07-28 08:33
可是如果不用场上请求的话，我怎么知道上位机向下位机读多少数那？
|
|
|
18楼#
发布于：2003-07-28 09:25
多谢任兄的指点，果然快了很多了，不过现在还是有个问题了，为什么上位机在读完本次数据之后到下次再读数之前会有一段时间的延时，这个时间上位机耗费在哪里那？我是在一个线程里面读的。
|
|
|
19楼#
发布于：2003-07-28 09:58
这些事件损耗来源于各级程序的返回以及完成过程，比如从hcd返回到usbd再返回到设备驱动，再返回到应用程序，如果你只有一个线程，应用程序理把数据写到文件中也是需要占用时间的，如果你用的buffered io方式，那么数据从驱动拷贝到应用程序也占用时间，向下发命令是个相反的过程，
因此上一个命令返回后到下一个命令到达设备之间会有一段时间间隔，usb2.0的时间间隔是1/10ms级，但是如果你的mcu比较快，而且是实时传输数据，那么就这么点时间也是足以致命的，因为在这段时间里你的mcu已经有可能把双缓冲的端点都填满了，那么在多出来的数据就会丢失。 解决这一问题有两个方法，一是在设备方加缓冲，具体多大和你的速度是成比例的，二是尽量减少数据返回占用的时间，比如取消写文件操作，主机上开个较大的缓冲区，把数据全部读回后再写文件，或者根本在驱动里就把数据收集完再返回给应用程序等。 |
|