USB:具有中断传输和原始HID的低延迟(<1ms) [英] USB: low latency (< 1ms) with interrupt transfer and raw HID
问题描述
我有一个项目，需要定期读取外部IMU陀螺仪数据并将其发送到Android手机.
I have a project that requires reading an external IMU gyroscope data at regular interval and sending the data over to an Android phone.
我正在使用十几岁的2.0板通过I2C查询IMU，并使用原始HID通过USB将其发送.我正在使用在teensyduino的usb_rawhid的usb_api.h中声明的RawHID变量.
I am using a teensy 2.0 board to query the IMU via I2C and send it over USB using raw HID. I am using RawHID variable which is declared in usb_api.h of usb_rawhid of teensyduino.
我已经读到，使用中断传输的全速USB可能具有1ms的最大延迟，并且希望达到1ms的最大延迟.我不确定要达到最大延迟需要寻找什么，并且想了解有关指针的信息.我的最终目标是每2 ms(500 Hz)接收一次陀螺仪数据.
I have read that a full-speed USB using interrupt transfer can have a 1ms maximum latency and would like to achieve this 1ms maximum latency. I am not sure what to look for to achieve this maximum latency and would like to please know about pointers. My ultimate goal is to receive the gyroscope data every 2 ms (500 Hz).
我知道一些可能是个问题:
A few things that I am aware that may be of an issue:
1)我将RAWHID_TX_SIZE更改为6个字节(陀螺仪值只需要6个字节)，并且RAWHID_TX_INTERVAL设置为1 ms(最快). 当前在不需要的接口中指定了OUT端点，我不确定是否删除它可以改善延迟.
1) I have changed the RAWHID_TX_SIZE to be 6 bytes (I only need 6 bytes for gyroscope value), and the RAWHID_TX_INTERVAL is set to 1 ms (fastest). An OUT endpoint is currently specified in the interface that I do not need, I am not sure if removing it can improve latency.
2)Android将Teensy识别为"hiddev USB HID v1.11设备".我不确定这是否是完整的原始HID或是否正在尝试解析它. Teensy正在使用上面指定的原始HID.
2) Android recognizes teensy as "hiddev USB HID v1.11 Device". I am not sure if this is full raw HID or if it is trying to parse it. Teensy is using raw HID as specified above.
3)在Android中，特定线程正在尝试在UsbRequest上将queue()排队，然后再请求requestWait().数据到达时的处理速度非常快(即:将其存储在全局变量中)，但是我受线程调度程序的支配.
3) In Android, a specific thread is trying to queue() on UsbRequest followed by requestWait(). The processing when the data arrive is very fast (ie: store it in a global variable), but I am at the mercy of the thread scheduler.
因此，这些是我知道的一些指针(并不能完全确定它们如何影响最大延迟).我希望能听到人们的反馈，并可能在如何改善最大USB延迟方面指明新的方向.找不到减少USB中断传输延迟的信息.
So those are some pointers I am aware of (and not completely sure how they affect maximum latency). I would love to please hear people's feedback and maybe pointing in new directions on how to improve my maximum USB latency. Finding information on reducing USB latency of interrupt transfer is scare.
推荐答案
对于USB，都是轮询.每1毫秒，您就会有一个帧"，其中不包含一个或多个传输描述符，每个传输描述符告诉USB控制器要轮询哪个USB设备.
For USB, it's all polling. Every 1 ms you have a "frame" consisting of none or more transfer descriptors, where each transfer descriptor tells the USB controller which USB device to poll.
通常，USB控制器以用于中断传输的传输描述符开始帧.这意味着通过一个中断传输描述符，您(几乎)可以保证每毫秒被轮询一次.如果您的设备有发送中断，则在轮询时将其返回.因此最糟糕的情况是您将获得1毫秒的延迟.
In general, the USB controller begins the frame with transfer descriptors for interrupt transfers. What this means is that with a single interrupt transfer descriptor you're (almost) guaranteed to get polled once per ms. If your device has an interrupt to send it returns it when polled; so you're going to get 1 ms latency as your worst case.
可以要求USB控制器较少地轮询设备(例如同步传输).也可以要求USB控制器在相同的1ms帧内多次轮询设备.但是，因为它通常首先会中断传输描述符，所以您希望几乎同时在两次轮询之间以大约1毫秒"的间隔进行轮询，所以这对最坏情况下的延迟没有帮助.
It is possible to ask the USB controller to poll the device less often (e.g. isochronous transfers). It's also possible to ask the USB controller to poll the device multiple times in the same 1ms frame; however because it typically does interrupt transfer descriptors first you'd expect to get polled twice at almost the same time with an "almost 1 ms" gap between, so that doesn't help worst case latency.
据我所知，对于"<2 ms"的要求，USB规范/协议，USB控制器，内核的USB控制器驱动程序和内核的USB HID驱动程序根本不是问题.问题是及时将数据从USB HID驱动程序传输到用户空间的进程/线程.
Mostly, as far as I can tell, for a "< 2 ms" requirement the USB specs/protocols, the USB controller, the kernel's USB controller driver and the kernel's USB HID driver are not a problem at all. The problem is getting the data from the USB HID driver to a user-space process/thread in a timely manner.
不幸的是，Linux/Andriod不是实时操作系统.它不提供任何保证.您将受线程调度程序(也许还有JVM的垃圾收集器)的支配.您可能对此无能为力.
Unfortunately, Linux/Andriod is not a real-time OS. It provides no guarantees. You will be at the mercy of the thread scheduler (and maybe also the JVM's garbage collector). There is probably nothing you can do about it.
我建议首先找出为什么需要每2 ms接收一次陀螺仪数据的原因.举一个简单的例子，您可以在陀螺仪数据中添加时间戳，并让接收线程从这些时间戳重建历史"，以使接收线程根本不需要低延迟吗?
I'd recommend finding out why you need to receive the gyroscope data every 2 ms in the first place. For a simple example, can you add a timestamp to the gyroscope data, and let the receiving thread "reconstruct history" from those timestamps such that the receiving thread doesn't need low latency at all?
这篇关于USB:具有中断传输和原始HID的低延迟(<1ms)的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
