`USBHost::Task` blocks for 5 seconds

[bbx10]

Calling usb.Task() results in a 5 second blocking delay. This makes it hard to use USB host with
other devices that need regular polling. For example, if data is
streaming in to Serial1 at 115200 bits/s, the incoming data will not
be processed for up to 5 seconds.

This can be seen by adding timing output to the KeyboardController and MouseController examples. For example, the following prints "delta millis 5000" when there is no keyboard or
mouse input:

void loop() {
  uint32_t delta, startMillis = millis();

  // Process USB tasks
  usb.Task();

  delta = millis() - startMillis;
  if (delta > 10) {
    Serial.print("delta millis ");
    Serial.println(delta);
  }
}

The problem is the input endpoint property defaults to wait until timeout which is 5 seconds. The proposed solution is to set the EpInfo.bmNakPower to USB_NAK_NOWAIT. This means if a single NAK is received, input operations return with an error instead of waiting for 5 seconds.

With this change usb.Task() returns in <= 10 ms when there is no input from the device.

hidboot.h
@@ -464,6 +464,7 @@ void HIDBoot<BOOT_PROTOCOL>::EndpointXtract(uint32_t conf, uint32_t iface, uint3
        epInfo[index].deviceEpNum       = (pep->bEndpointAddress & 0x0F);
        epInfo[index].maxPktSize    = (uint8_t)pep->wMaxPacketSize;
        epInfo[index].epAttribs     = 0;
+       epInfo[index].bmNakPower    = USB_NAK_NOWAIT;

        TRACE_USBHOST(printf("HIDBoot::EndpointXtract : Found new endpoint\r\n");)
        TRACE_USBHOST(printf("HIDBoot::EndpointXtract : deviceEpNum: %lu\r\n", epInfo[index].deviceEpNum);)

Additional context

A pull request has been submitted with this change: #6

Additional reports

• USBHost::Task blocks for 5 seconds #2 (comment)

[bbx10]

@cmaglie @Lauszus

This issue is related to the following issue felis/USB_Host_Shield_2.0#184.

union {
  uint8_t epAttribs;
  struct {
    uint8_t bmSndToggle : 1; // Send toggle, when zero bmSNDTOG0, bmSNDTOG1 otherwise
    uint8_t bmRcvToggle : 1; // Send toggle, when zero bmRCVTOG0, bmRCVTOG1 otherwise
    uint8_t bmNakPower : 6; // Binary order for NAK_LIMIT value
  } __attribute__((packed));
};

epInfo[index].epAttribs = 0;

is equivalent to

epInfo[index].bmNakPower = epInfo[index].bmRcvToggle = epInfo[index].bmSndToggle = 0;

The patch restores bmNakPower to USB_NAK_NOWAIT so Usb.Task => inTransfer =>dispatchPkt do not hang waiting for mouse or keyboard input.

If you prefer I can remove epInfo[index].epAttribs = 0 and set each field as needed.

epInfo[index].bmNakPower = USB_NAK_NOWAIT;
epInfo[index].bmRcvToggle = epInfo[index].bmSndToggle = 0;

[Lauszus]

Yes I believe it would be better never to set epAttribs, as it is prone to errors if you set things in the wrong order. Please see the following PR: felis/USB_Host_Shield_2.0#185.

[solarPV]

Thank you for posting.

I tried both options, adding this line:

epInfo[index].bmNakPower    = USB_NAK_NOWAIT;

and also adding the two lines:

epInfo[index].bmNakPower = USB_NAK_NOWAIT;
epInfo[index].bmRcvToggle = epInfo[index].bmSndToggle = 0;

but still having the same problem. I am trying to use it with a barcode Scanner a a touch screen and I have to keep on holding a button down for 5 seconds for the screen to react.

Any ideas? thank you

[solarPV]

Sorry, it was actually a problem with my code that was getting stuck in another place. Managed to get it working with no 5s delay. Thank you

[solarPV]

Well it doesn't really work correctly. As long as I don't act on the barcode reader there is no delay on my screen. But after the first time that I act on the barcode reader the 5s delay is back and the barcode reader stops working. If I disconnect the USB barcode the delay goes away and when I plug the barcode back it works again.

Any ideas? ty

[solarPV]

Ok so I think I found why it happens. In some actions of the touch screen I enter menus in which usb.Task() is not called. It seems that if I rest in those menus for too long, when I come back to the main loop where usb.Task() is, it no longer works. However If I only stay for a short time insided the menus when I come back it works normally. I have no idea why this happens. But maybe you guys with more info might now.

ty

[Lauszus]

You need to call Usb.Task() frequently. Are you using a delay anywhere in your code? If so please see the following guides: https://www.arduino.cc/en/Tutorial/BlinkWithoutDelay and https://learn.adafruit.com/multi-tasking-the-arduino-part-1/using-millis-for-timing.

[solarPV]

I was just comming to re-post. Yes I finally solving by calling usb.Task() inside each of the sub-menus which are inside a while until the exit button is pressed. Because I don't actually want a barcode to be scanned while inside these sub-menus I just added an if statement to not do anything when usb.Task() is called.

It now seems to work perfectly. ty

[dewhisna]

I've encountered a similar problem to what you are experiencing. In my case, I have to leave calling the Usb.Task() function to go into a special bootloader mode to transfer some EEPROM data. During that time, keyboard input and console serial I/O is suspended.

The problem, I think, is how the Usb.Task() function handles the "delay" calculation with millis(). If that runs too long, it has to loop all the way around before it starts working again, which in my case causes the keyboard to not respond at all until that extra timeout for it to finish wrapping around and millis() to catch back up (a delay similar to what you are experiencing).

I can see three possible solutions -- 1) Modify Task() to handle wrapping of the delay and millis() calculations. This would be the cleanest solution, and I think it would also fix another problem that I believe exists, which is when millis() itself rolls over and the 'delay' value is large and millis() is small because it just rolled over. In other words, Task() should calculate the delta time since the last call and not compare against the absolute value of millis() itself. 2) Add a delay logic reset function to the class that the client can call after it has to enter a period of suspending USB I/O. This would be a bit clunky, but is better than nothing. 3) Make Usb.Task() callable from a timer interrupt rather than having to be polled.

I originally tried to put the calling of the Usb.Task() function inside an interrupt driven timer tick so that it could happen without being part of the main loop and still be called during the other processing periods when polling isn't possible -- i.e. make it interrupt driven instead of polled. But I quickly found that the Task() function doesn't like being called from within an interrupt handler, as there seems to be a problem with nested interrupts and it receiving data from the USB channel while inside the timer tick interrupt. If you turn on the trace and watch it, that's where it seems to stop and just hangs, and I couldn't find an easy fix for it without completely reworking Task().

So, in my opinion, the best overall set of fixes would be to first fix the delta vs. absolute time issue in Task() itself as described in solution option 1, and then later work on redoing Task() to allow it to be interrupt driven as described in solution option 3 to eliminate it from having to be polled by the main loop. I'm currently doing the polling in my stdio getchar() handler which is called from the libc read() function, and it would be nice to decouple the USB logic from stdio completely. That would be the best solution.

I'm going to look into at least implementing solution option 1 and I will try to follow this post up with a fix for that. I think that needs to be done regardless of making Task() work as interrupt driven instead of polled. Otherwise, I think there's still going to be problems where millis() itself happens to roll over, even when calling Task() is done sufficiently often.

[bbx10]

The USB Host Shield library has a next-generation UHS30 project which is interrupt driven. I do not know much about it though. The plan is to have one library for host shield hardware as well as for native USB (Due and Zero). But as far as I know there is no native USB support yet. If you decide to try interrupt driven, it might be useful to look at UHS30.

[dewhisna]

Thanks for the suggestion on the UHS30 code. I'll have to find some time to look at that. In the meantime, I've implemented solution option 1 to fix the time wrapping issues in the Task() function and solve the problem I was experiencing. I've already submitted a pull-request to the libraries team, but it's at dewhisna/USBHost@ff3d990 (the usb_task_delta_time branch) if you'd like to pick it up too.