1 <!-- Copyright (C) 2001 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 substantively modified versions of this -->
7 <!-- document is prohibited without the explicit permission of the -->
8 <!-- copyright holder. -->
9 <!-- Distribution of the work or derivative of the work in any -->
10 <!-- standard (paper) book form is prohibited unless prior -->
11 <!-- permission is obtained from the copyright holder. -->
15 >USB-ethernet Data Transfers</TITLE
18 CONTENT="Modular DocBook HTML Stylesheet Version 1.64
21 TITLE="eCos Support for Developing USB-ethernet Peripherals"
22 HREF="io-usb-slave-eth.html"><LINK
24 TITLE="Initializing the USB-ethernet Package"
25 HREF="usbseth-init.html"><LINK
27 TITLE="USB-ethernet State Handling"
28 HREF="usbseth-control.html"></HEAD
47 >eCos Support for Developing USB-ethernet Peripherals</TH
55 HREF="usbseth-init.html"
68 HREF="usbseth-control.html"
79 >USB-ethernet Data Transfers</A
88 >USB-ethernet Data Transfers -- Exchanging ethernet packets with the USB host</DIV
90 CLASS="REFSYNOPSISDIV"
110 CLASS="FUNCSYNOPSISINFO"
111 >#include <cyg/io/usb/usbs_eth.h></PRE
119 >void usbs_eth_start_rx</CODE
120 >(usbs_eth* usbseth, unsigned char* buffer, void (*)(usbs_eth*, void*, int) complete_fn, void* complete_data);</CODE
126 >void usbs_eth_start_tx</CODE
127 >(usbs_eth* usbseth, unsigned char* buffer, void (*)(usbs_eth*, void*, int) complete_fn, void* complete_data);</CODE
141 >The USB-ethernet package provides two main modes of operation. In the
142 first mode it provides a <A
143 HREF="usbseth-netdev.html"
146 > for use by a TCP/IP stack running inside the USB
147 peripheral. All incoming ethernet packages should be passed up the
148 TCP/IP stack, and only the stack will generate outgoing packets. Apart
150 HREF="usbseth-init.html"
154 HREF="usbseth-control.html"
155 >control operations</A
157 higher-level code will not interact with the USB-ethernet package
160 >In the second mode there is no TCP/IP stack running inside the USB
161 peripheral. For example, a simple USB-ethernet converter has an
162 ethernet chip and a USB port: ethernet packets received by the
163 ethernet chip need to be forwarded to the USB host, and ethernet
164 packets sent by the USB host need to be sent out of the ethernet chip.
167 >usbs_eth_start_rx</TT
171 >usbs_eth_start_tx</TT
172 > allow for this lower-level
173 access to the USB-ethernet package.</P
175 >The two modes of operation are mutually exclusive. If the network
176 device driver mode is enabled then application code should communicate
177 at the TCP/IP level, and not by using the lower-level functions.
178 Instead, it is the network device driver that will make use of these
179 functions, and it assumes that it has exclusive access. The package
180 does not perform any locking.</P
182 >The transmit and receive functions work in much the same way. The
183 first argument identifies the <SPAN
187 structure that should be used. For the majority of applications this
191 >. The second argument specifies
192 the location of the ethernet packet; outgoing for
195 >usbs_eth_start_tx</TT
199 >usbs_eth_start_rx</TT
200 >. This buffer should correspond
202 HREF="usbseth-protocol.html"
211 >Outgoing packets can consist of up to 1516 bytes, consisting of a
212 two-byte header specific to USB-ethernet followed by a standard
213 ethernet frame (a header with 6-byte destination address, 6-byte
214 source address and a further two bytes, followed by a payload of
215 up to 1500 bytes). The two-byte USB-ethernet header consists simply of
216 the size of the ethernet frame, i.e. the size of the rest of the
217 packet not including the USB-ethernet header, with the least
218 significant byte first.</P
222 >For incoming packets the supplied buffer should usually be at least
223 1516 bytes. There may be special circumstances in which a smaller
224 buffer might be safe; for example, if the host-side device driver is
225 modified to support only smaller packets. Once the packet has been
226 received the buffer will contain a two-byte header specific to
227 USB-ethernet, followed by a normal ethernet frame. The header
228 gives the size of the ethernet frame, excluding the header, with the
229 least significant byte first.</P
235 >usbs_eth_start_tx</TT
239 >usbs_eth_start_rx</TT
240 > are asynchronous: the transfer
241 is started and, some time later, a completion function will be invoked.
242 The third and fourth arguments to both
245 >usbs_eth_start_tx</TT
249 >usbs_eth_start_rx</TT
250 > supply the completion function
251 and an argument to that function respectively. The completion function
252 will be invoked with three arguments: a pointer to the
256 > data structure, usually
260 >; the supplied completion data ; and a
261 return code field. A negative value indicates that an error occurred,
265 > if the connection between USB
266 host and peripheral has been broken, or <TT
270 an endpoint has been halted. A positive value indicates the total size
271 of the transfer, which should correspond to the size in the
272 USB-ethernet header plus an additional two bytes for the header
275 >If the data transfer is succesful then the completion function will
276 typically be invoked in DSR context rather than in thread context,
277 although this depends on the implementation of the underlying USB
278 device driver. Therefore the completion function is restricted in what
279 it can do; in particular, it must not make any calls that will or may
280 block such as locking a mutex or allocating memory. The kernel
281 documentation should be consulted for more details of DSR's and
282 interrupt handling generally. Note that if the transfer finishes
283 quickly then the completion function may be invoked before
286 >usbs_eth_start_rx</TT
290 >usbs_eth_start_tx</TT
291 > returns. This is especially
292 likely to happen if the current thread is descheduled after starting
293 the data transfer but before returning from these functions.</P
295 >For transmit operations, it is possible for
298 >usbs_eth_start_tx</TT
299 > to invoke the completion
300 function immediately. If there is no current connection between host
301 and target then the transmit will fail immediately with
305 >. In addition the USB-ethernet package will
306 check the destination MAC address and make sure that the ethernet
307 frame really is intended for the host: either it must be for the
308 address specified in the initialization call <A
309 HREF="usbseth-init.html"
315 it must be a broadcast packet, or the host must have enabled
316 promiscuous mode. </P
333 HREF="usbseth-init.html"
341 HREF="io-usb-slave-eth.html"
349 HREF="usbseth-control.html"
358 >Initializing the USB-ethernet Package</TD
368 >USB-ethernet State Handling</TD