isousb.htm

usb主机驱动 同步端点 用于 语音视频

  simply to demonstrate the technique of continually recycling a pair of IRPS for constant
  throughput.</FONT></TD>
</TR>
<TR><TD WIDTH="17%" VALIGN="TOP">
<FONT SIZE=2><P>rwiso.rc</FONT></TD>
<TD WIDTH="83%" VALIGN="TOP">
<FONT SIZE=2><P>Main resource file</FONT></TD>
</TR>
<TR><TD WIDTH="17%" VALIGN="TOP">
<FONT SIZE=2><P>makefile</FONT></TD>
<TD WIDTH="83%" VALIGN="TOP">
<FONT SIZE=2><P>DDK build environment makefile</FONT></TD>
</TR>
<TR><TD WIDTH="17%" VALIGN="TOP">
<FONT SIZE=2><P>sources</FONT></TD>
<TD WIDTH="83%" VALIGN="TOP">
<FONT SIZE=2><P>Generic sources file</FONT></TD>
</TR>

</TABLE>

<FONT size=2><P ALIGN="RIGHT"></P>
</FONT><FONT size=2><P>The following steps briefly describe the operation of the
 USB isochronous I/O minidriver. The sample minidriver routines mentioned here are described
 in greater detail in the comments of the sample source code and in routine-specific
 comments later in this article. It is helpful here to follow along in the sample code.</P>
</FONT><B><I><FONT FACE="Arial" SIZE=4><P> Loading The Driver</P>
</B></I></FONT><FONT size=2><P>When IsoUsb.sys is loaded by the operating system,
the minidriver抯 <B>DriverEntry</B> routine (in IsoUsb.c) is called to set the
Dispatch entry points for the MajorFunction IRPs that it handles and for AddDevice.</P>
<P>Notice that no resources are allocated here, because it should not be assumed
 that a Plug and Play device is actually plugged in at driver load time. Resource
  allocation and the creation of the Functional Device Object (FDO) do not occur
   until the device is detected by the USB stack. At this point, Plug and Play
    Manager calls the minidriver抯 <B>IsoUsb_PnPAddDevice</B> routine (in Isopnp.c),
	 which in turn calls the following functions:</P>
<B><P>IsoUsb_CreateDeviceObject</B> (in IsoUsb.c) is called to create the FDO and a
 DeviceExtension. Notice that <B>IsoUsb_SymbolicLink</B> (in IsoUsb.c) is called here
  to create and initialize a GUID-based symbolic link to the device that is used to
  open/create instances of the minidriver from user mode.</P>
<B><P>IsoUsb_QueryCapabilities</B> (in IsoPwr.c) is called to learn which system power
 states are to be mapped to which device power states for honoring IRP_MJ_POWER IRPs.
 To do this, an IRP is created by IsoUsb.sys using IoAllocateIrp() and set up with
  MajorFunction = IRP_MJ_PNP and MinorFunction = IRP_MN_QUERY_CAPABILITIES. This IRP
  is sent to the PDO, which is represented by the USB class driver, using IoCallDriver().
   A DEVICE_CAPABILITIES structure describing the device抯 power capabilities is returned
   and saved in the FDO抯 device extension.</P>
<B><P>IsoUsb_SelfSuspendOrActivate</B> (in IsoPwr.c) is called to try to power down
the device until data transfer is actually requested. This is because there may be a
significant time between device detection and the first time an application actually
uses the device for I/O梖or example, if a USB camera is kept plugged in at all times
but used only occasionally. IsoUsb.sys attempts to power down the device when no I/O
pipes are actually open on it.</P>
<P>After the USB stack assigns any resources to the device, it sends an IRP_MN_START_DEVICE
 that is handled by this minidriver抯 <B>IsoUsb_ProcessPnPIrp</B> routine (in Isopnp.c).
  Several additional minor Plug and Play IRPs are used by Plug and Play Manager to ensure
   the orderly stopping and removal of devices for purposes such as resource balancing.
    See the &quot;Stopping and Removing the Device&quot; section later in this article
	 for a discussion of how these minor Plug and Play IRPs are handled by
	  <B>IsoUsb_ProcessPnPIrp</B>.</P>
</FONT><B><I><FONT FACE="Arial" SIZE=4><P> Opening the Device and Performing File IO</P>
</B></I></FONT><FONT size=2><P>At this point the minidriver is operational;
let抯 talk about what needs to be done to start isochronous data transfer. RwIso.exe
can initiate data transfer via two distinct methods. The first is
by making CreateFile, ReadFile, WriteFile, and CloseHandle calls from
 within its <B>main</B> function. 
 Please refer to the "Bulk I/O Operation: Opening The Device" section in the BulkUsb documentation
 for a discussion on
 how the symbolic linkages are built up, and also see the description there of the pipes
 supported on our test board ( Both samples were developed on the same hardware ). In IsoUsb,
 the ReadFile/WriteFile handlers in OcrwIso.c work much the same as their Bulk IO counterparts in
 BulkUsb (OcrwBlk.c),
 allocating and freeing IRP  and URB ( USB Request Blocks ) structures for each IO request,
 and synchronously returning  to User mode with no furthur processing until more user-mode requests
 are made. There is little differerence in the interaction with USBDI except for using the URB
 flags  URB_FUNCTION_ISOCH_TRANSFER instead of URB_FUNCTION_BULK_OR_INTERRUPT_TRANSFER
   in USBDI IO requests. The other few URB_xxx request types used are the same as in the
   BulkUsb sample; see BulkUsb.htm as well as code comments in both samples
<P>
IsoUsb also defines a couple of special IOCTLS for starting and stopping a test
Isochronous stream that runs continuously for a specified number of seconds.
This is the heart of the IsoUsb sample. The main technique being illustrated here is a 
means of insuring that the minidriver
itself does not introduce any additional 'accidental' stream latency in the handling of a
continuous time-critical isochronous data stream to or from the device. For as long as the
stream is continuously running, a single pair of IRPS (and their associated URBS for communicating
with USBDI) are recycled; this eliminates the need for constant allocation and freeing
of IRP and URB data structures for the handling of every stream data block. The details
are discussed below in the section on IOCTL_ISOUSB_START_ISO_STREAM.



</FONT><FONT size=2><P ALIGN="RIGHT">&nbsp;</P>
</FONT><B><I><FONT FACE="Arial" SIZE=4><P> Handling IOCTLs</P>
</I></FONT><FONT size=2><P>IsoUsb_ProcessIOCTL</B> (in Ioctlblk.c) is the entry-point
 that is registered to handle IRP_MJ_DEVICE_CONTROL IRPs. Notice that there are
  circumstances under which <B>IsoUsb_ProcessIOCTL</B> can refuse to accept an
   I/O Control (IOCTL) request, such as if a device is removed. The IOCTLs
   handled by this function are described in this section and are defined in
   IsoUsb.h. All the discussed driver-defined structures are defined in Iso82930.h.</P>
<P>IsoUsb.h defines 5 IOCTLs for user-mode applications to access the driver
 using DeviceIoControl() calls.</P>

 <UL>

 <LI>IOCTL_ISOUSB_START_ISO_STREAM -- 

 When the driver receives this ioctl from RwIso.exe,
  <B>IsoUsb_StartIsoStream</B> is called to initiate a continuous stream from the device.
  
  A driver-defined stream descriptor structure,ISOUSB_STREAM_OBJECT ,
   is allocated  that contains an array of two ISOUSB_TRANSFER_OBJECT structures.
   These two transfer objects encapsulate the two sets of IRP/URB pairs that will be 
   kept endlessly recycling. IsoUsb_StartIsoStream next opens the Isochrounous input pipe
   ( on our test board this is pipe #5 of 6 ) . Note that the User App in this sample
   does not make a CreateFile() call to open the pipe or a CloseHandle() call
   to close it; we just 'hard-code' the use of this pipe, and the IOCTL_ISOUSB_STOP_ISO_STREAM
   logic internally closes it . Next a KEVENT object is initialized which is signalled whenever
   the count of pending Isochrnous stream IO IRPs goes to zero ( from a possible maximum of
   two: one for each of our transfer objects ). IOCTL_ISOUSB_STOP_ISO_STREAM will wait on this 
   event before completing and returning to the user.

   A defferred timeout procedure, <B>IsoUsb_StreamTimeoutDPC()</B> is set up to check for
    stream timeouts and errors, although
   in this sample the routine does little except reschedule itself whenever it is invoked.
   One suggested enhancement to the logic of this  mindriver would be to time-stamp the
   transfer object each time it is submitted. <B>IsoUsb_StreamTimeoutDPC()</B> would then
   iterate through the transfer objects and see if any had pending IRPS that were too old.

<B>IsoUsb_StartTransfer</B> is then called on each of the two ISOUSB_TRANSFER_OBJECT structures.
For each transfer object IsoUsb_StartTransfer allocates an IRP to be  used to pass the
 request through the NT driver stack, and a URB (USB Request Block ) for communication with USBDI.
Once the IRP/URB pair is allocated and initialized, the initial stream IO request is generated
by a call to <B>IsoUsb_InitializeStreamUrb</B> which sets up the URB for a call to USBDI.
<B>IoCallDriver()</B> is called on the IRP with the completion routine set to
<B>IsoUsb_IsoIrp_Complete</B>. The way the recycling of the transfer object IRP/URB pairs works
is that unless there have been errors  or the user has
submitted a IOCTL_ISOUSB_STOP_ISO_STREAM  since the last  transfer,
<B>IsoUsb_IsoIrp_Complete</B> always resubmits the IRP to the stack and the URB to USBDI.
It also calls <B>IsoUsb_ProcessTransfer</B> on each completed request.This is
where a driver for a real device would collect and/or process data in the buffers,
but this sample just checks for errors. Specifically, it checks the IRP stastus field, the
URB header status field, and then walks through the URB's list of packets checking the status
of  each. USBD breaks up transfers internally to 8-byte packets.
<B>IsoUsb_ProcessTransfer</B> and <B>IsoUsb_IsoIrp_Complete</B> also collect statistics on
total number of packets processed, total bytes processed,total number of errors, 
 and total number of times transfer objects were recycled.

<p>

 </LI>


 <LI>IOCTL_ISOUSB_STOP_ISO_STREAM -- 

 When the driver receives this ioctl from RwIso.exe,
  <B>IsoUsb_StopIsoStream</B> is called to terminate streaming from the device.
  A flag is reset in the stream object, "IsoStreamStarted", so that <B>IsoUsb_IsoIrp_Complete</B>
  will not resubmit the the transfers upon next completion. This flag also tells
  <B>IsoUsb_StreamTimeoutDPC()</B> not to reschedule itself. One this is done, we wait for the
  "NoPendingIrpEvent" to be signalled by <B>IsoUsb_IsoIrp_Complete</B>.
  Next we free the IRPS, URBS, and data buffers in the transfer objects, as well as freeing the
  stream object itself. Finally, the Isochrounous pipe is closed and we power the device down to
  D3 until more IO is requested.
  
 <p>

 </LI>



<P><LI>IOCTL_ISOUSB_GET_CONFIG_DESCRIPTOR calls <B>IsoUsb_GetConfigDescriptor</B>
to get a copy of the USB configuration descriptor that IsoUsb.sys saves at
 AddDevice time, and then returns a copy of the descriptor in the user-mode I/O buffer.
  The configuration descriptor is parsed by RwIso.exe to provide a nicely
   formatted console dump of the device configuration and endpoints (named pipes).</LI></P>
</FONT><FONT SIZE=2>

 </UL>
<P>The other two IOCTLs are not used by this sample console application,
but may be used by a more sophisticated application to deal with certain
user-mode device errors:</P>
 <UL>

</FONT><FONT size=2><LI>IOCTL_ISOUSB_RESET_DEVICE calls <B>IsoUsb_ResetDevice</B>.</LI>
<LI>IOCTL_ISOUSB_RESET_PIPE calls <B>IsoUsb_ResetPipe</B>. Both of
these functions are called internally by IsoUsb.sys in its read/write
logic as part of normal error handling. <B>IsoUsb_ResetDevice</B> attempts
 a complete reset of the USB port, while <B>IsoUsb_ResetPipe </B>only deals
 with error conditions on a particular pipe.</LI>
 
 
 </UL>

</FONT><FONT size=2><P ALIGN="RIGHT">&nbsp;</P>
</FONT><B><I><FONT FACE="Arial" SIZE=4><P>Supporting References for
 IsoUsb Sample Minidriver</P>
</B></I></FONT><FONT SIZE=2><P>The following additional materials will
 help you understand this sample minidriver:</P>

<UL>
</FONT>
<I><FONT size=2>
<LI>USB Specification Version 1.0</I>, as well as the
clarifications and enhancements to the core specification recommended by the USB
 Device Working Group. These documents are available on the web at http://www.usb.org.</LI>
 
<I><LI>Microsoft Windows NT&nbsp;5.0 DDK</I>, available through MSDN Professional
 membership, contains references to WDM core services used by IsoUsb.sys, as well
  as reference material for IRPs that IsoUsb.sys handles.</LI>
<I><LI>WDM USB Driver Interface</I> contains background information on the USB
driver interface. This document is available on the web
at http://www.microsoft.com/hwdev/wdmusb.htm.</LI>

<I><FONT size=2>
<LI>Handling Asynchronous Bulk Data Transfer in a USB Minidriver</I>, (BulkUsb.htm),
located in the same section of
 the ddk as this document.</LI></UL>

</FONT><P ALIGN="CENTER"><A HREF="#top"><FONT FACE="Verdana" SIZE=2>Top of page</FONT></A><FONT FACE="Verdana" SIZE=2> </P></FONT>
<TABLE CELLSPACING=0 BORDER=0 WIDTH=624>
<TR><TD VALIGN="MIDDLE" BGCOLOR="#00ffff" HEIGHT=2>
<P></TD>
</TR>
</TABLE>

<FONT FACE="MS Sans Serif" SIZE=1><P>&copy; 1999 Microsoft Corporation</FONT><FONT FACE="Verdana" SIZE=2> </P></FONT></BODY>
</HTML>