usbs-intro.html

有关ecos2。0介绍了实时嵌入式的结构以及线程调度的实现和内存的管理等

> and
<TT
CLASS="FUNCTION"
>write</TT
>, or non-blocking USB-specific calls, to
transfer data between host and target via a specific endpoint. Control
messages are more complicated but are usually handled by existing
code.</P
><P
>When a USB peripheral is plugged into the host there is an initial
enumeration and configuration process. The peripheral provides
information such as its class of device (audio, video, etc.), a
vendor id, which endpoints should be used for what kind of data, and
so on. The host OS uses this information to identify a suitable host
device driver. This could be a generic driver for a class of
peripherals, or it could be a vendor-specific driver. Assuming a
suitable driver is installed the host will then activate the USB
peripheral and perform additional application-specific initialisation.
For example for a USB-ethernet device this would involve obtaining an
ethernet MAC address. Most USB peripherals will be fairly simple, but
it is possible to build multifunction peripherals with multiple
configurations, interfaces, and alternate interface settings.</P
><P
>It is not possible for any of the eCos packages to generate all the
enumeration data automatically. Some of the required information such
as the vendor id cannot be supplied by generic packages; only by the
application developer. Class support code such as the USB-ethernet
package could in theory supply some of the information automatically,
but there are also hardware dependencies such as which endpoints get
used for incoming and outgoing ethernet frames. Instead it is the
responsibility of the application developer to provide all the
enumeration data and perform some additional initialisation. In
addition, the common USB slave package can handle all the standard
control messages for a simple USB peripheral, but for something like a
multifunction peripheral additional application support is needed.</P
><DIV
CLASS="NOTE"
><BLOCKQUOTE
CLASS="NOTE"
><P
><B
>Note: </B
>The initial implementation of the eCos USB slave packages involved
hardware that only supported control and bulk transfers, not
isochronous or interrupt. There may be future changes to the USB
code and API to allow for isochronous and interrupt transfers,
especially the former. Other changes may be required to support
different USB devices. At present there is no support for USB remote
wakeups, since again it is not supported by the hardware.</P
></BLOCKQUOTE
></DIV
></DIV
><DIV
CLASS="REFSECT1"
><A
NAME="AEN16075"
></A
><H2
>eCos USB I/O Facilities</H2
><P
>For protocols other than control messages, eCos provides two ways of
performing USB I/O. The first involves device table or devtab entries such
as <A
HREF="usbs-devtab.html"
><TT
CLASS="LITERAL"
>/dev/usb1r</TT
></A
>,
with one entry per endpoint per USB device. It is possible to
<TT
CLASS="FUNCTION"
>open</TT
> these devices and use conventional blocking
I/O functions such as <TT
CLASS="FUNCTION"
>read</TT
> and
<TT
CLASS="FUNCTION"
>write</TT
> to exchange data between host and
peripheral.</P
><P
>There is also a lower-level USB-specific API, consisting of functions
such as <A
HREF="usbs-start-rx.html"
><TT
CLASS="FUNCTION"
>usbs_start_rx_buffer</TT
></A
>.
A USB device driver will supply a data structure for each endpoint,
for example a <A
HREF="usbs-data.html"
><SPAN
CLASS="STRUCTNAME"
>usbs_rx_endpoint</SPAN
></A
>
structure for every receive endpoint. The first argument to
<TT
CLASS="FUNCTION"
>usbs_start_rx_buffer</TT
> should be a pointer to such
a data structure. The USB-specific API is non-blocking: the initial
call merely starts the transfer; some time later, once the transfer
has completed or has been aborted, the device driver will invoke a
completion function.</P
><P
>Control messages are different. With four different categories of
control messages including application and vendor specific ones, the
conventional
<TT
CLASS="FUNCTION"
>open</TT
>/<TT
CLASS="FUNCTION"
>read</TT
>/<TT
CLASS="FUNCTION"
>write</TT
>
model of I/O cannot easily be applied. Instead, a USB device driver
will supply a <A
HREF="usbs-control.html"
><SPAN
CLASS="STRUCTNAME"
>usbs_control_endpoint</SPAN
></A
>
data structure which can be manipulated appropriately. In practice the
standard control messages will usually be handled by the common USB
slave package, and other control messages will be handled by
class-specific code such as the USB-ethernet package. Typically,
application code remains responsible for supplying the <A
HREF="usbs-enum.html"
>enumeration data</A
> and for actually <A
HREF="usbs-start.html"
>starting</A
> up the USB device.</P
></DIV
><DIV
CLASS="REFSECT1"
><A
NAME="AEN16097"
></A
><H2
>Enabling the USB code</H2
><P
>If the target hardware contains a USB slave device then the
appropriate USB device driver and the common packages will typically
be loaded into the configuration automatically when that target is
selected (assuming a suitable device driver exists). However, the
driver will not necessarily be active. For example a processor might
have an on-chip USB device, but not all applications using that
processor will want to use USB functionality. Hence by default the USB
device is disabled, ensuring that applications do not suffer any
memory or other penalties for functionality that is not required.</P
><P
>If the application developer explicitly adds a class support package
such as the USB-ethernet one then this implies that the USB device is
actually needed, and the device will be enabled automatically.
However, if no suitable class package is available and the USB device
will instead be accessed by application code, it is necessary to
enable the USB device manually. Usually the easiest way to do this is
to enable the configuration option
<TT
CLASS="LITERAL"
>CYGGLO_IO_USB_SLAVE_APPLICATION</TT
>, and the USB device
driver and related packages will adjust accordingly. Alternatively,
the device driver may provide some configuration options to provide
more fine-grained control.</P
></DIV
><DIV
CLASS="NAVFOOTER"
><HR
ALIGN="LEFT"
WIDTH="100%"><TABLE
SUMMARY="Footer navigation table"
WIDTH="100%"
BORDER="0"
CELLPADDING="0"
CELLSPACING="0"
><TR
><TD
WIDTH="33%"
ALIGN="left"
VALIGN="top"
><A
HREF="io-usb-slave.html"
ACCESSKEY="P"
>Prev</A
></TD
><TD
WIDTH="34%"
ALIGN="center"
VALIGN="top"
><A
HREF="ecos-ref.html"
ACCESSKEY="H"
>Home</A
></TD
><TD
WIDTH="33%"
ALIGN="right"
VALIGN="top"
><A
HREF="usbs-enum.html"
ACCESSKEY="N"
>Next</A
></TD
></TR
><TR
><TD
WIDTH="33%"
ALIGN="left"
VALIGN="top"
>eCos USB Slave Support</TD
><TD
WIDTH="34%"
ALIGN="center"
VALIGN="top"
><A
HREF="io-usb-slave.html"
ACCESSKEY="U"
>Up</A
></TD
><TD
WIDTH="33%"
ALIGN="right"
VALIGN="top"
>USB Enumeration Data</TD
></TR
></TABLE
></DIV
></BODY
></HTML
>