We’re re-designing our USB 1.1 device and there is one unclear point. We’re communicating with the device using vendor specific control transfers which are taken as commands. Commands are processed by firmware interrupt handler which can take some time. We’d prefer to not buffer more commands so we decided to NAK status stage of vendor transfers until command is really processed. Normally, commands should be processed immediatelly but there can be situations when fw disables interrupts for some time. The question is how long time we can afford. USB specs (9.2.6.4) demands maximum 500 ms for standard device requests and also for class specific requests (9.2.6.5) unless exemption is defined. There is nothing about vendor specific requests. Can we take it as general 5 sec upper limit (9.2.6.1) should be applied? Please note I speak about exceptional case; normally, command would be processed immediatelly or within few ms.
I’d like to know how’d OS drivers behave if status stage is NAKed for relatively long time. From my previous experience (with buggy device) it seems they wait infinitely until request is completed and never give up (unless device is unplug). It’d be OK but what about other OSes? Has anybody an experience in this area?
BTW, in previous version we used different approach. Vendor request was confirmed immediatelly and command buffered and a pending bit set in a status register readable by other request. Host software had to poll status register until pending bit was cleared (when interrupt handler read buffered command). I dislike this approach because is needs unnecessary traffic and there are race conditions between reading status and sending command. So we decided to change it and hw designers prefer NAKing status phase. They dislike other possibility, a FIFO for received commands.
Any comment welcome.
Best regards,
Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]