OpenCores
URL https://opencores.org/ocsvn/openrisc_2011-10-31/openrisc_2011-10-31/trunk

Subversion Repositories openrisc_2011-10-31

[/] [openrisc/] [trunk/] [rtos/] [ecos-2.0/] [packages/] [io/] [usb/] [slave/] [v2_0/] [doc/] [usbs-enum.html] - Blame information for rev 252

Go to most recent revision | Details | Compare with Previous | View Log

Line No. Rev Author Line
1 27 unneback 
<!-- Copyright (C) 2002 Red Hat, Inc.                                -->
2 
<!-- This material may be distributed only subject to the terms      -->
3 
<!-- and conditions set forth in the Open Publication License, v1.0  -->
4 
<!-- or later (the latest version is presently available at          -->
5 
<!-- http://www.opencontent.org/openpub/).                           -->
6 
<!-- Distribution of substantively modified versions of this         -->
7 
<!-- document is prohibited without the explicit permission of the   -->
8 
<!-- copyright holder.                                               -->
9 
<!-- Distribution of the work or derivative of the work in any       -->
10 
<!-- standard (paper) book form is prohibited unless prior           -->
11 
<!-- permission is obtained from the copyright holder.               -->
12 
<HTML
13 
><HEAD
14 
><TITLE
15 
>USB Enumeration Data</TITLE
16 
><meta name="MSSmartTagsPreventParsing" content="TRUE">
17 
<META
18 
NAME="GENERATOR"
19 
CONTENT="Modular DocBook HTML Stylesheet Version 1.64
20 
"><LINK
21 
REL="HOME"
22 
TITLE="eCos USB Slave Support"
23 
HREF="io-usb-slave.html"><LINK
24 
REL="PREVIOUS"
25 
TITLE="Introduction"
26 
HREF="usbs-intro.html"><LINK
27 
REL="NEXT"
28 
TITLE="Starting up a USB Device"
29 
HREF="usbs-start.html"></HEAD
30 
><BODY
31 
CLASS="REFENTRY"
32 
BGCOLOR="#FFFFFF"
33 
TEXT="#000000"
34 
LINK="#0000FF"
35 
VLINK="#840084"
36 
ALINK="#0000FF"
37 
><DIV
38 
CLASS="NAVHEADER"
39 
><TABLE
40 
WIDTH="100%"
41 
BORDER="0"
42 
CELLPADDING="0"
43 
CELLSPACING="0"
44 
><TR
45 
><TH
46 
COLSPAN="3"
47 
ALIGN="center"
48 
>eCos USB Slave Support</TH
49 
></TR
50 
><TR
51 
><TD
52 
WIDTH="10%"
53 
ALIGN="left"
54 
VALIGN="bottom"
55 
><A
56 
HREF="usbs-intro.html"
57 
>Prev</A
58 
></TD
59 
><TD
60 
WIDTH="80%"
61 
ALIGN="center"
62 
VALIGN="bottom"
63 
></TD
64 
><TD
65 
WIDTH="10%"
66 
ALIGN="right"
67 
VALIGN="bottom"
68 
><A
69 
HREF="usbs-start.html"
70 
>Next</A
71 
></TD
72 
></TR
73 
></TABLE
74 
><HR
75 
ALIGN="LEFT"
76 
WIDTH="100%"></DIV
77 
><H1
78 
><A
79 
NAME="USBS-ENUM"
80 
>USB Enumeration Data</A
81 
></H1
82 
><DIV
83 
CLASS="REFNAMEDIV"
84 
><A
85 
NAME="AEN68"
86 
></A
87 
><H2
88 
>Name</H2
89 
>Enumeration Data&nbsp;--&nbsp;The USB enumeration data structures</DIV
90 
><DIV
91 
CLASS="REFSYNOPSISDIV"
92 
><A
93 
NAME="AEN71"
94 
></A
95 
><H2
96 
>Synopsis</H2
97 
><TABLE
98 
BORDER="0"
99 
BGCOLOR="#E0E0E0"
100 
WIDTH="100%"
101 
><TR
102 
><TD
103 
><PRE
104 
CLASS="SYNOPSIS"
105 
>#include &lt;cyg/io/usb/usb.h&gt;
106 
#include &lt;cyg/io/usb/usbs.h&gt;
107 
 
108 
typedef struct usb_device_descriptor {
109 
    &#8230;
110 
} usb_device_descriptor __attribute__((packed));
111 
 
112 
typedef struct usb_configuration_descriptor {
113 
    &#8230;
114 
} usb_configuration_descriptor __attribute__((packed));
115 
 
116 
typedef struct usb_interface_descriptor {
117 
    &#8230;
118 
} usb_interface_descriptor __attribute__((packed));
119 
 
120 
typedef struct usb_endpoint_descriptor {
121 
    &#8230;
122 
} usb_endpoint_descriptor;
123 
 
124 
typedef struct usbs_enumeration_data {
125 
    usb_device_descriptor               device;
126 
    int                                 total_number_interfaces;
127 
    int                                 total_number_endpoints;
128 
    int                                 total_number_strings;
129 
    const usb_configuration_descriptor* configurations;
130 
    const usb_interface_descriptor*     interfaces;
131 
    const usb_endpoint_descriptor*      endpoints;
132 
    const unsigned char**               strings;
133 
} usbs_enumeration_data;</PRE
134 
></TD
135 
></TR
136 
></TABLE
137 
></DIV
138 
><DIV
139 
CLASS="REFSECT1"
140 
><A
141 
NAME="AEN73"
142 
></A
143 
><H2
144 
>USB Enumeration Data</H2
145 
><P
146 
>When a USB host detects that a peripheral has been plugged in or
147 
powered up, one of the first steps is to ask the peripheral to
148 
describe itself by supplying enumeration data. Some of this data
149 
depends on the class of peripheral. Other fields are vendor-specific.
150 
There is also a dependency on the hardware, specifically which
151 
endpoints are available should be used. In general it is not possible
152 
for generic code to provide this information, so it is the
153 
responsibility of application code to provide a suitable
154 
<SPAN
155 
CLASS="STRUCTNAME"
156 
>usbs_enumeration_data</SPAN
157 
> data structure and
158 
install it in the endpoint 0 data structure during initialization.
159 
This must happen before the USB device is enabled by a call to
160 
<TT
161 
CLASS="FUNCTION"
162 
>usbs_start</TT
163 
>, for example:</P
164 
><TABLE
165 
BORDER="0"
166 
BGCOLOR="#E0E0E0"
167 
WIDTH="100%"
168 
><TR
169 
><TD
170 
><PRE
171 
CLASS="PROGRAMLISTING"
172 
>const usbs_enumeration_data usb_enum_data = {
173 
    &#8230;
174 
};
175 
 
176 
int
177 
main(int argc, char** argv)
178 
{
179 
    usbs_sa11x0_ep0.enumeration_data = &amp;usb_enum_data;
180 
    &#8230;
181 
    usbs_start(&amp;usbs_sa11x0_ep0);
182 
    &#8230;
183 
}</PRE
184 
></TD
185 
></TR
186 
></TABLE
187 
><P
188 
>For most applications the enumeration data will be static, although
189 
the <SPAN
190 
CLASS="STRUCTNAME"
191 
>usbs_enumeration_data</SPAN
192 
> structure can be
193 
filled in at run-time if necessary. Full details of the enumeration
194 
data can be found in the Universal Serial Bus specification obtainable
195 
from the <A
196 
HREF="http://www.usb.org/"
197 
TARGET="_top"
198 
>USB Implementers Forum web
199 
site</A
200 
>, although the meaning of most fields is fairly obvious.
201 
The various data structures and utility macros are defined in the
202 
header files <TT
203 
CLASS="FILENAME"
204 
>cyg/io/usb/usb.h</TT
205 
>
206 
and <TT
207 
CLASS="FILENAME"
208 
>cyg/io/usb/usbs.h</TT
209 
>. Note
210 
that the example code below makes use of the gcc labelled element
211 
extension.</P
212 
><DIV
213 
CLASS="REFSECT2"
214 
><A
215 
NAME="AEN84"
216 
></A
217 
><H3
218 
><SPAN
219 
CLASS="STRUCTNAME"
220 
>usb_device_descriptor</SPAN
221 
></H3
222 
><P
223 
>The main information about a USB peripheral comes from a single
224 
<SPAN
225 
CLASS="STRUCTNAME"
226 
>usb_device_descriptor</SPAN
227 
> structure, which is
228 
embedded in the <SPAN
229 
CLASS="STRUCTNAME"
230 
>usbs_enumeration_data</SPAN
231 
>
232 
structure. A typical example might look like this:</P
233 
><TABLE
234 
BORDER="0"
235 
BGCOLOR="#E0E0E0"
236 
WIDTH="100%"
237 
><TR
238 
><TD
239 
><PRE
240 
CLASS="PROGRAMLISTING"
241 
>const usbs_enumeration_data usb_enum_data = {
242 
    {
243 
        length:                 USB_DEVICE_DESCRIPTOR_LENGTH,
244 
        type:                   USB_DEVICE_DESCRIPTOR_TYPE,
245 
        usb_spec_lo:            USB_DEVICE_DESCRIPTOR_USB11_LO,
246 
        usb_spec_hi:            USB_DEVICE_DESCRIPTOR_USB11_HI,
247 
        device_class:           USB_DEVICE_DESCRIPTOR_CLASS_VENDOR,
248 
        device_subclass:        USB_DEVICE_DESCRIPTOR_SUBCLASS_VENDOR,
249 
        device_protocol:        USB_DEVICE_DESCRIPTOR_PROTOCOL_VENDOR,
250 
        max_packet_size:        8,
251 
        vendor_lo:              0x42,
252 
        vendor_hi:              0x42,
253 
        product_lo:             0x42,
254 
        product_hi:             0x42,
255 
        device_lo:              0x00,
256 
        device_hi:              0x01,
257 
        manufacturer_str:       1,
258 
        product_str:            2,
259 
        serial_number_str:      0,
260 
        number_configurations:  1
261 
    },
262 
    &#8230;
263 
};</PRE
264 
></TD
265 
></TR
266 
></TABLE
267 
><P
268 
>The length and type fields are specified by the USB standard. The
269 
<TT
270 
CLASS="STRUCTFIELD"
271 
><I
272 
>usb_spec_lo</I
273 
></TT
274 
> and
275 
<TT
276 
CLASS="STRUCTFIELD"
277 
><I
278 
>usb_spec_hi</I
279 
></TT
280 
> fields identify the particular
281 
revision of the standard that the peripheral implements, for example
282 
revision 1.1.</P
283 
><P
284 
>The device class, subclass, and protocol fields are used by generic
285 
host-side USB software to determine which host-side device driver
286 
should be loaded to interact with the peripheral. A number of standard
287 
classes are defined, for example mass-storage devices and
288 
human-interface devices. If a peripheral implements one of the
289 
standard classes then a standard existing host-side device driver may
290 
exist, eliminating the need to write a custom driver. The value
291 
<TT
292 
CLASS="LITERAL"
293 
>0xFF</TT
294 
> (<TT
295 
CLASS="LITERAL"
296 
>VENDOR</TT
297 
>) is reserved for
298 
peripherals that implement a vendor-specific protocol rather than a
299 
standard one. Such peripherals will require a custom host-side device
300 
driver. The value <TT
301 
CLASS="LITERAL"
302 
>0x00</TT
303 
>
304 
(<TT
305 
CLASS="LITERAL"
306 
>INTERFACE</TT
307 
>) is reserved and indicates that the
308 
protocol used by the peripheral is defined at the interface level
309 
rather than for the peripheral as a whole.</P
310 
><P
311 
>The <TT
312 
CLASS="STRUCTFIELD"
313 
><I
314 
>max_package_size</I
315 
></TT
316 
> field specifies the
317 
maximum length of a control message. There is a lower bound of eight
318 
bytes, and typical hardware will not support anything larger because
319 
control messages are usually small and not performance-critical.</P
320 
><P
321 
>The <TT
322 
CLASS="STRUCTFIELD"
323 
><I
324 
>vendor_lo</I
325 
></TT
326 
> and
327 
<TT
328 
CLASS="STRUCTFIELD"
329 
><I
330 
>vendor_hi</I
331 
></TT
332 
> fields specify a vendor id, which
333 
must be obtained from the USB Implementor's Forum. The numbers used in
334 
the code fragment above are examples only and must not be used in real
335 
USB peripherals. The product identifier is determined by the vendor,
336 
and different USB peripherals should use different identifiers. The
337 
device identifier field should indicate a release number in
338 
binary-coded decimal.</P
339 
><P
340 
>The above fields are all numerical in nature. A USB peripheral can
341 
also provide a number of strings as described <A
342 
HREF="usbs-enum.html#AEN159"
343 
>below</A
344 
>, for example the name of the
345 
vendor can be provided. The various <TT
346 
CLASS="STRUCTFIELD"
347 
><I
348 
>_str</I
349 
></TT
350 
>
351 
fields act as indices into an array of strings, with index 0
352 
indicating that no string is available. </P
353 
><P
354 
>A typical USB peripheral involves just a single configuration. However
355 
more complicated peripherals can support multiple configurations. Only
356 
one configuration will be active at any one time, and the host will
357 
switch between them as appropriate. If a peripheral does involve
358 
multiple configurations then typically it will be the responsibility
359 
of application code to <A
360 
HREF="usbs-control.html#AEN545"
361 
>handle</A
362 
> the standard
363 
set-configuration control message.</P
364 
></DIV
365 
><DIV
366 
CLASS="REFSECT2"
367 
><A
368 
NAME="AEN109"
369 
></A
370 
><H3
371 
><SPAN
372 
CLASS="STRUCTNAME"
373 
>usb_configuration_descriptor</SPAN
374 
></H3
375 
><P
376 
>A USB peripheral involves at least one and possible several different
377 
configurations. The <SPAN
378 
CLASS="STRUCTNAME"
379 
>usbs_enumeration_data</SPAN
380 
>
381 
structure requires a pointer to an array, possibly of length 1, of
382 
<SPAN
383 
CLASS="STRUCTNAME"
384 
>usb_configuration_descriptor</SPAN
385 
> structures.
386 
Usually a single structure suffices:</P
387 
><TABLE
388 
BORDER="0"
389 
BGCOLOR="#E0E0E0"
390 
WIDTH="100%"
391 
><TR
392 
><TD
393 
><PRE
394 
CLASS="PROGRAMLISTING"
395 
>const usb_configuration_descriptor usb_configuration = {
396 
    length:             USB_CONFIGURATION_DESCRIPTOR_LENGTH,
397 
    type:               USB_CONFIGURATION_DESCRIPTOR_TYPE,
398 
    total_length_lo:    USB_CONFIGURATION_DESCRIPTOR_TOTAL_LENGTH_LO(1, 2),
399 
    total_length_hi:    USB_CONFIGURATION_DESCRIPTOR_TOTAL_LENGTH_HI(1, 2),
400 
    number_interfaces:  1,
401 
    configuration_id:   1,
402 
    configuration_str:  0,
403 
    attributes:         USB_CONFIGURATION_DESCRIPTOR_ATTR_REQUIRED |
404 
                        USB_CONFIGURATION_DESCRIPTOR_ATTR_SELF_POWERED,
405 
    max_power:          50
406 
};
407 
 
408 
const usbs_enumeration_data usb_enum_data = {
409 
    &#8230;
410 
    configurations:             &amp;usb_configuration,
411 
    &#8230;
412 
};</PRE
413 
></TD
414 
></TR
415 
></TABLE
416 
><P
417 
>The values for the <TT
418 
CLASS="STRUCTFIELD"
419 
><I
420 
>length</I
421 
></TT
422 
> and
423 
<TT
424 
CLASS="STRUCTFIELD"
425 
><I
426 
>type</I
427 
></TT
428 
> fields are determined by the standard.
429 
The <TT
430 
CLASS="STRUCTFIELD"
431 
><I
432 
>total_length</I
433 
></TT
434 
> field depends on the
435 
number of interfaces and endpoints used by this configuration, and
436 
convenience macros are provided to calculate this: the first argument
437 
to the macros specify the number of interfaces, the second the number
438 
of endpoints. The <TT
439 
CLASS="STRUCTFIELD"
440 
><I
441 
>number_interfaces</I
442 
></TT
443 
> field
444 
is self-explanatory. If the peripheral involves multiple
445 
configurations then each one must have a unique id, and this will be
446 
used in the set-configuration control message. The id
447 
<TT
448 
CLASS="LITERAL"
449 
>0</TT
450 
> is reserved, and a set-configuration control
451 
message that uses this id indicates that the peripheral should be
452 
inactive. Configurations can have a string description if required.
453 
The <TT
454 
CLASS="STRUCTFIELD"
455 
><I
456 
>attributes</I
457 
></TT
458 
> field must have the
459 
<TT
460 
CLASS="LITERAL"
461 
>REQUIRED</TT
462 
> bit set; the
463 
<TT
464 
CLASS="LITERAL"
465 
>SELF_POWERED</TT
466 
> bit informs the host that the
467 
peripheral has its own power supply and will not draw any power over
468 
the bus, leaving more bus power available to other peripherals; the
469 
<TT
470 
CLASS="LITERAL"
471 
>REMOTE_WAKEUP</TT
472 
> bit is used if the peripheral can
473 
interrupt the host when the latter is in power-saving mode. For
474 
peripherals that are not self-powered, the
475 
<TT
476 
CLASS="STRUCTFIELD"
477 
><I
478 
>max_power</I
479 
></TT
480 
> field specifies the power
481 
requirements in units of 2mA.</P
482 
></DIV
483 
><DIV
484 
CLASS="REFSECT2"
485 
><A
486 
NAME="AEN127"
487 
></A
488 
><H3
489 
><SPAN
490 
CLASS="STRUCTNAME"
491 
>usb_interface_descriptor</SPAN
492 
></H3
493 
><P
494 
>A USB configuration involves one or more interfaces, typically
495 
corresponding to different streams of data. For example, one interface
496 
might involve video data while another interface is for audio.
497 
Multiple interfaces in a single configuration will be active at the
498 
same time.</P
499 
><TABLE
500 
BORDER="0"
501 
BGCOLOR="#E0E0E0"
502 
WIDTH="100%"
503 
><TR
504 
><TD
505 
><PRE
506 
CLASS="PROGRAMLISTING"
507 
>const usb_interface_descriptor usb_interface = {
508 
    length:             USB_INTERFACE_DESCRIPTOR_LENGTH,
509 
    type:               USB_INTERFACE_DESCRIPTOR_TYPE,
510 
    interface_id:       0,
511 
    alternate_setting:  0,
512 
    number_endpoints:   2,
513 
    interface_class:    USB_INTERFACE_DESCRIPTOR_CLASS_VENDOR,
514 
    interface_subclass: USB_INTERFACE_DESCRIPTOR_SUBCLASS_VENDOR,
515 
    interface_protocol: USB_INTERFACE_DESCRIPTOR_PROTOCOL_VENDOR,
516 
    interface_str:      0
517 
};
518 
 
519 
const usbs_enumeration_data usb_enum_data = {
520 
    &#8230;
521 
    total_number_interfaces:    1,
522 
    interfaces:                 &amp;usb_interface,
523 
    &#8230;
524 
};</PRE
525 
></TD
526 
></TR
527 
></TABLE
528 
><P
529 
>Again, the <TT
530 
CLASS="STRUCTFIELD"
531 
><I
532 
>length</I
533 
></TT
534 
> and
535 
<TT
536 
CLASS="STRUCTFIELD"
537 
><I
538 
>type</I
539 
></TT
540 
> fields are specified by the standard.
541 
Each interface within a configuration requires its own id. However, a
542 
given interface may have several alternate settings, in other words
543 
entries in the interfaces array with the same id but different
544 
<TT
545 
CLASS="STRUCTFIELD"
546 
><I
547 
>alternate_setting</I
548 
></TT
549 
> fields. For example,
550 
there might be one setting which requires a bandwidth of 100K/s and
551 
another setting that only needs 50K/s. The host can use the standard
552 
set-interface control message to choose the most appropriate setting.
553 
The handling of this request is the responsibility of higher-level
554 
code, so the application may have to <A
555 
HREF="usbs-control.html#AEN545"
556 
>install</A
557 
> its own handler.</P
558 
><P
559 
>The number of endpoints used by an interface is specified in the
560 
<TT
561 
CLASS="STRUCTFIELD"
562 
><I
563 
>number_endpoints</I
564 
></TT
565 
> field. Exact details of
566 
which endpoints are used is held in a separate array of endpoint
567 
descriptors. The class, subclass and protocol fields are used by
568 
host-side code to determine which host-side device driver should
569 
handle this specific interface. Usually this is determined on a
570 
per-peripheral basis in the
571 
<SPAN
572 
CLASS="STRUCTNAME"
573 
>usb_device_descriptor</SPAN
574 
> structure, but that can
575 
defer the details to individual interfaces. A per-interface string
576 
is allowed as well.</P
577 
><P
578 
>For USB peripherals involving multiple configurations, the array of
579 
<SPAN
580 
CLASS="STRUCTNAME"
581 
>usb_interface_descriptor</SPAN
582 
> structures should
583 
first contain all the interfaces for the first configuration, then all
584 
the interfaces for the second configuration, and so on.</P
585 
></DIV
586 
><DIV
587 
CLASS="REFSECT2"
588 
><A
589 
NAME="AEN142"
590 
></A
591 
><H3
592 
><SPAN
593 
CLASS="STRUCTNAME"
594 
>usb_endpoint_descriptor</SPAN
595 
></H3
596 
><P
597 
>The host also needs information about which endpoint should be used
598 
for what. This involves an array of endpoint descriptors:</P
599 
><TABLE
600 
BORDER="0"
601 
BGCOLOR="#E0E0E0"
602 
WIDTH="100%"
603 
><TR
604 
><TD
605 
><PRE
606 
CLASS="PROGRAMLISTING"
607 
>const usb_endpoint_descriptor usb_endpoints[] = {
608 
    {
609 
        length:         USB_ENDPOINT_DESCRIPTOR_LENGTH,
610 
        type:           USB_ENDPOINT_DESCRIPTOR_TYPE,
611 
        endpoint:       USB_ENDPOINT_DESCRIPTOR_ENDPOINT_OUT | 1,
612 
        attributes:     USB_ENDPOINT_DESCRIPTOR_ATTR_BULK,
613 
        max_packet_lo:  64,
614 
        max_packet_hi:  0,
615 
        interval:       0
616 
    },
617 
    {
618 
        length:         USB_ENDPOINT_DESCRIPTOR_LENGTH,
619 
        type:           USB_ENDPOINT_DESCRIPTOR_TYPE,
620 
        endpoint:       USB_ENDPOINT_DESCRIPTOR_ENDPOINT_IN | 2,
621 
        attributes:     USB_ENDPOINT_DESCRIPTOR_ATTR_BULK,
622 
        max_packet_lo:  64,
623 
        max_packet_hi:  0,
624 
        interval:       0
625 
    }
626 
};
627 
 
628 
const usbs_enumeration_data usb_enum_data = {
629 
    &#8230;
630 
    total_number_endpoints:     2,
631 
    endpoints:                  usb_endpoints,
632 
    &#8230;
633 
};</PRE
634 
></TD
635 
></TR
636 
></TABLE
637 
><P
638 
>As usual the values for the <TT
639 
CLASS="STRUCTFIELD"
640 
><I
641 
>length</I
642 
></TT
643 
> and
644 
<TT
645 
CLASS="STRUCTFIELD"
646 
><I
647 
>type</I
648 
></TT
649 
> fields are specified by the standard.
650 
The <TT
651 
CLASS="STRUCTFIELD"
652 
><I
653 
>endpoint</I
654 
></TT
655 
> 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 
<TT
660 
CLASS="STRUCTFIELD"
661 
><I
662 
>attributes</I
663 
></TT
664 
> field indicates the USB protocol
665 
that should be used on this endpoint: <TT
666 
CLASS="LITERAL"
667 
>CONTROL</TT
668 
>,
669 
<TT
670 
CLASS="LITERAL"
671 
>ISOCHRONOUS</TT
672 
>, <TT
673 
CLASS="LITERAL"
674 
>BULK</TT
675 
> or
676 
<TT
677 
CLASS="LITERAL"
678 
>INTERRUPT</TT
679 
>. The
680 
<TT
681 
CLASS="STRUCTFIELD"
682 
><I
683 
>max_packet</I
684 
></TT
685 
> field specifies the maximum size
686 
of a single USB packet. For bulk transfers this will typically be 64
687 
bytes. For isochronous transfers this can be up to 1023 bytes. For
688 
interrupt transfers it can be up to 64 bytes, although usually a
689 
smaller value will be used. The <TT
690 
CLASS="STRUCTFIELD"
691 
><I
692 
>interval</I
693 
></TT
694 
>
695 
field is ignored for control and bulk transfers. For isochronous
696 
transfers it should be set to 1. For interrupt transfers it can be a
697 
value between 1 and 255, and indicates the number of milliseconds
698 
between successive polling operations.</P
699 
><P
700 
>For USB peripherals involving multiple configurations or interfaces
701 
the array of endpoint descriptors should be organized sequentially:
702 
first the endpoints corresponding to the first interface of the first
703 
configuration, then the second interface in that configuration, and so
704 
on; then all the endpoints for all the interfaces in the second
705 
configuration; etc.</P
706 
></DIV
707 
><DIV
708 
CLASS="REFSECT2"
709 
><A
710 
NAME="AEN159"
711 
></A
712 
><H3
713 
>Strings</H3
714 
><P
715 
>The enumeration data can contain a number of strings with additional
716 
information. Unicode encoding is used for the strings, and it is
717 
possible for a peripheral to supply a given string in multiple
718 
languages using the appropriate characters. The first two bytes of
719 
each string give a length and type field. The first string is special;
720 
after the two bytes header it consists of an array of 2-byte language
721 
id codes, indicating the supported languages. The language code
722 
0x0409 corresponds to English (United States). </P
723 
><TABLE
724 
BORDER="0"
725 
BGCOLOR="#E0E0E0"
726 
WIDTH="100%"
727 
><TR
728 
><TD
729 
><PRE
730 
CLASS="PROGRAMLISTING"
731 
>const unsigned char* usb_strings[] = {
732 
    "\004\003\011\004",
733 
    "\020\003R\000e\000d\000 \000H\000a\000t\000"
734 
};
735 
 
736 
const usbs_enumeration_data usb_enum_data = {
737 
    &#8230;
738 
    total_number_strings:       2,
739 
    strings:                    usb_strings,
740 
    &#8230;
741 
};</PRE
742 
></TD
743 
></TR
744 
></TABLE
745 
><P
746 
>The default handler for standard control messages assumes that the
747 
peripheral only uses a single language. If this is not the case then
748 
higher-level code will have to handle the standard get-descriptor
749 
control messages when a string descriptor is requested.</P
750 
></DIV
751 
><DIV
752 
CLASS="REFSECT2"
753 
><A
754 
NAME="AEN164"
755 
></A
756 
><H3
757 
><SPAN
758 
CLASS="STRUCTNAME"
759 
>usbs_enumeration_data</SPAN
760 
></H3
761 
><P
762 
>The <SPAN
763 
CLASS="STRUCTNAME"
764 
>usbs_enumeration_data</SPAN
765 
> data structure
766 
collects together all the various descriptors that make up the
767 
enumeration data. It is the responsibility of application code to
768 
supply a suitable data structure and install it in the control
769 
endpoints's <TT
770 
CLASS="STRUCTFIELD"
771 
><I
772 
>enumeration_data</I
773 
></TT
774 
> field before
775 
the USB device is started.</P
776 
></DIV
777 
></DIV
778 
><DIV
779 
CLASS="NAVFOOTER"
780 
><HR
781 
ALIGN="LEFT"
782 
WIDTH="100%"><TABLE
783 
WIDTH="100%"
784 
BORDER="0"
785 
CELLPADDING="0"
786 
CELLSPACING="0"
787 
><TR
788 
><TD
789 
WIDTH="33%"
790 
ALIGN="left"
791 
VALIGN="top"
792 
><A
793 
HREF="usbs-intro.html"
794 
>Prev</A
795 
></TD
796 
><TD
797 
WIDTH="34%"
798 
ALIGN="center"
799 
VALIGN="top"
800 
><A
801 
HREF="io-usb-slave.html"
802 
>Home</A
803 
></TD
804 
><TD
805 
WIDTH="33%"
806 
ALIGN="right"
807 
VALIGN="top"
808 
><A
809 
HREF="usbs-start.html"
810 
>Next</A
811 
></TD
812 
></TR
813 
><TR
814 
><TD
815 
WIDTH="33%"
816 
ALIGN="left"
817 
VALIGN="top"
818 
>Introduction</TD
819 
><TD
820 
WIDTH="34%"
821 
ALIGN="center"
822 
VALIGN="top"
823 
>&nbsp;</TD
824 
><TD
825 
WIDTH="33%"
826 
ALIGN="right"
827 
VALIGN="top"
828 
>Starting up a USB Device</TD
829 
></TR
830 
></TABLE
831 
></DIV
832 
></BODY
833 
></HTML
834 
>

powered by: WebSVN 2.1.0

© copyright 1999-2024 OpenCores.org, equivalent to Oliscience, all rights reserved. OpenCores®, registered trademark.