1 <!-- Copyright (C) 2003 Red Hat, Inc. -->
2 <!-- This material may be distributed only subject to the terms -->
3 <!-- and conditions set forth in the Open Publication License, v1.0 -->
4 <!-- or later (the latest version is presently available at -->
5 <!-- http://www.opencontent.org/openpub/). -->
6 <!-- Distribution of the work or derivative of the work in any -->
7 <!-- standard (paper) book form is prohibited unless prior -->
8 <!-- permission is obtained from the copyright holder. -->
12 >USB-ethernet Data Transfers</TITLE
13 ><meta name="MSSmartTagsPreventParsing" content="TRUE">
16 CONTENT="Modular DocBook HTML Stylesheet Version 1.76b+
19 TITLE="eCos Reference Manual"
20 HREF="ecos-ref.html"><LINK
22 TITLE="eCos Support for Developing USB-ethernet Peripherals"
23 HREF="io-usb-slave-eth.html"><LINK
25 TITLE="Initializing the USB-ethernet Package"
26 HREF="usbseth-init.html"><LINK
28 TITLE="USB-ethernet State Handling"
29 HREF="usbseth-control.html"></HEAD
40 SUMMARY="Header navigation table"
49 >eCos Reference Manual</TH
57 HREF="usbseth-init.html"
71 HREF="usbseth-control.html"
82 NAME="USBSETH-DATA">USB-ethernet Data Transfers</H1
90 >USB-ethernet Data Transfers -- Exchanging ethernet packets with the USB host</DIV
92 CLASS="REFSYNOPSISDIV"
108 CLASS="FUNCSYNOPSISINFO"
109 >#include <cyg/io/usb/usbs_eth.h></PRE
117 >void usbs_eth_start_rx</CODE
118 >(usbs_eth* usbseth, unsigned char* buffer, void (*)(usbs_eth*, void*, int) complete_fn, void* complete_data);</CODE
124 >void usbs_eth_start_tx</CODE
125 >(usbs_eth* usbseth, unsigned char* buffer, void (*)(usbs_eth*, void*, int) complete_fn, void* complete_data);</CODE
139 >The USB-ethernet package provides two main modes of operation. In the
140 first mode it provides a <A
141 HREF="usbseth-netdev.html"
144 > for use by a TCP/IP stack running inside the USB
145 peripheral. All incoming ethernet packages should be passed up the
146 TCP/IP stack, and only the stack will generate outgoing packets. Apart
148 HREF="usbseth-init.html"
152 HREF="usbseth-control.html"
153 >control operations</A
155 higher-level code will not interact with the USB-ethernet package
158 >In the second mode there is no TCP/IP stack running inside the USB
159 peripheral. For example, a simple USB-ethernet converter has an
160 ethernet chip and a USB port: ethernet packets received by the
161 ethernet chip need to be forwarded to the USB host, and ethernet
162 packets sent by the USB host need to be sent out of the ethernet chip.
165 >usbs_eth_start_rx</TT
169 >usbs_eth_start_tx</TT
170 > allow for this lower-level
171 access to the USB-ethernet package.</P
173 >The two modes of operation are mutually exclusive. If the network
174 device driver mode is enabled then application code should communicate
175 at the TCP/IP level, and not by using the lower-level functions.
176 Instead, it is the network device driver that will make use of these
177 functions, and it assumes that it has exclusive access. The package
178 does not perform any locking.</P
180 >The transmit and receive functions work in much the same way. The
181 first argument identifies the <SPAN
185 structure that should be used. For the majority of applications this
189 >. The second argument specifies
190 the location of the ethernet packet; outgoing for
193 >usbs_eth_start_tx</TT
197 >usbs_eth_start_rx</TT
198 >. This buffer should correspond
200 HREF="usbseth-protocol.html"
209 >Outgoing packets can consist of up to 1516 bytes, consisting of a
210 two-byte header specific to USB-ethernet followed by a standard
211 ethernet frame (a header with 6-byte destination address, 6-byte
212 source address and a further two bytes, followed by a payload of
213 up to 1500 bytes). The two-byte USB-ethernet header consists simply of
214 the size of the ethernet frame, i.e. the size of the rest of the
215 packet not including the USB-ethernet header, with the least
216 significant byte first.</P
220 >For incoming packets the supplied buffer should usually be at least
221 1516 bytes. There may be special circumstances in which a smaller
222 buffer might be safe; for example, if the host-side device driver is
223 modified to support only smaller packets. Once the packet has been
224 received the buffer will contain a two-byte header specific to
225 USB-ethernet, followed by a normal ethernet frame. The header
226 gives the size of the ethernet frame, excluding the header, with the
227 least significant byte first.</P
233 >usbs_eth_start_tx</TT
237 >usbs_eth_start_rx</TT
238 > are asynchronous: the transfer
239 is started and, some time later, a completion function will be invoked.
240 The third and fourth arguments to both
243 >usbs_eth_start_tx</TT
247 >usbs_eth_start_rx</TT
248 > supply the completion function
249 and an argument to that function respectively. The completion function
250 will be invoked with three arguments: a pointer to the
254 > data structure, usually
258 >; the supplied completion data ; and a
259 return code field. A negative value indicates that an error occurred,
263 > if the connection between USB
264 host and peripheral has been broken, or <TT
268 an endpoint has been halted. A positive value indicates the total size
269 of the transfer, which should correspond to the size in the
270 USB-ethernet header plus an additional two bytes for the header
273 >If the data transfer is succesful then the completion function will
274 typically be invoked in DSR context rather than in thread context,
275 although this depends on the implementation of the underlying USB
276 device driver. Therefore the completion function is restricted in what
277 it can do; in particular, it must not make any calls that will or may
278 block such as locking a mutex or allocating memory. The kernel
279 documentation should be consulted for more details of DSR's and
280 interrupt handling generally. Note that if the transfer finishes
281 quickly then the completion function may be invoked before
284 >usbs_eth_start_rx</TT
288 >usbs_eth_start_tx</TT
289 > returns. This is especially
290 likely to happen if the current thread is descheduled after starting
291 the data transfer but before returning from these functions.</P
293 >For transmit operations, it is possible for
296 >usbs_eth_start_tx</TT
297 > to invoke the completion
298 function immediately. If there is no current connection between host
299 and target then the transmit will fail immediately with
303 >. In addition the USB-ethernet package will
304 check the destination MAC address and make sure that the ethernet
305 frame really is intended for the host: either it must be for the
306 address specified in the initialization call <A
307 HREF="usbseth-init.html"
313 it must be a broadcast packet, or the host must have enabled
314 promiscuous mode. </P
321 SUMMARY="Footer navigation table"
332 HREF="usbseth-init.html"
350 HREF="usbseth-control.html"
360 >Initializing the USB-ethernet Package</TD
366 HREF="io-usb-slave-eth.html"
374 >USB-ethernet State Handling</TD