WriteFile access error on UMDF USB driver
in [Device Drivers]
|
Prev: development of a virtual cdrom UMDF driver
Next: marvendas@gmail.com Kit completo deSolenóides ( solenoid ) + chicote Para Câmbio automatico 01M hidramatico Audi A3 Vw Golf gti turbo 62402
From: ricobandito on 24 Feb 2010 12:45 "Tim Roberts" wrote: > ricobandito <ricobandito(a)discussions.microsoft.com> wrote: > >"Tim Roberts" wrote: > >> > >> This is a side trip, but why use an interrupt out pipe? I've never seen > >> the point -- you can do the same thing with bulk and get better > >> performance. > > > >This is what the hardware provides. Not my decision. > > And you can't ask why this decision was made? > > >> How are you "passing on" the request? Are you calling > >> FormatRequestForWrite and ForwardFormattedRequest in your OnWrite handler, > >> like in the sample? Are you seeing an error in your OnCompletion handler? > >> Which error? > > > >Just as you say, error code is some odd value. Does not match any > >meaningful error code. > > You didn't answer any of my questions. > -- > Tim Roberts, timr(a)probo.com > Providenza & Boekelheide, Inc. > . > Oh, and I am using a symbolic line name as well.
From: ricobandito on 24 Feb 2010 12:47 I mean "symbolic link"
From: Tim Roberts on 25 Feb 2010 00:26 ricobandito <ricobandito(a)discussions.microsoft.com> wrote: > >The answer I received was that all packet sizes a small (<= 64 bytes) and >latency for these messages is better than in bulk. That's completely wrong. The CONSISTENCY is better with interrupt, but the LATENCY (and bandwidth) is provably better with bulk. A bulk packet will go out instantly. An interrupt packet must wait for the pipe's interval. >Yes, using FormatRequestForWrite just as in the sample, including call to >ForwardFormattedRequest. OnWrite and OnRead are just as in sample. >Everything I am finding does not appear to point out any differences in this >method, interrupt or bulk. Driver trace is showing OnCompletion being >called with good parameter data, but that does not make it back to the app. That's interesting. So, if you print GetCompletionStatus() and GetInformation() in OnCompletion, the numbers look OK, and don't match the application's result? -- Tim Roberts, timr(a)probo.com Providenza & Boekelheide, Inc.
From: ricobandito on 25 Feb 2010 10:06
"Tim Roberts" wrote: > ricobandito <ricobandito(a)discussions.microsoft.com> wrote: > > > >The answer I received was that all packet sizes a small (<= 64 bytes) and > >latency for these messages is better than in bulk. > > That's completely wrong. The CONSISTENCY is better with interrupt, but the > LATENCY (and bandwidth) is provably better with bulk. A bulk packet will > go out instantly. An interrupt packet must wait for the pipe's interval. > Perhaps I misunderstand then, but the hardware developers are convinced the interrupt is a better option in this case than bulk. I have a basic understanding of USB, so I can't make a strong argument to go with one over the other, and really, that is neither here not there for the situation I am seeing, I don't think. > >Yes, using FormatRequestForWrite just as in the sample, including call to > >ForwardFormattedRequest. OnWrite and OnRead are just as in sample. > >Everything I am finding does not appear to point out any differences in this > >method, interrupt or bulk. Driver trace is showing OnCompletion being > >called with good parameter data, but that does not make it back to the app. > > That's interesting. So, if you print GetCompletionStatus() and > GetInformation() in OnCompletion, the numbers look OK, and don't match the > application's result? Yes, the trace shows all the parameter status such as GetCompletionStatus() and GetInformation() look good. Issue looks to be the driver not getting the right status back to the app, so the writefile on the app is failing. One thing I did try was to remove the completion callback and call CompleteWithInformation() right after the send. This gets we one good WriteFile call, and then I get a failure on the second call, with a GetLastError() of 6. Odd coincidence is that the first byte in the write data is 6. > -- > Tim Roberts, timr(a)probo.com > Providenza & Boekelheide, Inc. > . > |