Adapting hidusbfx2 sample to use isoc transfers
in [Device Drivers]
|
Prev: What is the difference between using IOCTL to write/read IO ports vs. modifying IOPM and using _INP/OUTP_ ??
Next: Problem attaching WinDbg to target after WDK7600 upgrade
From: Egidio [MSFT] on 4 Sep 2009 13:26 Yes, you are right. At this time you have to build your own isoc continuous reader. Remember to pend minimum 2 or 3 read isoc URBs at USB level. And depending on your application/technology behind the USB bus you may also need to set the USB frame# for these transfers. Writing a good isoc continuous reader is not simple. Note that (a), (b) and (c) below are just a sequence of steps not options: i.e., your app tells your driver to start reading (app/driver interface), the driver reads data in its internal buffer (driver/usb interface), and then the app reads this data using other irps (app/driver interface). Egi. "sinosoidal" <sinosoidal(a)discussions.microsoft.com> wrote in message news:4E0517C8-FDC5-49A9-B0D3-9CD427F36334(a)microsoft.com... > Hi Egidio, > > I would for the b option, however, as I know there is no continuous reader > for isoc endpoints... right? > > At least, I have tried already and they don't work... am I right? > > That would be the most easy option. > > Please tell me that i'm wrong! :P > > Nuno > > "Egidio [MSFT]" wrote: > >> Doesn't look like there are other samples on this (do a search for 'isoc' >> in >> the sample directory). >> Isoc input is not very common and how it is done depends a lot on the >> type >> of technology that sits behind the USB bus: Bluetooth, audio/video, >> proprietary device, other. I.e., each environment has it own standards >> and >> constraints on how the isoc transfer needs to be accomplished. >> Like Tim suggested, one possible solutions is: >> (a) app sends down an irp to let the driver know when to start reading. >> (b) driver reads input with a isoc continuous reader, puts data in its >> internal buffer. >> (c) app sends down other irps to read this data >> >> Egi. >> >> >> "sinosoidal" <sinosoidal(a)discussions.microsoft.com> wrote in message >> news:920CB12C-8C9E-46D2-A632-FD5C39399771(a)microsoft.com... >> > Hi Tim, >> > >> > Maybe you don't know hidusbfxz2 sample. What it does is to map a non >> > hid >> > device, which in this case is a usb device based on bulk transfers to a >> > hid >> > device, using a miniport driver. Of course I know that HID don't >> > support >> > iso >> > transfer! :) >> > >> > As I have told you the other response you gave me is that I don't know >> > how >> > to prepare the invocation of isoc transfers without being based on user >> > requests because the only reference code I have is the usbsamp for isoc >> > transfers. >> > >> > If you could point me out an example in which this is done in other way >> > or >> > something else that helps me to understand what has to be done in order >> > to >> > accomplish that. >> > >> > I have a very reduced knowledge about WDK and its foundations because >> > i'm >> > only working with this for the last 2 months. >> > >> > With my best regards, >> > >> > Nuno >> > >> > "Tim Roberts" wrote: >> > >> >> sinosoidal <sinosoidal(a)discussions.microsoft.com> wrote: >> >> > >> >> >I'm adapting hidusbfx2 sample to use isoc transfer. To do that i'm >> >> >basing >> >> >myself on the usbsamp sample. >> >> >> >> HID devices cannot use isochronous pipes. They are required to use >> >> interrupt. That's part of the HID class spec. >> >> >> >> >My questions resides if the isoc transfers are always happening but >> >> >the >> >> >data >> >> >is only transfered to the user mode on request or if, the user mode >> >> >request >> >> >triggers the data request from the device at that point. >> >> >> >> It depends on what you need. Both schemes are done. Sometimes, the >> >> driver >> >> creates its own set of URBs, copying into its own circular buffer, and >> >> returns data to the user mode app when needed. Sometimes, the driver >> >> waits >> >> for a request from above. >> >> >> >> >I wanted a similar schema in order to start the reading and have >> >> >something >> >> >similar like a callback on data request completion. >> >> >> >> Fine. That's commonly done. >> >> >> >> >As I don't know very well the possibilities provided by the WDK I >> >> >would >> >> >love >> >> >to hear the opinion of more experienced users and developers. >> >> >> >> Opinion on what? >> >> -- >> >> Tim Roberts, timr(a)probo.com >> >> Providenza & Boekelheide, Inc. >> >> >>
From: Tim Roberts on 5 Sep 2009 16:31
sinosoidal <sinosoidal(a)discussions.microsoft.com> wrote: > >I would for the b option, however, as I know there is no continuous reader >for isoc endpoints... right? The KMDF continuous reader does not support isochronous pipes. Writing your own is not difficult. You do have to make some design decisions, like what are you going to do with the data? Will you allocate a big circular buffer, and have your pool of URBs copy into the buffer? What happens when the buffer fills up? Will you stop submitting, or keep going and throw away the old data? When you're ready to start streaming, you just allocate 4 buffers, 4 requests, and 4 URBs, fill them in, and submit them all right in a row. Then, your completion routine copies the data to your circular buffer (if you want), and resubmits. You also need to check for errors and shutdown conditions. -- Tim Roberts, timr(a)probo.com Providenza & Boekelheide, Inc. |