A few years ago I created a UMDF driver that’s used with a CCD camera. An application will do a readfile, the driver will create a new bulk request to allow the read request to be a multiple of the packet size. It pends the original request for later completion and then forwards the newly created request to the input pipe.
In the completion callback, based on the pContext the original request is located in the manual queue and completed.
This has been working fine, however with a recent upgrade to a larger format CCD chip, artifacts are starting to show up in the read data. The artifacts (brighter pixels) occur at regular intervals in the received data every 4MB.
The bulk read itself is for several MB of data that represent a single full frame readout of the CCD pixels. The hardware has limited buffering available (4KB) and reads data out of the chip based on the clocks the USB chip on the device generates. The current feeling is that after 4MB of transfer, the host usb chip clock is halted for a small amount of time before resuming transfer which causes artifacts on the following few pixels read.
After a bit of searching, I found the following link on the MS website
http://msdn.microsoft.com/en-us/library/windows/hardware/ff538112(v=vs.85).aspx
which notes transfer sizes for high speed devices on windows 7 are limited to 4MB. It may be a coincidence, but this ties up with the amount of data transfered before each cycle of the artifacts occur. Perhaps due to the latency involved in setting up another transfer?
Assuming this is indeed the issue (suggestions welcome if you think it may be something else), can anyone suggest a way to work around this? I considered a switch to Isochronous, but the loss of guaranteed delivery makes this unsuitable.
If something below the UMDF code is splitting the 12+MB transfer into 3+ transfers, is there any way to allow the next transfer to begin prior to the previous transfer been ack’d?
Driver and firmware can be modified as needed, the only thing that’s not really an option is hardware changes, such as adding RAM to pre-buffer the entire CCD frame prior to sending, such that any USB delays wouldn’t impact the data readout.
Regards,
Gary