Comtrol eCos - Manual (Page 692)

Devtab Entries
read operations
cyg_io_read and similar functions in higher-level packages can be used to perform a transfer from host to pe-
ripheral. This should be a complete transfer: higher-level protocols should define an upper bound on the amount
of data being transferred, and the
read operation should involve at least this amount of data. The return value will
indicate the actual transfer size, which may be less than requested.
Some device drivers may support partial reads, but USB device drivers are not expected to perform any buffering
because that involves both memory and code overheads. One technique that may work for bulk transfers is to exploit
the fact that such transfers happen in 64-byte packets. It is possible to
read an initial 64 bytes, corresponding to
the first packet in the transfer. These 64 bytes can then be examined to determine the total transfer size, and the
remaining data can be transferred in another
read operation. This technique is not guaranteed to work with all
USB hardware. Also, if the delay between accepting the first packet and the remainder of the transfer is excessive
then this could cause timeout problems for the host-side software. For these reasons the use of partial reads should
be avoided.
There are two likely error conditions. EPIPE indicates that the connection between host and target has been broken.
EAGAIN indicates that the endpoint has been stalled, either at the request of the host or by other activity inside the
peripheral.
USB device drivers are not expected to do any locking. If higher-level code performs multiple concurrent read
operations on a single endpoint then the resulting behaviour is undefined.
select operations
Typical USB device drivers will not provide any support for select . Consider bulk transfers from the host to
the peripheral. At the USB device driver level there is no way of knowing in advance how large a transfer will
be, so it is not feasible for the device driver to buffer the entire transfer. It may be possible to buffer part of the
transfer, for example the first 64-byte packet, and copy this into application space at the start of a
read , but this
adds code and memory overheads. Worse, it means that there is an unknown but potentially long delay between
a peripheral accepting the first packet of a transfer and the remaining packets, which could confuse or upset the
host-side software.
With some USB hardware it may be possible for the device driver to detect OUT tokens from the host without
actually accepting the data, and this would indicate that a
read is likely to succeed. However, it would not be
reliable since the host-side I/O operation could time out. A similar mechanism could be used to implement select
for outgoing data, but again this would not be reliable.
Some device drivers may provide partial support for select anyway, possibly under the control of a configuration
option. The device driver’s documentation should be consulted for further information. It is also worth noting that
the USB-specific non-blocking API can often be used as an alternative to
select .
get_config and set_config operations
There are no set_config or get_config (also known as ioctl ) operations defined for USB devices. Some
device drivers may provide hardware-specific facilities this way.
Note: Currently the USB-specific functions related to halted endpoints cannot be accessed readily via devtab
entries. This functionality should probably be made available via set_config and get_config . It may also prove
useful to provide a get_config operation that maps from the devtab entries to the underlying endpoint data
structures.
588