I misspoke indeed, sorry about that. The device actually has 2 endpoints, an interrupt OUT and an interrupt IN, but only one interests me, and it’s the IN (device->host), not the OUT (host->device).
@Tim_Roberts, I was also unclear by saying “USB controller”. In this case, I meant the USB device controller.
To clarify the architecture of the problem, although I’m not sure how much specifics belong here, the device is a controller adapter (used by numerous people that won’t be able to mess with hardware - and contacting the vendor isn’t an option), which means that there is (in my mind):
- The controllers (that provide data upon receiving a message using the communication protocol established with the adapter)
- The main process in the adapter that manages communication with the controllers. (Polls controllers every ~1,4ms)
- The USB device controller (Exposes a 8ms bInterval, not HID. I am not knowledgeable about how it’s implemented. I’ve seen in another device two chips coexist - one dedicated to USB and one to the main task, but this one appears to only have the STM32L151 chip.)
- The USB HC + HCD
- The Windows driver
- Whatever application is using the data. Said application’s engine is most likely similar to a 60Hz state machine that uses one snapshot of controller data per state increment.
The problem I’m trying to fix in the end is that feeding a 60Hz state machine with an data polled at 62,5Hz (every 8ms) makes things go very wrong. (Think of the “time distortion” that happens when 3 polls, spaced by 8ms, are fed in a single 16,67ms period of the state machine, instead of the usual 2? If we had 1000Hz controller data, we would get time distortions of 16ms or 17ms into 16,67ms - much less harmful than 24ms into 16,67ms. The consequences of this are another subject entirely, though, and I doubt they belong here. In short, it’s terrible on the user end.)
So the problem is the following : is it possible to access the data of the controllers that the adapter chip is pulling every ~1,4ms ?
And if I understood this correctly, interrupt endpoints on the device side are necessarily implemented using a buffer that the device fills and that the USB device controller reads right away when queried.
To fix the problems with software only, there is one precondition, and then we have to poll it faster than allowed.
The precondition is that the buffer the USB device controller is updated at the request of the device’s main process, every ~1,4ms, instead of being updated at the request of the USB device controller, at the same frequency as the exposed bInterval, so, every 8ms. If the latter, all is lost. I don’t know which case we’re in yet.
And if the former, that means that USB device controller actually could provide more data than what it tells the host and there only remain to disregard the exposed polling interval - so to speak, overclock.
I digressed earlier, wanting to check if by some alignments of the stars, sending a longer buffer than the returned data would cause the chip to accumulate every 1,4ms data in the buffer and return it every 8ms, but there are numerous reasons this probably wasn’t going to work, and actually I had understood nothing. As per Mr. Roberts explanation, if I got it right, data certainly doesn’t accumulate in blocks one after another in a buffer too large for the device to internally handle it (how did I ever think this was going to work ?) but is split at the HC/HCD level into requests fit for the device, one after another, and the Windows driver will get all the answers back at once once they’re all complete.
I hope this clarified my various unclear statements from earlier. I’ll now try HidUsbF.
In this case, i just ask for confirmation if i correctly understood your initial request:
“make 2 or 1ms polling on device with 8ms bInterval in Interrupt Endpoint Descriptor”
And @SweetLow , I hope this clarifies my request !