1 |
786 |
skrzyp |
|
2 |
|
|
|
3 |
|
|
|
4 |
|
|
|
5 |
|
|
|
6 |
|
|
|
7 |
|
|
|
8 |
|
|
|
9 |
|
|
|
10 |
|
|
|
11 |
|
|
|
12 |
|
|
|
13 |
|
|
|
14 |
|
|
|
15 |
|
|
|
16 |
|
|
|
17 |
|
|
|
18 |
|
|
|
19 |
|
|
|
20 |
|
|
|
21 |
|
|
|
22 |
|
|
|
23 |
|
|
|
24 |
|
|
|
25 |
|
|
|
26 |
|
|
|
27 |
|
|
|
28 |
|
|
|
29 |
|
|
|
30 |
|
|
|
31 |
|
|
|
32 |
|
|
|
33 |
|
|
|
34 |
|
|
|
35 |
|
|
|
36 |
|
|
|
37 |
|
|
|
38 |
|
|
|
39 |
|
|
|
40 |
|
|
eCos USB Slave Support
|
41 |
|
|
|
42 |
|
|
|
43 |
|
|
|
44 |
|
|
|
45 |
|
|
|
46 |
|
|
Introduction
|
47 |
|
|
|
48 |
|
|
|
49 |
|
|
Introduction
|
50 |
|
|
eCos support for USB slave devices
|
51 |
|
|
|
52 |
|
|
|
53 |
|
|
Introduction
|
54 |
|
|
|
55 |
|
|
The eCos USB slave support allows developers to produce USB
|
56 |
|
|
peripherals. It consists of a number of different eCos packages:
|
57 |
|
|
|
58 |
|
|
|
59 |
|
|
|
60 |
|
|
|
61 |
|
|
|
62 |
|
|
Device drivers for specific implementations of USB slave hardware, for
|
63 |
|
|
example the on-chip USB Device Controller provided by the Intel SA1110
|
64 |
|
|
processor. A typical USB peripheral will only provide one USB slave
|
65 |
|
|
port and therefore only one such device driver package will be needed.
|
66 |
|
|
Usually the device driver package will be loaded automatically when
|
67 |
|
|
you create an eCos configuration for target hardware that has a USB
|
68 |
|
|
slave device. If you select a target which does have a USB slave
|
69 |
|
|
device but no USB device driver is loaded, this implies that no such
|
70 |
|
|
device driver is currently available.
|
71 |
|
|
|
72 |
|
|
|
73 |
|
|
|
74 |
|
|
|
75 |
|
|
|
76 |
|
|
The common USB slave package. This serves two purposes. It defines the
|
77 |
|
|
API that specific device drivers should implement. It also provides
|
78 |
|
|
various utilities that will be needed by most USB device drivers and
|
79 |
|
|
applications, such as handlers for standard control messages.
|
80 |
|
|
Usually this package will be loaded automatically at the same time as
|
81 |
|
|
the USB device driver.
|
82 |
|
|
|
83 |
|
|
|
84 |
|
|
|
85 |
|
|
|
86 |
|
|
|
87 |
|
|
The common USB package. This merely provides some information common
|
88 |
|
|
to both the host and slave sides of USB, such as details of the
|
89 |
|
|
control protocol. It is also used to place the other USB-related
|
90 |
|
|
packages appropriately in the overall configuration hierarchy. Usually
|
91 |
|
|
this package will be loaded at the same time as the USB device driver.
|
92 |
|
|
|
93 |
|
|
|
94 |
|
|
|
95 |
|
|
|
96 |
|
|
|
97 |
|
|
Class-specific USB support packages. These make it easier to develop
|
98 |
|
|
specific classes of USB peripheral, such as a USB-ethernet device. If
|
99 |
|
|
no suitable package is available for a given class of peripheral then
|
100 |
|
|
the USB device driver can instead be accessed directly from
|
101 |
|
|
application code. Such packages will never be loaded automatically
|
102 |
|
|
since the configuration system has no way of knowing what class of USB
|
103 |
|
|
peripheral is being developed. Instead developers have to add the
|
104 |
|
|
appropriate package or packages explicitly.
|
105 |
|
|
|
106 |
|
|
|
107 |
|
|
|
108 |
|
|
|
109 |
|
|
|
110 |
|
|
|
111 |
|
|
These packages only provide support for developing USB peripherals,
|
112 |
|
|
not USB hosts.
|
113 |
|
|
|
114 |
|
|
|
115 |
|
|
|
116 |
|
|
USB Concepts
|
117 |
|
|
|
118 |
|
|
Information about USB can be obtained from a number of sources
|
119 |
|
|
including the USB Implementers Forum
|
120 |
|
|
web site. Only a brief summary is provided here.
|
121 |
|
|
|
122 |
|
|
|
123 |
|
|
A USB network is asymmetrical: it consists of a single host, one or
|
124 |
|
|
more slave devices, and possibly some number of intermediate hubs. The
|
125 |
|
|
host side is significantly more complicated than the slave side.
|
126 |
|
|
Essentially, all operations are initiated by the host. For example, if
|
127 |
|
|
the host needs to receive some data from a particular USB peripheral
|
128 |
|
|
then it will send an IN token to that peripheral; the latter should
|
129 |
|
|
respond with either a NAK or with appropriate data. Similarly, when
|
130 |
|
|
the host wants to transmit data to a peripheral it will send an OUT
|
131 |
|
|
token followed by the data; the peripheral will return a NAK if it is
|
132 |
|
|
currently unable to receive more data or if there was corruption,
|
133 |
|
|
otherwise it will return an ACK. All transfers are check-summed and
|
134 |
|
|
there is a clearly-defined error recovery process. USB peripherals can
|
135 |
|
|
only interact with the host, not with each other.
|
136 |
|
|
|
137 |
|
|
|
138 |
|
|
USB supports four different types of communication: control messages,
|
139 |
|
|
interrupt transfers, isochronous transfers, and bulk transfers.
|
140 |
|
|
Control messages are further subdivided into four categories:
|
141 |
|
|
standard, class, vendor and a reserved category. All USB peripherals
|
142 |
|
|
must respond to certain standard control messages, and usually this
|
143 |
|
|
will be handled by the common USB slave package (for complicated
|
144 |
|
|
peripherals, application support will be needed). Class and vendor
|
145 |
|
|
control messages may be handled by an class-specific USB support
|
146 |
|
|
package, for example the USB-ethernet package will handle control
|
147 |
|
|
messages such as getting the MAC address or enabling/disabling
|
148 |
|
|
promiscuous mode. Alternatively, some or all of these messages will
|
149 |
|
|
have to be handled by application code.
|
150 |
|
|
|
151 |
|
|
|
152 |
|
|
Interrupt transfers are used for devices which need to be polled
|
153 |
|
|
regularly. For example, a USB keyboard might be polled once every
|
154 |
|
|
millisecond. The host will not poll the device more frequently than
|
155 |
|
|
this, so interrupt transfers are best suited to peripherals that
|
156 |
|
|
involve a relatively small amount of data. Isochronous transfers are
|
157 |
|
|
intended for multimedia-related peripherals where typically a large
|
158 |
|
|
amount of video or audio data needs to be exchanged continuously.
|
159 |
|
|
Given appropriate host support a USB peripheral can reserve some of
|
160 |
|
|
the available bandwidth. Isochronous transfers are not reliable; if a
|
161 |
|
|
particular packet is corrupted then it will just be discarded and
|
162 |
|
|
software is expected to recover from this. Bulk transfers are used for
|
163 |
|
|
everything else: after taking care of any pending control, isochronous
|
164 |
|
|
and interrupt transfers the host will use whatever bandwidth remains
|
165 |
|
|
for bulk transfers. Bulk transfers are reliable.
|
166 |
|
|
|
167 |
|
|
|
168 |
|
|
Transfers are organized into USB packets, with the details depending
|
169 |
|
|
on the transfer type. Control messages always involve an initial
|
170 |
|
|
8-byte packet from host to peripheral, optionally followed by some
|
171 |
|
|
additional packets; in theory these additional packets can be up to 64
|
172 |
|
|
bytes, but hardware may limit it to 8 bytes. Interrupt transfers
|
173 |
|
|
involve a single packet of up to 64 bytes. Isochronous transfers
|
174 |
|
|
involve a single packet of up to 1024 bytes. Bulk transfers involve
|
175 |
|
|
multiple packets. There will be some number, possibly zero, of 64-byte
|
176 |
|
|
packets. The transfer is terminated by a single packet of less than 64
|
177 |
|
|
bytes. If the transfer involves an exact multiple of 64 bytes than the
|
178 |
|
|
final packet will be 0 bytes, consisting of just a header and checksum
|
179 |
|
|
which typically will be generated by the hardware. There is no
|
180 |
|
|
pre-defined limit on the size of a bulk transfer. Instead higher-level
|
181 |
|
|
protocols are expected to handle this, so for a USB-ethernet
|
182 |
|
|
peripheral the protocol could impose a limit of 1514 bytes of data
|
183 |
|
|
plus maybe some additional protocol overhead.
|
184 |
|
|
|
185 |
|
|
|
186 |
|
|
Transfers from the host to a peripheral are addressed not just to that
|
187 |
|
|
peripheral but to a specific endpoint within that peripheral.
|
188 |
|
|
Similarly, the host requests incoming data from a specific endpoint
|
189 |
|
|
rather than from the peripheral as a whole. For example, a combined
|
190 |
|
|
keyboard/touchpad device could provide the keyboard events on endpoint
|
191 |
|
|
1 and the mouse events on endpoint 2. A given USB peripheral can have
|
192 |
|
|
up to 16 endpoints for incoming data and another 16 for outgoing data.
|
193 |
|
|
However, given the comparatively high speed of USB I/O this endpoint
|
194 |
|
|
addressing is typically implemented in hardware rather than software,
|
195 |
|
|
and the hardware will only implement a small number of endpoints.
|
196 |
|
|
Endpoint 0 is generally used only for control messages.
|
197 |
|
|
|
198 |
|
|
|
199 |
|
|
In practice, many of these details are irrelevant to application code
|
200 |
|
|
or to class packages. Instead, such higher-level code usually just
|
201 |
|
|
performs blocking read and
|
202 |
|
|
write, or non-blocking USB-specific calls, to
|
203 |
|
|
transfer data between host and target via a specific endpoint. Control
|
204 |
|
|
messages are more complicated but are usually handled by existing
|
205 |
|
|
code.
|
206 |
|
|
|
207 |
|
|
|
208 |
|
|
When a USB peripheral is plugged into the host there is an initial
|
209 |
|
|
enumeration and configuration process. The peripheral provides
|
210 |
|
|
information such as its class of device (audio, video, etc.), a
|
211 |
|
|
vendor id, which endpoints should be used for what kind of data, and
|
212 |
|
|
so on. The host OS uses this information to identify a suitable host
|
213 |
|
|
device driver. This could be a generic driver for a class of
|
214 |
|
|
peripherals, or it could be a vendor-specific driver. Assuming a
|
215 |
|
|
suitable driver is installed the host will then activate the USB
|
216 |
|
|
peripheral and perform additional application-specific initialisation.
|
217 |
|
|
For example for a USB-ethernet device this would involve obtaining an
|
218 |
|
|
ethernet MAC address. Most USB peripherals will be fairly simple, but
|
219 |
|
|
it is possible to build multifunction peripherals with multiple
|
220 |
|
|
configurations, interfaces, and alternate interface settings.
|
221 |
|
|
|
222 |
|
|
|
223 |
|
|
It is not possible for any of the eCos packages to generate all the
|
224 |
|
|
enumeration data automatically. Some of the required information such
|
225 |
|
|
as the vendor id cannot be supplied by generic packages; only by the
|
226 |
|
|
application developer. Class support code such as the USB-ethernet
|
227 |
|
|
package could in theory supply some of the information automatically,
|
228 |
|
|
but there are also hardware dependencies such as which endpoints get
|
229 |
|
|
used for incoming and outgoing ethernet frames. Instead it is the
|
230 |
|
|
responsibility of the application developer to provide all the
|
231 |
|
|
enumeration data and perform some additional initialisation. In
|
232 |
|
|
addition, the common USB slave package can handle all the standard
|
233 |
|
|
control messages for a simple USB peripheral, but for something like a
|
234 |
|
|
multifunction peripheral additional application support is needed.
|
235 |
|
|
|
236 |
|
|
|
237 |
|
|
|
238 |
|
|
The initial implementation of the eCos USB slave packages involved
|
239 |
|
|
hardware that only supported control and bulk transfers, not
|
240 |
|
|
isochronous or interrupt. There may be future changes to the USB
|
241 |
|
|
code and API to allow for isochronous and interrupt transfers,
|
242 |
|
|
especially the former. Other changes may be required to support
|
243 |
|
|
different USB devices. At present there is no support for USB remote
|
244 |
|
|
wakeups, since again it is not supported by the hardware.
|
245 |
|
|
|
246 |
|
|
|
247 |
|
|
|
248 |
|
|
|
249 |
|
|
eCos USB I/O Facilities
|
250 |
|
|
|
251 |
|
|
For protocols other than control messages, eCos provides two ways of
|
252 |
|
|
performing USB I/O. The first involves device table or devtab entries such
|
253 |
|
|
as /dev/usb1r,
|
254 |
|
|
with one entry per endpoint per USB device. It is possible to
|
255 |
|
|
open these devices and use conventional blocking
|
256 |
|
|
I/O functions such as read and
|
257 |
|
|
write to exchange data between host and
|
258 |
|
|
peripheral.
|
259 |
|
|
|
260 |
|
|
|
261 |
|
|
There is also a lower-level USB-specific API, consisting of functions
|
262 |
|
|
such as
|
263 |
|
|
linkend="usbs-start-rx">usbs_start_rx_buffer.
|
264 |
|
|
A USB device driver will supply a data structure for each endpoint,
|
265 |
|
|
for example a
|
266 |
|
|
linkend="usbs-data">usbs_rx_endpoint
|
267 |
|
|
structure for every receive endpoint. The first argument to
|
268 |
|
|
usbs_start_rx_buffer should be a pointer to such
|
269 |
|
|
a data structure. The USB-specific API is non-blocking: the initial
|
270 |
|
|
call merely starts the transfer; some time later, once the transfer
|
271 |
|
|
has completed or has been aborted, the device driver will invoke a
|
272 |
|
|
completion function.
|
273 |
|
|
|
274 |
|
|
|
275 |
|
|
Control messages are different. With four different categories of
|
276 |
|
|
control messages including application and vendor specific ones, the
|
277 |
|
|
conventional
|
278 |
|
|
open/read/write
|
279 |
|
|
model of I/O cannot easily be applied. Instead, a USB device driver
|
280 |
|
|
will supply a
|
281 |
|
|
linkend="usbs-control">usbs_control_endpoint
|
282 |
|
|
data structure which can be manipulated appropriately. In practice the
|
283 |
|
|
standard control messages will usually be handled by the common USB
|
284 |
|
|
slave package, and other control messages will be handled by
|
285 |
|
|
class-specific code such as the USB-ethernet package. Typically,
|
286 |
|
|
application code remains responsible for supplying the
|
287 |
|
|
linkend="usbs-enum">enumeration data and for actually
|
288 |
|
|
linkend="usbs-start">starting up the USB device.
|
289 |
|
|
|
290 |
|
|
|
291 |
|
|
|
292 |
|
|
Enabling the USB code
|
293 |
|
|
|
294 |
|
|
If the target hardware contains a USB slave device then the
|
295 |
|
|
appropriate USB device driver and the common packages will typically
|
296 |
|
|
be loaded into the configuration automatically when that target is
|
297 |
|
|
selected (assuming a suitable device driver exists). However, the
|
298 |
|
|
driver will not necessarily be active. For example a processor might
|
299 |
|
|
have an on-chip USB device, but not all applications using that
|
300 |
|
|
processor will want to use USB functionality. Hence by default the USB
|
301 |
|
|
device is disabled, ensuring that applications do not suffer any
|
302 |
|
|
memory or other penalties for functionality that is not required.
|
303 |
|
|
|
304 |
|
|
|
305 |
|
|
If the application developer explicitly adds a class support package
|
306 |
|
|
such as the USB-ethernet one then this implies that the USB device is
|
307 |
|
|
actually needed, and the device will be enabled automatically.
|
308 |
|
|
However, if no suitable class package is available and the USB device
|
309 |
|
|
will instead be accessed by application code, it is necessary to
|
310 |
|
|
enable the USB device manually. Usually the easiest way to do this is
|
311 |
|
|
to enable the configuration option
|
312 |
|
|
CYGGLO_IO_USB_SLAVE_APPLICATION, and the USB device
|
313 |
|
|
driver and related packages will adjust accordingly. Alternatively,
|
314 |
|
|
the device driver may provide some configuration options to provide
|
315 |
|
|
more fine-grained control.
|
316 |
|
|
|
317 |
|
|
|
318 |
|
|
|
319 |
|
|
|
320 |
|
|
|
321 |
|
|
|
322 |
|
|
|
323 |
|
|
|
324 |
|
|
|
325 |
|
|
|
326 |
|
|
USB Enumeration Data
|
327 |
|
|
|
328 |
|
|
|
329 |
|
|
Enumeration Data
|
330 |
|
|
The USB enumeration data structures
|
331 |
|
|
|
332 |
|
|
|
333 |
|
|
|
334 |
|
|
|
335 |
|
|
#include <cyg/io/usb/usb.h>
|
336 |
|
|
#include <cyg/io/usb/usbs.h>
|
337 |
|
|
|
338 |
|
|
typedef struct usb_device_descriptor {
|
339 |
|
|
…
|
340 |
|
|
} usb_device_descriptor __attribute__((packed));
|
341 |
|
|
|
342 |
|
|
typedef struct usb_configuration_descriptor {
|
343 |
|
|
…
|
344 |
|
|
} usb_configuration_descriptor __attribute__((packed));
|
345 |
|
|
|
346 |
|
|
typedef struct usb_interface_descriptor {
|
347 |
|
|
…
|
348 |
|
|
} usb_interface_descriptor __attribute__((packed));
|
349 |
|
|
|
350 |
|
|
typedef struct usb_endpoint_descriptor {
|
351 |
|
|
…
|
352 |
|
|
} usb_endpoint_descriptor;
|
353 |
|
|
|
354 |
|
|
typedef struct usbs_enumeration_data {
|
355 |
|
|
usb_device_descriptor device;
|
356 |
|
|
int total_number_interfaces;
|
357 |
|
|
int total_number_endpoints;
|
358 |
|
|
int total_number_strings;
|
359 |
|
|
const usb_configuration_descriptor* configurations;
|
360 |
|
|
const usb_interface_descriptor* interfaces;
|
361 |
|
|
const usb_endpoint_descriptor* endpoints;
|
362 |
|
|
const unsigned char** strings;
|
363 |
|
|
} usbs_enumeration_data;
|
364 |
|
|
|
365 |
|
|
|
366 |
|
|
|
367 |
|
|
USB Enumeration Data
|
368 |
|
|
|
369 |
|
|
When a USB host detects that a peripheral has been plugged in or
|
370 |
|
|
powered up, one of the first steps is to ask the peripheral to
|
371 |
|
|
describe itself by supplying enumeration data. Some of this data
|
372 |
|
|
depends on the class of peripheral. Other fields are vendor-specific.
|
373 |
|
|
There is also a dependency on the hardware, specifically which
|
374 |
|
|
endpoints are available should be used. In general it is not possible
|
375 |
|
|
for generic code to provide this information, so it is the
|
376 |
|
|
responsibility of application code to provide a suitable
|
377 |
|
|
usbs_enumeration_data data structure and
|
378 |
|
|
install it in the endpoint 0 data structure during initialization.
|
379 |
|
|
This must happen before the USB device is enabled by a call to
|
380 |
|
|
usbs_start, for example:
|
381 |
|
|
|
382 |
|
|
|
383 |
|
|
const usbs_enumeration_data usb_enum_data = {
|
384 |
|
|
…
|
385 |
|
|
};
|
386 |
|
|
|
387 |
|
|
int
|
388 |
|
|
main(int argc, char** argv)
|
389 |
|
|
{
|
390 |
|
|
usbs_sa11x0_ep0.enumeration_data = &usb_enum_data;
|
391 |
|
|
…
|
392 |
|
|
usbs_start(&usbs_sa11x0_ep0);
|
393 |
|
|
…
|
394 |
|
|
}
|
395 |
|
|
|
396 |
|
|
|
397 |
|
|
For most applications the enumeration data will be static, although
|
398 |
|
|
the usbs_enumeration_data structure can be
|
399 |
|
|
filled in at run-time if necessary. Full details of the enumeration
|
400 |
|
|
data can be found in the Universal Serial Bus specification obtainable
|
401 |
|
|
from the USB Implementers Forum web
|
402 |
|
|
site, although the meaning of most fields is fairly obvious.
|
403 |
|
|
The various data structures and utility macros are defined in the
|
404 |
|
|
header files
|
405 |
|
|
and . Note
|
406 |
|
|
that the example code below makes use of the gcc labelled element
|
407 |
|
|
extension.
|
408 |
|
|
|
409 |
|
|
|
410 |
|
|
usb_device_descriptor
|
411 |
|
|
|
412 |
|
|
The main information about a USB peripheral comes from a single
|
413 |
|
|
usb_device_descriptor structure, which is
|
414 |
|
|
embedded in the usbs_enumeration_data
|
415 |
|
|
structure. A typical example might look like this:
|
416 |
|
|
|
417 |
|
|
|
418 |
|
|
const usbs_enumeration_data usb_enum_data = {
|
419 |
|
|
{
|
420 |
|
|
length: USB_DEVICE_DESCRIPTOR_LENGTH,
|
421 |
|
|
type: USB_DEVICE_DESCRIPTOR_TYPE,
|
422 |
|
|
usb_spec_lo: USB_DEVICE_DESCRIPTOR_USB11_LO,
|
423 |
|
|
usb_spec_hi: USB_DEVICE_DESCRIPTOR_USB11_HI,
|
424 |
|
|
device_class: USB_DEVICE_DESCRIPTOR_CLASS_VENDOR,
|
425 |
|
|
device_subclass: USB_DEVICE_DESCRIPTOR_SUBCLASS_VENDOR,
|
426 |
|
|
device_protocol: USB_DEVICE_DESCRIPTOR_PROTOCOL_VENDOR,
|
427 |
|
|
max_packet_size: 8,
|
428 |
|
|
vendor_lo: 0x42,
|
429 |
|
|
vendor_hi: 0x42,
|
430 |
|
|
product_lo: 0x42,
|
431 |
|
|
product_hi: 0x42,
|
432 |
|
|
device_lo: 0x00,
|
433 |
|
|
device_hi: 0x01,
|
434 |
|
|
manufacturer_str: 1,
|
435 |
|
|
product_str: 2,
|
436 |
|
|
serial_number_str: 0,
|
437 |
|
|
number_configurations: 1
|
438 |
|
|
},
|
439 |
|
|
…
|
440 |
|
|
};
|
441 |
|
|
|
442 |
|
|
|
443 |
|
|
The length and type fields are specified by the USB standard. The
|
444 |
|
|
usb_spec_lo and
|
445 |
|
|
usb_spec_hi fields identify the particular
|
446 |
|
|
revision of the standard that the peripheral implements, for example
|
447 |
|
|
revision 1.1.
|
448 |
|
|
|
449 |
|
|
|
450 |
|
|
The device class, subclass, and protocol fields are used by generic
|
451 |
|
|
host-side USB software to determine which host-side device driver
|
452 |
|
|
should be loaded to interact with the peripheral. A number of standard
|
453 |
|
|
classes are defined, for example mass-storage devices and
|
454 |
|
|
human-interface devices. If a peripheral implements one of the
|
455 |
|
|
standard classes then a standard existing host-side device driver may
|
456 |
|
|
exist, eliminating the need to write a custom driver. The value
|
457 |
|
|
0xFF (VENDOR) is reserved for
|
458 |
|
|
peripherals that implement a vendor-specific protocol rather than a
|
459 |
|
|
standard one. Such peripherals will require a custom host-side device
|
460 |
|
|
driver. The value 0x00
|
461 |
|
|
(INTERFACE) is reserved and indicates that the
|
462 |
|
|
protocol used by the peripheral is defined at the interface level
|
463 |
|
|
rather than for the peripheral as a whole.
|
464 |
|
|
|
465 |
|
|
|
466 |
|
|
The max_package_size field specifies the
|
467 |
|
|
maximum length of a control message. There is a lower bound of eight
|
468 |
|
|
bytes, and typical hardware will not support anything larger because
|
469 |
|
|
control messages are usually small and not performance-critical.
|
470 |
|
|
|
471 |
|
|
|
472 |
|
|
The vendor_lo and
|
473 |
|
|
vendor_hi fields specify a vendor id, which
|
474 |
|
|
must be obtained from the USB Implementor's Forum. The numbers used in
|
475 |
|
|
the code fragment above are examples only and must not be used in real
|
476 |
|
|
USB peripherals. The product identifier is determined by the vendor,
|
477 |
|
|
and different USB peripherals should use different identifiers. The
|
478 |
|
|
device identifier field should indicate a release number in
|
479 |
|
|
binary-coded decimal.
|
480 |
|
|
|
481 |
|
|
|
482 |
|
|
The above fields are all numerical in nature. A USB peripheral can
|
483 |
|
|
also provide a number of strings as described
|
484 |
|
|
linkend="usbs-enum-strings">below, for example the name of the
|
485 |
|
|
vendor can be provided. The various _str
|
486 |
|
|
fields act as indices into an array of strings, with index 0
|
487 |
|
|
indicating that no string is available.
|
488 |
|
|
|
489 |
|
|
|
490 |
|
|
A typical USB peripheral involves just a single configuration. However
|
491 |
|
|
more complicated peripherals can support multiple configurations. Only
|
492 |
|
|
one configuration will be active at any one time, and the host will
|
493 |
|
|
switch between them as appropriate. If a peripheral does involve
|
494 |
|
|
multiple configurations then typically it will be the responsibility
|
495 |
|
|
of application code to
|
496 |
|
|
linkend="usbs-control-standard">handle the standard
|
497 |
|
|
set-configuration control message.
|
498 |
|
|
|
499 |
|
|
|
500 |
|
|
|
501 |
|
|
usb_configuration_descriptor
|
502 |
|
|
|
503 |
|
|
A USB peripheral involves at least one and possible several different
|
504 |
|
|
configurations. The usbs_enumeration_data
|
505 |
|
|
structure requires a pointer to an array, possibly of length 1, of
|
506 |
|
|
usb_configuration_descriptor structures.
|
507 |
|
|
Usually a single structure suffices:
|
508 |
|
|
|
509 |
|
|
|
510 |
|
|
const usb_configuration_descriptor usb_configuration = {
|
511 |
|
|
length: USB_CONFIGURATION_DESCRIPTOR_LENGTH,
|
512 |
|
|
type: USB_CONFIGURATION_DESCRIPTOR_TYPE,
|
513 |
|
|
total_length_lo: USB_CONFIGURATION_DESCRIPTOR_TOTAL_LENGTH_LO(1, 2),
|
514 |
|
|
total_length_hi: USB_CONFIGURATION_DESCRIPTOR_TOTAL_LENGTH_HI(1, 2),
|
515 |
|
|
number_interfaces: 1,
|
516 |
|
|
configuration_id: 1,
|
517 |
|
|
configuration_str: 0,
|
518 |
|
|
attributes: USB_CONFIGURATION_DESCRIPTOR_ATTR_REQUIRED |
|
519 |
|
|
USB_CONFIGURATION_DESCRIPTOR_ATTR_SELF_POWERED,
|
520 |
|
|
max_power: 50
|
521 |
|
|
};
|
522 |
|
|
|
523 |
|
|
const usbs_enumeration_data usb_enum_data = {
|
524 |
|
|
…
|
525 |
|
|
configurations: &usb_configuration,
|
526 |
|
|
…
|
527 |
|
|
};
|
528 |
|
|
|
529 |
|
|
|
530 |
|
|
The values for the length and
|
531 |
|
|
type fields are determined by the standard.
|
532 |
|
|
The total_length field depends on the
|
533 |
|
|
number of interfaces and endpoints used by this configuration, and
|
534 |
|
|
convenience macros are provided to calculate this: the first argument
|
535 |
|
|
to the macros specify the number of interfaces, the second the number
|
536 |
|
|
of endpoints. The number_interfaces field
|
537 |
|
|
is self-explanatory. If the peripheral involves multiple
|
538 |
|
|
configurations then each one must have a unique id, and this will be
|
539 |
|
|
used in the set-configuration control message. The id
|
540 |
|
|
0 is reserved, and a set-configuration control
|
541 |
|
|
message that uses this id indicates that the peripheral should be
|
542 |
|
|
inactive. Configurations can have a string description if required.
|
543 |
|
|
The attributes field must have the
|
544 |
|
|
REQUIRED bit set; the
|
545 |
|
|
SELF_POWERED bit informs the host that the
|
546 |
|
|
peripheral has its own power supply and will not draw any power over
|
547 |
|
|
the bus, leaving more bus power available to other peripherals; the
|
548 |
|
|
REMOTE_WAKEUP bit is used if the peripheral can
|
549 |
|
|
interrupt the host when the latter is in power-saving mode. For
|
550 |
|
|
peripherals that are not self-powered, the
|
551 |
|
|
max_power field specifies the power
|
552 |
|
|
requirements in units of 2mA.
|
553 |
|
|
|
554 |
|
|
|
555 |
|
|
|
556 |
|
|
usb_interface_descriptor
|
557 |
|
|
|
558 |
|
|
A USB configuration involves one or more interfaces, typically
|
559 |
|
|
corresponding to different streams of data. For example, one interface
|
560 |
|
|
might involve video data while another interface is for audio.
|
561 |
|
|
Multiple interfaces in a single configuration will be active at the
|
562 |
|
|
same time.
|
563 |
|
|
|
564 |
|
|
|
565 |
|
|
const usb_interface_descriptor usb_interface = {
|
566 |
|
|
length: USB_INTERFACE_DESCRIPTOR_LENGTH,
|
567 |
|
|
type: USB_INTERFACE_DESCRIPTOR_TYPE,
|
568 |
|
|
interface_id: 0,
|
569 |
|
|
alternate_setting: 0,
|
570 |
|
|
number_endpoints: 2,
|
571 |
|
|
interface_class: USB_INTERFACE_DESCRIPTOR_CLASS_VENDOR,
|
572 |
|
|
interface_subclass: USB_INTERFACE_DESCRIPTOR_SUBCLASS_VENDOR,
|
573 |
|
|
interface_protocol: USB_INTERFACE_DESCRIPTOR_PROTOCOL_VENDOR,
|
574 |
|
|
interface_str: 0
|
575 |
|
|
};
|
576 |
|
|
|
577 |
|
|
const usbs_enumeration_data usb_enum_data = {
|
578 |
|
|
…
|
579 |
|
|
total_number_interfaces: 1,
|
580 |
|
|
interfaces: &usb_interface,
|
581 |
|
|
…
|
582 |
|
|
};
|
583 |
|
|
|
584 |
|
|
|
585 |
|
|
Again, the length and
|
586 |
|
|
type fields are specified by the standard.
|
587 |
|
|
Each interface within a configuration requires its own id. However, a
|
588 |
|
|
given interface may have several alternate settings, in other words
|
589 |
|
|
entries in the interfaces array with the same id but different
|
590 |
|
|
alternate_setting fields. For example,
|
591 |
|
|
there might be one setting which requires a bandwidth of 100K/s and
|
592 |
|
|
another setting that only needs 50K/s. The host can use the standard
|
593 |
|
|
set-interface control message to choose the most appropriate setting.
|
594 |
|
|
The handling of this request is the responsibility of higher-level
|
595 |
|
|
code, so the application may have to
|
596 |
|
|
linkend="usbs-control-standard">install its own handler.
|
597 |
|
|
|
598 |
|
|
|
599 |
|
|
The number of endpoints used by an interface is specified in the
|
600 |
|
|
number_endpoints field. Exact details of
|
601 |
|
|
which endpoints are used is held in a separate array of endpoint
|
602 |
|
|
descriptors. The class, subclass and protocol fields are used by
|
603 |
|
|
host-side code to determine which host-side device driver should
|
604 |
|
|
handle this specific interface. Usually this is determined on a
|
605 |
|
|
per-peripheral basis in the
|
606 |
|
|
usb_device_descriptor structure, but that can
|
607 |
|
|
defer the details to individual interfaces. A per-interface string
|
608 |
|
|
is allowed as well.
|
609 |
|
|
|
610 |
|
|
|
611 |
|
|
For USB peripherals involving multiple configurations, the array of
|
612 |
|
|
usb_interface_descriptor structures should
|
613 |
|
|
first contain all the interfaces for the first configuration, then all
|
614 |
|
|
the interfaces for the second configuration, and so on.
|
615 |
|
|
|
616 |
|
|
|
617 |
|
|
|
618 |
|
|
usb_endpoint_descriptor
|
619 |
|
|
|
620 |
|
|
The host also needs information about which endpoint should be used
|
621 |
|
|
for what. This involves an array of endpoint descriptors:
|
622 |
|
|
|
623 |
|
|
|
624 |
|
|
const usb_endpoint_descriptor usb_endpoints[] = {
|
625 |
|
|
{
|
626 |
|
|
length: USB_ENDPOINT_DESCRIPTOR_LENGTH,
|
627 |
|
|
type: USB_ENDPOINT_DESCRIPTOR_TYPE,
|
628 |
|
|
endpoint: USB_ENDPOINT_DESCRIPTOR_ENDPOINT_OUT | 1,
|
629 |
|
|
attributes: USB_ENDPOINT_DESCRIPTOR_ATTR_BULK,
|
630 |
|
|
max_packet_lo: 64,
|
631 |
|
|
max_packet_hi: 0,
|
632 |
|
|
interval: 0
|
633 |
|
|
},
|
634 |
|
|
{
|
635 |
|
|
length: USB_ENDPOINT_DESCRIPTOR_LENGTH,
|
636 |
|
|
type: USB_ENDPOINT_DESCRIPTOR_TYPE,
|
637 |
|
|
endpoint: USB_ENDPOINT_DESCRIPTOR_ENDPOINT_IN | 2,
|
638 |
|
|
attributes: USB_ENDPOINT_DESCRIPTOR_ATTR_BULK,
|
639 |
|
|
max_packet_lo: 64,
|
640 |
|
|
max_packet_hi: 0,
|
641 |
|
|
interval: 0
|
642 |
|
|
}
|
643 |
|
|
};
|
644 |
|
|
|
645 |
|
|
const usbs_enumeration_data usb_enum_data = {
|
646 |
|
|
…
|
647 |
|
|
total_number_endpoints: 2,
|
648 |
|
|
endpoints: usb_endpoints,
|
649 |
|
|
…
|
650 |
|
|
};
|
651 |
|
|
|
652 |
|
|
|
653 |
|
|
As usual the values for the length and
|
654 |
|
|
type fields are specified by the standard.
|
655 |
|
|
The endpoint field gives both the endpoint
|
656 |
|
|
number and the direction, so in the above example endpoint 1 is used
|
657 |
|
|
for OUT (host to peripheral) transfers and endpoint 2 is used for IN
|
658 |
|
|
(peripheral to host) transfers. The
|
659 |
|
|
attributes field indicates the USB protocol
|
660 |
|
|
that should be used on this endpoint: CONTROL,
|
661 |
|
|
ISOCHRONOUS, BULK or
|
662 |
|
|
INTERRUPT. The
|
663 |
|
|
max_packet field specifies the maximum size
|
664 |
|
|
of a single USB packet. For bulk transfers this will typically be 64
|
665 |
|
|
bytes. For isochronous transfers this can be up to 1023 bytes. For
|
666 |
|
|
interrupt transfers it can be up to 64 bytes, although usually a
|
667 |
|
|
smaller value will be used. The interval
|
668 |
|
|
field is ignored for control and bulk transfers. For isochronous
|
669 |
|
|
transfers it should be set to 1. For interrupt transfers it can be a
|
670 |
|
|
value between 1 and 255, and indicates the number of milliseconds
|
671 |
|
|
between successive polling operations.
|
672 |
|
|
|
673 |
|
|
|
674 |
|
|
For USB peripherals involving multiple configurations or interfaces
|
675 |
|
|
the array of endpoint descriptors should be organized sequentially:
|
676 |
|
|
first the endpoints corresponding to the first interface of the first
|
677 |
|
|
configuration, then the second interface in that configuration, and so
|
678 |
|
|
on; then all the endpoints for all the interfaces in the second
|
679 |
|
|
configuration; etc.
|
680 |
|
|
|
681 |
|
|
|
682 |
|
|
|
683 |
|
|
Strings
|
684 |
|
|
|
685 |
|
|
The enumeration data can contain a number of strings with additional
|
686 |
|
|
information. Unicode encoding is used for the strings, and it is
|
687 |
|
|
possible for a peripheral to supply a given string in multiple
|
688 |
|
|
languages using the appropriate characters. The first two bytes of
|
689 |
|
|
each string give a length and type field. The first string is special;
|
690 |
|
|
after the two bytes header it consists of an array of 2-byte language
|
691 |
|
|
id codes, indicating the supported languages. The language code
|
692 |
|
|
0x0409 corresponds to English (United States).
|
693 |
|
|
|
694 |
|
|
|
695 |
|
|
const unsigned char* usb_strings[] = {
|
696 |
|
|
"\004\003\011\004",
|
697 |
|
|
"\020\003R\000e\000d\000 \000H\000a\000t\000"
|
698 |
|
|
};
|
699 |
|
|
|
700 |
|
|
const usbs_enumeration_data usb_enum_data = {
|
701 |
|
|
…
|
702 |
|
|
total_number_strings: 2,
|
703 |
|
|
strings: usb_strings,
|
704 |
|
|
…
|
705 |
|
|
};
|
706 |
|
|
|
707 |
|
|
|
708 |
|
|
The default handler for standard control messages assumes that the
|
709 |
|
|
peripheral only uses a single language. If this is not the case then
|
710 |
|
|
higher-level code will have to handle the standard get-descriptor
|
711 |
|
|
control messages when a string descriptor is requested.
|
712 |
|
|
|
713 |
|
|
|
714 |
|
|
|
715 |
|
|
usbs_enumeration_data
|
716 |
|
|
|
717 |
|
|
The usbs_enumeration_data data structure
|
718 |
|
|
collects together all the various descriptors that make up the
|
719 |
|
|
enumeration data. It is the responsibility of application code to
|
720 |
|
|
supply a suitable data structure and install it in the control
|
721 |
|
|
endpoints's enumeration_data field before
|
722 |
|
|
the USB device is started.
|
723 |
|
|
|
724 |
|
|
|
725 |
|
|
|
726 |
|
|
|
727 |
|
|
|
728 |
|
|
|
729 |
|
|
|
730 |
|
|
|
731 |
|
|
|
732 |
|
|
|
733 |
|
|
|
734 |
|
|
Starting up a USB Device
|
735 |
|
|
|
736 |
|
|
|
737 |
|
|
usbs_start
|
738 |
|
|
Starting up a USB Device
|
739 |
|
|
|
740 |
|
|
|
741 |
|
|
|
742 |
|
|
|
743 |
|
|
|
744 |
|
|
#include <cyg/io/usb/usbs.h>
|
745 |
|
|
|
746 |
|
|
|
747 |
|
|
void usbs_start
|
748 |
|
|
usbs_control_endpoint* ep0
|
749 |
|
|
|
750 |
|
|
|
751 |
|
|
|
752 |
|
|
|
753 |
|
|
Description
|
754 |
|
|
|
755 |
|
|
Initializing a USB device requires some support from higher-level
|
756 |
|
|
code, typically the application, in the form of enumeration data.
|
757 |
|
|
Hence it is not possible for the low-level USB driver to activate a
|
758 |
|
|
USB device itself. Instead the higher-level code has to take care of
|
759 |
|
|
this by invoking usbs_start. This function takes
|
760 |
|
|
a pointer to a USB control endpoint data structure. USB device drivers
|
761 |
|
|
should provide exactly one such data structure for every USB device,
|
762 |
|
|
so the pointer uniquely identifies the device.
|
763 |
|
|
|
764 |
|
|
|
765 |
|
|
const usbs_enumeration_data usb_enum_data = {
|
766 |
|
|
…
|
767 |
|
|
};
|
768 |
|
|
|
769 |
|
|
int
|
770 |
|
|
main(int argc, char** argv)
|
771 |
|
|
{
|
772 |
|
|
usbs_sa11x0_ep0.enumeration_data = &usb_enum_data;
|
773 |
|
|
…
|
774 |
|
|
usbs_start(&usbs_sa11x0_ep0);
|
775 |
|
|
…
|
776 |
|
|
}
|
777 |
|
|
|
778 |
|
|
|
779 |
|
|
The exact behaviour of usbs_start depends on the
|
780 |
|
|
USB hardware and the device driver. A typical implementation would
|
781 |
|
|
change the USB data pins from tristated to active. If the peripheral
|
782 |
|
|
is already plugged into a host then the latter should detect this
|
783 |
|
|
change and start interacting with the peripheral, including requesting
|
784 |
|
|
the enumeration data. Some of this may happen before
|
785 |
|
|
usbs_start returns, but given that multiple
|
786 |
|
|
interactions between USB host and peripheral are required it is likely
|
787 |
|
|
that the function will return before the peripheral is fully
|
788 |
|
|
configured. Control endpoints provide a
|
789 |
|
|
linkend="usbs-control-state">mechanism for informing
|
790 |
|
|
higher-level code of USB state changes.
|
791 |
|
|
usbs_start will return even if the peripheral is
|
792 |
|
|
not currently connected to a host: it will not block until the
|
793 |
|
|
connection is established.
|
794 |
|
|
|
795 |
|
|
|
796 |
|
|
usbs_start should only be called once for a given
|
797 |
|
|
USB device. There are no defined error conditions. Note that the
|
798 |
|
|
function affects the entire USB device and not just the control
|
799 |
|
|
endpoint: there is no need to start any data endpoints as well.
|
800 |
|
|
|
801 |
|
|
|
802 |
|
|
|
803 |
|
|
|
804 |
|
|
|
805 |
|
|
|
806 |
|
|
|
807 |
|
|
|
808 |
|
|
|
809 |
|
|
Devtab Entries
|
810 |
|
|
|
811 |
|
|
|
812 |
|
|
Devtab Entries
|
813 |
|
|
Data endpoint data structure
|
814 |
|
|
|
815 |
|
|
|
816 |
|
|
|
817 |
|
|
|
818 |
|
|
/dev/usb0c
|
819 |
|
|
/dev/usb1r
|
820 |
|
|
/dev/usb2w
|
821 |
|
|
|
822 |
|
|
|
823 |
|
|
|
824 |
|
|
Devtab Entries
|
825 |
|
|
|
826 |
|
|
USB device drivers provide two ways of transferring data between host
|
827 |
|
|
and peripheral. The first involves USB-specific functionality such as
|
828 |
|
|
|
829 |
|
|
linkend="usbs-start-rx">usbs_start_rx_buffer.
|
830 |
|
|
This provides non-blocking I/O: a transfer is started, and some time
|
831 |
|
|
later the device driver will call a supplied completion function. The
|
832 |
|
|
second uses the conventional I/O model: there are entries in the
|
833 |
|
|
device table corresponding to the various endpoints. Standard calls
|
834 |
|
|
such as open can then be used to get a suitable
|
835 |
|
|
handle. Actual I/O happens via blocking read and
|
836 |
|
|
write calls. In practice the blocking operations
|
837 |
|
|
are simply implemented using the underlying non-blocking
|
838 |
|
|
functionality.
|
839 |
|
|
|
840 |
|
|
|
841 |
|
|
Each endpoint will have its own devtab entry. The exact names are
|
842 |
|
|
controlled by the device driver package, but typically the root will
|
843 |
|
|
be /dev/usb. This is followed by one or more
|
844 |
|
|
decimal digits giving the endpoint number, followed by
|
845 |
|
|
c for a control endpoint, r for
|
846 |
|
|
a receive endpoint (host to peripheral), and w for
|
847 |
|
|
a transmit endpoint (peripheral to host). If the target hardware
|
848 |
|
|
involves more than one USB device then different roots should be used,
|
849 |
|
|
for example /dev/usb0c and
|
850 |
|
|
/dev/usb1_0c. This may require explicit
|
851 |
|
|
manipulation of device driver configuration options by the application
|
852 |
|
|
developer.
|
853 |
|
|
|
854 |
|
|
|
855 |
|
|
At present the devtab entry for a control endpoint does not support
|
856 |
|
|
any I/O operations.
|
857 |
|
|
|
858 |
|
|
|
859 |
|
|
write operations
|
860 |
|
|
|
861 |
|
|
cyg_io_write and similar functions in
|
862 |
|
|
higher-level packages can be used to perform a transfer from
|
863 |
|
|
peripheral to host. Successive write operations will not be coalesced.
|
864 |
|
|
For example, when doing a 1000 byte write to an endpoint that uses the
|
865 |
|
|
bulk transfer protocol this will involve 15 full-size 64-byte packets
|
866 |
|
|
and a terminating 40-byte packet. USB device drivers are not expected
|
867 |
|
|
to do any locking, and if higher-level code performs multiple
|
868 |
|
|
concurrent write operations on a single endpoint then the resulting
|
869 |
|
|
behaviour is undefined.
|
870 |
|
|
|
871 |
|
|
|
872 |
|
|
A USB write operation will never transfer less
|
873 |
|
|
data than specified. It is the responsibility of higher-level code to
|
874 |
|
|
ensure that the amount of data being transferred is acceptable to the
|
875 |
|
|
host-side code. Usually this will be defined by a higher-level
|
876 |
|
|
protocol. If an attempt is made to transfer more data than the host
|
877 |
|
|
expects then the resulting behaviour is undefined.
|
878 |
|
|
|
879 |
|
|
|
880 |
|
|
There are two likely error conditions. EPIPE
|
881 |
|
|
indicates that the connection between host and target has been broken.
|
882 |
|
|
EAGAIN indicates that the endpoint has been
|
883 |
|
|
stalled, either at the request of the host or by other activity
|
884 |
|
|
inside the peripheral.
|
885 |
|
|
|
886 |
|
|
|
887 |
|
|
|
888 |
|
|
read operations
|
889 |
|
|
|
890 |
|
|
cyg_io_read and similar functions in higher-level
|
891 |
|
|
packages can be used to perform a transfer from host to peripheral.
|
892 |
|
|
This should be a complete transfer: higher-level protocols should
|
893 |
|
|
define an upper bound on the amount of data being transferred, and the
|
894 |
|
|
read operation should involve at least this
|
895 |
|
|
amount of data. The return value will indicate the actual transfer
|
896 |
|
|
size, which may be less than requested.
|
897 |
|
|
|
898 |
|
|
|
899 |
|
|
Some device drivers may support partial reads, but USB device drivers
|
900 |
|
|
are not expected to perform any buffering because that involves both
|
901 |
|
|
memory and code overheads. One technique that may work for bulk
|
902 |
|
|
transfers is to exploit the fact that such transfers happen in 64-byte
|
903 |
|
|
packets. It is possible to read an initial 64
|
904 |
|
|
bytes, corresponding to the first packet in the transfer. These 64
|
905 |
|
|
bytes can then be examined to determine the total transfer size, and
|
906 |
|
|
the remaining data can be transferred in another
|
907 |
|
|
read operation. This technique is not guaranteed
|
908 |
|
|
to work with all USB hardware. Also, if the delay between accepting
|
909 |
|
|
the first packet and the remainder of the transfer is excessive then
|
910 |
|
|
this could cause timeout problems for the host-side software. For
|
911 |
|
|
these reasons the use of partial reads should be avoided.
|
912 |
|
|
|
913 |
|
|
|
914 |
|
|
There are two likely error conditions. EPIPE
|
915 |
|
|
indicates that the connection between host and target has been broken.
|
916 |
|
|
EAGAIN indicates that the endpoint has been
|
917 |
|
|
stalled, either at the request of the host or by other activity
|
918 |
|
|
inside the peripheral.
|
919 |
|
|
|
920 |
|
|
|
921 |
|
|
USB device drivers are not expected to do any locking. If higher-level
|
922 |
|
|
code performs multiple concurrent read operations on a single endpoint
|
923 |
|
|
then the resulting behaviour is undefined.
|
924 |
|
|
|
925 |
|
|
|
926 |
|
|
|
927 |
|
|
select operations
|
928 |
|
|
|
929 |
|
|
Typical USB device drivers will not provide any support for
|
930 |
|
|
select. Consider bulk transfers from the host to
|
931 |
|
|
the peripheral. At the USB device driver level there is no way of
|
932 |
|
|
knowing in advance how large a transfer will be, so it is not feasible
|
933 |
|
|
for the device driver to buffer the entire transfer. It may be
|
934 |
|
|
possible to buffer part of the transfer, for example the first 64-byte
|
935 |
|
|
packet, and copy this into application space at the start of a
|
936 |
|
|
read, but this adds code and memory overheads.
|
937 |
|
|
Worse, it means that there is an unknown but potentially long delay
|
938 |
|
|
between a peripheral accepting the first packet of a transfer and the
|
939 |
|
|
remaining packets, which could confuse or upset the host-side
|
940 |
|
|
software.
|
941 |
|
|
|
942 |
|
|
|
943 |
|
|
With some USB hardware it may be possible for the device driver to
|
944 |
|
|
detect OUT tokens from the host without actually accepting the data,
|
945 |
|
|
and this would indicate that a read is likely to
|
946 |
|
|
succeed. However, it would not be reliable since the host-side I/O
|
947 |
|
|
operation could time out. A similar mechanism could be used to
|
948 |
|
|
implement select for outgoing data, but again
|
949 |
|
|
this would not be reliable.
|
950 |
|
|
|
951 |
|
|
|
952 |
|
|
Some device drivers may provide partial support for
|
953 |
|
|
select anyway, possibly under the control of a
|
954 |
|
|
configuration option. The device driver's documentation should be
|
955 |
|
|
consulted for further information. It is also worth noting that the
|
956 |
|
|
USB-specific non-blocking API can often be used as an alternative to
|
957 |
|
|
select.
|
958 |
|
|
|
959 |
|
|
|
960 |
|
|
|
961 |
|
|
get_config and
|
962 |
|
|
set_config operations
|
963 |
|
|
|
964 |
|
|
There are no set_config or
|
965 |
|
|
get_config (also known as
|
966 |
|
|
ioctl) operations defined for USB devices.
|
967 |
|
|
Some device drivers may provide hardware-specific facilities this way.
|
968 |
|
|
|
969 |
|
|
|
970 |
|
|
|
971 |
|
|
Currently the USB-specific functions related to
|
972 |
|
|
linkend="usbs-halt">halted endpoints cannot be accessed readily
|
973 |
|
|
via devtab entries. This functionality should probably be made
|
974 |
|
|
available via set_config and
|
975 |
|
|
get_config. It may also prove useful to provide
|
976 |
|
|
a get_config operation that maps from the
|
977 |
|
|
devtab entries to the underlying endpoint data structures.
|
978 |
|
|
|
979 |
|
|
|
980 |
|
|
|
981 |
|
|
|
982 |
|
|
Presence
|
983 |
|
|
|
984 |
|
|
The devtab entries are optional. If the USB device is accessed
|
985 |
|
|
primarily by class-specific code such as the USB-ethernet package and
|
986 |
|
|
that package uses the USB-specific API directly, the devtab entries
|
987 |
|
|
are redundant. Even if application code does need to access the USB
|
988 |
|
|
device, the non-blocking API may be more convenient than the blocking
|
989 |
|
|
I/O provided via the devtab entries. In these cases the devtab entries
|
990 |
|
|
serve no useful purpose, but they still impose a memory overhead. It
|
991 |
|
|
is possible to suppress the presence of these entries by disabling the
|
992 |
|
|
configuration option
|
993 |
|
|
CYGGLO_IO_USB_SLAVE_PROVIDE_DEVTAB_ENTRIES.
|
994 |
|
|
|
995 |
|
|
|
996 |
|
|
|
997 |
|
|
|
998 |
|
|
|
999 |
|
|
|
1000 |
|
|
|
1001 |
|
|
|
1002 |
|
|
|
1003 |
|
|
|
1004 |
|
|
Receiving Data from the Host
|
1005 |
|
|
|
1006 |
|
|
|
1007 |
|
|
usbs_start_rx_buffer
|
1008 |
|
|
Receiving Data from the Host
|
1009 |
|
|
|
1010 |
|
|
|
1011 |
|
|
|
1012 |
|
|
|
1013 |
|
|
|
1014 |
|
|
#include <cyg/io/usb/usbs.h>
|
1015 |
|
|
|
1016 |
|
|
|
1017 |
|
|
void usbs_start_rx_buffer
|
1018 |
|
|
usbs_rx_endpoint* ep
|
1019 |
|
|
unsigned char* buffer
|
1020 |
|
|
int length
|
1021 |
|
|
void (*)(void*,int) complete_fn
|
1022 |
|
|
void * complete_data
|
1023 |
|
|
|
1024 |
|
|
|
1025 |
|
|
|
1026 |
|
|
void usbs_start_rx
|
1027 |
|
|
usbs_rx_endpoint* ep
|
1028 |
|
|
|
1029 |
|
|
|
1030 |
|
|
|
1031 |
|
|
|
1032 |
|
|
|
1033 |
|
|
Description
|
1034 |
|
|
|
1035 |
|
|
usbs_start_rx_buffer is a USB-specific function
|
1036 |
|
|
to accept a transfer from host to peripheral. It can be used for bulk,
|
1037 |
|
|
interrupt or isochronous transfers, but not for control messages.
|
1038 |
|
|
Instead those involve manipulating the
|
1039 |
|
|
linkend="usbs-control">usbs_control_endpoint
|
1040 |
|
|
data structure directly. The function takes five arguments:
|
1041 |
|
|
|
1042 |
|
|
|
1043 |
|
|
|
1044 |
|
|
|
1045 |
|
|
The first argument identifies the specific endpoint that should be
|
1046 |
|
|
used. Different USB devices will support different sets of endpoints
|
1047 |
|
|
and the device driver will provide appropriate data structures. The
|
1048 |
|
|
device driver's documentation should be consulted for details of which
|
1049 |
|
|
endpoints are available.
|
1050 |
|
|
|
1051 |
|
|
|
1052 |
|
|
|
1053 |
|
|
|
1054 |
|
|
The buffer and length
|
1055 |
|
|
arguments control the actual transfer. USB device drivers are not
|
1056 |
|
|
expected to perform any buffering or to support partial transfers, so
|
1057 |
|
|
the length specified should correspond to the maximum transfer that is
|
1058 |
|
|
currently possible and the buffer should be at least this large. For
|
1059 |
|
|
isochronous transfers the USB specification imposes an upper bound of
|
1060 |
|
|
1023 bytes, and a smaller limit may be set in the
|
1061 |
|
|
linkend="usbs-enum-endpoint">enumeration data. Interrupt
|
1062 |
|
|
transfers are similarly straightforward with an upper bound of 64
|
1063 |
|
|
bytes, or less as per the enumeration data. Bulk transfers are more
|
1064 |
|
|
complicated because they can involve multiple 64-byte packets plus a
|
1065 |
|
|
terminating packet of less than 64 bytes, so there is no predefined
|
1066 |
|
|
limit on the transfer size. Instead it is left to higher-level
|
1067 |
|
|
protocols to specify an appropriate upper bound.
|
1068 |
|
|
|
1069 |
|
|
|
1070 |
|
|
One technique that may work for bulk transfers is to exploit the fact
|
1071 |
|
|
that such transfers happen in 64-byte packets: it may be possible to
|
1072 |
|
|
receive an initial 64 bytes, corresponding to the first packet in the
|
1073 |
|
|
transfer; these 64 bytes can then be examined to determine the total
|
1074 |
|
|
transfer size, and the remaining data can be transferred in another
|
1075 |
|
|
receive operation. This technique is not guaranteed to work with all
|
1076 |
|
|
USB hardware. Also, if the delay between accepting the first packet and
|
1077 |
|
|
the remainder of the transfer is excessive then this could cause
|
1078 |
|
|
timeout problems for the host-side software. For these reasons this
|
1079 |
|
|
technique should be avoided.
|
1080 |
|
|
|
1081 |
|
|
|
1082 |
|
|
|
1083 |
|
|
|
1084 |
|
|
usbs_start_rx_buffer is non-blocking. It merely
|
1085 |
|
|
starts the receive operation, and does not wait for completion. At
|
1086 |
|
|
some later point the USB device driver will invoke the completion
|
1087 |
|
|
function parameter with two arguments: the completion data defined by
|
1088 |
|
|
the last parameter and a result field. A result >=
|
1089 |
|
|
0 indicates a successful transfer of that many
|
1090 |
|
|
bytes, which may be less than the upper bound imposed by the
|
1091 |
|
|
length argument. A result <
|
1092 |
|
|
0 indicates an error. The most likely errors are
|
1093 |
|
|
-EPIPE to indicate that the connection between the
|
1094 |
|
|
host and the target has been broken, and -EAGAIN
|
1095 |
|
|
for when the endpoint has been
|
1096 |
|
|
linkend="usbs-halt">halted. Specific USB device drivers may
|
1097 |
|
|
specify additional error conditions.
|
1098 |
|
|
|
1099 |
|
|
|
1100 |
|
|
|
1101 |
|
|
|
1102 |
|
|
The normal sequence of events is that the USB device driver will
|
1103 |
|
|
update the appropriate hardware registers. At some point after that
|
1104 |
|
|
the host will attempt to send data by transmitting an OUT token
|
1105 |
|
|
followed by a data packet, and since a receive operation is now in
|
1106 |
|
|
progress the data will be accepted and ACK'd. If there were no receive
|
1107 |
|
|
operation then the peripheral would instead generate a NAK. The USB
|
1108 |
|
|
hardware will generate an interrupt once the whole packet has been
|
1109 |
|
|
received, and the USB device driver will service this interrupt and
|
1110 |
|
|
arrange for a DSR to be called. Isochronous and interrupt transfers
|
1111 |
|
|
involve just a single packet. However, bulk transfers may involve
|
1112 |
|
|
multiple packets so the device driver has to check whether the packet
|
1113 |
|
|
was a full 64 bytes or whether it was a terminating packet of less
|
1114 |
|
|
than this. When the device driver DSR detects a complete transfer it
|
1115 |
|
|
will inform higher-level code by invoking the supplied completion
|
1116 |
|
|
function.
|
1117 |
|
|
|
1118 |
|
|
|
1119 |
|
|
This means that the completion function will normally be invoked by a
|
1120 |
|
|
DSR and not in thread context - although some USB device drivers may
|
1121 |
|
|
have a different implementation. Therefore the completion function is
|
1122 |
|
|
restricted in what it can do. In particular it must not make any
|
1123 |
|
|
calls that will or may block such as locking a mutex or allocating
|
1124 |
|
|
memory. The kernel documentation should be consulted for more details
|
1125 |
|
|
of DSR's and interrupt handling generally.
|
1126 |
|
|
|
1127 |
|
|
|
1128 |
|
|
It is possible that the completion function will be invoked before
|
1129 |
|
|
usbs_start_rx_buffer returns. Such an event would
|
1130 |
|
|
be unusual because the transfer cannot happen until the next time the
|
1131 |
|
|
host tries to send data to this peripheral, but it may happen if for
|
1132 |
|
|
example another interrupt happens and a higher priority thread is
|
1133 |
|
|
scheduled to run. Also, if the endpoint is currently halted then the
|
1134 |
|
|
completion function will be invoked immediately with
|
1135 |
|
|
-EAGAIN: typically this will happen in the current
|
1136 |
|
|
thread rather than in a separate DSR. The completion function is
|
1137 |
|
|
allowed to start another transfer immediately by calling
|
1138 |
|
|
usbs_start_rx_buffer again.
|
1139 |
|
|
|
1140 |
|
|
|
1141 |
|
|
USB device drivers are not expected to perform any locking. It is the
|
1142 |
|
|
responsibility of higher-level code to ensure that there is only one
|
1143 |
|
|
receive operation for a given endpoint in progress at any one time. If
|
1144 |
|
|
there are concurrent calls to
|
1145 |
|
|
usbs_start_rx_buffer then the resulting behaviour
|
1146 |
|
|
is undefined. For typical USB applications this does not present any
|
1147 |
|
|
problems, because only one piece of code will access a given endpoint
|
1148 |
|
|
at any particular time.
|
1149 |
|
|
|
1150 |
|
|
|
1151 |
|
|
The following code fragment illustrates a very simple use of
|
1152 |
|
|
usbs_start_rx_buffer to implement a blocking
|
1153 |
|
|
receive, using a semaphore to synchronise between the foreground
|
1154 |
|
|
thread and the DSR. For a simple example like this no completion data
|
1155 |
|
|
is needed.
|
1156 |
|
|
|
1157 |
|
|
|
1158 |
|
|
static int error_code = 0;
|
1159 |
|
|
static cyg_sem_t completion_wait;
|
1160 |
|
|
|
1161 |
|
|
static void
|
1162 |
|
|
completion_fn(void* data, int result)
|
1163 |
|
|
{
|
1164 |
|
|
error_code = result;
|
1165 |
|
|
cyg_semaphore_post(&completion_wait);
|
1166 |
|
|
}
|
1167 |
|
|
|
1168 |
|
|
int
|
1169 |
|
|
blocking_receive(usbs_rx_endpoint* ep, unsigned char* buf, int len)
|
1170 |
|
|
{
|
1171 |
|
|
error_code = 0;
|
1172 |
|
|
usbs_start_rx_buffer(ep, buf, len, &completion_fn, NULL);
|
1173 |
|
|
cyg_semaphore_wait(&completion_wait);
|
1174 |
|
|
return error_code;
|
1175 |
|
|
}
|
1176 |
|
|
|
1177 |
|
|
|
1178 |
|
|
There is also a utility function usbs_start_rx. This
|
1179 |
|
|
can be used by code that wants to manipulate
|
1180 |
|
|
linkend="usbs-data">data endpoints directly, specifically the
|
1181 |
|
|
complete_fn,
|
1182 |
|
|
complete_data,
|
1183 |
|
|
buffer and
|
1184 |
|
|
buffer_size fields.
|
1185 |
|
|
usbs_start_tx just invokes a function
|
1186 |
|
|
supplied by the device driver.
|
1187 |
|
|
|
1188 |
|
|
|
1189 |
|
|
|
1190 |
|
|
|
1191 |
|
|
|
1192 |
|
|
|
1193 |
|
|
|
1194 |
|
|
|
1195 |
|
|
|
1196 |
|
|
Sending Data to the Host
|
1197 |
|
|
|
1198 |
|
|
|
1199 |
|
|
usbs_start_tx_buffer
|
1200 |
|
|
Sending Data to the Host
|
1201 |
|
|
|
1202 |
|
|
|
1203 |
|
|
|
1204 |
|
|
|
1205 |
|
|
|
1206 |
|
|
#include <cyg/io/usb/usbs.h>
|
1207 |
|
|
|
1208 |
|
|
|
1209 |
|
|
void usbs_start_tx_buffer
|
1210 |
|
|
usbs_tx_endpoint* ep
|
1211 |
|
|
const unsigned char* buffer
|
1212 |
|
|
int length
|
1213 |
|
|
void (*)(void*,int) complete_fn
|
1214 |
|
|
void * complete_data
|
1215 |
|
|
|
1216 |
|
|
|
1217 |
|
|
|
1218 |
|
|
void usbs_start_tx
|
1219 |
|
|
usbs_tx_endpoint* ep
|
1220 |
|
|
|
1221 |
|
|
|
1222 |
|
|
|
1223 |
|
|
|
1224 |
|
|
|
1225 |
|
|
Description
|
1226 |
|
|
|
1227 |
|
|
usbs_start_tx_buffer is a USB-specific function
|
1228 |
|
|
to transfer data from peripheral to host. It can be used for bulk,
|
1229 |
|
|
interrupt or isochronous transfers, but not for control messages;
|
1230 |
|
|
instead those involve manipulating the
|
1231 |
|
|
linkend="usbs-control">usbs_control_endpoint
|
1232 |
|
|
data structure directly. The function takes five arguments:
|
1233 |
|
|
|
1234 |
|
|
|
1235 |
|
|
|
1236 |
|
|
|
1237 |
|
|
The first argument identifies the specific endpoint that should be
|
1238 |
|
|
used. Different USB devices will support different sets of endpoints
|
1239 |
|
|
and the device driver will provide appropriate data structures. The
|
1240 |
|
|
device driver's documentation should be consulted for details of which
|
1241 |
|
|
endpoints are available.
|
1242 |
|
|
|
1243 |
|
|
|
1244 |
|
|
|
1245 |
|
|
|
1246 |
|
|
The buffer and length
|
1247 |
|
|
arguments control the actual transfer. USB device drivers are not
|
1248 |
|
|
allowed to modify the buffer during the transfer, so the data can
|
1249 |
|
|
reside in read-only memory. The transfer will be for all the data
|
1250 |
|
|
specified, and it is the responsibility of higher-level code to make
|
1251 |
|
|
sure that the host is expecting this amount of data. For isochronous
|
1252 |
|
|
transfers the USB specification imposes an upper bound of 1023 bytes,
|
1253 |
|
|
but a smaller limit may be set in the
|
1254 |
|
|
linkend="usbs-enum-endpoint">enumeration data. Interrupt
|
1255 |
|
|
transfers have an upper bound of 64 bytes or less, as per the
|
1256 |
|
|
enumeration data. Bulk transfers are more complicated because they can
|
1257 |
|
|
involve multiple 64-byte packets plus a terminating packet of less
|
1258 |
|
|
than 64 bytes, so the basic USB specification does not impose an upper
|
1259 |
|
|
limit on the total transfer size. Instead it is left to higher-level
|
1260 |
|
|
protocols to specify an appropriate upper bound. If the peripheral
|
1261 |
|
|
attempts to send more data than the host is willing to accept then the
|
1262 |
|
|
resulting behaviour is undefined and may well depend on the specific
|
1263 |
|
|
host operating system being used.
|
1264 |
|
|
|
1265 |
|
|
|
1266 |
|
|
For bulk transfers, the USB device driver or the underlying hardware
|
1267 |
|
|
will automatically split the transfer up into the appropriate number
|
1268 |
|
|
of full-size 64-byte packets plus a single terminating packet, which
|
1269 |
|
|
may be 0 bytes.
|
1270 |
|
|
|
1271 |
|
|
|
1272 |
|
|
|
1273 |
|
|
|
1274 |
|
|
usbs_start_tx_buffer is non-blocking. It merely
|
1275 |
|
|
starts the transmit operation, and does not wait for completion. At
|
1276 |
|
|
some later point the USB device driver will invoke the completion
|
1277 |
|
|
function parameter with two arguments: the completion data defined by
|
1278 |
|
|
the last parameter, and a result field. This result will be either an
|
1279 |
|
|
error code < 0, or the amount of data
|
1280 |
|
|
transferred which should correspond to the
|
1281 |
|
|
length argument. The most likely errors are
|
1282 |
|
|
-EPIPE to indicate that the connection between the
|
1283 |
|
|
host and the target has been broken, and -EAGAIN
|
1284 |
|
|
for when the endpoint has been
|
1285 |
|
|
linkend="usbs-halt">halted. Specific USB device drivers may
|
1286 |
|
|
define additional error conditions.
|
1287 |
|
|
|
1288 |
|
|
|
1289 |
|
|
|
1290 |
|
|
|
1291 |
|
|
The normal sequence of events is that the USB device driver will
|
1292 |
|
|
update the appropriate hardware registers. At some point after that
|
1293 |
|
|
the host will attempt to fetch data by transmitting an IN token. Since
|
1294 |
|
|
a transmit operation is now in progress the peripheral can send a
|
1295 |
|
|
packet of data, and the host will generate an ACK. At this point the
|
1296 |
|
|
USB hardware will generate an interrupt, and the device driver will
|
1297 |
|
|
service this interrupt and arrange for a DSR to be called. Isochronous
|
1298 |
|
|
and interrupt transfers involve just a single packet. However, bulk
|
1299 |
|
|
transfers may involve multiple packets so the device driver has to
|
1300 |
|
|
check whether there is more data to send and set things up for the
|
1301 |
|
|
next packet. When the device driver DSR detects a complete transfer it
|
1302 |
|
|
will inform higher-level code by invoking the supplied completion
|
1303 |
|
|
function.
|
1304 |
|
|
|
1305 |
|
|
|
1306 |
|
|
This means that the completion function will normally be invoked by a
|
1307 |
|
|
DSR and not in thread context - although some USB device drivers may
|
1308 |
|
|
have a different implementation. Therefore the completion function is
|
1309 |
|
|
restricted in what it can do, in particular it must not make any
|
1310 |
|
|
calls that will or may block such as locking a mutex or allocating
|
1311 |
|
|
memory. The kernel documentation should be consulted for more details
|
1312 |
|
|
of DSR's and interrupt handling generally.
|
1313 |
|
|
|
1314 |
|
|
|
1315 |
|
|
It is possible that the completion function will be invoked before
|
1316 |
|
|
usbs_start_tx_buffer returns. Such an event would
|
1317 |
|
|
be unusual because the transfer cannot happen until the next time the
|
1318 |
|
|
host tries to fetch data from this peripheral, but it may happen if,
|
1319 |
|
|
for example, another interrupt happens and a higher priority thread is
|
1320 |
|
|
scheduled to run. Also, if the endpoint is currently halted then the
|
1321 |
|
|
completion function will be invoked immediately with
|
1322 |
|
|
-EAGAIN: typically this will happen in the current
|
1323 |
|
|
thread rather than in a separate DSR. The completion function is
|
1324 |
|
|
allowed to start another transfer immediately by calling
|
1325 |
|
|
usbs_start_tx_buffer again.
|
1326 |
|
|
|
1327 |
|
|
|
1328 |
|
|
USB device drivers are not expected to perform any locking. It is the
|
1329 |
|
|
responsibility of higher-level code to ensure that there is only one
|
1330 |
|
|
transmit operation for a given endpoint in progress at any one time.
|
1331 |
|
|
If there are concurrent calls to
|
1332 |
|
|
usbs_start_tx_buffer then the resulting behaviour
|
1333 |
|
|
is undefined. For typical USB applications this does not present any
|
1334 |
|
|
problems because only piece of code will access a given endpoint at
|
1335 |
|
|
any particular time.
|
1336 |
|
|
|
1337 |
|
|
|
1338 |
|
|
The following code fragment illustrates a very simple use of
|
1339 |
|
|
usbs_start_tx_buffer to implement a blocking
|
1340 |
|
|
transmit, using a semaphore to synchronise between the foreground
|
1341 |
|
|
thread and the DSR. For a simple example like this no completion data
|
1342 |
|
|
is needed.
|
1343 |
|
|
|
1344 |
|
|
|
1345 |
|
|
static int error_code = 0;
|
1346 |
|
|
static cyg_sem_t completion_wait;
|
1347 |
|
|
|
1348 |
|
|
static void
|
1349 |
|
|
completion_fn(void* data, int result)
|
1350 |
|
|
{
|
1351 |
|
|
error_code = result;
|
1352 |
|
|
cyg_semaphore_post(&completion_wait);
|
1353 |
|
|
}
|
1354 |
|
|
|
1355 |
|
|
int
|
1356 |
|
|
blocking_transmit(usbs_tx_endpoint* ep, const unsigned char* buf, int len)
|
1357 |
|
|
{
|
1358 |
|
|
error_code = 0;
|
1359 |
|
|
usbs_start_tx_buffer(ep, buf, len, &completion_fn, NULL);
|
1360 |
|
|
cyg_semaphore_wait(&completion_wait);
|
1361 |
|
|
return error_code;
|
1362 |
|
|
}
|
1363 |
|
|
|
1364 |
|
|
|
1365 |
|
|
There is also a utility function usbs_start. This
|
1366 |
|
|
can be used by code that wants to manipulate
|
1367 |
|
|
linkend="usbs-data">data endpoints directly, specifically the
|
1368 |
|
|
complete_fn,
|
1369 |
|
|
complete_data,
|
1370 |
|
|
buffer and
|
1371 |
|
|
buffer_size fields.
|
1372 |
|
|
usbs_start_tx just calls a function supplied by
|
1373 |
|
|
the device driver.
|
1374 |
|
|
|
1375 |
|
|
|
1376 |
|
|
|
1377 |
|
|
|
1378 |
|
|
|
1379 |
|
|
|
1380 |
|
|
|
1381 |
|
|
|
1382 |
|
|
|
1383 |
|
|
Halted Endpoints
|
1384 |
|
|
|
1385 |
|
|
|
1386 |
|
|
Halted Endpoints
|
1387 |
|
|
Support for Halting and Halted Endpoints
|
1388 |
|
|
|
1389 |
|
|
|
1390 |
|
|
|
1391 |
|
|
|
1392 |
|
|
|
1393 |
|
|
|
1394 |
|
|
#include <cyg/io/usb/usbs.h>
|
1395 |
|
|
|
1396 |
|
|
|
1397 |
|
|
|
1398 |
|
|
cyg_bool usbs_rx_endpoint_halted
|
1399 |
|
|
usbs_rx_endpoint* ep
|
1400 |
|
|
|
1401 |
|
|
|
1402 |
|
|
void usbs_set_rx_endpoint_halted
|
1403 |
|
|
usbs_rx_endpoint* ep
|
1404 |
|
|
cyg_bool new_state
|
1405 |
|
|
|
1406 |
|
|
|
1407 |
|
|
void usbs_start_rx_endpoint_wait
|
1408 |
|
|
usbs_rx_endpoint* ep
|
1409 |
|
|
void (*)(void*, int) complete_fn
|
1410 |
|
|
void * complete_data
|
1411 |
|
|
|
1412 |
|
|
|
1413 |
|
|
|
1414 |
|
|
cyg_bool
|
1415 |
|
|
usbs_tx_endpoint_halted
|
1416 |
|
|
usbs_tx_endpoint* ep
|
1417 |
|
|
|
1418 |
|
|
|
1419 |
|
|
void usbs_set_tx_endpoint_halted
|
1420 |
|
|
usbs_tx_endpoint* ep
|
1421 |
|
|
cyg_bool new_state
|
1422 |
|
|
|
1423 |
|
|
|
1424 |
|
|
void usbs_start_tx_endpoint_wait
|
1425 |
|
|
usbs_tx_endpoint* ep
|
1426 |
|
|
void (*)(void*, int) complete_fn
|
1427 |
|
|
void * complete_data
|
1428 |
|
|
|
1429 |
|
|
|
1430 |
|
|
|
1431 |
|
|
|
1432 |
|
|
|
1433 |
|
|
Description
|
1434 |
|
|
|
1435 |
|
|
Normal USB traffic involves straightforward handshakes, with either an
|
1436 |
|
|
ACK to indicate that a packet was transferred
|
1437 |
|
|
without errors, or a NAK if an error occurred, or
|
1438 |
|
|
if a peripheral is currently unable to process another packet from the
|
1439 |
|
|
host, or has no packet to send to the host. There is a third form of
|
1440 |
|
|
handshake, a STALL, which indicates that the
|
1441 |
|
|
endpoint is currently halted.
|
1442 |
|
|
|
1443 |
|
|
|
1444 |
|
|
When an endpoint is halted it means that the host-side code needs to
|
1445 |
|
|
take some sort of recovery action before communication over that
|
1446 |
|
|
endpoint can resume. The exact circumstances under which this can
|
1447 |
|
|
happen are not defined by the USB specification, but one example would
|
1448 |
|
|
be a protocol violation if say the peripheral attempted to transmit
|
1449 |
|
|
more data to the host than was permitted by the protocol in use. The
|
1450 |
|
|
host can use the standard control messages get-status, set-feature and
|
1451 |
|
|
clear-feature to examine and manipulate the halted status of a given
|
1452 |
|
|
endpoint. There are USB-specific functions which can be used inside
|
1453 |
|
|
the peripheral to achieve the same effect. Once an endpoint has been
|
1454 |
|
|
halted the host can then interact with the peripheral using class or
|
1455 |
|
|
vendor control messages to perform appropriate recovery, and then the
|
1456 |
|
|
halted condition can be cleared.
|
1457 |
|
|
|
1458 |
|
|
|
1459 |
|
|
Halting an endpoint does not constitute a device state change, and
|
1460 |
|
|
there is no mechanism by which higher-level code can be informed
|
1461 |
|
|
immediately. However, any ongoing receive or transmit operations will
|
1462 |
|
|
be aborted with an -EAGAIN error, and any new
|
1463 |
|
|
receives or transmits will fail immediately with the same error.
|
1464 |
|
|
|
1465 |
|
|
|
1466 |
|
|
There are six functions to support halted endpoints, one set for
|
1467 |
|
|
receive endpoints and another for transmit endpoints, with both sets
|
1468 |
|
|
behaving in essentially the same way. The first,
|
1469 |
|
|
usbs_rx_endpoint_halted, can be used to determine
|
1470 |
|
|
whether or not an endpoint is currently halted: it takes a single
|
1471 |
|
|
argument that identifies the endpoint of interest. The second
|
1472 |
|
|
function, usbs_set_rx_endpoint_halted, can be
|
1473 |
|
|
used to change the halted condition of an endpoint: it takes two
|
1474 |
|
|
arguments; one to identify the endpoint and another to specify the new
|
1475 |
|
|
state. The last function
|
1476 |
|
|
usbs_start_rx_endpoint_wait operates in much the
|
1477 |
|
|
same way as usbs_start_rx_buffer: when the
|
1478 |
|
|
endpoint is no longer halted the device driver will invoke the
|
1479 |
|
|
supplied completion function with a status of 0. The completion
|
1480 |
|
|
function has the same signature as that for a transfer operation.
|
1481 |
|
|
Often it will be possible to use a single completion function and have
|
1482 |
|
|
the foreground code invoke either
|
1483 |
|
|
usbs_start_rx_buffer or
|
1484 |
|
|
usbs_start_rx_endpoint_wait depending on the
|
1485 |
|
|
current state of the endpoint.
|
1486 |
|
|
|
1487 |
|
|
|
1488 |
|
|
|
1489 |
|
|
|
1490 |
|
|
|
1491 |
|
|
|
1492 |
|
|
|
1493 |
|
|
|
1494 |
|
|
|
1495 |
|
|
Control Endpoints
|
1496 |
|
|
|
1497 |
|
|
|
1498 |
|
|
Control Endpoints
|
1499 |
|
|
Control endpoint data structure
|
1500 |
|
|
|
1501 |
|
|
|
1502 |
|
|
|
1503 |
|
|
|
1504 |
|
|
#include <cyg/io/usb/usbs.h>
|
1505 |
|
|
|
1506 |
|
|
typedef struct usbs_control_endpoint {
|
1507 |
|
|
*hellip;
|
1508 |
|
|
} usbs_control_endpoint;
|
1509 |
|
|
|
1510 |
|
|
|
1511 |
|
|
|
1512 |
|
|
usbs_control_endpoint Data Structure
|
1513 |
|
|
|
1514 |
|
|
The device driver for a USB slave device should supply one
|
1515 |
|
|
usbs_control_endpoint data structure per USB
|
1516 |
|
|
device. This corresponds to endpoint 0 which will be used for all
|
1517 |
|
|
control message interaction between the host and that device. The data
|
1518 |
|
|
structure is also used for internal management purposes, for example
|
1519 |
|
|
to keep track of the current state. In a typical USB peripheral there
|
1520 |
|
|
will only be one such data structure in the entire system, but if
|
1521 |
|
|
there are multiple USB slave ports, allowing the peripheral to be
|
1522 |
|
|
connected to multiple hosts, then there will be a separate data
|
1523 |
|
|
structure for each one. The name or names of the data structures are
|
1524 |
|
|
determined by the device drivers. For example, the SA11x0 USB device
|
1525 |
|
|
driver package provides usbs_sa11x0_ep0.
|
1526 |
|
|
|
1527 |
|
|
|
1528 |
|
|
The operations on a control endpoint do not fit cleanly into a
|
1529 |
|
|
conventional open/read/write I/O model. For example, when the host
|
1530 |
|
|
sends a control message to the USB peripheral this may be one of four
|
1531 |
|
|
types: standard, class, vendor and reserved. Some or all of the
|
1532 |
|
|
standard control messages will be handled automatically by the common
|
1533 |
|
|
USB slave package or by the device driver itself. Other standard
|
1534 |
|
|
control messages and the other types of control messages may be
|
1535 |
|
|
handled by a class-specific package or by application code. Although
|
1536 |
|
|
it would be possible to have devtab entries such as
|
1537 |
|
|
/dev/usbs_ep0/standard and
|
1538 |
|
|
/dev/usbs_ep0/class, and then support read and
|
1539 |
|
|
write operations on these devtab entries, this would add significant
|
1540 |
|
|
overhead and code complexity. Instead, all of the fields in the
|
1541 |
|
|
control endpoint data structure are public and can be manipulated
|
1542 |
|
|
directly by higher level code if and when required.
|
1543 |
|
|
|
1544 |
|
|
|
1545 |
|
|
Control endpoints involve a number of callback functions, with
|
1546 |
|
|
higher-level code installing suitable function pointers in the control
|
1547 |
|
|
endpoint data structure. For example, if the peripheral involves
|
1548 |
|
|
vendor-specific control messages then a suitable handler for these
|
1549 |
|
|
messages should be installed. Although the exact details depend on the
|
1550 |
|
|
device driver, typically these callback functions will be invoked at
|
1551 |
|
|
DSR level rather than thread level. Therefore, only certain eCos
|
1552 |
|
|
functions can be invoked; specifically, those functions that are
|
1553 |
|
|
guaranteed not to block. If a potentially blocking function such as a
|
1554 |
|
|
semaphore wait or a mutex lock operation is invoked from inside the
|
1555 |
|
|
callback then the resulting behaviour is undefined, and the system as
|
1556 |
|
|
a whole may fail. In addition, if one of the callback functions
|
1557 |
|
|
involves significant processing effort then this may adversely affect
|
1558 |
|
|
the system's real time characteristics. The eCos kernel documentation
|
1559 |
|
|
should be consulted for more details of DSR handling.
|
1560 |
|
|
|
1561 |
|
|
|
1562 |
|
|
Initialization
|
1563 |
|
|
|
1564 |
|
|
The usbs_control_endpoint data structure
|
1565 |
|
|
contains the following fields related to initialization.
|
1566 |
|
|
|
1567 |
|
|
|
1568 |
|
|
typedef struct usbs_control_endpoint {
|
1569 |
|
|
…
|
1570 |
|
|
const usbs_enumeration_data* enumeration_data;
|
1571 |
|
|
void (*start_fn)(usbs_control_endpoint*);
|
1572 |
|
|
…
|
1573 |
|
|
};
|
1574 |
|
|
|
1575 |
|
|
|
1576 |
|
|
It is the responsibility of higher-level code, usually the
|
1577 |
|
|
application, to define the USB enumeration data. This needs to be
|
1578 |
|
|
installed in the control endpoint data structure early on during
|
1579 |
|
|
system startup, before the USB device is actually started and any
|
1580 |
|
|
interaction with the host is possible. Details of the enumeration data
|
1581 |
|
|
are supplied in the section USB Enumeration
|
1582 |
|
|
Data. Typically, the enumeration data is constant for a given
|
1583 |
|
|
peripheral, although it can be constructed dynamically if necessary.
|
1584 |
|
|
However, the enumeration data cannot change while the peripheral is
|
1585 |
|
|
connected to a host: the peripheral cannot easily claim to be a
|
1586 |
|
|
keyboard one second and a printer the next.
|
1587 |
|
|
|
1588 |
|
|
|
1589 |
|
|
The start_fn member is normally accessed
|
1590 |
|
|
via the utility
|
1591 |
|
|
linkend="usbs-start">usbs_start rather
|
1592 |
|
|
than directly. It is provided by the device driver and should be
|
1593 |
|
|
invoked once the system is fully initialized and interaction with the
|
1594 |
|
|
host is possible. A typical implementation would change the USB data
|
1595 |
|
|
pins from tristated to active. If the peripheral is already plugged
|
1596 |
|
|
into a host then the latter should detect this change and start
|
1597 |
|
|
interacting with the peripheral, including requesting the enumeration
|
1598 |
|
|
data.
|
1599 |
|
|
|
1600 |
|
|
|
1601 |
|
|
|
1602 |
|
|
State
|
1603 |
|
|
|
1604 |
|
|
There are three usbs_control_endpoint fields
|
1605 |
|
|
related to the current state of a USB slave device, plus some state
|
1606 |
|
|
constants and an enumeration of the possible state changes:
|
1607 |
|
|
|
1608 |
|
|
|
1609 |
|
|
typedef struct usbs_control_endpoint {
|
1610 |
|
|
…
|
1611 |
|
|
int state;
|
1612 |
|
|
void (*state_change_fn)(struct usbs_control_endpoint*, void*,
|
1613 |
|
|
usbs_state_change, int);
|
1614 |
|
|
void* state_change_data;
|
1615 |
|
|
…
|
1616 |
|
|
};
|
1617 |
|
|
|
1618 |
|
|
#define USBS_STATE_DETACHED 0x01
|
1619 |
|
|
#define USBS_STATE_ATTACHED 0x02
|
1620 |
|
|
#define USBS_STATE_POWERED 0x03
|
1621 |
|
|
#define USBS_STATE_DEFAULT 0x04
|
1622 |
|
|
#define USBS_STATE_ADDRESSED 0x05
|
1623 |
|
|
#define USBS_STATE_CONFIGURED 0x06
|
1624 |
|
|
#define USBS_STATE_MASK 0x7F
|
1625 |
|
|
#define USBS_STATE_SUSPENDED (1 << 7)
|
1626 |
|
|
|
1627 |
|
|
typedef enum {
|
1628 |
|
|
USBS_STATE_CHANGE_DETACHED = 1,
|
1629 |
|
|
USBS_STATE_CHANGE_ATTACHED = 2,
|
1630 |
|
|
USBS_STATE_CHANGE_POWERED = 3,
|
1631 |
|
|
USBS_STATE_CHANGE_RESET = 4,
|
1632 |
|
|
USBS_STATE_CHANGE_ADDRESSED = 5,
|
1633 |
|
|
USBS_STATE_CHANGE_CONFIGURED = 6,
|
1634 |
|
|
USBS_STATE_CHANGE_DECONFIGURED = 7,
|
1635 |
|
|
USBS_STATE_CHANGE_SUSPENDED = 8,
|
1636 |
|
|
USBS_STATE_CHANGE_RESUMED = 9
|
1637 |
|
|
} usbs_state_change;
|
1638 |
|
|
|
1639 |
|
|
|
1640 |
|
|
The USB standard defines a number of states for a given USB
|
1641 |
|
|
peripheral. The initial state is detached, where
|
1642 |
|
|
the peripheral is either not connected to a host at all or, from the
|
1643 |
|
|
host's perspective, the peripheral has not started up yet because the
|
1644 |
|
|
relevant pins are tristated. The peripheral then moves via
|
1645 |
|
|
intermediate attached and
|
1646 |
|
|
powered states to its default or
|
1647 |
|
|
reset state, at which point the host and
|
1648 |
|
|
peripheral can actually start exchanging data. The first message is
|
1649 |
|
|
from host to peripheral and provides a unique 7-bit address within the
|
1650 |
|
|
local USB network, resulting in a state change to
|
1651 |
|
|
addressed. The host then requests enumeration
|
1652 |
|
|
data and performs other initialization. If everything succeeds the
|
1653 |
|
|
host sends a standard set-configuration control message, after which
|
1654 |
|
|
the peripheral is configured and expected to be
|
1655 |
|
|
up and running. Note that some USB device drivers may be unable to
|
1656 |
|
|
distinguish between the detached,
|
1657 |
|
|
attached and powered states
|
1658 |
|
|
but generally this is not important to higher-level code.
|
1659 |
|
|
|
1660 |
|
|
|
1661 |
|
|
A USB host should generate at least one token every millisecond. If a
|
1662 |
|
|
peripheral fails to detect any USB traffic for a period of time then
|
1663 |
|
|
typically this indicates that the host has entered a power-saving
|
1664 |
|
|
mode, and the peripheral should do the same if possible. This
|
1665 |
|
|
corresponds to the suspended bit. The actual
|
1666 |
|
|
state is a combination of suspended and the
|
1667 |
|
|
previous state, for example configured and
|
1668 |
|
|
suspended rather than just
|
1669 |
|
|
suspended. When the peripheral subsequently
|
1670 |
|
|
detects USB traffic it would switch back to the
|
1671 |
|
|
configured state.
|
1672 |
|
|
|
1673 |
|
|
|
1674 |
|
|
The USB device driver and the common USB slave package will maintain
|
1675 |
|
|
the current state in the control endpoint's
|
1676 |
|
|
state field. There should be no need for
|
1677 |
|
|
any other code to change this field, but it can be examined whenever
|
1678 |
|
|
appropriate. In addition whenever a state change occurs the generic
|
1679 |
|
|
code can invoke a state change callback function. By default, no such
|
1680 |
|
|
callback function will be installed. Some class-specific packages such
|
1681 |
|
|
as the USB-ethernet package will install a suitable function to keep
|
1682 |
|
|
track of whether or not the host-peripheral connection is up, that is
|
1683 |
|
|
whether or not ethernet packets can be exchanged. Application code can
|
1684 |
|
|
also update this field. If multiple parties want to be informed of
|
1685 |
|
|
state changes, for example both a class-specific package and
|
1686 |
|
|
application code, then typically the application code will install its
|
1687 |
|
|
state change handler after the class-specific package and is
|
1688 |
|
|
responsible for chaining into the package's handler.
|
1689 |
|
|
|
1690 |
|
|
|
1691 |
|
|
The state change callback function is invoked with four arguments. The
|
1692 |
|
|
first identifies the control endpoint. The second is an arbitrary
|
1693 |
|
|
pointer: higher-level code can fill in the
|
1694 |
|
|
state_change_data field to set this. The
|
1695 |
|
|
third argument specifies the state change that has occurred, and the
|
1696 |
|
|
last argument supplies the previous state (the new state is readily
|
1697 |
|
|
available from the control endpoint structure).
|
1698 |
|
|
|
1699 |
|
|
|
1700 |
|
|
eCos does not provide any utility functions for updating or examining
|
1701 |
|
|
the state_change_fn or
|
1702 |
|
|
state_change_data fields. Instead, it is
|
1703 |
|
|
expected that the fields in the
|
1704 |
|
|
usbs_control_endpoint data structure will be
|
1705 |
|
|
manipulated directly. Any utility functions would do just this, but
|
1706 |
|
|
at the cost of increased code and cpu overheads.
|
1707 |
|
|
|
1708 |
|
|
|
1709 |
|
|
|
1710 |
|
|
Standard Control Messages
|
1711 |
|
|
|
1712 |
|
|
typedef struct usbs_control_endpoint {
|
1713 |
|
|
…
|
1714 |
|
|
unsigned char control_buffer[8];
|
1715 |
|
|
usbs_control_return (*standard_control_fn)(struct usbs_control_endpoint*, void*);
|
1716 |
|
|
void* standard_control_data;
|
1717 |
|
|
…
|
1718 |
|
|
} usbs_control_endpoint;
|
1719 |
|
|
|
1720 |
|
|
typedef enum {
|
1721 |
|
|
USBS_CONTROL_RETURN_HANDLED = 0,
|
1722 |
|
|
USBS_CONTROL_RETURN_UNKNOWN = 1,
|
1723 |
|
|
USBS_CONTROL_RETURN_STALL = 2
|
1724 |
|
|
} usbs_control_return;
|
1725 |
|
|
|
1726 |
|
|
extern usbs_control_return usbs_handle_standard_control(struct usbs_control_endpoint*);
|
1727 |
|
|
|
1728 |
|
|
|
1729 |
|
|
When a USB peripheral is connected to the host it must always respond
|
1730 |
|
|
to control messages sent to endpoint 0. Control messages always
|
1731 |
|
|
consist of an initial eight-byte header, containing fields such as a
|
1732 |
|
|
request type. This may be followed by a further data transfer, either
|
1733 |
|
|
from host to peripheral or from peripheral to host. The way this is
|
1734 |
|
|
handled is described in the
|
1735 |
|
|
linkend="usbs-control-buffer">Buffer Management section below.
|
1736 |
|
|
|
1737 |
|
|
|
1738 |
|
|
The USB device driver will always accept the initial eight-byte
|
1739 |
|
|
header, storing it in the control_buffer
|
1740 |
|
|
field. Then it determines the request type: standard, class, vendor,
|
1741 |
|
|
or reserved. The way in which the last three of these are processed is
|
1742 |
|
|
described in the section Other
|
1743 |
|
|
Control Messages. Some
|
1744 |
|
|
standard control messages will be handled by the device driver itself;
|
1745 |
|
|
typically the set-address request and the
|
1746 |
|
|
get-status, set-feature and
|
1747 |
|
|
clear-feature requests when applied to endpoints.
|
1748 |
|
|
|
1749 |
|
|
|
1750 |
|
|
If a standard control message cannot be handled by the device driver
|
1751 |
|
|
itself, the driver checks the
|
1752 |
|
|
standard_control_fn field in the control
|
1753 |
|
|
endpoint data structure. If higher-level code has installed a suitable
|
1754 |
|
|
callback function then this will be invoked with two argument, the
|
1755 |
|
|
control endpoint data structure itself and the
|
1756 |
|
|
standard_control_data field. The latter
|
1757 |
|
|
allows the higher level code to associate arbitrary data with the
|
1758 |
|
|
control endpoint. The callback function can return one of three
|
1759 |
|
|
values: HANDLED to indicate that the request has
|
1760 |
|
|
been processed; UNKNOWN if the message should be
|
1761 |
|
|
handled by the default code; or STALL to indicate
|
1762 |
|
|
an error condition. If higher level code has not installed a callback
|
1763 |
|
|
function or if the callback function has returned
|
1764 |
|
|
UNKNOWN then the device driver will invoke a
|
1765 |
|
|
default handler, usbs_handle_standard_control
|
1766 |
|
|
provided by the common USB slave package.
|
1767 |
|
|
|
1768 |
|
|
|
1769 |
|
|
The default handler can cope with all of the standard control messages
|
1770 |
|
|
for a simple USB peripheral. However, if the peripheral involves
|
1771 |
|
|
multiple configurations, multiple interfaces in a configuration, or
|
1772 |
|
|
alternate settings for an interface, then this cannot be handled by
|
1773 |
|
|
generic code. For example, a multimedia peripheral may support various
|
1774 |
|
|
alternate settings for a given data source with different bandwidth
|
1775 |
|
|
requirements, and the host can select a setting that takes into
|
1776 |
|
|
account the current load. Clearly higher-level code needs to be aware
|
1777 |
|
|
when the host changes the current setting, so that it can adjust the
|
1778 |
|
|
rate at which data is fed to or retrieved from the host. Therefore the
|
1779 |
|
|
higher-level code needs to install its own standard control callback
|
1780 |
|
|
and process appropriate messages, rather than leaving these to the
|
1781 |
|
|
default handler.
|
1782 |
|
|
|
1783 |
|
|
|
1784 |
|
|
The default handler will take care of the
|
1785 |
|
|
get-descriptor request used to obtain the
|
1786 |
|
|
enumeration data. It has support for string descriptors but ignores
|
1787 |
|
|
language encoding issues. If language encoding is important for the
|
1788 |
|
|
peripheral then this will have to be handled by an
|
1789 |
|
|
application-specific standard control handler.
|
1790 |
|
|
|
1791 |
|
|
|
1792 |
|
|
The header file
|
1793 |
|
|
class="headerfile"><cyg/io/usb/usb.h> defines various
|
1794 |
|
|
constants related to control messages, for example the function codes
|
1795 |
|
|
corresponding to the standard request types. This header file is
|
1796 |
|
|
provided by the common USB package, not by the USB slave package,
|
1797 |
|
|
since the information is also relevant to USB hosts.
|
1798 |
|
|
|
1799 |
|
|
|
1800 |
|
|
|
1801 |
|
|
Other Control Messages
|
1802 |
|
|
|
1803 |
|
|
typedef struct usbs_control_endpoint {
|
1804 |
|
|
…
|
1805 |
|
|
usbs_control_return (*class_control_fn)(struct usbs_control_endpoint*, void*);
|
1806 |
|
|
void* class_control_data;
|
1807 |
|
|
usbs_control_return (*vendor_control_fn)(struct usbs_control_endpoint*, void*);
|
1808 |
|
|
void* vendor_control_data;
|
1809 |
|
|
usbs_control_return (*reserved_control_fn)(struct usbs_control_endpoint*, void*);
|
1810 |
|
|
void* reserved_control_data;
|
1811 |
|
|
…
|
1812 |
|
|
} usbs_control_endpoint;
|
1813 |
|
|
|
1814 |
|
|
|
1815 |
|
|
Non-standard control messages always have to be processed by
|
1816 |
|
|
higher-level code. This could be class-specific packages. For example,
|
1817 |
|
|
the USB-ethernet package will handle requests for getting the MAC
|
1818 |
|
|
address and for enabling or disabling promiscuous mode. In all cases
|
1819 |
|
|
the device driver will store the initial request in the
|
1820 |
|
|
control_buffer field, check for an
|
1821 |
|
|
appropriate handler, and invoke it with details of the control
|
1822 |
|
|
endpoint and any handler-specific data that has been installed
|
1823 |
|
|
alongside the handler itself. The handler should return either
|
1824 |
|
|
USBS_CONTROL_RETURN_HANDLED to report success or
|
1825 |
|
|
USBS_CONTROL_RETURN_STALL to report failure. The
|
1826 |
|
|
device driver will report this to the host.
|
1827 |
|
|
|
1828 |
|
|
|
1829 |
|
|
If there are multiple parties interested in a particular type of
|
1830 |
|
|
control messages, it is the responsibility of application code to
|
1831 |
|
|
install an appropriate handler and process the requests appropriately.
|
1832 |
|
|
|
1833 |
|
|
|
1834 |
|
|
|
1835 |
|
|
Buffer Management
|
1836 |
|
|
|
1837 |
|
|
typedef struct usbs_control_endpoint {
|
1838 |
|
|
…
|
1839 |
|
|
unsigned char* buffer;
|
1840 |
|
|
int buffer_size;
|
1841 |
|
|
void (*fill_buffer_fn)(struct usbs_control_endpoint*);
|
1842 |
|
|
void* fill_data;
|
1843 |
|
|
int fill_index;
|
1844 |
|
|
usbs_control_return (*complete_fn)(struct usbs_control_endpoint*, int);
|
1845 |
|
|
…
|
1846 |
|
|
} usbs_control_endpoint;
|
1847 |
|
|
|
1848 |
|
|
|
1849 |
|
|
Many USB control messages involve transferring more data than just the
|
1850 |
|
|
initial eight-byte header. The header indicates the direction of the
|
1851 |
|
|
transfer, OUT for host to peripheral or IN for peripheral to host.
|
1852 |
|
|
It also specifies a length field, which is exact for an OUT transfer
|
1853 |
|
|
or an upper bound for an IN transfer. Control message handlers can
|
1854 |
|
|
manipulate six fields within the control endpoint data structure to
|
1855 |
|
|
ensure that the transfer happens correctly.
|
1856 |
|
|
|
1857 |
|
|
|
1858 |
|
|
For an OUT transfer, the handler should examine the length field in
|
1859 |
|
|
the header and provide a single buffer for all the data. A
|
1860 |
|
|
class-specific protocol would typically impose an upper bound on the
|
1861 |
|
|
amount of data, allowing the buffer to be allocated statically.
|
1862 |
|
|
The handler should update the buffer and
|
1863 |
|
|
complete_fn fields. When all the data has
|
1864 |
|
|
been transferred the completion callback will be invoked, and its
|
1865 |
|
|
return value determines the response sent back to the host. The USB
|
1866 |
|
|
standard allows for a new control message to be sent before the
|
1867 |
|
|
current transfer has completed, effectively cancelling the current
|
1868 |
|
|
operation. When this happens the completion function will also be
|
1869 |
|
|
invoked. The second argument to the completion function specifies what
|
1870 |
|
|
has happened, with a value of 0 indicating success and an error code
|
1871 |
|
|
such as -EPIPE or -EIO
|
1872 |
|
|
indicating that the current transfer has been cancelled.
|
1873 |
|
|
|
1874 |
|
|
|
1875 |
|
|
IN transfers are a little bit more complicated. The required
|
1876 |
|
|
information, for example the enumeration data, may not be in a single
|
1877 |
|
|
contiguous buffer. Instead a mechanism is provided by which the buffer
|
1878 |
|
|
can be refilled, thus allowing the transfer to move from one record to
|
1879 |
|
|
the next. Essentially, the transfer operates as follows:
|
1880 |
|
|
|
1881 |
|
|
|
1882 |
|
|
|
1883 |
|
|
|
1884 |
|
|
When the host requests another chunk of data (typically eight bytes),
|
1885 |
|
|
the USB device driver will examine the
|
1886 |
|
|
buffer_size field. If non-zero then
|
1887 |
|
|
buffer contains at least one more byte of
|
1888 |
|
|
data, and then buffer_size is decremented.
|
1889 |
|
|
|
1890 |
|
|
|
1891 |
|
|
|
1892 |
|
|
|
1893 |
|
|
When buffer_size has dropped to 0, the
|
1894 |
|
|
fill_buffer_fn field will be examined. If
|
1895 |
|
|
non-null it will be invoked to refill the buffer.
|
1896 |
|
|
|
1897 |
|
|
|
1898 |
|
|
|
1899 |
|
|
|
1900 |
|
|
The fill_data and
|
1901 |
|
|
fill_index fields are not used by the
|
1902 |
|
|
device driver. Instead these fields are available to the refill
|
1903 |
|
|
function to keep track of the current state of the transfer.
|
1904 |
|
|
|
1905 |
|
|
|
1906 |
|
|
|
1907 |
|
|
|
1908 |
|
|
When buffer_size is 0 and
|
1909 |
|
|
fill_buffer_fn is NULL, no more data is
|
1910 |
|
|
available and the transfer has completed.
|
1911 |
|
|
|
1912 |
|
|
|
1913 |
|
|
|
1914 |
|
|
|
1915 |
|
|
Optionally a completion function can be installed. This will be
|
1916 |
|
|
invoked with 0 if the transfer completes successfully, or with an
|
1917 |
|
|
error code if the transfer is cancelled because of another control
|
1918 |
|
|
messsage.
|
1919 |
|
|
|
1920 |
|
|
|
1921 |
|
|
|
1922 |
|
|
|
1923 |
|
|
If the requested data is contiguous then the only fields that need
|
1924 |
|
|
to be manipulated are buffer and
|
1925 |
|
|
buffer_size, and optionally
|
1926 |
|
|
complete_fn. If the requested data is not
|
1927 |
|
|
contiguous then the initial control message handler should update
|
1928 |
|
|
fill_buffer_fn and some or all of the other
|
1929 |
|
|
fields, as required. An example of this is the handling of the
|
1930 |
|
|
standard get-descriptor control message by
|
1931 |
|
|
usbs_handle_standard_control.
|
1932 |
|
|
|
1933 |
|
|
|
1934 |
|
|
|
1935 |
|
|
Polling Support
|
1936 |
|
|
|
1937 |
|
|
typedef struct usbs_control_endpoint {
|
1938 |
|
|
void (*poll_fn)(struct usbs_control_endpoint*);
|
1939 |
|
|
int interrupt_vector;
|
1940 |
|
|
…
|
1941 |
|
|
} usbs_control_endpoint;
|
1942 |
|
|
|
1943 |
|
|
|
1944 |
|
|
In nearly all circumstances USB I/O should be interrupt-driven.
|
1945 |
|
|
However, there are special environments such as RedBoot where polled
|
1946 |
|
|
operation may be appropriate. If the device driver can operate in
|
1947 |
|
|
polled mode then it will provide a suitable function via the
|
1948 |
|
|
poll_fn field, and higher-level code can
|
1949 |
|
|
invoke this regularly. This polling function will take care of all
|
1950 |
|
|
endpoints associated with the device, not just the control endpoint.
|
1951 |
|
|
If the USB hardware involves a single interrupt vector then this will
|
1952 |
|
|
be identified in the data structure as well.
|
1953 |
|
|
|
1954 |
|
|
|
1955 |
|
|
|
1956 |
|
|
Dynamic Data Endpoint Support
|
1957 |
|
|
|
1958 |
|
|
typedef struct usbs_control_endpoint {
|
1959 |
|
|
struct usbs_rx_endpoint* (*get_rxep_fn)(struct usbs_control_endpoint*, cyg_uint8);
|
1960 |
|
|
struct usbs_tx_endpoint* (*get_txep_fn)(struct usbs_control_endpoint*, cyg_uint8);
|
1961 |
|
|
…
|
1962 |
|
|
} usbs_control_endpoint;
|
1963 |
|
|
|
1964 |
|
|
|
1965 |
|
|
USB slave hardware may support multiple USB configurations via
|
1966 |
|
|
configurable data endpoints. If the device driver can support such
|
1967 |
|
|
operation, it will provide a pair of functions via the
|
1968 |
|
|
get_rxep_fn and
|
1969 |
|
|
get_txep_fn fields which enable retrieval
|
1970 |
|
|
of the receive and transmit data endpoint structures using the logical
|
1971 |
|
|
endpoint IDs specified in a USB class descriptor. Access to these
|
1972 |
|
|
functions from higher-level code is provided by the
|
1973 |
|
|
usbs_get_rx_endpoint and
|
1974 |
|
|
usbs_get_tx_endpoint functions.
|
1975 |
|
|
|
1976 |
|
|
|
1977 |
|
|
|
1978 |
|
|
|
1979 |
|
|
|
1980 |
|
|
|
1981 |
|
|
|
1982 |
|
|
|
1983 |
|
|
|
1984 |
|
|
|
1985 |
|
|
|
1986 |
|
|
|
1987 |
|
|
Data Endpoints
|
1988 |
|
|
|
1989 |
|
|
|
1990 |
|
|
Data Endpoints
|
1991 |
|
|
Data endpoint data structures
|
1992 |
|
|
|
1993 |
|
|
|
1994 |
|
|
|
1995 |
|
|
|
1996 |
|
|
#include <cyg/io/usb/usbs.h>
|
1997 |
|
|
|
1998 |
|
|
typedef struct usbs_rx_endpoint {
|
1999 |
|
|
void (*start_rx_fn)(struct usbs_rx_endpoint*);
|
2000 |
|
|
void (*set_halted_fn)(struct usbs_rx_endpoint*, cyg_bool);
|
2001 |
|
|
void (*complete_fn)(void*, int);
|
2002 |
|
|
void* complete_data;
|
2003 |
|
|
unsigned char* buffer;
|
2004 |
|
|
int buffer_size;
|
2005 |
|
|
cyg_bool halted;
|
2006 |
|
|
} usbs_rx_endpoint;
|
2007 |
|
|
|
2008 |
|
|
typedef struct usbs_tx_endpoint {
|
2009 |
|
|
void (*start_tx_fn)(struct usbs_tx_endpoint*);
|
2010 |
|
|
void (*set_halted_fn)(struct usbs_tx_endpoint*, cyg_bool);
|
2011 |
|
|
void (*complete_fn)(void*, int);
|
2012 |
|
|
void* complete_data;
|
2013 |
|
|
const unsigned char* buffer;
|
2014 |
|
|
int buffer_size;
|
2015 |
|
|
cyg_bool halted;
|
2016 |
|
|
} usbs_tx_endpoint;
|
2017 |
|
|
|
2018 |
|
|
|
2019 |
|
|
|
2020 |
|
|
Receive and Transmit Data Structures
|
2021 |
|
|
|
2022 |
|
|
In addition to a single usbs_control_endpoint
|
2023 |
|
|
data structure per USB slave device, the USB device driver should also
|
2024 |
|
|
provide receive and transmit data structures corresponding to the
|
2025 |
|
|
other endpoints. The names of these are determined by the device
|
2026 |
|
|
driver. For example, the SA1110 USB device driver package provides
|
2027 |
|
|
usbs_sa11x0_ep1 for receives and
|
2028 |
|
|
usbs_sa11x0_ep2 for transmits.
|
2029 |
|
|
|
2030 |
|
|
|
2031 |
|
|
Unlike control endpoints, the common USB slave package does provide a
|
2032 |
|
|
number of utility routines to manipulate data endpoints. For example
|
2033 |
|
|
|
2034 |
|
|
linkend="usbs-start-rx">usbs_start_rx_buffer
|
2035 |
|
|
can be used to receive data from the host into a buffer. In addition
|
2036 |
|
|
the USB device driver can provide devtab entries such as
|
2037 |
|
|
/dev/usbs1r and /dev/usbs2w, so
|
2038 |
|
|
higher-level code can open these devices and then
|
2039 |
|
|
perform blocking read and
|
2040 |
|
|
write operations.
|
2041 |
|
|
|
2042 |
|
|
|
2043 |
|
|
However, the operation of data endpoints and the various
|
2044 |
|
|
endpoint-related functions is relatively straightforward. First
|
2045 |
|
|
consider a usbs_rx_endpoint structure. The
|
2046 |
|
|
device driver will provide the members
|
2047 |
|
|
start_rx_fn and
|
2048 |
|
|
set_halted_fn, and it will maintain the
|
2049 |
|
|
halted field. To receive data, higher-level
|
2050 |
|
|
code sets the buffer,
|
2051 |
|
|
buffer_size,
|
2052 |
|
|
complete_fn and optionally the
|
2053 |
|
|
complete_data fields. Next the
|
2054 |
|
|
start_rx_fn member should be called. When
|
2055 |
|
|
the transfer has finished the device driver will invoke the completion
|
2056 |
|
|
function, using complete_data as the first
|
2057 |
|
|
argument and a size field for the second argument. A negative size
|
2058 |
|
|
indicates an error of some sort: -EGAIN indicates
|
2059 |
|
|
that the endpoint has been halted, usually at the request of the host;
|
2060 |
|
|
-EPIPE indicates that the connection between the
|
2061 |
|
|
host and the peripheral has been broken. Certain device drivers may
|
2062 |
|
|
generate other error codes.
|
2063 |
|
|
|
2064 |
|
|
|
2065 |
|
|
If higher-level code needs to halt or unhalt an endpoint then it can
|
2066 |
|
|
invoke the set_halted_fn member. When an
|
2067 |
|
|
endpoint is halted, invoking start_rx_fn
|
2068 |
|
|
wit buffer_size set to 0 indicates that
|
2069 |
|
|
higher-level code wants to block until the endpoint is no longer
|
2070 |
|
|
halted; at that point the completion function will be invoked.
|
2071 |
|
|
|
2072 |
|
|
|
2073 |
|
|
USB device drivers are allowed to assume that higher-level protocols
|
2074 |
|
|
ensure that host and peripheral agree on the amount of data that will
|
2075 |
|
|
be transferred, or at least on an upper bound. Therefore there is no
|
2076 |
|
|
need for the device driver to maintain its own buffers, and copy
|
2077 |
|
|
operations are avoided. If the host sends more data than expected then
|
2078 |
|
|
the resulting behaviour is undefined.
|
2079 |
|
|
|
2080 |
|
|
|
2081 |
|
|
Transmit endpoints work in essentially the same way as receive
|
2082 |
|
|
endpoints. Higher-level code should set the
|
2083 |
|
|
buffer and
|
2084 |
|
|
buffer_size fields to point at the data to
|
2085 |
|
|
be transferred, then call start_tx_fn, and
|
2086 |
|
|
the device driver will invoked the completion function when the
|
2087 |
|
|
transfer has completed.
|
2088 |
|
|
|
2089 |
|
|
|
2090 |
|
|
USB device drivers are not expected to perform any locking. If at any
|
2091 |
|
|
time there are two concurrent receive operations for a given endpoint,
|
2092 |
|
|
or two concurrent transmit operations, then the resulting behaviour is
|
2093 |
|
|
undefined. It is the responsibility of higher-level code to perform
|
2094 |
|
|
any synchronisation that may be necessary. In practice, conflicts are
|
2095 |
|
|
unlikely because typically a given endpoint will only be accessed
|
2096 |
|
|
sequentially by just one part of the overall system.
|
2097 |
|
|
|
2098 |
|
|
|
2099 |
|
|
|
2100 |
|
|
|
2101 |
|
|
|
2102 |
|
|
|
2103 |
|
|
|
2104 |
|
|
|
2105 |
|
|
|
2106 |
|
|
|
2107 |
|
|
|
2108 |
|
|
Writing a USB Device Driver
|
2109 |
|
|
|
2110 |
|
|
|
2111 |
|
|
Writing a USB Device Driver
|
2112 |
|
|
USB Device Driver Porting Guide
|
2113 |
|
|
|
2114 |
|
|
|
2115 |
|
|
Introduction
|
2116 |
|
|
|
2117 |
|
|
Often the best way to write a USB device driver will be to start with
|
2118 |
|
|
an existing one and modify it as necessary. The information given here
|
2119 |
|
|
is intended primarily as an outline rather than as a complete guide.
|
2120 |
|
|
|
2121 |
|
|
|
2122 |
|
|
|
2123 |
|
|
At the time of writing only one USB device driver has been
|
2124 |
|
|
implemented. Hence it is possible, perhaps probable, that some
|
2125 |
|
|
portability issues have not yet been addressed. One issue
|
2126 |
|
|
involves the different types of transfer, for example the initial
|
2127 |
|
|
target hardware had no support for isochronous or interrupt transfers,
|
2128 |
|
|
so additional functionality may be needed to switch between transfer
|
2129 |
|
|
types. Another issue would be hardware where a given endpoint number,
|
2130 |
|
|
say endpoint 1, could be used for either receiving or transmitting
|
2131 |
|
|
data, but not both because a single fifo is used. Issues like these
|
2132 |
|
|
will have to be resolved as and when additional USB device drivers are
|
2133 |
|
|
written.
|
2134 |
|
|
|
2135 |
|
|
|
2136 |
|
|
|
2137 |
|
|
|
2138 |
|
|
The Control Endpoint
|
2139 |
|
|
|
2140 |
|
|
A USB device driver should provide a single
|
2141 |
|
|
linkend="usbs-control">usbs_control_endpoint
|
2142 |
|
|
data structure for every USB device. Typical peripherals will have
|
2143 |
|
|
only one USB port so there will be just one such data structure in the
|
2144 |
|
|
entire system, but theoretically it is possible to have multiple USB
|
2145 |
|
|
devices. These may all involve the same chip, in which case a single
|
2146 |
|
|
device driver should support multiple device instances, or they may
|
2147 |
|
|
involve different chips. The name or names of these data structures
|
2148 |
|
|
are determined by the device driver, but appropriate care should be
|
2149 |
|
|
taken to avoid name clashes.
|
2150 |
|
|
|
2151 |
|
|
|
2152 |
|
|
A USB device cannot be used unless the control endpoint data structure
|
2153 |
|
|
exists. However, the presence of USB hardware in the target processor
|
2154 |
|
|
or board does not guarantee that the application will necessarily want
|
2155 |
|
|
to use that hardware. To avoid unwanted code or data overheads, the
|
2156 |
|
|
device driver can provide a configuration option to determine whether
|
2157 |
|
|
or not the endpoint 0 data structure is actually provided. A default
|
2158 |
|
|
value of CYGINT_IO_USB_SLAVE_CLIENTS ensures that
|
2159 |
|
|
the USB driver will be enabled automatically if higher-level code does
|
2160 |
|
|
require USB support, while leaving ultimate control to the user.
|
2161 |
|
|
|
2162 |
|
|
|
2163 |
|
|
The USB device driver is responsible for filling in the
|
2164 |
|
|
start_fn,
|
2165 |
|
|
poll_fn and
|
2166 |
|
|
interrupt_vector fields. Usually this can
|
2167 |
|
|
be achieved by static initialization. The driver is also largely
|
2168 |
|
|
responsible for maintaining the state
|
2169 |
|
|
field. The control_buffer array should be
|
2170 |
|
|
used to hold the first packet of a control message. The
|
2171 |
|
|
buffer and other fields related to data
|
2172 |
|
|
transfers will be managed
|
2173 |
|
|
linkend="usbs-control-buffer">jointly by higher-level code and
|
2174 |
|
|
the device driver. The remaining fields are generally filled in by
|
2175 |
|
|
higher-level code, although the driver should initialize them to NULL
|
2176 |
|
|
values.
|
2177 |
|
|
|
2178 |
|
|
|
2179 |
|
|
Hardware permitting, the USB device should be inactive until the
|
2180 |
|
|
start_fn is invoked, for example by
|
2181 |
|
|
tristating the appropriate pins. This prevents the host from
|
2182 |
|
|
interacting with the peripheral before all other parts of the system
|
2183 |
|
|
have initialized. It is expected that the
|
2184 |
|
|
start_fn will only be invoked once, shortly
|
2185 |
|
|
after power-up.
|
2186 |
|
|
|
2187 |
|
|
|
2188 |
|
|
Where possible the device driver should detect state changes, such as
|
2189 |
|
|
when the connection between host and peripheral is established, and
|
2190 |
|
|
report these to higher-level
|
2191 |
|
|
code via the state_change_fn callback, if
|
2192 |
|
|
any. The state change to and from configured state cannot easily be
|
2193 |
|
|
handled by the device driver itself, instead higher-level code such as
|
2194 |
|
|
the common USB slave package will take care of this.
|
2195 |
|
|
|
2196 |
|
|
|
2197 |
|
|
Once the connection between host and peripheral has been established,
|
2198 |
|
|
the peripheral must be ready to accept control messages at all times,
|
2199 |
|
|
and must respond to these within certain time constraints. For
|
2200 |
|
|
example, the standard set-address control message must be handled
|
2201 |
|
|
within 50ms. The USB specification provides more information on these
|
2202 |
|
|
constraints. The device driver is responsible for receiving the
|
2203 |
|
|
initial packet of a control message. This packet will always be eight
|
2204 |
|
|
bytes and should be stored in the
|
2205 |
|
|
control_buffer field. Certain standard
|
2206 |
|
|
control messages should be detected and handled by the device driver
|
2207 |
|
|
itself. The most important is set-address, but usually the get-status,
|
2208 |
|
|
set-feature and clear-feature requests when applied to halted
|
2209 |
|
|
endpoints should also be handled by the driver. Other standard control
|
2210 |
|
|
messages should first be passed on to the
|
2211 |
|
|
standard_control_fn callback (if any), and
|
2212 |
|
|
finally to the default handler
|
2213 |
|
|
usbs_handle_standard_control provided by the
|
2214 |
|
|
common USB slave package. Class, vendor and reserved control messages
|
2215 |
|
|
should always be dispatched to the appropriate callback and there is
|
2216 |
|
|
no default handler for these.
|
2217 |
|
|
|
2218 |
|
|
|
2219 |
|
|
Some control messages will involve further data transfer, not just the
|
2220 |
|
|
initial packet. The device driver must handle this in accordance with
|
2221 |
|
|
the USB specification and the
|
2222 |
|
|
linkend="usbs-control-buffer">buffer management strategy. The
|
2223 |
|
|
driver is also responsible for keeping track of whether or not the
|
2224 |
|
|
control operation has succeeded and generating an ACK or STALL
|
2225 |
|
|
handshake.
|
2226 |
|
|
|
2227 |
|
|
|
2228 |
|
|
The polling support is optional and may not be feasible on all
|
2229 |
|
|
hardware. It is only used in certain specialised environments such as
|
2230 |
|
|
RedBoot. A typical implementation of the polling function would just
|
2231 |
|
|
check whether or not an interrupt would have occurred and, if so, call
|
2232 |
|
|
the same code that the interrupt handler would.
|
2233 |
|
|
|
2234 |
|
|
|
2235 |
|
|
|
2236 |
|
|
Data Endpoints
|
2237 |
|
|
|
2238 |
|
|
In addition to the control endpoint data structure, a USB device
|
2239 |
|
|
driver should also provide appropriate data
|
2240 |
|
|
endpoint data structures. Obviously this is only relevant if
|
2241 |
|
|
the USB support generally is desired, that is if the control endpoint is
|
2242 |
|
|
provided. In addition, higher-level code may not require all the
|
2243 |
|
|
endpoints, so it may be useful to provide configuration options that
|
2244 |
|
|
control the presence of each endpoint. For example, the intended
|
2245 |
|
|
application might only involve a single transmit endpoint and of
|
2246 |
|
|
course control messages, so supporting receive endpoints might waste
|
2247 |
|
|
memory.
|
2248 |
|
|
|
2249 |
|
|
|
2250 |
|
|
Conceptually, data endpoints are much simpler than the control
|
2251 |
|
|
endpoint. The device driver has to supply two functions, one for
|
2252 |
|
|
data transfers and another to control the halted condition. These
|
2253 |
|
|
implement the functionality for
|
2254 |
|
|
usbs_start_rx_buffer,
|
2255 |
|
|
usbs_start_tx_buffer,
|
2256 |
|
|
usbs_set_rx_endpoint_halted and
|
2257 |
|
|
usbs_set_tx_endpoint_halted.
|
2258 |
|
|
The device driver is also responsible for maintaining the
|
2259 |
|
|
halted status.
|
2260 |
|
|
|
2261 |
|
|
|
2262 |
|
|
For data transfers, higher-level code will have filled in the
|
2263 |
|
|
buffer,
|
2264 |
|
|
buffer_size,
|
2265 |
|
|
complete_fn and
|
2266 |
|
|
complete_data fields. The transfer function
|
2267 |
|
|
should arrange for the transfer to start, allowing the host to send or
|
2268 |
|
|
receive packets. Typically this will result in an interrupt at the end
|
2269 |
|
|
of the transfer or after each packet. Once the entire transfer has
|
2270 |
|
|
been completed, the driver's interrupt handling code should invoke the
|
2271 |
|
|
completion function. This can happen either in DSR context or thread
|
2272 |
|
|
context, depending on the driver's implementation. There are a number
|
2273 |
|
|
of special cases to consider. If the endpoint is halted when the
|
2274 |
|
|
transfer is started then the completion function can be invoked
|
2275 |
|
|
immediately with -EAGAIN. If the transfer cannot be
|
2276 |
|
|
completed because the connection is broken then the completion
|
2277 |
|
|
function should be invoked with -EPIPE. If the
|
2278 |
|
|
endpoint is stalled during the transfer, either because of a standard
|
2279 |
|
|
control message or because higher-level code calls the appropriate
|
2280 |
|
|
set_halted_fn, then again the completion
|
2281 |
|
|
function should be invoked with -EAGAIN. Finally,
|
2282 |
|
|
the <usbs_start_rx_endpoint_wait and
|
2283 |
|
|
usbs_start_tx_endpoint_wait functions involve
|
2284 |
|
|
calling the device driver's data transfer function with a buffer size
|
2285 |
|
|
of 0 bytes.
|
2286 |
|
|
|
2287 |
|
|
|
2288 |
|
|
Giving a buffer size of 0 bytes a special meaning is problematical
|
2289 |
|
|
because it prevents transfers of that size. Such transfers are allowed
|
2290 |
|
|
by the USB protocol, consisting of just headers and acknowledgements
|
2291 |
|
|
and an empty data phase, although rarely useful. A future modification
|
2292 |
|
|
of the device driver specification will address this issue, although
|
2293 |
|
|
care has to be taken that the functionality remains accessible through
|
2294 |
|
|
devtab entries as well as via low-level accesses.
|
2295 |
|
|
|
2296 |
|
|
|
2297 |
|
|
|
2298 |
|
|
Devtab Entries
|
2299 |
|
|
|
2300 |
|
|
For some applications or higher-level packages it may be more
|
2301 |
|
|
convenient to use traditional open/read/write I/O calls rather than
|
2302 |
|
|
the non-blocking USB I/O calls. To support this the device driver can
|
2303 |
|
|
provide a devtab entry for each endpoint, for example:
|
2304 |
|
|
|
2305 |
|
|
|
2306 |
|
|
#ifdef CYGVAR_DEVS_USB_SA11X0_EP1_DEVTAB_ENTRY
|
2307 |
|
|
|
2308 |
|
|
static CHAR_DEVIO_TABLE(usbs_sa11x0_ep1_devtab_functions,
|
2309 |
|
|
&cyg_devio_cwrite,
|
2310 |
|
|
&usbs_devtab_cread,
|
2311 |
|
|
&cyg_devio_bwrite,
|
2312 |
|
|
&cyg_devio_bread,
|
2313 |
|
|
&cyg_devio_select,
|
2314 |
|
|
&cyg_devio_get_config,
|
2315 |
|
|
&cyg_devio_set_config);
|
2316 |
|
|
|
2317 |
|
|
static CHAR_DEVTAB_ENTRY(usbs_sa11x0_ep1_devtab_entry,
|
2318 |
|
|
CYGDAT_DEVS_USB_SA11X0_DEVTAB_BASENAME "1r",
|
2319 |
|
|
0,
|
2320 |
|
|
&usbs_sa11x0_ep1_devtab_functions,
|
2321 |
|
|
&usbs_sa11x0_devtab_dummy_init,
|
2322 |
|
|
0,
|
2323 |
|
|
(void*) &usbs_sa11x0_ep1);
|
2324 |
|
|
#endif
|
2325 |
|
|
|
2326 |
|
|
|
2327 |
|
|
Again care must be taken to avoid name clashes. This can be achieved
|
2328 |
|
|
by having a configuration option to control the base name, with a
|
2329 |
|
|
default value of e.g. /dev/usbs, and appending an
|
2330 |
|
|
endpoint-specific string. This gives the application developer
|
2331 |
|
|
sufficient control to eliminate any name clashes. The common USB slave
|
2332 |
|
|
package provides functions usbs_devtab_cwrite and
|
2333 |
|
|
usbs_devtab_cread, which can be used in the
|
2334 |
|
|
function tables for transmit and receive endpoints respectively. The
|
2335 |
|
|
private field priv of the devtab entry
|
2336 |
|
|
should be a pointer to the underlying endpoint data structure.
|
2337 |
|
|
|
2338 |
|
|
|
2339 |
|
|
Because devtab entries are never accessed directly, only indirectly,
|
2340 |
|
|
they would usually be eliminated by the linker. To avoid this the
|
2341 |
|
|
devtab entries should normally be defined in a separate source file
|
2342 |
|
|
which ends up the special library libextras.a
|
2343 |
|
|
rather than in the default library libtarget.a.
|
2344 |
|
|
|
2345 |
|
|
|
2346 |
|
|
Not all applications or higher-level packages will want to use the
|
2347 |
|
|
devtab entries and the blocking I/O facilities. It may be appropriate
|
2348 |
|
|
for the device driver to provide additional configuration options that
|
2349 |
|
|
control whether or not any or all of the devtab entries should be
|
2350 |
|
|
provided, to avoid unnecessary memory overheads.
|
2351 |
|
|
|
2352 |
|
|
|
2353 |
|
|
|
2354 |
|
|
Interrupt Handling
|
2355 |
|
|
|
2356 |
|
|
A typical USB device driver will need to service interrupts for all of
|
2357 |
|
|
the endpoints and possibly for additional USB events such as entering
|
2358 |
|
|
or leaving suspended mode. Usually these interrupts need not be
|
2359 |
|
|
serviced directly by the ISR. Instead, they can be left to a DSR. If
|
2360 |
|
|
the peripheral is not able to accept or send another packet just yet,
|
2361 |
|
|
the hardware will generate a NAK and the host will just retry a little
|
2362 |
|
|
bit later. If high throughput is required then it may be desirable to
|
2363 |
|
|
handle the bulk transfer protocol largely at ISR level, that is take
|
2364 |
|
|
care of each packet in the ISR and only activate the DSR once the
|
2365 |
|
|
whole transfer has completed.
|
2366 |
|
|
|
2367 |
|
|
|
2368 |
|
|
Control messages may involve invoking arbitrary callback functions in
|
2369 |
|
|
higher-level code. This should normally happen at DSR level. Doing it
|
2370 |
|
|
at ISR level could seriously affect the system's interrupt latency and
|
2371 |
|
|
impose unacceptable constraints on what operations can be performed by
|
2372 |
|
|
those callbacks. If the device driver requires a thread anyway then it
|
2373 |
|
|
may be appropriate to use this thread for invoking the callbacks, but
|
2374 |
|
|
usually it is not worthwhile to add a new thread to the system just
|
2375 |
|
|
for this; higher-level code is expected to write callbacks that
|
2376 |
|
|
function sensibly at DSR level. Much the same applies to the
|
2377 |
|
|
completion functions associated with data transfers. These should also
|
2378 |
|
|
be invoked at DSR or thread level.
|
2379 |
|
|
|
2380 |
|
|
|
2381 |
|
|
|
2382 |
|
|
Support for USB Testing
|
2383 |
|
|
|
2384 |
|
|
Optionally a USB device driver can provide support for the
|
2385 |
|
|
USB test software. This requires
|
2386 |
|
|
defining a number of additional data structures, allowing the
|
2387 |
|
|
generic test code to work out just what the hardware is capable of and
|
2388 |
|
|
hence what testing can be performed.
|
2389 |
|
|
|
2390 |
|
|
|
2391 |
|
|
The key data structure is
|
2392 |
|
|
usbs_testing_endpoint, defined in
|
2393 |
|
|
class="headerfile">cyg/io/usb/usbs.h. In addition some
|
2394 |
|
|
commonly required constants are provided by the common USB package in
|
2395 |
|
|
. One
|
2396 |
|
|
usbs_testing_endpoint structure should be
|
2397 |
|
|
defined for each supported endpoint. The following fields need to be
|
2398 |
|
|
filled in:
|
2399 |
|
|
|
2400 |
|
|
|
2401 |
|
|
|
2402 |
|
|
endpoint_type
|
2403 |
|
|
|
2404 |
|
|
This specifies the type of endpoint and should be one of
|
2405 |
|
|
USB_ENDPOINT_DESCRIPTOR_ATTR_CONTROL,
|
2406 |
|
|
BULK, ISOCHRONOUS or
|
2407 |
|
|
INTERRUPT.
|
2408 |
|
|
|
2409 |
|
|
|
2410 |
|
|
|
2411 |
|
|
endpoint_number
|
2412 |
|
|
|
2413 |
|
|
This identifies the number that should be used by the host
|
2414 |
|
|
to address this endpoint. For a control endpoint it should
|
2415 |
|
|
be 0. For other types of endpoints it should be between
|
2416 |
|
|
1 and 15.
|
2417 |
|
|
|
2418 |
|
|
|
2419 |
|
|
|
2420 |
|
|
endpoint_direction
|
2421 |
|
|
|
2422 |
|
|
For control endpoints this field is irrelevant. For other
|
2423 |
|
|
types of endpoint it should be either
|
2424 |
|
|
USB_ENDPOINT_DESCRIPTOR_ENDPOINT_IN or
|
2425 |
|
|
USB_ENDPOINT_DESCRIPTOR_ENDPOINT_OUT. If a given
|
2426 |
|
|
endpoint number can be used for traffic in both directions then
|
2427 |
|
|
there should be two entries in the array, one for each direction.
|
2428 |
|
|
|
2429 |
|
|
|
2430 |
|
|
|
2431 |
|
|
endpoint
|
2432 |
|
|
|
2433 |
|
|
This should be a pointer to the appropriate
|
2434 |
|
|
usbs_control_endpoint,
|
2435 |
|
|
usbs_rx_endpoint or
|
2436 |
|
|
usbs_tx_endpoint structure, allowing the
|
2437 |
|
|
generic testing code to perform low-level I/O.
|
2438 |
|
|
|
2439 |
|
|
|
2440 |
|
|
|
2441 |
|
|
devtab_entry
|
2442 |
|
|
|
2443 |
|
|
If the endpoint also has an entry in the system's device table then
|
2444 |
|
|
this field should give the corresponding string, for example
|
2445 |
|
|
"/dev/usbs1r". This allows the
|
2446 |
|
|
generic testing code to access the device via higher-level
|
2447 |
|
|
calls like open and read.
|
2448 |
|
|
|
2449 |
|
|
|
2450 |
|
|
|
2451 |
|
|
min_size
|
2452 |
|
|
|
2453 |
|
|
This indicates the smallest transfer size that the hardware can
|
2454 |
|
|
support on this endpoint. Typically this will be one.
|
2455 |
|
|
|
2456 |
|
|
|
2457 |
|
|
Strictly speaking a minimum size of one is not quite right since it
|
2458 |
|
|
is valid for a USB transfer to involve zero bytes, in other words a
|
2459 |
|
|
transfer that involves just headers and acknowledgements and an
|
2460 |
|
|
empty data phase, and that should be tested as well. However current
|
2461 |
|
|
device drivers interpret a transfer size of 0 as special, so that
|
2462 |
|
|
would have to be resolved first.
|
2463 |
|
|
|
2464 |
|
|
|
2465 |
|
|
|
2466 |
|
|
|
2467 |
|
|
max_size
|
2468 |
|
|
|
2469 |
|
|
Similarly, this specifies the largest transfer size. For control
|
2470 |
|
|
endpoints the USB protocol uses only two bytes to hold the transfer
|
2471 |
|
|
length, so there is an upper bound of 65535 bytes. In practice
|
2472 |
|
|
it is very unlikely that any control transfers would ever need to
|
2473 |
|
|
be this large, and in fact such transfers would take a long time
|
2474 |
|
|
and probably violate timing constraints. For other types of endpoint
|
2475 |
|
|
any of the protocol, the hardware, or the device driver may impose
|
2476 |
|
|
size limits. For example a given device driver might be unable to
|
2477 |
|
|
cope with transfers larger than 65535 bytes. If it should be
|
2478 |
|
|
possible to transfer arbitrary amounts of data then a value of
|
2479 |
|
|
-1 indicates no upper limit, and transfer
|
2480 |
|
|
sizes will be limited by available memory and by the capabilities
|
2481 |
|
|
of the host machine.
|
2482 |
|
|
|
2483 |
|
|
|
2484 |
|
|
|
2485 |
|
|
max_in_padding
|
2486 |
|
|
|
2487 |
|
|
This field is needed on some hardware where it is impossible to
|
2488 |
|
|
send packets of a certain size. For example the hardware may be
|
2489 |
|
|
incapable of sending an empty bulk packet to terminate a transfer
|
2490 |
|
|
that is an exact multiple of the 64-byte bulk packet size.
|
2491 |
|
|
Instead the driver has to do some padding and send an extra byte,
|
2492 |
|
|
and the host has to be prepared to receive this extra byte. Such a
|
2493 |
|
|
driver should specify a value of 1 for the
|
2494 |
|
|
padding field. For most drivers this field should be set to
|
2495 |
|
|
0.
|
2496 |
|
|
|
2497 |
|
|
|
2498 |
|
|
A better solution would be for the device driver to supply a
|
2499 |
|
|
fragment of Tcl code that would adjust the receive buffer size
|
2500 |
|
|
only when necessary, rather than for every transfer. Forcing
|
2501 |
|
|
receive padding on all transfers when only certain transfers
|
2502 |
|
|
will actually be padded reduces the accuracy of certain tests.
|
2503 |
|
|
|
2504 |
|
|
|
2505 |
|
|
|
2506 |
|
|
alignment
|
2507 |
|
|
|
2508 |
|
|
On some hardware data transfers may need to be aligned to certain
|
2509 |
|
|
boundaries, for example a word boundary or a cacheline boundary.
|
2510 |
|
|
Although in theory device drivers could hide such alignment
|
2511 |
|
|
restrictions from higher-level code by having their own buffers and
|
2512 |
|
|
performing appropriate copying, that would be expensive in terms of
|
2513 |
|
|
both memory and cpu cycles. Instead the generic testing code will
|
2514 |
|
|
align any buffers passed to the device driver to the specified
|
2515 |
|
|
boundary. For example, if the driver requires that buffers be
|
2516 |
|
|
aligned to a word boundary then it should specify an alignment
|
2517 |
|
|
value of 4.
|
2518 |
|
|
|
2519 |
|
|
|
2520 |
|
|
|
2521 |
|
|
|
2522 |
|
|
|
2523 |
|
|
The device driver should provide an array of these structures
|
2524 |
|
|
usbs_testing_endpoints[]. The USB testing code
|
2525 |
|
|
examines this array and uses the information to perform appropriate
|
2526 |
|
|
tests. Because different USB devices support different numbers of
|
2527 |
|
|
endpoints the number of entries in the array is not known in advance,
|
2528 |
|
|
so instead the testing code looks for a special terminator
|
2529 |
|
|
USBS_TESTING_ENDPOINTS_TERMINATOR. An example
|
2530 |
|
|
array, showing just the control endpoint and the terminator, might
|
2531 |
|
|
look like this:
|
2532 |
|
|
|
2533 |
|
|
|
2534 |
|
|
usbs_testing_endpoint usbs_testing_endpoints[] = {
|
2535 |
|
|
{
|
2536 |
|
|
endpoint_type : USB_ENDPOINT_DESCRIPTOR_ATTR_CONTROL,
|
2537 |
|
|
endpoint_number : 0,
|
2538 |
|
|
endpoint_direction : USB_ENDPOINT_DESCRIPTOR_ENDPOINT_IN,
|
2539 |
|
|
endpoint : (void*) &ep0.common,
|
2540 |
|
|
devtab_entry : (const char*) 0,
|
2541 |
|
|
min_size : 1,
|
2542 |
|
|
max_size : 0x0FFFF,
|
2543 |
|
|
max_in_padding : 0,
|
2544 |
|
|
alignment : 0
|
2545 |
|
|
},
|
2546 |
|
|
…,
|
2547 |
|
|
USBS_TESTING_ENDPOINTS_TERMINATOR
|
2548 |
|
|
};
|
2549 |
|
|
|
2550 |
|
|
|
2551 |
|
|
|
2552 |
|
|
|
2553 |
|
|
The use of a single array usbs_testing_endpoints
|
2554 |
|
|
limits USB testing to platforms with a single USB device: if there
|
2555 |
|
|
were multiple devices, each defining their own instance of this array,
|
2556 |
|
|
then there would a collision at link time. In practice this should not
|
2557 |
|
|
be a major problem since typical USB peripherals only interact with a
|
2558 |
|
|
single host machine via a single slave port. In addition, even if a
|
2559 |
|
|
peripheral did have multiple slave ports the current USB testing code
|
2560 |
|
|
would not support this since it would not know which port to use.
|
2561 |
|
|
|
2562 |
|
|
|
2563 |
|
|
|
2564 |
|
|
|
2565 |
|
|
|
2566 |
|
|
|
2567 |
|
|
|
2568 |
|
|
|
2569 |
|
|
|
2570 |
|
|
|
2571 |
|
|
|
2572 |
|
|
|
2573 |
|
|
Testing
|
2574 |
|
|
|
2575 |
|
|
|
2576 |
|
|
Testing
|
2577 |
|
|
Testing of USB Device Drivers
|
2578 |
|
|
|
2579 |
|
|
|
2580 |
|
|
Introduction
|
2581 |
|
|
|
2582 |
|
|
The support for USB testing provided by the eCos USB common slave
|
2583 |
|
|
package is somewhat different in nature from the kind of testing used
|
2584 |
|
|
in many other packages. One obvious problem is that USB tests cannot
|
2585 |
|
|
be run on just a bare target platform: instead the target platform
|
2586 |
|
|
must be connected to a suitable USB host machine, and that host
|
2587 |
|
|
machine must be running appropriate software for the test code to
|
2588 |
|
|
interact with. This is very different from say a kernel test which
|
2589 |
|
|
typically will have no external dependencies. Another important
|
2590 |
|
|
difference between USB testing and say a C library
|
2591 |
|
|
strcmp test is sensitivity to timing and to
|
2592 |
|
|
hardware boundary conditions: although a simple test case that just
|
2593 |
|
|
performs a small number of USB transfers is better than no testing at
|
2594 |
|
|
all, it should also be possible to run tests for hours or days on end,
|
2595 |
|
|
under a variety of loads. In order to provide the required
|
2596 |
|
|
functionality the basic architecture of the USB testing support is as
|
2597 |
|
|
follows:
|
2598 |
|
|
|
2599 |
|
|
|
2600 |
|
|
|
2601 |
|
|
There is a single target-side program
|
2602 |
|
|
usbtarget. By default when this is run
|
2603 |
|
|
on a target platform it will appear to do nothing. In fact it is
|
2604 |
|
|
waiting to be contacted by another program
|
2605 |
|
|
usbhost which will tell it what test or
|
2606 |
|
|
tests to run. usbtarget provides
|
2607 |
|
|
mechanisms for running a wide range of tests.
|
2608 |
|
|
|
2609 |
|
|
|
2610 |
|
|
usbtarget is a generic program, but USB
|
2611 |
|
|
testing depends to some extent on the functionality provided by the
|
2612 |
|
|
hardware. For example there is no point in testing bulk transmits
|
2613 |
|
|
to endpoint 12 if the target hardware does not support an endpoint
|
2614 |
|
|
12. Therefore each USB device driver should supply information about
|
2615 |
|
|
what the hardware is actually capable of, in the form of an array of
|
2616 |
|
|
usbs_testing_endpoint data structures.
|
2617 |
|
|
|
2618 |
|
|
|
2619 |
|
|
There is a single host-side program
|
2620 |
|
|
usbhost, which acts as a counterpart to
|
2621 |
|
|
usbtarget. Again
|
2622 |
|
|
usbhost has no built-in knowledge of
|
2623 |
|
|
the test or tests that are supposed to run, it only provides
|
2624 |
|
|
mechanisms for running a wide range of tests. On start-up
|
2625 |
|
|
usbhost will search the USB bus for
|
2626 |
|
|
hardware running the target-side program, specifically a USB device
|
2627 |
|
|
that identifies itself as the product "Red Hat eCos
|
2628 |
|
|
USB test".
|
2629 |
|
|
|
2630 |
|
|
|
2631 |
|
|
usbhost contains a Tcl interpreter, and
|
2632 |
|
|
will execute any Tcl scripts specified on the command line
|
2633 |
|
|
together with appropriate arguments. The Tcl interpreter has been
|
2634 |
|
|
extended with various commands such as
|
2635 |
|
|
usbtest::bulktest, so the script can perform
|
2636 |
|
|
the desired test or tests.
|
2637 |
|
|
|
2638 |
|
|
|
2639 |
|
|
Adding a new test simply involves writing a short Tcl script that
|
2640 |
|
|
invokes the appropriate USB-specific commands. Running multiple
|
2641 |
|
|
tests involves passing appropriate arguments to
|
2642 |
|
|
usbhost, or alternatively writing a
|
2643 |
|
|
single script that just invokes other scripts.
|
2644 |
|
|
|
2645 |
|
|
|
2646 |
|
|
|
2647 |
|
|
The current implementation of usbhost
|
2648 |
|
|
depends heavily on functionality provided by the Linux kernel and in
|
2649 |
|
|
particular the usbdevfs support. It uses
|
2650 |
|
|
/proc/bus/usb/devices to find out what devices
|
2651 |
|
|
are attached to the bus, and will then access the device by opening
|
2652 |
|
|
/proc/bus/usb/xxx/yyy and performing
|
2653 |
|
|
ioctl operations. This allows USB testing to take
|
2654 |
|
|
place without having to write a new host-side device driver, but
|
2655 |
|
|
getting the code working on host machines not running Linux would
|
2656 |
|
|
obviously be problematical.
|
2657 |
|
|
|
2658 |
|
|
|
2659 |
|
|
|
2660 |
|
|
Building and Running the Target-side Code
|
2661 |
|
|
|
2662 |
|
|
The target-side component of the USB testing software consists of a
|
2663 |
|
|
single program usbtarget which contains
|
2664 |
|
|
support for a range of different tests, under the control of host-side
|
2665 |
|
|
software. This program is not built by default alongside other eCos
|
2666 |
|
|
test cases since it will only operate in certain environments,
|
2667 |
|
|
specifically when the target board's connector is plugged into a Linux
|
2668 |
|
|
host, and when the appropriate host-side software has been installed
|
2669 |
|
|
on that host. Instead the user must enable a configuration option
|
2670 |
|
|
CYGBLD_IO_USB_SLAVE_USBTEST to add the program to
|
2671 |
|
|
the list of tests for the current configuration.
|
2672 |
|
|
|
2673 |
|
|
|
2674 |
|
|
Starting the usbtarget program does not
|
2675 |
|
|
require anything unusual, so it can be run in a normal
|
2676 |
|
|
gdb session just like any eCos application.
|
2677 |
|
|
After initialization the program will wait for activity from the host.
|
2678 |
|
|
Depending on the hardware, the Linux host will detect that a new USB
|
2679 |
|
|
peripheral is present on the bus either when the
|
2680 |
|
|
usbtarget initialization is complete or
|
2681 |
|
|
when the cable between target and host is connected. The host will
|
2682 |
|
|
perform the normal USB enumeration sequence and discover that the
|
2683 |
|
|
peripheral does not match any known vendor or product id and that
|
2684 |
|
|
there is no device driver for "Red Hat eCos USB
|
2685 |
|
|
test", so it will ignore the peripheral. When the
|
2686 |
|
|
usbhost program is run on the host it will
|
2687 |
|
|
connect to the target-side software, and testing can now commence.
|
2688 |
|
|
|
2689 |
|
|
|
2690 |
|
|
|
2691 |
|
|
Building and Running the Host-side Code
|
2692 |
|
|
|
2693 |
|
|
In theory the host-side software should be built when the package is
|
2694 |
|
|
installed in the component repository, and removed when a package
|
2695 |
|
|
is uninstalled. The current eCos administration tool does not provide
|
2696 |
|
|
this functionality.
|
2697 |
|
|
|
2698 |
|
|
|
2699 |
|
|
The host-side software should be built via the usual sequence of
|
2700 |
|
|
"configure/make/make install". It can only be built on a
|
2701 |
|
|
Linux host and the configure script contains an
|
2702 |
|
|
explicit test for this. Because the eCos component repository should
|
2703 |
|
|
generally be treated as a read-only resource the configure script will
|
2704 |
|
|
also prevent you from trying to build inside the source tree. Instead
|
2705 |
|
|
a separate build tree is required. Hence a typical sequence for
|
2706 |
|
|
building the host-side software would be as follows:
|
2707 |
|
|
|
2708 |
|
|
|
2709 |
|
|
$ mkdir usbhost_build
|
2710 |
|
|
$ cd usbhost_build
|
2711 |
|
|
$ <repo>packages/io/usb/slave/current/host/configure <args>
|
2712 |
|
|
$ make
|
2713 |
|
|
<output from make>
|
2714 |
|
|
$ su
|
2715 |
|
|
$ make install
|
2716 |
|
|
<output from make install>
|
2717 |
|
|
$
|
2718 |
|
|
|
2719 |
|
|
|
2720 |
|
|
|
2721 |
|
|
|
2722 |
|
|
The location of the eCos component repository should be substituted
|
2723 |
|
|
for <repo>.
|
2724 |
|
|
|
2725 |
|
|
|
2726 |
|
|
|
2727 |
|
|
|
2728 |
|
|
If the package has been obtained via CVS or anonymous CVS then the
|
2729 |
|
|
package version will be current, as per the
|
2730 |
|
|
example. If instead the package has been obtained as part of a full
|
2731 |
|
|
eCos release or as a separate .epk file then the
|
2732 |
|
|
appropriate package version should be used instead of
|
2733 |
|
|
current.
|
2734 |
|
|
|
2735 |
|
|
|
2736 |
|
|
|
2737 |
|
|
|
2738 |
|
|
The configure script takes the usual arguments such
|
2739 |
|
|
as --prefix= to specify where the executables
|
2740 |
|
|
and support files should be installed. The only other parameter that
|
2741 |
|
|
some users may wish to specify is the location of a suitable Tcl
|
2742 |
|
|
installation. By default usbhost will use
|
2743 |
|
|
the existing Tcl installation in /usr,
|
2744 |
|
|
as provided by your Linux distribution. An alternative Tcl
|
2745 |
|
|
installation can be specified using the parameter
|
2746 |
|
|
--with-tcl=, or alternatively using some
|
2747 |
|
|
combination of --with-tcl-include,
|
2748 |
|
|
--with-tcl-lib and
|
2749 |
|
|
--with-tcl-version.
|
2750 |
|
|
|
2751 |
|
|
|
2752 |
|
|
|
2753 |
|
|
|
2754 |
|
|
One of the host-side executables that gets built,
|
2755 |
|
|
usbchmod, needs to be installed with suid
|
2756 |
|
|
root privileges. Although the Linux kernel makes it possible for
|
2757 |
|
|
applications to perform low-level USB operations such as transmitting
|
2758 |
|
|
bulk packets, by default access to this functionality is restricted to
|
2759 |
|
|
programs with superuser privileges. It is undesirable to run a complex
|
2760 |
|
|
program such as usbhost with such
|
2761 |
|
|
privileges, especially since the program contains a general-purpose
|
2762 |
|
|
Tcl interpreter. Therefore when usbhost
|
2763 |
|
|
starts up and discovers that it does not have sufficient access to the
|
2764 |
|
|
appropriate entries in /proc/bus/usb,
|
2765 |
|
|
it spawns an instance of usbchmod to modify
|
2766 |
|
|
the permissions on these entries. usbchmod
|
2767 |
|
|
will only do this for a USB device "Red Hat eCos USB
|
2768 |
|
|
test", so installing this program suid root should not
|
2769 |
|
|
introduce any security problems.
|
2770 |
|
|
|
2771 |
|
|
|
2772 |
|
|
|
2773 |
|
|
|
2774 |
|
|
|
2775 |
|
|
During make install the following actions will take
|
2776 |
|
|
place:
|
2777 |
|
|
|
2778 |
|
|
|
2779 |
|
|
|
2780 |
|
|
|
2781 |
|
|
usbhost will be installed in /usr/local/bin,
|
2782 |
|
|
or some other bin directory if
|
2783 |
|
|
the default location is changed at configure-time using a
|
2784 |
|
|
--prefix= or similar option. It will be
|
2785 |
|
|
installed as the executable
|
2786 |
|
|
usbhost_<version>, for example
|
2787 |
|
|
usbhost_current, thus allowing several
|
2788 |
|
|
releases of the USB slave package to co-exist. For convenience a
|
2789 |
|
|
symbolic link from usbhost to this executable
|
2790 |
|
|
will be created, so users can just run usbhost to
|
2791 |
|
|
access the most recently-installed version.
|
2792 |
|
|
|
2793 |
|
|
|
2794 |
|
|
|
2795 |
|
|
|
2796 |
|
|
usbchmod will be installed in
|
2797 |
|
|
/usr/local/libexec/ecos/io_usb_slave_<version>.
|
2798 |
|
|
This program should only be run by usbhost,
|
2799 |
|
|
not invoked directly, so it is not placed in the bin
|
2800 |
|
|
directory. Again the presence of the package version in the directory
|
2801 |
|
|
name allows multiple releases of the package to co-exist.
|
2802 |
|
|
|
2803 |
|
|
|
2804 |
|
|
|
2805 |
|
|
|
2806 |
|
|
A Tcl script usbhost.tcl will get installed in
|
2807 |
|
|
the same directory as usbchmod. This Tcl
|
2808 |
|
|
script is loaded automatically by the
|
2809 |
|
|
usbhost executable.
|
2810 |
|
|
|
2811 |
|
|
|
2812 |
|
|
|
2813 |
|
|
|
2814 |
|
|
A number of additional Tcl scripts, for example
|
2815 |
|
|
list.tcl will get installed alongside
|
2816 |
|
|
usbhost.tcl. These correspond to various test
|
2817 |
|
|
cases provided as standard. If a given test case is specified on the
|
2818 |
|
|
command line and cannot be found relative to the current directory
|
2819 |
|
|
then usbhost will search the install
|
2820 |
|
|
directory for these test cases.
|
2821 |
|
|
|
2822 |
|
|
|
2823 |
|
|
Strictly speaking installing the usbhost.tcl and
|
2824 |
|
|
other Tcl scripts below the libexec
|
2825 |
|
|
directory deviates from standard practice: they are
|
2826 |
|
|
architecture-independent data files so should be installed below
|
2827 |
|
|
the share subdirectory. In
|
2828 |
|
|
practice the files are sufficiently small that there is no point in
|
2829 |
|
|
sharing them, and keeping them below libexec
|
2830 |
|
|
simplifies the host-side software somewhat.
|
2831 |
|
|
|
2832 |
|
|
|
2833 |
|
|
|
2834 |
|
|
|
2835 |
|
|
|
2836 |
|
|
The usbhost should be run only when there is a
|
2837 |
|
|
suitable target attached to the USB bus and running the
|
2838 |
|
|
usbtarget program. It will search
|
2839 |
|
|
/proc/bus/usb/devices for an entry corresponding
|
2840 |
|
|
to this program, invoke usbchmod if
|
2841 |
|
|
necessary to change the access rights, and then interact with
|
2842 |
|
|
usbtarget over the USB bus.
|
2843 |
|
|
usbhost should be invoked as follows:
|
2844 |
|
|
|
2845 |
|
|
|
2846 |
|
|
$ usbhost [-v|--version] [-h|--help] [-V|--verbose] <test> [<test parameters>]
|
2847 |
|
|
|
2848 |
|
|
|
2849 |
|
|
|
2850 |
|
|
|
2851 |
|
|
The -v or --version
|
2852 |
|
|
option will display version information for
|
2853 |
|
|
usbhost including the version of the USB
|
2854 |
|
|
slave package that was used to build the executable.
|
2855 |
|
|
|
2856 |
|
|
|
2857 |
|
|
|
2858 |
|
|
|
2859 |
|
|
The -h or --help option
|
2860 |
|
|
will display usage information.
|
2861 |
|
|
|
2862 |
|
|
|
2863 |
|
|
|
2864 |
|
|
|
2865 |
|
|
The -V or --verbose
|
2866 |
|
|
option can be used to obtain more information at run-time, for example
|
2867 |
|
|
some output for every USB transfer. This option can be repeated
|
2868 |
|
|
multiple times to increase the amount of output.
|
2869 |
|
|
|
2870 |
|
|
|
2871 |
|
|
|
2872 |
|
|
|
2873 |
|
|
The first argument that does not begin with a hyphen specifies a test
|
2874 |
|
|
that should be run, in the form of a Tcl script. For example an
|
2875 |
|
|
argument of list.tcl will cause
|
2876 |
|
|
usbhost to look for a script with that
|
2877 |
|
|
name, adding a .tcl suffix if necessarary, and
|
2878 |
|
|
run that script. usbhost will look in the
|
2879 |
|
|
current directory first, then in the install tree for standard test
|
2880 |
|
|
scripts provided by the USB slave package.
|
2881 |
|
|
|
2882 |
|
|
|
2883 |
|
|
|
2884 |
|
|
|
2885 |
|
|
Some test scripts may want their own parameters, for example a
|
2886 |
|
|
duration in seconds. These can be passed on the command line after
|
2887 |
|
|
the name of the test, for example
|
2888 |
|
|
usbhost mytest 60.
|
2889 |
|
|
|
2890 |
|
|
|
2891 |
|
|
|
2892 |
|
|
|
2893 |
|
|
|
2894 |
|
|
Writing a Test
|
2895 |
|
|
|
2896 |
|
|
Each test is defined by a Tcl script, running inside an interpreter
|
2897 |
|
|
provided by usbhost. In addition to the
|
2898 |
|
|
normal Tcl functionality this interpreter provides a number of
|
2899 |
|
|
variables and functions related to USB testing. For example there is a
|
2900 |
|
|
variable bulk_in_endpoints that lists all the
|
2901 |
|
|
endpoints on the target that can perform bulk IN operations, and a
|
2902 |
|
|
related array bulk_in which contains information
|
2903 |
|
|
such as the minimum and maximum packets sizes. There is a function
|
2904 |
|
|
bulktest which can be used to perform bulk tests
|
2905 |
|
|
on a particular endpoint. A simple test script aimed at specific
|
2906 |
|
|
hardware could ignore the information variables since it would know
|
2907 |
|
|
exactly what USB hardware is available on the target, whereas a
|
2908 |
|
|
general-purpose script would use the information to adapt to the
|
2909 |
|
|
hardware capabilities.
|
2910 |
|
|
|
2911 |
|
|
|
2912 |
|
|
To avoid namespace pollution all USB-related Tcl variables and
|
2913 |
|
|
functions live in the usbtest:: namespace.
|
2914 |
|
|
Therefore accessing requires either explicitly including the
|
2915 |
|
|
namespace any references, for example
|
2916 |
|
|
$usbtest::bulk_in_endpoints, or by using Tcl's
|
2917 |
|
|
namespace import facility.
|
2918 |
|
|
|
2919 |
|
|
|
2920 |
|
|
A very simple test script might look like this:
|
2921 |
|
|
|
2922 |
|
|
|
2923 |
|
|
usbtest::bulktest 1 out 4000
|
2924 |
|
|
usbtest::bulktest 2 in 4000
|
2925 |
|
|
if { [usbtest::start 60] } {
|
2926 |
|
|
puts "Test successful"
|
2927 |
|
|
} else
|
2928 |
|
|
puts "Test failed"
|
2929 |
|
|
foreach result $usbtest::results {
|
2930 |
|
|
puts $result
|
2931 |
|
|
}
|
2932 |
|
|
}
|
2933 |
|
|
|
2934 |
|
|
|
2935 |
|
|
This would perform a test run involving 4000 bulk transfers from the
|
2936 |
|
|
host to the target's endpoint 1, and concurrently 4000 bulk transfers
|
2937 |
|
|
from endpoint 2. Default settings for packet sizes, contents, and
|
2938 |
|
|
delays would be used. The actual test would not start running until
|
2939 |
|
|
usbtest is invoked, and it is expected that the
|
2940 |
|
|
test would complete within 60 seconds. If any failures occur then they
|
2941 |
|
|
are reported.
|
2942 |
|
|
|
2943 |
|
|
|
2944 |
|
|
|
2945 |
|
|
Available Hardware
|
2946 |
|
|
|
2947 |
|
|
Each target-side USB device driver provides information about the
|
2948 |
|
|
actual capabilities of the hardware, for example which endpoints are
|
2949 |
|
|
available. Strictly speaking it provides information about what is
|
2950 |
|
|
actually supported by the device driver, which may be a subset of what
|
2951 |
|
|
the hardware is capable of. For example, the hardware may support
|
2952 |
|
|
isochronous transfers on a particular endpoint but if there is no
|
2953 |
|
|
software support for this in the driver then this endpoint will not be
|
2954 |
|
|
listed. When usbhost first contacts the
|
2955 |
|
|
usbtarget program running on the target
|
2956 |
|
|
platform, it obtains this information and makes it available to test
|
2957 |
|
|
scripts via Tcl variables:
|
2958 |
|
|
|
2959 |
|
|
|
2960 |
|
|
|
2961 |
|
|
bulk_in_endpoints
|
2962 |
|
|
|
2963 |
|
|
This is a simple list of the endpoints which can support bulk IN
|
2964 |
|
|
transfers. For example if the target-side hardware supports
|
2965 |
|
|
these transfers on endpoints 3 and 5 then the value would be
|
2966 |
|
|
"3 5" Typical test scripts would
|
2967 |
|
|
iterate over the list using something like:
|
2968 |
|
|
|
2969 |
|
|
|
2970 |
|
|
if { 0 != [llength $usbtest::bulk_in_endpoints] } {
|
2971 |
|
|
puts"Bulk IN endpoints: $usbtest::bulk_in_endpoints"
|
2972 |
|
|
foreach endpoint $usbtest:bulk_in_endpoints {
|
2973 |
|
|
…
|
2974 |
|
|
}
|
2975 |
|
|
}
|
2976 |
|
|
|
2977 |
|
|
|
2978 |
|
|
|
2979 |
|
|
|
2980 |
|
|
bulk_in()
|
2981 |
|
|
|
2982 |
|
|
This array holds additional information about each bulk IN endpoint.
|
2983 |
|
|
The array is indexed by two fields, the endpoint number and one of
|
2984 |
|
|
min_size, max_size,
|
2985 |
|
|
max_in_padding and devtab:
|
2986 |
|
|
|
2987 |
|
|
|
2988 |
|
|
|
2989 |
|
|
min_size
|
2990 |
|
|
|
2991 |
|
|
This field specifies a lower bound on the size of bulk transfers,
|
2992 |
|
|
and will typically will have a value of 1.
|
2993 |
|
|
|
2994 |
|
|
|
2995 |
|
|
The typical minimum transfer size of a single byte is not strictly
|
2996 |
|
|
speaking correct, since under some circumstances it can make sense
|
2997 |
|
|
to have a transfer size of zero bytes. However current target-side
|
2998 |
|
|
device drivers interpret a request to transfer zero bytes as a way
|
2999 |
|
|
for higher-level code to determine whether or not an endpoint is
|
3000 |
|
|
stalled, so it is not actually possible to perform zero-byte
|
3001 |
|
|
transfers. This issue will be addressed at some future point.
|
3002 |
|
|
|
3003 |
|
|
|
3004 |
|
|
|
3005 |
|
|
|
3006 |
|
|
max_size
|
3007 |
|
|
|
3008 |
|
|
This field specifies an upper bound on the size of bulk transfers.
|
3009 |
|
|
Some target-side drivers may be limited to transfers of say
|
3010 |
|
|
0x0FFFF bytes because of hardware limitations. In practice the
|
3011 |
|
|
transfer size is likely to be limited primarily to limit memory
|
3012 |
|
|
consumption of the test code on the target hardware, and to ensure
|
3013 |
|
|
that tests complete reasonably quickly. At the time of writing
|
3014 |
|
|
transfers are limited to 4K.
|
3015 |
|
|
|
3016 |
|
|
|
3017 |
|
|
|
3018 |
|
|
max_in_padding
|
3019 |
|
|
|
3020 |
|
|
On some hardware it may be necessary for the target-side device
|
3021 |
|
|
driver to send more data than is actually intended. For example
|
3022 |
|
|
the SA11x0 USB hardware cannot perform bulk transfers that are
|
3023 |
|
|
an exact multiple of 64 bytes, instead it must pad such
|
3024 |
|
|
transfers with an extra byte and the host must be ready to
|
3025 |
|
|
accept and discard this byte. The
|
3026 |
|
|
max_in_padding field indicates the amount of
|
3027 |
|
|
padding that is required. The low-level code inside
|
3028 |
|
|
usbhost will use this field
|
3029 |
|
|
automatically, and there is no need for test scripts to adjust
|
3030 |
|
|
packet sizes for padding. The field is provided for
|
3031 |
|
|
informational purposes only.
|
3032 |
|
|
|
3033 |
|
|
|
3034 |
|
|
|
3035 |
|
|
devtab
|
3036 |
|
|
|
3037 |
|
|
This is a string indicating whether or not the
|
3038 |
|
|
target-side USB device driver supports access to this endpoint
|
3039 |
|
|
via entries in the device table, in other words through
|
3040 |
|
|
conventional calls like open and
|
3041 |
|
|
write. Some device drivers may only
|
3042 |
|
|
support low-level USB access because typically that is what gets
|
3043 |
|
|
used by USB class-specific packages such as USB-ethernet.
|
3044 |
|
|
An empty string indicates that no devtab entry is available,
|
3045 |
|
|
otherwise it will be something like
|
3046 |
|
|
"/dev/usbs2w".
|
3047 |
|
|
|
3048 |
|
|
|
3049 |
|
|
|
3050 |
|
|
|
3051 |
|
|
Typical test scripts would access this data using something like:
|
3052 |
|
|
|
3053 |
|
|
|
3054 |
|
|
foreach endpoint $usbtest:bulk_in_endpoints {
|
3055 |
|
|
puts "Endpoint $endpoint: "
|
3056 |
|
|
puts " minimum transfer size $usbtest::bulk_in($endpoint,min_size)"
|
3057 |
|
|
puts " maximum transfer size $usbtest::bulk_in($endpoint,max_size)"
|
3058 |
|
|
if { 0 == $usbtest::bulk_in($endpoint,max_in_padding) } {
|
3059 |
|
|
puts " no IN padding required"
|
3060 |
|
|
} else {
|
3061 |
|
|
puts " $usbtest::bulk_in($endpoint,max_in_padding) bytes of IN padding required"
|
3062 |
|
|
}
|
3063 |
|
|
if { "" == $usbtest::bulk_in($endpoint,devtab) } {
|
3064 |
|
|
puts " no devtab entry provided"
|
3065 |
|
|
} else {
|
3066 |
|
|
puts " corresponding devtab entry is $usbtest::bulk_in($endpoint,devtab)"
|
3067 |
|
|
}
|
3068 |
|
|
}
|
3069 |
|
|
|
3070 |
|
|
|
3071 |
|
|
|
3072 |
|
|
|
3073 |
|
|
bulk_out_endpoint
|
3074 |
|
|
|
3075 |
|
|
This is a simple list of the endpoints which can support bulk OUT
|
3076 |
|
|
transfers. It is analogous to
|
3077 |
|
|
bulk_in_endpoints.
|
3078 |
|
|
|
3079 |
|
|
|
3080 |
|
|
|
3081 |
|
|
bulk_out()
|
3082 |
|
|
|
3083 |
|
|
This array holds additional information about each bulk OUT
|
3084 |
|
|
endpoint. It can be accessed in the same way as
|
3085 |
|
|
bulk_in(), except that there is no
|
3086 |
|
|
max_in_padding field because that field only
|
3087 |
|
|
makes sense for IN transfers.
|
3088 |
|
|
|
3089 |
|
|
|
3090 |
|
|
|
3091 |
|
|
control()
|
3092 |
|
|
|
3093 |
|
|
This array holds information about the control endpoint. It contains
|
3094 |
|
|
two fields, min_size and
|
3095 |
|
|
max_size. Note that there is no variable
|
3096 |
|
|
control_endpoints because a USB target always
|
3097 |
|
|
supports a single control endpoint 0. Similarly
|
3098 |
|
|
the control array does not use an endpoint number
|
3099 |
|
|
as the first index because that would be redundant.
|
3100 |
|
|
|
3101 |
|
|
|
3102 |
|
|
|
3103 |
|
|
isochronous_in_endpoints and
|
3104 |
|
|
isochronous_in()
|
3105 |
|
|
|
3106 |
|
|
These variables provide the same information as
|
3107 |
|
|
bulk_in_endpoints and bulk_in,
|
3108 |
|
|
but for endpoints that support isochronous IN transfers.
|
3109 |
|
|
|
3110 |
|
|
|
3111 |
|
|
|
3112 |
|
|
isochronous_out_endpoints and
|
3113 |
|
|
isochronous_out()
|
3114 |
|
|
|
3115 |
|
|
These variables provide the same information as
|
3116 |
|
|
bulk_out_endpoints and bulk_out,
|
3117 |
|
|
but for endpoints that support isochronous OUT transfers.
|
3118 |
|
|
|
3119 |
|
|
|
3120 |
|
|
|
3121 |
|
|
interrupt_in_endpoints and
|
3122 |
|
|
interrupt_in()
|
3123 |
|
|
|
3124 |
|
|
These variables provide the same information as
|
3125 |
|
|
bulk_in_endpoints and bulk_in,
|
3126 |
|
|
but for endpoints that support interrupt IN transfers.
|
3127 |
|
|
|
3128 |
|
|
|
3129 |
|
|
|
3130 |
|
|
interrupt_out_endpoints and
|
3131 |
|
|
interrupt_out()
|
3132 |
|
|
|
3133 |
|
|
These variables provide the same information as
|
3134 |
|
|
bulk_out_endpoints and bulk_out,
|
3135 |
|
|
but for endpoints that support interrupt OUT transfers.
|
3136 |
|
|
|
3137 |
|
|
|
3138 |
|
|
|
3139 |
|
|
|
3140 |
|
|
|
3141 |
|
|
|
3142 |
|
|
Testing Bulk Transfers
|
3143 |
|
|
|
3144 |
|
|
The main function for initiating a bulk test is
|
3145 |
|
|
usbtest::bulktest. This takes three compulsory
|
3146 |
|
|
arguments, and can be given a number of additional arguments to
|
3147 |
|
|
control the exact behaviour. The compulsory arguments are:
|
3148 |
|
|
|
3149 |
|
|
|
3150 |
|
|
|
3151 |
|
|
endpoint
|
3152 |
|
|
|
3153 |
|
|
This specifies the endpoint to use. It should correspond to
|
3154 |
|
|
one of the entries in
|
3155 |
|
|
usbtest::bulk_in_endpoints or
|
3156 |
|
|
usbtest::bulk_out_endpoints, depending on the
|
3157 |
|
|
transfer direction.
|
3158 |
|
|
|
3159 |
|
|
|
3160 |
|
|
|
3161 |
|
|
direction
|
3162 |
|
|
|
3163 |
|
|
This should be either in or out.
|
3164 |
|
|
|
3165 |
|
|
|
3166 |
|
|
|
3167 |
|
|
number of transfers
|
3168 |
|
|
|
3169 |
|
|
This specifies the number of transfers that should take place. The
|
3170 |
|
|
testing software does not currently support the concept of performing
|
3171 |
|
|
transfers for a given period of time because synchronising this on
|
3172 |
|
|
both the host and a wide range of targets is difficult. However it
|
3173 |
|
|
is relatively easy to work out the approximate time a number of bulk
|
3174 |
|
|
transfers should take place, based on a typical bandwidth of
|
3175 |
|
|
1MB/second and assuming say a 1ms overhead per transfer.
|
3176 |
|
|
Alternatively a test script could perform a small initial run to
|
3177 |
|
|
determine what performance can actually be expected from a given
|
3178 |
|
|
target, and then use this information to run a much longer test.
|
3179 |
|
|
|
3180 |
|
|
|
3181 |
|
|
|
3182 |
|
|
|
3183 |
|
|
Additional arguments can be used to control the exact transfer. For
|
3184 |
|
|
example a txdelay+ argument can be used to
|
3185 |
|
|
slowly increase the delay between transfers. All such arguments involve
|
3186 |
|
|
a value which can be passed either as part of the argument itself,
|
3187 |
|
|
for example txdelay+=5, or as a subsequent
|
3188 |
|
|
argument, txdelay+ 5. The possible arguments fall
|
3189 |
|
|
into a number of categories: data, I/O mechanism, transmit size,
|
3190 |
|
|
receive size, transmit delay, and receive delay.
|
3191 |
|
|
|
3192 |
|
|
|
3193 |
|
|
Data
|
3194 |
|
|
|
3195 |
|
|
An obvious parameter to control is the actual data that gets sent.
|
3196 |
|
|
This can be controlled by the argument data
|
3197 |
|
|
which can take one of five values: none,
|
3198 |
|
|
bytefill, intfill,
|
3199 |
|
|
byteseq and wordseq. The default
|
3200 |
|
|
value is none.
|
3201 |
|
|
|
3202 |
|
|
|
3203 |
|
|
|
3204 |
|
|
none
|
3205 |
|
|
|
3206 |
|
|
The transmit code will not attempt to fill the buffer in any way,
|
3207 |
|
|
and the receive code will not check it. The actual data that gets
|
3208 |
|
|
transferred will be whatever happened to be in the buffer before
|
3209 |
|
|
the transfer started.
|
3210 |
|
|
|
3211 |
|
|
|
3212 |
|
|
|
3213 |
|
|
bytefill
|
3214 |
|
|
|
3215 |
|
|
The entire buffer will be filled with a single byte, as per
|
3216 |
|
|
memset.
|
3217 |
|
|
|
3218 |
|
|
|
3219 |
|
|
|
3220 |
|
|
intfill
|
3221 |
|
|
|
3222 |
|
|
The buffer will be treated as an array of 32-bit integers, and will
|
3223 |
|
|
be filled with the same integer repeated the appropriate number of
|
3224 |
|
|
times. If the buffer size is not a multiple of four bytes then
|
3225 |
|
|
the last few bytes will be set to 0.
|
3226 |
|
|
|
3227 |
|
|
|
3228 |
|
|
|
3229 |
|
|
byteseq
|
3230 |
|
|
|
3231 |
|
|
The buffer will be filled with a sequence of bytes, generated by
|
3232 |
|
|
a linear congruential generator. If the first byte in the buffer is
|
3233 |
|
|
filled with the value x, the next byte will be
|
3234 |
|
|
(m*x)+i. For example a sequence of slowly
|
3235 |
|
|
incrementing bytes can be achieved by setting both the multiplier
|
3236 |
|
|
and the increment to 1. Alternatively a pseudo-random number
|
3237 |
|
|
sequence can be achieved using values 1103515245 and 12345, as
|
3238 |
|
|
per the standard C library rand function.
|
3239 |
|
|
For convenience these two constants are available as Tcl
|
3240 |
|
|
variables usbtest::MULTIPLIER and
|
3241 |
|
|
usbtest::INCREMENT.
|
3242 |
|
|
|
3243 |
|
|
|
3244 |
|
|
|
3245 |
|
|
wordseq
|
3246 |
|
|
|
3247 |
|
|
This acts like byteseq, except that the buffer is
|
3248 |
|
|
treated as an array of 32-bit integers rather than as an array of
|
3249 |
|
|
bytes. If the buffer is not a multiple of four bytes then the last
|
3250 |
|
|
few bytes will be filled with zeroes.
|
3251 |
|
|
|
3252 |
|
|
|
3253 |
|
|
|
3254 |
|
|
|
3255 |
|
|
The above requires three additional parameters
|
3256 |
|
|
data1, data* and
|
3257 |
|
|
data+. data1 specifies
|
3258 |
|
|
the value to be used for byte or word fills, or the first number when
|
3259 |
|
|
calculating a sequence. The default value is 0.
|
3260 |
|
|
data* and data+ specify
|
3261 |
|
|
the multiplier and increment for a sequence, and have default values
|
3262 |
|
|
of 1 and 0 respectively. For
|
3263 |
|
|
example, to perform a bulk transfer of a pseudo-random sequence of
|
3264 |
|
|
integers starting with 42 the following code could be used:
|
3265 |
|
|
|
3266 |
|
|
|
3267 |
|
|
bulktest 2 IN 1000 data=wordseq data1=42 \
|
3268 |
|
|
data* $usbtest::MULTIPLIER data+ $usbtest::INCREMENT
|
3269 |
|
|
|
3270 |
|
|
|
3271 |
|
|
The above parameters define what data gets transferred for the first
|
3272 |
|
|
transfer, but a test can involve multiple transfers. The data format
|
3273 |
|
|
will be the same for all transfers, but it is possible to adjust the
|
3274 |
|
|
current value, the multiplier, and the increment between each
|
3275 |
|
|
transfer. This is achieved with parameters data1*,
|
3276 |
|
|
data1+, data**,
|
3277 |
|
|
data*+, data+*, and
|
3278 |
|
|
data++, with default values of 1 for each
|
3279 |
|
|
multiplier and 0 for each increment. For example, if the multiplier
|
3280 |
|
|
for the first transfer is set to 2 using
|
3281 |
|
|
data*, and arguments
|
3282 |
|
|
data** 2 and data*+ -1 are also
|
3283 |
|
|
supplied, then the multiplier for subsequent transfers will be
|
3284 |
|
|
3, 5, 9,
|
3285 |
|
|
….
|
3286 |
|
|
|
3287 |
|
|
|
3288 |
|
|
|
3289 |
|
|
Currently it is not possible for a test script to send specific data,
|
3290 |
|
|
for example a specific sequence of bytes captured by a protocol analyser
|
3291 |
|
|
that caused a problem. If the transfer was from host to target then
|
3292 |
|
|
the target would have to know the exact sequence of bytes to expect,
|
3293 |
|
|
which means transferring data over the USB bus when that data is known
|
3294 |
|
|
to have caused problems in the past. Similarly for target to host
|
3295 |
|
|
transfers the target would have to know what bytes to send. A possible
|
3296 |
|
|
future extension of the USB testing support would allow for bounce
|
3297 |
|
|
operations, where a given message is first sent to the target and then
|
3298 |
|
|
sent back to the host, with only the host checking that the data was
|
3299 |
|
|
returned correctly.
|
3300 |
|
|
|
3301 |
|
|
|
3302 |
|
|
|
3303 |
|
|
I/O Mechanism
|
3304 |
|
|
|
3305 |
|
|
On the target side USB transfers can happen using either low-level
|
3306 |
|
|
USB calls such as usbs_start_rx_buffer, or by
|
3307 |
|
|
higher-level calls which go through the device table. By default the
|
3308 |
|
|
target-side code will use the low-level calls. If it is desired to
|
3309 |
|
|
test the higher-level calls instead, for example because those are
|
3310 |
|
|
what the application uses, then that can be achieved with an
|
3311 |
|
|
argument mechanism=devtab.
|
3312 |
|
|
|
3313 |
|
|
|
3314 |
|
|
|
3315 |
|
|
Transmit Size
|
3316 |
|
|
|
3317 |
|
|
The next set of arguments can be used to control the size of the
|
3318 |
|
|
transmitted buffer: txsize1,
|
3319 |
|
|
txsize>=, txsize<=
|
3320 |
|
|
txsize*, txsize/,
|
3321 |
|
|
and txsize+.
|
3322 |
|
|
|
3323 |
|
|
|
3324 |
|
|
txsize1 determines the size of the first
|
3325 |
|
|
transfer, and has a default value of 32 bytes. The size of the next
|
3326 |
|
|
transfer is calculated by first multiplying by the
|
3327 |
|
|
txsize* value, then dividing by the
|
3328 |
|
|
txsize/ value, and finally adding the
|
3329 |
|
|
txsize+ value. The defaults for these are
|
3330 |
|
|
1, 1, and 0
|
3331 |
|
|
respectively, which means that the transfer size will remain
|
3332 |
|
|
unchanged. If for example the transfer size should increase by
|
3333 |
|
|
approximately 50 per cent each time then suitable values might be
|
3334 |
|
|
txsize* 3, txsize/ 2,
|
3335 |
|
|
and txsize+ 1.
|
3336 |
|
|
|
3337 |
|
|
|
3338 |
|
|
The txsize>= and
|
3339 |
|
|
txsize<= arguments can be used to impose
|
3340 |
|
|
lower and upper bounds on the transfer. By default the
|
3341 |
|
|
min_size and max_size values
|
3342 |
|
|
appropriate for the endpoint will be used. If at any time the
|
3343 |
|
|
current size falls outside the bounds then it will be normalized.
|
3344 |
|
|
|
3345 |
|
|
|
3346 |
|
|
|
3347 |
|
|
Receive Size
|
3348 |
|
|
|
3349 |
|
|
The receive size, in other words the number of bytes that either host
|
3350 |
|
|
or target will expect to receive as opposed to the number of bytes
|
3351 |
|
|
that actually get sent, can be adjusted using a similar set of
|
3352 |
|
|
arguments: rxsize1,
|
3353 |
|
|
rxsize>=,
|
3354 |
|
|
rxsize<=,
|
3355 |
|
|
rxsize*, rxsize/ and
|
3356 |
|
|
rxsize+. The current receive size will be
|
3357 |
|
|
adjusted between transfers just like the transmit size. However when
|
3358 |
|
|
communicating over USB it is not a good idea to attempt to receive
|
3359 |
|
|
less data than will actually be sent: typically neither the hardware
|
3360 |
|
|
nor the software will be able to do anything useful with the excess,
|
3361 |
|
|
so there will be problems. Therefore if at any time the calculated
|
3362 |
|
|
receive size is less than the transmit size, the actual receive will
|
3363 |
|
|
be for the exact number of bytes that will get transmitted. However
|
3364 |
|
|
this will not affect the calculations for the next receive size.
|
3365 |
|
|
|
3366 |
|
|
|
3367 |
|
|
The default values for rxsize1,
|
3368 |
|
|
rxsize*, rxsize/ and
|
3369 |
|
|
rxsize+ are 0,
|
3370 |
|
|
1, 1 and 0
|
3371 |
|
|
respectively. This means that the calculated receive size will always
|
3372 |
|
|
be less than the transmit size, so the receive operation will be for
|
3373 |
|
|
the exact number of bytes transmitted. For some USB protocols this
|
3374 |
|
|
would not accurately reflect the traffic that will happen. For example
|
3375 |
|
|
with USB-ethernet transfer sizes will vary between 16 and 1516 bytes,
|
3376 |
|
|
so the receiver will always expect up to 1516 bytes. This can be
|
3377 |
|
|
achieved using rxsize1 1516, leaving the
|
3378 |
|
|
other parameters at their default values.
|
3379 |
|
|
|
3380 |
|
|
|
3381 |
|
|
For target hardware which involves non-zero
|
3382 |
|
|
max_in_padding, on the host side the padding will
|
3383 |
|
|
be added automatically to the receive size if necessary.
|
3384 |
|
|
|
3385 |
|
|
|
3386 |
|
|
|
3387 |
|
|
Transmit and Receive Delays
|
3388 |
|
|
|
3389 |
|
|
Typically during the testing there will be some minor delays between
|
3390 |
|
|
transfers on both host and target. Some of these delays will be caused
|
3391 |
|
|
by timeslicing, for example another process running on the host, or a
|
3392 |
|
|
concurrent test thread running inside the target. Other delays will be
|
3393 |
|
|
caused by the USB bus itself, for example activity from another device
|
3394 |
|
|
on the bus. However it is desirable that test cases be allowed to
|
3395 |
|
|
inject additional and somewhat more controlled delays into the system,
|
3396 |
|
|
for example to make sure that the target behaves correctly even if the
|
3397 |
|
|
target is not yet ready to receive data from the host.
|
3398 |
|
|
|
3399 |
|
|
|
3400 |
|
|
The transmit delay is controlled by six parameters:
|
3401 |
|
|
txdelay1, txdelay*,
|
3402 |
|
|
txdelay/, txdelay+,
|
3403 |
|
|
txdelay>= and
|
3404 |
|
|
txdelay<=. The default values for these are
|
3405 |
|
|
0, 1, 1,
|
3406 |
|
|
0, 0 and
|
3407 |
|
|
1000000000 respectively, so that by default
|
3408 |
|
|
transmits will happen as quickly as possible. Delays are measured in
|
3409 |
|
|
nanoseconds, so a value of 1000000 would correspond
|
3410 |
|
|
to a delay of 0.001 seconds or one millisecond. By default delays have
|
3411 |
|
|
an upper bound of one second. Between transfers the transmit delay is
|
3412 |
|
|
updated in much the same was as the transfer sizes.
|
3413 |
|
|
|
3414 |
|
|
|
3415 |
|
|
The receive delay is controlled by a similar set of six parameters:
|
3416 |
|
|
rxdelay1, rxdelay*,
|
3417 |
|
|
rxdelay/, rxdelay+,
|
3418 |
|
|
rxdelay>= and
|
3419 |
|
|
rxdelay<=. The default values for these are
|
3420 |
|
|
the same as for transmit delays.
|
3421 |
|
|
|
3422 |
|
|
|
3423 |
|
|
The transmit delay is used on the side which sends data over the USB
|
3424 |
|
|
bus, so for a bulk IN transfer it is the target that sends data and
|
3425 |
|
|
hence sleeps for the specified transmit delay, while the host receives
|
3426 |
|
|
data sleeps for the receive delay. For an OUT transfer the positions
|
3427 |
|
|
are reversed.
|
3428 |
|
|
|
3429 |
|
|
|
3430 |
|
|
It should be noted that although the delays are measured in
|
3431 |
|
|
nanoseconds, the actual delays will be much less precise and are
|
3432 |
|
|
likely to be of the order of milliseconds. The exact details will
|
3433 |
|
|
depend on the kernel clock speed.
|
3434 |
|
|
|
3435 |
|
|
|
3436 |
|
|
|
3437 |
|
|
|
3438 |
|
|
|
3439 |
|
|
Other Types of Transfer
|
3440 |
|
|
|
3441 |
|
|
Support for testing other types of USB traffic such as isochronous
|
3442 |
|
|
transfers is not yet implemented.
|
3443 |
|
|
|
3444 |
|
|
|
3445 |
|
|
|
3446 |
|
|
Starting a Test and Collecting Results
|
3447 |
|
|
|
3448 |
|
|
A USB test script should prepare one or more transfers using
|
3449 |
|
|
appropriate functions such as usbtest::bulktest.
|
3450 |
|
|
Once all the individual tests have been prepared they can be started
|
3451 |
|
|
by a call to usbtest::start. This takes a single
|
3452 |
|
|
argument, a maximum duration measured in seconds. If all transfers
|
3453 |
|
|
have not been completed in the specified time then any remaining
|
3454 |
|
|
transfers will be aborted.
|
3455 |
|
|
|
3456 |
|
|
|
3457 |
|
|
usbtest::start will return 1
|
3458 |
|
|
if all the tests have succeeded, or 0 if any of
|
3459 |
|
|
them have failed. More detailed reports will be stored in the
|
3460 |
|
|
Tcl variable usbtests::results, which will be a
|
3461 |
|
|
list of string messages.
|
3462 |
|
|
|
3463 |
|
|
|
3464 |
|
|
|
3465 |
|
|
Existing Test Scripts
|
3466 |
|
|
|
3467 |
|
|
A number of test scripts are provided as standard. These are located
|
3468 |
|
|
in the host subdirectory of the
|
3469 |
|
|
common USB slave package, and will be installed as part of the process
|
3470 |
|
|
of building the host-side software. When a script is specified on the
|
3471 |
|
|
command line usbhost will first search for
|
3472 |
|
|
it in the current directory, then in the install tree. Standard
|
3473 |
|
|
test scripts include the following:
|
3474 |
|
|
|
3475 |
|
|
|
3476 |
|
|
list.tcl
|
3477 |
|
|
|
3478 |
|
|
This script simply displays information about the capabilities
|
3479 |
|
|
of the target platform, as provided by the target-side USB
|
3480 |
|
|
device driver. It can help with tracking down problems, but its
|
3481 |
|
|
primary purpose is to let users check that everything is working
|
3482 |
|
|
correctly: if running usbhost list.tcl
|
3483 |
|
|
outputs sensible information then the user knows that the
|
3484 |
|
|
target side is running correctly and that communication between
|
3485 |
|
|
host and target is possible.
|
3486 |
|
|
|
3487 |
|
|
|
3488 |
|
|
verbose.tcl
|
3489 |
|
|
|
3490 |
|
|
The target-side code can provide information about what
|
3491 |
|
|
is happening while tests are prepared and run. This facility
|
3492 |
|
|
should not normally be used since the extra I/O involved will
|
3493 |
|
|
significantly affect the behaviour of the system, but in some
|
3494 |
|
|
circumstances it may prove useful. Since an eCos application
|
3495 |
|
|
cannot easily be given command-line arguments the target-side
|
3496 |
|
|
verbosity level cannot be controlled using
|
3497 |
|
|
-V or --verbose
|
3498 |
|
|
options. Instead it can be controlled from inside
|
3499 |
|
|
gdb by changing the integer
|
3500 |
|
|
variable verbose. Alternatively it can
|
3501 |
|
|
be manipulated by running the test script
|
3502 |
|
|
verbose.tcl. This script takes a single
|
3503 |
|
|
argument, the desired verbosity level, which should be a small
|
3504 |
|
|
integer. For example, to disable target-side run-time logging
|
3505 |
|
|
the command usbhost verbose 0 can
|
3506 |
|
|
be used.
|
3507 |
|
|
|
3508 |
|
|
|
3509 |
|
|
bulk-boundaries.tcl
|
3510 |
|
|
This script performs simple bulk IN and OUT
|
3511 |
|
|
transfers of different sizes around interesting boundaries. This
|
3512 |
|
|
test is useful to ensure the driver correctly handles the case
|
3513 |
|
|
where a transfer is just smaller than, the same size as, and
|
3514 |
|
|
just bigger than the hardware buffer in the endpoint hardware.
|
3515 |
|
|
This script takes no parameters. It determines what endpoints
|
3516 |
|
|
the device has by asking it.
|
3517 |
|
|
|
3518 |
|
|
|
3519 |
|
|
|
3520 |
|
|
|
3521 |
|
|
|
3522 |
|
|
Possible Problems
|
3523 |
|
|
|
3524 |
|
|
If all transfers succeed within the specified time then both host and
|
3525 |
|
|
target remain in synch and further tests can be run without problem.
|
3526 |
|
|
However, if at any time a failure occurs then things get more
|
3527 |
|
|
complicated. For example, if the current test involves a series of
|
3528 |
|
|
bulk OUT transfers and the target detects that for one of these
|
3529 |
|
|
transfers it received less data than was expected then the test has
|
3530 |
|
|
failed, and the target will stop accepting data on this endpoint.
|
3531 |
|
|
However the host-side software may not have detected anything wrong
|
3532 |
|
|
and is now blocked trying to send the next lot of data.
|
3533 |
|
|
|
3534 |
|
|
|
3535 |
|
|
The test code goes to considerable effort to recover from problems
|
3536 |
|
|
such as these. On the host-side separate threads are used for
|
3537 |
|
|
concurrent transfers, and on the target-side appropriate asynchronous
|
3538 |
|
|
I/O mechanisms are used. In addition there is a control thread on the
|
3539 |
|
|
host that checks the state of all the main host-side threads, and the
|
3540 |
|
|
state of the target using private control messages. If it discovers
|
3541 |
|
|
that one side has stopped sending or receiving data because of an
|
3542 |
|
|
error and the other side is blocked as a result, it will set certain
|
3543 |
|
|
flags and then cause one additional transfer to take place. That
|
3544 |
|
|
additional transfer will have the effect of unblocking the other side,
|
3545 |
|
|
which then discovers that an error has occurred by checking the
|
3546 |
|
|
appropriate flags. In this way both host and target should end up back
|
3547 |
|
|
in synch, and it is possible to move on to the next set of tests.
|
3548 |
|
|
|
3549 |
|
|
|
3550 |
|
|
However, the above assumes that the testing has not triggered any
|
3551 |
|
|
serious hardware conditions. If instead the target-side hardware has
|
3552 |
|
|
been left in some strange state so that, for example, it will no
|
3553 |
|
|
longer raise an interrupt for traffic on a particular endpoint then
|
3554 |
|
|
recovery is not currently possible, and the testing software will just
|
3555 |
|
|
hang.
|
3556 |
|
|
|
3557 |
|
|
|
3558 |
|
|
A possible future enhancement to the testing software would allow the
|
3559 |
|
|
host-side to raise a USB reset signal whenever a failure occurs, in
|
3560 |
|
|
the hope that this would clear any remaining problems within the
|
3561 |
|
|
target-side USB hardware.
|
3562 |
|
|
|
3563 |
|
|
|
3564 |
|
|
|
3565 |
|
|
|
3566 |
|
|
|
3567 |
|
|
|
3568 |
|
|
|
3569 |
|
|
|
3570 |
|
|
|
3571 |
|
|
|