When sending read requests to the OSR FX kit I’m finding that my read
request buffer size must exactly match the size of the previous write
request.
i.e.
Write 512 bytes followed by read 512 bytes: No Problem.
Write 512 bytes followed by read 1024 bytes: Fails
I was expecting the latter to succeed and just return 512 bytes, but this is
not the case.
Is it possible to make it work like this, or is this just the nature of USB?
Chris
Please provide more information than “it fails”. Specifically, what is the
value of Urb->UrbHeader.Status? Look in usb.h (or usbdi.h) to find the
corresponding USBD_STATUS_* value to find the symbolic name of the status
value.
That status value is very important for understanding why the request
failed. Also, what are the endpoint descriptors for your device?
– arlie
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@cox.net
Sent: Thursday, April 20, 2006 1:07 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] OSR FX 2 Read Problems
When sending read requests to the OSR FX kit I’m finding that my read
request buffer size must exactly match the size of the previous write
request.
i.e.
Write 512 bytes followed by read 512 bytes: No Problem.
Write 512 bytes followed by read 1024 bytes: Fails
I was expecting the latter to succeed and just return 512 bytes, but this is
not the case.
Is it possible to make it work like this, or is this just the nature of USB?
Chris
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
I setup the timeout options, once the timeout expires the call returns as
expected,
Write 512 bytes followed by read 1024 bytes: Timeout expires with a read of
512 bytes.
Chris
wrote in message news:xxxxx@ntdev…
> When sending read requests to the OSR FX kit I’m finding that my read
> request buffer size must exactly match the size of the previous write
> request.
>
> i.e.
> Write 512 bytes followed by read 512 bytes: No Problem.
> Write 512 bytes followed by read 1024 bytes: Fails
>
> I was expecting the latter to succeed and just return 512 bytes, but this
> is not the case.
> Is it possible to make it work like this, or is this just the nature of
> USB?
>
> Chris
>
>
When sending the read urb down, did you set the short transfer OK flag?
(If you are using kmdf, it is set for you already.)
d
– I can spell, I just can’t type.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@cox.net
Sent: Thursday, April 20, 2006 10:07 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] OSR FX 2 Read Problems
When sending read requests to the OSR FX kit I’m finding that my read
request buffer size must exactly match the size of the previous write
request.
i.e.
Write 512 bytes followed by read 512 bytes: No Problem.
Write 512 bytes followed by read 1024 bytes: Fails
I was expecting the latter to succeed and just return 512 bytes, but
this is
not the case.
Is it possible to make it work like this, or is this just the nature of
USB?
Chris
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
xxxxx@cox.net wrote:
I setup the timeout options, once the timeout expires the call returns as
expected,Write 512 bytes followed by read 1024 bytes: Timeout expires with a read of
512 bytes.
Right. That’s what should happen with this driver. You told it to read
1024 bytes, and it’s going to wait until it has 1024 bytes to return to you.
Remember that this is all synchronous. The driver doesn’t submit a read
request until you read some data. At that point, the driver will
continue to submit read URBs until your read is satisfied.
It is certainly possible to rewrite the driver to disconnect input from
output, so that the driver submits read URBs continuously and queues up
the data in a circular buffer; then, you can have the IRP_MJ_READ
handler return immediately with whatever happens to be available. We
did that on a previous FX2 project. It’s a fair amount of work, but
there are environments where it works better.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
If the driver is written in KMDF, a continuous reader is already
implemented and available for use. Definitely will cut down on the
development time by not developing your own. Handling all the edge cases
takes a bit of time to sort out.
d
– I can spell, I just can’t type.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Tim Roberts
Sent: Thursday, April 20, 2006 1:31 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] OSR FX 2 Read Problems
xxxxx@cox.net wrote:
I setup the timeout options, once the timeout expires the call returns
as
expected,Write 512 bytes followed by read 1024 bytes: Timeout expires with a
read of
512 bytes.
Right. That’s what should happen with this driver. You told it to read
1024 bytes, and it’s going to wait until it has 1024 bytes to return to
you.
Remember that this is all synchronous. The driver doesn’t submit a read
request until you read some data. At that point, the driver will
continue to submit read URBs until your read is satisfied.
It is certainly possible to rewrite the driver to disconnect input from
output, so that the driver submits read URBs continuously and queues up
the data in a circular buffer; then, you can have the IRP_MJ_READ
handler return immediately with whatever happens to be available. We
did that on a previous FX2 project. It’s a fair amount of work, but
there are environments where it works better.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer