USB isochronous

NTDEV
1

Hi,

I have a question regarding the USB isochronous endpoint.

I am developing a usb driver in kdmf for my instrument. Basically my instrument captures analog data and converts it into digital data. I need to get the data out from the micro-controller through USB at high rate. As this is kind of capturing device.

I looked into the USB specification and found out that USB isochronous is best suitable endpoint for this purpose. My usb device is full speed only so I can send 1023 bytes per frame. Also, on the bus, only my device will be connected. so there is no bandwidth problem here.

I need to know how to implement the continuous reader.

Also, i have two applications which are running side by side. But need to get the same data from the usb driver. In other words, usb device data needs to be shared between applications. I can’t use COM server or any service application. Is it possible if I do it somehow at driver level.

Regards.

2

How about NOT using iso and using Bulk or Interrupt instead? Seriously. Life immediately becomes easier and your problem regarding continuous reader is solved.

Yes, it’s a simple matter of programming. Just keep track of the number of open instances, buffer the read data internally in your driver, and service the reads coming from each application separately. Exactly HOW you implement this will greatly depend on exactly how you want this to work, but… not hard at all.

Peter
OSR

3

Thanks for the reply Peter.

What is the approach for bulk or interrupt if I go through that route.

Also, for knowledge sake, how will I deal this problem with isochronous.

I have read this article: -

http://msdn.microsoft.com/en-gb/library/windows/hardware/hh406225(v=vs.85).aspx

Also, I thought that if I create a separate thread and send two URBs while I am waiting for the two URBs to be completed. I will prepare the next two URBs. And when the URBs gets completed then I will send the next two prepared URBs.

Regards.

4

Well, you’re going to write your driver using KMDF, right? There’s a built-in function call “USB Continuous Reader” that takes care of exactly this sort of thing FOR you, for Interrupt or Bulk endpoints.

In terms of rolling-your-own (I suggest you not do this and) you just handle it like you would any “keep an I/O in progress” type of thing, in user-mode or kernel-mode… no difference. Send down a few Requests, when one completes, pass along or buffer the input, and then immediately send down a replacement. The number of Requests you need to keep pending is a function of (a) the rapidity with which Requests are being completed, and (2) the amount of processing you need to perform for each Request when it’s completed.

Peter
OSR

5

To add to what peter said…for a cont reader there is no need for a dedicated thread or waiting for the io to complete. Everything is async. You submit the reads, when one completes, you send it back down again. The hard part with a cont reader is corralling all of those reads in flight (by canceling and then when for ALL to complete) when you need to stop them for pnp or power state changes. A complete PIA.

d

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@osr.com
Sent: Tuesday, December 11, 2012 9:27 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] USB isochronous

Well, you’re going to write your driver using KMDF, right? There’s a built-in function call “USB Continuous Reader” that takes care of exactly this sort of thing FOR you, for Interrupt or Bulk endpoints.

In terms of rolling-your-own (I suggest you not do this and) you just handle it like you would any “keep an I/O in progress” type of thing, in user-mode or kernel-mode… no difference. Send down a few Requests, when one completes, pass along or buffer the input, and then immediately send down a replacement. The number of Requests you need to keep pending is a function of (a) the rapidity with which Requests are being completed, and (2) the amount of processing you need to perform for each Request when it’s completed.

Peter
OSR

NTDEV is sponsored by OSR

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

6

xxxxx@prescott-instruments.com wrote:

What is the approach for bulk or interrupt if I go through that route.

I don’t understand what you’re asking. Have you looked at the USB
samples in the WDK? KMDF includes a continuous reader component for
bulk and interrupt pipes that does the work for you (see
WdfUsbTargetPipeConfigContinuousReader). You might even be able to use
UMDF for this.

Also, for knowledge sake, how will I deal this problem with isochronous.

What problem? The concept of a continuous reader is just about the same
for all three pipe types, except that isochronous URBs are formatted a
little differently.

Also, I thought that if I create a separate thread and send two URBs while I am waiting for the two URBs to be completed. I will prepare the next two URBs. And when the URBs gets completed then I will send the next two prepared URBs.

You do not need a separate thread. Create several URBs and submit them
all at once. In the completion routine, copy the data somewhere (a
circular buffer, maybe?) and resubmit the request again.

Even better, just use the KMDF continuous reader. It handles these
details for you.

Remember that USB is a scheduled bus – the host controller scheduled
the frame in advance, and submit it to the hardware as a batch. If you
do not have an empty request ready and waiting when the controller does
its scheduling, you will miss that frame.

Also, i have two applications which are running side by side. But need to get the same data from the usb driver. In other words, usb device data needs to be shared between applications. I can’t use COM server or any service application. Is it possible if I do it somehow at driver level.

Why can you not use a service application? That’s a much better
solution. NEVER do anything in kernel mode that does not absolutely
have to be in kernel mode. Just provide an interface DLL that hides all
of the internals, and have the applications use that DLL. That way, you
can change your mind partway through, and no one will know or care.

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

7

Since you said that no other device will be on the USB you don’t need the bandwidth guarantee that isochronous transfers give you at great expense in complexity, lack of data quality guarantee and lots and lots of development time. If you can do it in UMDF you have just saved months of development and testing and improved system reliability. M.

----- Original Message -----
From: Tim Roberts
To: Windows System Software Devs Interest List
Sent: Tuesday, December 11, 2012 5:47 PM
Subject: Re: [ntdev] USB isochronous

xxxxx@prescott-instruments.com wrote:
> What is the approach for bulk or interrupt if I go through that route.

I don’t understand what you’re asking. Have you looked at the USB
samples in the WDK? KMDF includes a continuous reader component for
bulk and interrupt pipes that does the work for you (see
WdfUsbTargetPipeConfigContinuousReader). You might even be able to use
UMDF for this.

Also, for knowledge sake, how will I deal this problem with isochronous.

What problem? The concept of a continuous reader is just about the same
for all three pipe types, except that isochronous URBs are formatted a
little differently.