Game programming with usb device and rumble (FFB)

[ulao]

I'm seeing a pattern here that I assume may of you deal with or have dealt with before.

Game send interrupt transfers to a usb controller to get button data. The game also sends control transfers to rumble the controller (force feedback). If the game does lots of FFB eventual it sends at the same time the button data is asked for resulting in no ACK. Because the host didn't get the ACK it freezes for a moment resulting in skippy game play.

I don't think usb 2.0 has this issue but 1.1 seems to. On a single threaded chip you can only do one thing at a time, so if controller data is being requested all control transfers must wait. Hence no ACK...

So what can one do to fix this in the case where you can not change the game code. Does it help to have the interrupt on EN1? Can EN0 handle the interrupt and control transfers. Or woudl that even help much. I could pause the usb button data once a rumble command comes in but then you will get latency issue during lots of game rumble.

[Jan Axelson]

Endpoint responses to transactions are set up in advance in device firmware.

On receiving an IN token packet, the endpoint responds with ACK, NAK, or data according to how the endpoint is set up, and without requiring firmware intervention. The endpoint then typically will return NAK until firmware sets up a different response to use for a new token packet.

Endpoint zero does control transfers only.

[ulao]

In your best guess. What could possibly cause the freezing? The freezing stops if the device is unplugged. So some how the device is causing this. I can pull usb logs...

[Jan Axelson]

A hardware-based protocol analyzer will show if an endpoint is failing to return a response.