hello ,my dear friend,thank you for you answer in “is it the bug of wdk and wdm”,and now I post a new thread to summarize the subject which discussed some day ago.
At first,I introduce the background of my driver. this is a Camera driver,and I Communication with the hardware through communication protocol,First i build a vendor request and Send a setup packet,and listen the Endpoint ,then read the dada.The hardware receive my request and prepare send dada.the hareware buffer is 2K,and every time fill 512 bytes in it ,and it fill the buffer whether the data read or not. if the read speed is slower,then the dada will be cover with,at this time,it will be receive not enough dada.
and the camera driver must judge whether the dada is enough or not ,when it not enough ,I will send a request to the hardware ,and the hardware send the dada again.
I change the wdk’s usbsamp for my Camera driver,and use bulk transfer.
my application pragram set the buffer equal to the driver’s MAX_TRANSFER_SIZE, it is run well usually, but when the request timeout,I can not receive any datas,the transfer size is zero.
And now ,there are some problem with it ?
(1) I am modify the wdk’s usbsamp driver for my camera device ,and the
application buffer is 2014208 bytes. I change usbsamp’s MAX_TRANSFER_SIZE to
2014208,and usually run well,but some time IO request timeout ,and at this time
,it can not receive any datas.
(2)if the device send dada size less than the MAX_TRANSFER_SIZE of driver,at this time ,is it the driver can not receive any dada?
(3) I change MAX_TRANSFER_SIZE to 512,or 2048, It timeout every time ,but it can return some data which less than 2014208. I am confused why MAX_TRANSFER_SIZE influence the results? and when MAX_TRANSFER_SIZE is smaller,it every time timeout ,is it stand for call Complete routine need much time. so I modify MAX_TRANSFER_SIZE to 2014208,at this time ,only call complete routine one time. but when it timeout ,will receive no dada.
(4)Chris Aseltine say" I suspect you’ve sent down a request for 2MB
down to USB, and the device has responded with some fraction of that which is an
exact multiple of the endpoint’s maximum packet size. Since the device did not
send a short packet, the transfer never completed."
yes, the hardware not send a short packet or zero packet,but now the camera usually run well ,and sometime can not receive any data? why?
(5)and thanks for Tim Roberts,you say “Well, here is a question for the KMDF folks. If I submit a USB requestand set a timeout in the WDF_REQUEST_SEND_OPTIONS, will I be able torecover whatever partial buffer had been transferred by the time of the timeout? I’ve never had occasion to test that.” ,I think it is a good topic to discuss?
(6)Tim Roberts say "Interesting. There must be a solution for this, because there are
situations in USB that cannot be reasonably handled in any other way. Consider a device that sends between 100k and 200k bytes at random(potentially long) intervals. You can’t afford to send a bazillion 512-byte requests because of the overhead. You need to send a larger request, but then you need a way to bring back the partial buffer after
a timeout. " it is a good topic to discuss ,because my device run well in linux ,and my hardware team say it is not the device problem because of this ,and say it driver problem or windows system problem.
(7)thank you Peter Viscarola,and you say "OR, he COULD just hang a bunch of 512 byte packets out there… since his device isn’t transferring short blocks, those packets would be completely filled by a transfer, right?? Isn’t that what we’re talking about? ",to you answer,i will say ,though it not send a short parket or zero parket ,but in my opinion,it will receive some dada,because It is already send some dada before receive short parket or zero parket .
(8) and Hagen Patzke says
"Well, here Chris is backed by the USB 2.0 spec, section 5.8.3:
A bulk 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
" thank you Hagen Patzke ,I have a question ,if the device not send a short packet or zero packet,and when it lose some dada ,is it the application program can not receive any dada? thank you ?
(9)and some people suggest me to receive 512 bytes every time ,but I test it ,every time timeout ,and Tim Roberts says " For a 2M transfer, you’retalking about 4,000 IRPs, and they will be completed at a rate of 120 per millisecond. For one frame, you could do it, but if you’re streaming, it can’t be done. You can’t sustain it" and I say before ,I reduce the max_transfer_size to 512 bytes,and also timeout,because so many complete route.
(10)thank you Peter Viscarola ,you say “TOTALLY right. Shit flows down hill, and it’s us driver devs who are perennially at the bottom of that hill looking up. OS problem? We get to work around it. Bug in the silicon? We get to compensate for it. Firmware deficiency? Fix it up. And when these things don’t work, it’s ALWAYS our fault.”
I agree with you standpoint ,and my hardware say my device run well in linux ,so it you problem.
thank you ,every one,and welcome every body discuss this problem with me ?
thank you very much indeed.
stone
2010.09.06