USB Host (teensy 4.1) possible to configure to not skip empty poll events?

C

cirthix

Member
Hi,
I've got a teensy 4.1 connected to an FPGA to handle all of the usb host protocol stuff. Right now, the system is working with a 4khz mouse and it is great. One minor source of annoyance is that the data logging on the fpga is now tied to how quickly (or not) the mouse is moving. Having a consistent update rate regardless of mouse movement would be great. Does the usb library allow this? I didn't see a clear path.

A shortened version of my arduino sketch:

void ProcessMouseData(){
uint32_t cur_buttons;
int16_t cur_x;
int16_t cur_y;
if (mouse.available()) { // <<<<========== Ideally, this should fire every on polling request answer, not just those with mouse position/click changes.
cur_buttons = mouse.getButtons();
cur_x = mouse.getMouseX();
cur_y = mouse.getMouseY();
mouse.mouseDataClear();
SendMouseDataToUART(cur_buttons, cur_x, cur_y); // This function just sends a few characters to translate usb poll response stream to a character stream on the uart
}
}

void setup(){
Serial.begin(UARTSPEED_HOST);
Serial2.begin(UARTSPEED_MOUSE);
myusb.begin();
}

void loop(){
myusb.Task();
ProcessMouseData();
watchForUSBDeviceChanges();
}

Thanks :)
 
The polling that causes the host to transmit IN tokens happens entirely in the EHCI hardware, so there is no "easy" way.

The hardware does have an option to interrupt on NAK, but I've never tried it. If you want to deep dive into the low-level code, search for USBHS_USBSTS_NAK. There should be a corresponding bit in USBHS_USBINTR to enable that interrupt. Then in the main interrupt handler, check if the USBHS_USBSTS_NAK bit is set. What to actually do inside the interrupt and how to turn this into something actually useful, I'm not sure. But curious to hear how it goes, if you give it a try?
 
That doesn't seem like the logical way to do what is desired; rather it sounds like you should be transmitting the mouse data in a separate timed loop if that's what the FPGA requires.
 
Thanks for the suggestion. Had a look around and I think the NAK interrupt feature is only for device mode? Not sure. I ended up trying a predictor to send a null packet if a poll-miss was detected, validated that it did an ok job most of the time, then disabled it because it would occasionally run into a situation where the null packet delayed a real poll update. I've gone forward with an approach to just deal with some post-processing on the output dataset. In the next iteration of this experiment, I'll use an open source HID and just add a side-channel high speed UART rather than using a usb host in the middle.

Thanks :)
 
You must log in or register to reply here.
Back
Top