用官方的HID例子测试USB HID的一次读写所用的时间,通讯一次的时间是近100ms。
测试方法:上位机发64字节给STM32下位机,然后STM32下位机再回复64字节给上位机。整个过程用bus hound监测。用时近100ms.
也就是速度只有可怜的640*2Byte/s。而理论值是64KB/s。不知这样的测试方式是否有问题,或者大家的速度也是这样的?
我想应该是我哪里出了问题。我看到大家在相关的帖子里提到有的可以到30KB/s。
USB接收中断
{
接收;
处理;
发送;
}
定时器测试USB接收中断时间为40微秒。另外消耗的时间去哪里了。
USB Trace监控的是从PC外设USB的BUFFER收发的数据。还是和bus hound 一样。USB Trace测试的时间要少一些,大概20个毫秒的样子。但也不符合40微秒的用时。
端点描述符中polling的间隔是设置如下
/******************** Descriptor of Custom HID endpoints ******************/
/* 27 */
0x07, /* bLength: Endpoint Descriptor size */
USB_ENDPOINT_DESCRIPTOR_TYPE, /* bDescriptorType: */
0x81, /* bEndpointAddress: Endpoint Address (IN) */
0x03, /* bmAttributes: Interrupt endpoint */
0x40, /* wMaxPacketSize: 2 Bytes max */
0x00,
0x20, /* bInterval: Polling Interval (32 ms) */---------------》修改此值传输一次的时间基本没有变化,维持在90-100ms之间
/* 34 */
0x07, /* bLength: Endpoint Descriptor size */
USB_ENDPOINT_DESCRIPTOR_TYPE, /* bDescriptorType: */
/* Endpoint descriptor type */
0x01, /* bEndpointAddress: */
/* Endpoint Address (OUT) */
0x03, /* bmAttributes: Interrupt endpoint */
0x40, /* wMaxPacketSize: 2 Bytes max */
0x00,
0x20, /* bInterval: Polling Interval (20 ms) */---------------》修改此值传输一次的时间基本没有变化,维持在90-100ms之间
端点1的初始化部分
/* Initialize Endpoint 1 */
SetEPType(ENDP1, EP_INTERRUPT);
SetEPTxAddr(ENDP1, ENDP1_TXADDR);
SetEPRxAddr(ENDP1, ENDP1_RXADDR);
SetEPTxCount(ENDP1, 64);
SetEPRxCount(ENDP1, 64);
SetEPRxStatus(ENDP1, EP_RX_VALID);
SetEPTxStatus(ENDP1, EP_TX_NAK);
我测试的USB的接收中断中处理+发送(当然这里只是从用户数据区拷贝到USB发送缓冲区)时间也只有40微秒。
端点描述符中设置的发送polling时间为1毫秒。也就是说一次收发的时间理论值是在稍微大于1毫秒的样子。
但我想你应该没有实测PC发64字节到STM32,然后STM32收到后再发64字节回给PC。这个时间将远远不是64KB/S的水平。
问题可能出在两方面:
1.测试工具的问题:
我用bus hound 与 USB Trace测试的,或许这两款软件本就截获的不是硬件USB端到端的数据(比如,或许是在应用层截获的)。
2.上位机软件与PC端驱动
首先上位机系统(这里是WINDOWS)并不是实时的。这导致USB收到的数据并不能得到及时的处理。这个时间无法估计,不过应该至少也是毫秒级的。
再者,上位机软件获取数据的过程应该也是 驱动 拷贝到 用户的模型。这里有一定的软件开销,当然,考虑到上位机的强悍,这个时间应该很小。
所以这里还是希望有朋友给出一些数据佐证一下64KB/S的理论值在一问一答模式下到底有多少利用价值。 |