USBHost.Task() and USBSerial.flush() What are they?

[ValStorm]

Hello,

I searched as much as I could but I can't figure out what USBHost.Task() does. I couldn't find any implementation in the library, just some open and closed brackets, but I see it in lots of examples. My code works without it, but am I missing something?

For USBSerial.flush() when is the use case for this? It appears that USBSerial.write() gets the info into the buffer and out to the device without it. When is this function ideally used? Again code works without it, but I'm wondering when I might need it.

The USBHost_t36 library is a great gift, but it's very dense and hard to jump into figuring out what's going on.

Thanks for your help!

 

[KurtE]

Many classes do not need anything special and simply don't do anything.

But some classes might.

For example in the USBDrive code, it has a ::task() implementation that when task is called and the drive state has changed, i.e. lets say you plugged in a new drive into the USBHost,
the drive will have it's partitions enumerated, and volume File system objects created for them.

I did not want to do all of this on an interrupt as it might take a bit of time. So preferred to have on task() where your sketch code has some control over when it is done.

USBSerial.flush(), same thing as Serial1.flush().
Which if you are talking in linux terms does the equivalent of tcdrain() call. '

The idea is that the code should not return until the last bits of the output data have been sent out over the wire.
When to use? Hard thing to say precisely. But for example, suppose you have code that maybe does a request out to whatever is plugged in, and then waits for a response to come back before doing something else. (or converse, you receive a request) and you know the other side will not continue until it receives your response. So, using something, like this can help reduce latency. However, it can easily reduce data throughput, as you are not transferring full buffers.

But there is also a risk that it WONT help in latency. It may depend on what type of Serial adapter that is connected. That is some, like FTDI it helps with, some that are not FTDI, it can be detrimental.

Hope that helps, as I know clear as mud.

 

[ValStorm]

Excellent. Thank you. That does help.

In lieu of starting another thread... I'm curious if there's any way to know if a device (USBHost w/ USBSerial) has been unplugged or plugged back in... specifically one not using power on the bus. Just a DPDT on the data lines.

Is there a keep alive thing happening? Or is there something I could overload/override/callback from to get control during these events?

Or would this be something I would have to implement?

The device works going in and out but I would like to update/refresh its state switching back over.