Jan,
The USB2.0 SPec (and your book) states:
An interrupt transfer is complete when the endpoint does one of the following:
• Has transferred exactly the amount of data expected
• Transfers a packet with a payload size less than wMaxPacketSize or transfers a zero-length packet
Is the 'expected' data the maximum report size for an endpoint, or is it the buffer size that is used in the ReadFile() or WriteFile() functions? I realise that they SHOULD be the same if the host software has correctly used the HidP_GetCaps attributes, but this is not a certainty (should I make that assumption).
My concern stems from the situation where I might have a maximum packet size of say 8 bytes, and the maximum report size is 16bytes.
If I have only 8 bytes to transmit (assuming an IN), it is simple, I send the next packet as a zero-length packet because I have transferred all my data to the buffer, or if I have only 7 bytes to transmit the transfer will complete due to a short packet.
With a maximum report size that is equal to a intergral multiple of the maximum packet size, the transfer will be over after I have transferred 16 bytes. To ensure that I am not trying to send a zero-length packet after sending 16bytes, should I just be keepting track of the number of bytes sent and comparing that to the maximum report size? It seems odd that the spec would not just want to have a zero-length packet next to keep it similar to a Control Transfer. Surely one extra zero length packet is not going to upset the apple cart too much.
This is simple in Control transfers because DATA OUT will only transfer the expected amount of data which is defined in the wLength bytes. It is also simple with an DATA IN because you cannot send an intergral multiple of the maximum packet size without sending a zero-length packet to notify the host that your are complete.
I am probably overthinking this.
Thanks,
Ray
