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 >NEC uPD985xx USB Device Driver</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="NEC uPD985xx USB Device Driver"
23 HREF="devs-usb-nec-upd985xx-ref.html"><LINK
25 TITLE="NEC uPD985xx USB Device Driver"
26 HREF="devs-usb-nec-upd985xx-ref.html"><LINK
28 TITLE="Synthetic Target Ethernet Driver"
29 HREF="devs-eth-synth-ecosynth-ref.html"></HEAD
40 SUMMARY="Header navigation table"
49 >eCos Reference Manual</TH
57 HREF="devs-usb-nec-upd985xx-ref.html"
71 HREF="devs-eth-synth-ecosynth-ref.html"
82 NAME="DEVS-USB-NEC-UPD985XX">NEC uPD985xx USB Device Driver</H1
90 >NEC uPD985xx USB Support -- Device driver for the on-chip NEC uPD985xx USB device</DIV
97 >NEC uPD985xx USB Hardware</H2
99 >The NEC uPD985xx family of processors is supplied with an on-chip USB
100 slave device, the UDC (USB Device Controller). This supports seven
101 endpoints. Endpoint 0 can only be used for control messages. Endpoints
102 1 and 2 are for isochronous transmits and receives respectively.
103 Endpoints 3 and 4 support bulk transmits and receives. Endpoints 5 and
104 6 normally support interrupt transmits and receives, but endpoint 5 can
105 also be configured to support bulk transmits. At this time only the
106 control endpoint 0, the bulk endpoints 3 and 4, and the interrupt
107 endpoint 5 are supported.</P
115 >Endpoint Data Structures</H2
117 >The uPD985xx USB device driver can provide up to four data structures
118 corresponding to the four supported endpoints: a
121 >usbs_control_endpoint</SPAN
125 >usbs_upd985xx_ep0</TT
129 >usbs_tx_endpoint</SPAN
133 >usbs_upd985xx_ep3</TT
137 >usbs_upd985xx_ep5</TT
141 >usbs_rx_endpoint</SPAN
145 >usbs_upd985xx_ep4</TT
149 >cyg/io/usb/usbs_nec_upd985xx.h</TT
151 provides declarations for these.</P
153 >Not all applications will require support for all the endpoints. For
154 example, if the intended use of the UDC only involves peripheral to
155 host transfers then <TT
157 >usbs_upd985xx_ep4</TT
159 The device driver provides configuration options to control the
160 presence of each endpoint:</P
167 >Endpoint 0 is controlled by
170 >CYGFUN_DEVS_USB_UPD985XX_EP0</TT
172 enabled if there are any higher-level packages that require USB
173 hardware or if the global preference
176 >CYGGLO_IO_USB_SLAVE_APPLICATION</TT
178 otherwise it is disabled. Usually this has the desired effect. It may
179 be necessary to override this in special circumstances, for example if
180 the target board uses an external USB chip in preference to the UDC
181 and it is that external chip's device driver that should be used
182 rather than the on-chip UDC. It is not possible to disable endpoint 0
183 and at the same time enable one or both of the other endpoints, since
184 a USB device is only usable if it can process the standard control
189 >Endpoint 3 is controlled by
192 >CYGPKG_DEVS_USB_UPD985XX_EP3</TT
194 endpoint is disabled: according to NEC erratum U3 there may be
195 problems when attempting bulk transfers of 192 bytes or greater. As an
196 alternative the device driver provides support for endpoint 5,
197 configured to allow bulk transfers. Endpoint 3 can be enabled if the
198 application only requires bulk transfers of less than 192 bytes, or if
199 this erratum is not applicable to the system being developed for other
204 >Endpoint 4 is controlled by
207 >CYGPKG_DEVS_USB_UPD985XX_EP4</TT
208 >. This is enabled by
209 default whenever endpoint 0 is enabled, but it can be disabled
214 >Endpoint 5 is controlled by
217 >CYGPKG_DEVS_USB_UPD985XX_EP5</TT
218 >. This is enabled by
219 default whenever endpoint 0 is enabled, but it can be disabled
220 manually. There is also a configuration option
223 >CYGIMP_DEVS_USB_UPD985XX_EP5_BULK</TT
225 default. This option allows the endpoint to be used for bulk
226 transfers rather than interrupt transfers.</P
230 >The uPD985xx USB device driver implements the interface specified by the
231 common eCos USB Slave Support package. The documentation for that
232 package should be consulted for further details. </P
234 >The device driver assumes a bulk packet size of 64 bytes, so this
235 value should be used in the endpoint descriptors in the enumeration
236 data provided by application code. The device driver also assumes
237 a control packet size of eight bytes, and again this should be
238 reflected in the enumeration data. If endpoint 5 is configured for
239 interrupt rather than bulk transfers then the maximum packet size is
240 limited to 64 bytes by the USB standard.</P
250 >In addition to the endpoint data structures the uPD985xx USB device
251 driver can also provide devtab entries for each endpoint. This allows
252 higher-level code to use traditional I/O operations such as
263 rather than the USB-specific non-blocking functions like
266 >usbs_start_rx_buffer</TT
267 >. These devtab entries are
268 optional since they are not always required. The relevant
269 configuration options are
272 >CYGVAR_DEVS_USB_UPD985XX_EP0_DEVTAB_ENTRY</TT
276 >CYGVAR_DEVS_USB_UPD985XX_EP3_DEVTAB_ENTRY</TT
280 >CYGVAR_DEVS_USB_UPD985XX_EP4_DEVTAB_ENTRY</TT
284 >CYGVAR_DEVS_USB_UPD985XX_EP5_DEVTAB_ENTRY</TT
286 default these devtab entries are provided if the global preference
289 >CYGGLO_USB_SLAVE_PROVIDE_DEVTAB_ENTRIES</TT
291 which is usually the case. Obviously a devtab entry for a given
292 endpoint will only be provided if the underlying endpoint is enabled.
293 For example, there will not be a devtab entry for endpoint 4 if
296 >CYGPKG_DEVS_USB_UPD985XX_EP4</TT
299 >The names for the devtab entries are determined by using a
300 configurable base name and appending <TT
314 The base name is determined by the configuration option
317 >CYGDAT_DEVS_USB_UPD985XX_DEVTAB_BASENAME</TT
322 >, so the devtab entry for
323 endpoint 4 would default to <TT
327 target hardware involves multiple USB devices then application
328 developers may have to change the base name to prevent a name clash
329 with other USB device drivers.</P
339 >The current device driver imposes a restriction on certain bulk
340 receives on endpoint 4. If the protocol being used involves
341 variable-length transfers, in other words if the host is allowed to
342 send less data than a maximum-sized transfer, then the buffer passed
343 to the device driver for receives must be aligned to a 16-byte
344 cacheline boundary and it must be a multiple of this 16-byte cacheline
345 size. This restriction does not apply if the protocol only involves
346 fixed-size transfers.</P
354 >Optional Hardware Workarounds</H2
356 >The NEC errata list a number of other problems that affect the USB
357 device driver. The device driver contains workarounds for these, which
358 are enabled by default but can be disabled if the application
359 developer knows that the errata are not relevant to the system being
362 >Erratum S1 lists a possible problem if the device driver attempts
363 multiple writes to the USB hardware. This is circumvented by a
364 dummy read operation after every write. If the workaround is not
365 required then the configuration option
368 >CYGIMP_DEVS_USB_UPD985XX_IBUS_WRITE_LIMIT</TT
369 > can be disabled.</P
371 >Errata U3 and U4 describe various problems related to concurrent
372 transmissions on different endpoints. By default the device driver
373 works around this by serializing all transmit operations. For example
374 if the device driver needs to send a response to a control message on
375 endpoint 0 while there is an ongoing bulk transfer on endpoint 5, the
376 response is delayed until the bulk transfer has completed. Under
377 typical operating conditions this does not cause any problems:
378 endpoint 0 traffic usually happens only during initialization, when
379 the target is connected to the host, while endpoint 5 traffic only
380 happens after initialization. However if transmit serialization is
381 inappropriate for the system being developed then it can be disabled
382 using the configuration option
385 >CYGIMP_DEVS_USB_UPD985XX_SERIALIZE_TRANSMITS</TT
394 >Platform Dependencies</H2
396 >On some platforms it is necessary for the low-level USB device driver
397 to perform some additional operations during start-up. For example it
398 may be necessary to manipulate one of the processor's GPIO lines
399 before the host can detect a new USB peripheral and attempt to
400 communicate with it. This avoids problems if the target involves a
401 significant amount of work prior to device driver initialization, for
402 example a power-on self-test sequence. If the USB host attempted to
403 contact the target before the USB device driver had been initialized,
404 it would fail to get the expected responses and conclude that the
405 target was not a functional USB peripheral.</P
407 >Platform-specific initialization code can be provided via a macro
410 >UPD985XX_USB_PLATFORM_INIT</TT
411 >. Typically this macro
412 would be defined in the platform HAL's header file
415 >cyg/hal/plf_io.h</TT
417 current platform defines such a macro, the USB device driver will
418 invoke it during the endpoint 0 start-up operation.</P
425 SUMMARY="Footer navigation table"
436 HREF="devs-usb-nec-upd985xx-ref.html"
454 HREF="devs-eth-synth-ecosynth-ref.html"
464 >NEC uPD985xx USB Device Driver</TD
470 HREF="devs-usb-nec-upd985xx-ref.html"
478 >Synthetic Target Ethernet Driver</TD