--- /dev/null
+<!-- Copyright (C) 2003 Red Hat, Inc. -->
+<!-- This material may be distributed only subject to the terms -->
+<!-- and conditions set forth in the Open Publication License, v1.0 -->
+<!-- or later (the latest version is presently available at -->
+<!-- http://www.opencontent.org/openpub/). -->
+<!-- Distribution of the work or derivative of the work in any -->
+<!-- standard (paper) book form is prohibited unless prior -->
+<!-- permission is obtained from the copyright holder. -->
+<HTML
+><HEAD
+><TITLE
+>Data Endpoints</TITLE
+><meta name="MSSmartTagsPreventParsing" content="TRUE">
+<META
+NAME="GENERATOR"
+CONTENT="Modular DocBook HTML Stylesheet Version 1.76b+
+"><LINK
+REL="HOME"
+TITLE="eCos Reference Manual"
+HREF="ecos-ref.html"><LINK
+REL="UP"
+TITLE="eCos USB Slave Support"
+HREF="io-usb-slave.html"><LINK
+REL="PREVIOUS"
+TITLE="Control Endpoints"
+HREF="usbs-control.html"><LINK
+REL="NEXT"
+TITLE="Writing a USB Device Driver"
+HREF="usbs-writing.html"></HEAD
+><BODY
+CLASS="REFENTRY"
+BGCOLOR="#FFFFFF"
+TEXT="#000000"
+LINK="#0000FF"
+VLINK="#840084"
+ALINK="#0000FF"
+><DIV
+CLASS="NAVHEADER"
+><TABLE
+SUMMARY="Header navigation table"
+WIDTH="100%"
+BORDER="0"
+CELLPADDING="0"
+CELLSPACING="0"
+><TR
+><TH
+COLSPAN="3"
+ALIGN="center"
+>eCos Reference Manual</TH
+></TR
+><TR
+><TD
+WIDTH="10%"
+ALIGN="left"
+VALIGN="bottom"
+><A
+HREF="usbs-control.html"
+ACCESSKEY="P"
+>Prev</A
+></TD
+><TD
+WIDTH="80%"
+ALIGN="center"
+VALIGN="bottom"
+></TD
+><TD
+WIDTH="10%"
+ALIGN="right"
+VALIGN="bottom"
+><A
+HREF="usbs-writing.html"
+ACCESSKEY="N"
+>Next</A
+></TD
+></TR
+></TABLE
+><HR
+ALIGN="LEFT"
+WIDTH="100%"></DIV
+><H1
+><A
+NAME="USBS-DATA">Data Endpoints</H1
+><DIV
+CLASS="REFNAMEDIV"
+><A
+NAME="AEN16660"
+></A
+><H2
+>Name</H2
+>Data Endpoints -- Data endpoint data structures</DIV
+><DIV
+CLASS="REFSYNOPSISDIV"
+><A
+NAME="AEN16663"><H2
+>Synopsis</H2
+><TABLE
+BORDER="5"
+BGCOLOR="#E0E0F0"
+WIDTH="70%"
+><TR
+><TD
+><PRE
+CLASS="SYNOPSIS"
+>#include <cyg/io/usb/usbs.h>
+
+typedef struct usbs_rx_endpoint {
+ void (*start_rx_fn)(struct usbs_rx_endpoint*);
+ void (*set_halted_fn)(struct usbs_rx_endpoint*, cyg_bool);
+ void (*complete_fn)(void*, int);
+ void* complete_data;
+ unsigned char* buffer;
+ int buffer_size;
+ cyg_bool halted;
+} usbs_rx_endpoint;
+
+typedef struct usbs_tx_endpoint {
+ void (*start_tx_fn)(struct usbs_tx_endpoint*);
+ void (*set_halted_fn)(struct usbs_tx_endpoint*, cyg_bool);
+ void (*complete_fn)(void*, int);
+ void* complete_data;
+ const unsigned char* buffer;
+ int buffer_size;
+ cyg_bool halted;
+} usbs_tx_endpoint;</PRE
+></TD
+></TR
+></TABLE
+></DIV
+><DIV
+CLASS="REFSECT1"
+><A
+NAME="AEN16665"
+></A
+><H2
+>Receive and Transmit Data Structures</H2
+><P
+>In addition to a single <SPAN
+CLASS="STRUCTNAME"
+>usbs_control_endpoint</SPAN
+>
+data structure per USB slave device, the USB device driver should also
+provide receive and transmit data structures corresponding to the
+other endpoints. The names of these are determined by the device
+driver. For example, the SA1110 USB device driver package provides
+<TT
+CLASS="LITERAL"
+>usbs_sa11x0_ep1</TT
+> for receives and
+<TT
+CLASS="LITERAL"
+>usbs_sa11x0_ep2</TT
+> for transmits.</P
+><P
+>Unlike control endpoints, the common USB slave package does provide a
+number of utility routines to manipulate data endpoints. For example
+<A
+HREF="usbs-start-rx.html"
+><TT
+CLASS="FUNCTION"
+>usbs_start_rx_buffer</TT
+></A
+>
+can be used to receive data from the host into a buffer. In addition
+the USB device driver can provide devtab entries such as
+<TT
+CLASS="LITERAL"
+>/dev/usbs1r</TT
+> and <TT
+CLASS="LITERAL"
+>/dev/usbs2w</TT
+>, so
+higher-level code can <TT
+CLASS="FUNCTION"
+>open</TT
+> these devices and then
+perform blocking <TT
+CLASS="FUNCTION"
+>read</TT
+> and
+<TT
+CLASS="FUNCTION"
+>write</TT
+> operations.</P
+><P
+>However, the operation of data endpoints and the various
+endpoint-related functions is relatively straightforward. First
+consider a <SPAN
+CLASS="STRUCTNAME"
+>usbs_rx_endpoint</SPAN
+> structure. The
+device driver will provide the members
+<TT
+CLASS="STRUCTFIELD"
+><I
+>start_rx_fn</I
+></TT
+> and
+<TT
+CLASS="STRUCTFIELD"
+><I
+>set_halted_fn</I
+></TT
+>, and it will maintain the
+<TT
+CLASS="STRUCTFIELD"
+><I
+>halted</I
+></TT
+> field. To receive data, higher-level
+code sets the <TT
+CLASS="STRUCTFIELD"
+><I
+>buffer</I
+></TT
+>,
+<TT
+CLASS="STRUCTFIELD"
+><I
+>buffer_size</I
+></TT
+>,
+<TT
+CLASS="STRUCTFIELD"
+><I
+>complete_fn</I
+></TT
+> and optionally the
+<TT
+CLASS="STRUCTFIELD"
+><I
+>complete_data</I
+></TT
+> fields. Next the
+<TT
+CLASS="STRUCTFIELD"
+><I
+>start_rx_fn</I
+></TT
+> member should be called. When
+the transfer has finished the device driver will invoke the completion
+function, using <TT
+CLASS="STRUCTFIELD"
+><I
+>complete_data</I
+></TT
+> as the first
+argument and a size field for the second argument. A negative size
+indicates an error of some sort: <TT
+CLASS="LITERAL"
+>-EGAIN</TT
+> indicates
+that the endpoint has been halted, usually at the request of the host;
+<TT
+CLASS="LITERAL"
+>-EPIPE</TT
+> indicates that the connection between the
+host and the peripheral has been broken. Certain device drivers may
+generate other error codes.</P
+><P
+>If higher-level code needs to halt or unhalt an endpoint then it can
+invoke the <TT
+CLASS="STRUCTFIELD"
+><I
+>set_halted_fn</I
+></TT
+> member. When an
+endpoint is halted, invoking <TT
+CLASS="STRUCTFIELD"
+><I
+>start_rx_fn</I
+></TT
+>
+wit <TT
+CLASS="STRUCTFIELD"
+><I
+>buffer_size</I
+></TT
+> set to 0 indicates that
+higher-level code wants to block until the endpoint is no longer
+halted; at that point the completion function will be invoked.</P
+><P
+>USB device drivers are allowed to assume that higher-level protocols
+ensure that host and peripheral agree on the amount of data that will
+be transferred, or at least on an upper bound. Therefore there is no
+need for the device driver to maintain its own buffers, and copy
+operations are avoided. If the host sends more data than expected then
+the resulting behaviour is undefined.</P
+><P
+>Transmit endpoints work in essentially the same way as receive
+endpoints. Higher-level code should set the
+<TT
+CLASS="STRUCTFIELD"
+><I
+>buffer</I
+></TT
+> and
+<TT
+CLASS="STRUCTFIELD"
+><I
+>buffer_size</I
+></TT
+> fields to point at the data to
+be transferred, then call <TT
+CLASS="STRUCTFIELD"
+><I
+>start_tx_fn</I
+></TT
+>, and
+the device driver will invoked the completion function when the
+transfer has completed.</P
+><P
+>USB device drivers are not expected to perform any locking. If at any
+time there are two concurrent receive operations for a given endpoint,
+or two concurrent transmit operations, then the resulting behaviour is
+undefined. It is the responsibility of higher-level code to perform
+any synchronisation that may be necessary. In practice, conflicts are
+unlikely because typically a given endpoint will only be accessed
+sequentially by just one part of the overall system.</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="usbs-control.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-writing.html"
+ACCESSKEY="N"
+>Next</A
+></TD
+></TR
+><TR
+><TD
+WIDTH="33%"
+ALIGN="left"
+VALIGN="top"
+>Control Endpoints</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"
+>Writing a USB Device Driver</TD
+></TR
+></TABLE
+></DIV
+></BODY
+></HTML
+>
\ No newline at end of file
projects / karo-tx-redboot.git / blobdiff