RE: interrupt transfers

[John S. <joh...@au...>]

> Is there an example somewhere showing interrupt transfers stacked up
> and resubmitted ? Although setting different timeouts is getting me
> past this problem I suspect I might need to recalculate the timeout on
> each resubmission to ensure there are a certain number outstanding at
> all times ?
>

Do you really need the timeout?  Usually, a timeout on an interrupt pipe
is just an escape hatch, in case something goes horribly wrong.  In that
case, you could set it to a very long interval that was unlikely to
occur in real life.

[John Stirling] 

Setting the timeout to eg 15 seconds results works ok for a few
transfers but then seems to occasionally stick (for about 15 seconds)
and then delivers the data via the interrupt callback 15 seconds later
than it is actually observed on the USB trace.

I initially tried with timeout=0. That seems to result in a few
successful transfers followed by nothing. Possibly this is the same
problem as above.

I'm guessing above is not expected behaviour.

Going back to my original example with 10 transfers stacked up I have
double checked that they have not timed out at the point where the
problem occurs. The USB analyser shows two packets successfully
transferred on HID report 1. There is a 1ms gap between the two. I'm
only seeing data from the 2nd packet appear in the callback. The index
of the transfer is as expected (ie one greater than the last rx
transfer). It's like the 2nd packet has just overwritten the 1st.

If I repeat the test several times I am occasionally seeing the first
packet. I can't see any pattern to this yet.

Any suggestions ?

Audio Partnership PLC, Gallery Court, Hankey Place, London SE1 4BB, UK 
Reg No. 2953313
This e-mail is confidential and for the addressee only. 
Please refer to <a href="http://www.audiopartnership.com/AP-disclaimer.html">Disclaimer</a>  for important notices.