Author Topic: hakcing the binterval - pitfalls  (Read 9467 times)

ulao

  • Frequent Contributor
  • ****
  • Posts: 172
hakcing the binterval - pitfalls
« on: November 30, 2019, 03:45:10 pm »
So a trick some hardware devices are using (mainly linux) is to rebuild the kernel for a poll rate of near 700us. This is only pertaining game pads...  I for one am not on board with this is a good hack but wanted to talk about the legitimacy of it here. So first there are 3 version of USB for this topic.

1 2.0
2 1.1
3 v-USB

The ideal is simple, just trick the host to poll at a given rate and for the most part 4ms seems to be ok. With 1.1 the frames are 1ms apart so I can't see 700us working very well. Many suggest 1.1 will not tolerate less the 8ms but I have no experimental data. v-usb seems it would work with > 1ms from what I see on the scope but being it is a software only driver, i'm not sure that will hold up. I think 2.0 is a fairly safe bet it will take the abuse.

There are some clear failure points here like using control transfers. I do not see that working as they often take longer the 3ms to complete but if nak'd they go one forever. Though I wonder what I may not be thinking of here. Anyone have a thought to pass along?



Jan Axelson

  • Administrator
  • Frequent Contributor
  • *****
  • Posts: 3033
    • Lakeview Research
Re: hakcing the binterval - pitfalls
« Reply #1 on: November 30, 2019, 05:25:32 pm »
A host can poll as often as it wants. If an interrupt, bulk, or control endpoint isn't ready to send or receive data, it can return NAK.

It's possible, however, that a device won't be tested at rates faster than expected, and if an IN or OUT token arrives too quickly, the endpoint won't be set up in time to return NAK.

As for control transfers, from USB Complete 5th Ed:

In a USB 2.0 control transfer, where stricter timing isn’t specified (as in a class specification), in a transfer where the host requests data from the device, a device may delay as long as 500 ms before making the data available to the host.

In a transfer where the host sends data to the device, if the host sends data at the maximum rate the device can accept the data, a USB 2.0 device can take up to 5 seconds to accept all of the data and complete the Status stage. Once begun, the Status stage must complete within 50 ms.

The host and its drivers aren’t required to enforce the timing limits, but all devices should comply with the limits to ensure proper operation with any host.