Feature reports are never lost?

[kentwmartin]

I just finished reading the 5th edition of USB Complete. It is very informative, but there is a sentence in the book I don't quite understand. In chapter 13, Human Interface Devices: Host Application, it says on page 309-310 "If you need to be absolutely sure not to lose a report, use Feature reports." I wish Jan had explained this a bit more. How are feature reports not susceptible to being lost?

[Jan Axelson]

From page 309, referring to reports read with interrupt transfers:

The host’s HID driver stores received reports in a ring buffer. A request to get a report returns the oldest report in the buffer. If the driver’s buffer is empty, the read operation waits for a report to arrive until a timeout occurs. If the buffer is full when a new report arrives, the buffer drops the oldest report.

I'm glad to hear you found USB Complete useful!

[kentwmartin]

Thanks for the reply. I thought this applied to all input reports. Does it not?

[Jan Axelson]

For Input reports transferred via interrupt transfers, the host driver uses the ring buffer to store received reports.

For Input reports transferred via control transfers and for all Feature reports, there are no periodic transfers. Instead, the device sends data in the Data stage of the control transfer.

[ulao]

I always saw it this way.

interrupts: - Always on time but buffered. FILO CON: data loss.

feature: - FIFO not timed well. CON: Waiting  for transfer to start and complete can take time.

Maybe there is more to it but this seems to apply well.

[Jan Axelson]

I like this, except the ring buffer for interrupt transfers is FIFO - first in, first out.

Control transfers don't really have a buffer; they just send the current data.

[ulao]

Sorry I did say that wrong.

[Jan Axelson]

no problem, thanks for weighing in!