usbsamp driver for Win8

wesley · January 15, 2013, 12:49am

Recently, I download the newest version usbsamp code.

It:

Support SS bulk stream.
ISO transfer code change a lot.

For

I have test it, and it works for different stream numbers of the bulk EP.
For ISO

I still using old version for USB3.0 device test
1.it must multiple of 8 packets, if not driver will make it conform, and any Total LENGTH is acceptable.
2.using ASAP scheme

But newest version:

no multiple of 8 packets restriction, but it only acceptable total length as multiple of TransferSizePerFrame

How ridiculous?

Which means that Application could only assign
Testapp.exe -w or -r multiple of TransferSizePerFrame

//////////////////////////////////////////////////////////////////////////////////
if ((TotalLength % pipeContext->TransferSizePerFrame) != 0) {
UsbSamp_DbgPrint(1, (“The transfer must evenly start and end on whole frame boundaries.\n”));
UsbSamp_DbgPrint(1, (“Transfer length should be multiples of %d\n”, pipeContext->TransferSizePerFrame));
status = STATUS_INVALID_PARAMETER;
goto Exit;
}
//////////////////////////////////////////////////////////////////////////////////

using start frame number instead of ASAP.
This is used for delete code of race condition.

Can any one give comments about the restriction of:
it only acceptable total length as multiple of TransferSizePerFrame

OSR_Community_User · January 15, 2013, 12:57am

The restriction seems odd, but to make it supportable, there should be an
IOCTL_QUERY_TRANSFER_FRAME_SIZE, because when applications start
hardwiring these values, I get real nervous about binary compatibility. I
have not looked at the code at all, so don’t know if this already exists.
But I think it would be better to not have such an arbitrary restriction.
joe

Recently, I download the newest version usbsamp code.

It:

Support SS bulk stream.

ISO transfer code change a lot.

For

I have test it, and it works for different stream numbers of the bulk
EP.

For ISO

I still using old version for USB3.0 device test
1.it must multiple of 8 packets, if not driver will make it conform, and
any Total LENGTH is acceptable.
2.using ASAP scheme

But newest version:

no multiple of 8 packets restriction, but it only acceptable total
length as multiple of TransferSizePerFrame

How ridiculous?

Which means that Application could only assign
Testapp.exe -w or -r multiple of TransferSizePerFrame

//////////////////////////////////////////////////////////////////////////////////
if ((TotalLength % pipeContext->TransferSizePerFrame) != 0) {
UsbSamp_DbgPrint(1, (“The transfer must evenly start and end on
whole frame boundaries.\n”));
UsbSamp_DbgPrint(1, (“Transfer length should be multiples of
%d\n”, pipeContext->TransferSizePerFrame));
status = STATUS_INVALID_PARAMETER;
goto Exit;
}
//////////////////////////////////////////////////////////////////////////////////

using start frame number instead of ASAP.
This is used for delete code of race condition.

Can any one give comments about the restriction of:
it only acceptable total length as multiple of TransferSizePerFrame

NTDEV is sponsored by OSR

OSR is HIRING!! See http://www.osr.com/careers

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

wesley · January 15, 2013, 1:11am

Another consideration:

code:
//////////////////////
NT_ASSERT(pipeInfo.MaximumPacketSize == wBytesPerInterval);
pipeContext->TransferSizePerMicroframe = wBytesPerInterval;

numberOfFrames = TotalLength / pipeContext->TransferSizePerFrame;
numberOfPackets = TotalLength / pipeContext->TransferSizePerMicroframe;
////////////////////////
1.
wBytesPerInterval is the length of EP service interval total length.
It doesn’t mean that it will transfer in one micro frame.
2.
And for

///
pipeContext->TransferSizePerMicroframe = wBytesPerInterval;
numberOfPackets = TotalLength / pipeContext->TransferSizePerMicroframe;
///
doesn’t really tell us the real number of packets
because in USB3.0 DP length max is 1024 bytes
wBytesPerInterval could more than one DP

wesley · January 15, 2013, 1:15am

hi, Joe

there is no interface as:
IOCTL_QUERY_TRANSFER_FRAME_SIZE

OSR_Community_User · January 15, 2013, 5:52am

I would think that any interface which imposes a buffer constraint would
have a call to specify what that constraint is. If there is no call, the
constraint should not exist, because it cannot be checked, only assumed.
joe

hi, Joe

there is no interface as:
IOCTL_QUERY_TRANSFER_FRAME_SIZE

NTDEV is sponsored by OSR

OSR is HIRING!! See http://www.osr.com/careers

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

Tim_Roberts · January 15, 2013, 12:31pm

workingmailing@163.com wrote:

Recently, I download the newest version usbsamp code.
…
But newest version:

no multiple of 8 packets restriction, but it only acceptable total length as multiple of TransferSizePerFrame

The limitation has never been “multiple of 8”. The limitation has
always been that an isochronous URB has to span a whole number of frames
(NOT microframes). If your interval is 1, that means a multiple of 8.
If your interval is 2, that means a multiple of 4. If your interval is
4, that means a multiple of 2. If your interval is 8 or more, there are
no restrictions.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

wesley · January 15, 2013, 8:09pm

Hi, Tim,

I have not got any clue/text/MSDN from WDK that URB should span a whole number of frames.

And on the other hand:
With Usbsamp driver/algorithm, ISO EP out service interval is 1ms(what you said, 8), maxpacket siz is 1K
This driver send out 8, 128 bytes DPs in 8ms of each 1ms.
It is not what I wanted case: 1K DP in any microframe of the 1ms service interval.

Tim_Roberts · January 16, 2013, 12:32pm

workingmailing@163.com wrote:

I have not got any clue/text/MSDN from WDK that URB should span a whole number of frames.

http://msdn.microsoft.com/en-us/library/windows/hardware/hh406225.aspx,
check about 1/4 of the way down, under “what are the restrictions on the
number of packets for each bus speed.” This has always been the case
for USB 2.0.

And on the other hand:
With Usbsamp driver/algorithm, ISO EP out service interval is 1ms(what you said, 8),

The “whole number of frames” rule is for isochronous IN endpoints. I
don’t believe it is enforced for isochronous OUT, but if your interval
is 8, then each packet is one frame, so it’s not an issue.

maxpacket siz is 1K
This driver send out 8, 128 bytes DPs in 8ms of each 1ms.
It is not what I wanted case: 1K DP in any microframe of the 1ms service interval.

OK, so do that. The sample code is just that – generic sample code.
It’s not a straightjacket.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

wesley · January 16, 2013, 11:23pm

thank you Tim.

this link give very details.

And another useful information: MaximumPacketSize in different speed, especially in Superspeed.

wesley · January 17, 2013, 12:05am

The “whole number of frames” rule is for isochronous IN endpoints. I
don’t believe it is enforced for isochronous OUT, but if your interval
is 8, then each packet is one frame, so it’s not an issue.

can you give the reason of you consideration of:
it it for In but not for OUT?

wesley · January 17, 2013, 12:35am

I found in the link code sample Tim supplied:

if (numberOfPackets % numberOfPacketsPerFrame != 0)
{

// Number of packets should be a multiple of numberOfPacketsPerFrame
ntStatus = STATUS_INVALID_PARAMETER;
goto Exit;
}

actually, in old version USBSAMP code, it has a algorithm for make the packets to 8.

So, I think ,for MS
it it better

update the code sample, merge the algorithm, with different interval case.
For example, same algrithom but for different numberOfPacketsPerFrame

Tim_Roberts · January 17, 2013, 1:29pm

workingmailing@163.com wrote:

>The “whole number of frames” rule is for isochronous IN endpoints. I
>don’t believe it is enforced for isochronous OUT, but if your interval
>is 8, then each packet is one frame, so it’s not an issue.

can you give the reason of you consideration of:
it it for In but not for OUT?

I’m not quite sure what you are asking. Are you asking “why do I think
it’s not enforced for isochronous OUT?”

Remember that, for isochronous OUT, the host controller driver knows
exactly how much data will be involved. If a transfer only needs two
packets to complete, then it knows there will be no need for further
transfers in that frame. With isochronous IN, there is an assumption
that you asked for an interval of 1 because your device has enough data
for every microframe. It simplifies the scheduling to have one request
for the whole frame instead of stitching together multiple requests.

On the other hand, maybe my memory is faulty. Isochronous OUT devices
are not all that common.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.