1 |
ea1423e7
|
laforge
|
<section>
|
2 |
|
|
<title>USB Protocol</title>
|
3 |
|
|
<para>
|
4 |
|
|
The USB protocol is completely non-standard. Since OpenPICC is a very
|
5 |
|
|
special-purpose device, it's obvious that no standard USB protocol will be
|
6 |
|
|
applicable. However, our vendor-specific protocol is completely open and
|
7 |
|
|
documented to allow for development of interoperable applications.
|
8 |
|
|
</para>
|
9 |
|
|
|
10 |
|
|
<section>
|
11 |
|
|
<Title>USB Endpoints</title>
|
12 |
|
|
<para>
|
13 |
|
|
Since the SAM7 hardware only provides four USB endpoints, we have to use them
|
14 |
|
|
according to their endpoint type, rather than to their function within the
|
15 |
|
|
protocol. We have to overload and (de)multiplex within one endpoint quite a
|
16 |
|
|
bit.
|
17 |
|
|
</para>
|
18 |
|
|
<para>
|
19 |
|
|
EP0 - Control Endpoint
|
20 |
|
|
EP1 - Bulk Out endpoint (host -> device)
|
21 |
|
|
EP2 - Bulik In endpoint (device -> host)
|
22 |
|
|
EP3 - Interrupt In endpoint (device -> host)
|
23 |
|
|
</para>
|
24 |
|
|
<para>
|
25 |
|
|
The control endpoint behaves according to the USB specification. It only
|
26 |
|
|
takes care of usb configuration and management. No application data is
|
27 |
|
|
transferred over it.
|
28 |
|
|
</para>
|
29 |
|
|
</section> <!-- USB Endpoints -->
|
30 |
|
|
|
31 |
|
|
<section>
|
32 |
|
|
<title>USB packets, transfers</title>
|
33 |
|
|
<para>
|
34 |
|
|
In order to understand this devices' USB prootocol, some basics about any
|
35 |
|
|
communication with USB endpoints need to be known.
|
36 |
|
|
</para>
|
37 |
|
|
<para>
|
38 |
|
|
USB endpoints exchange a stream of data by means of USB transfers. Every
|
39 |
|
|
transfer is conveyed as multiple transaction. Every transaction transports
|
40 |
|
|
multiple USB packets. The Endpoint buffer size of the SAM7 usb device
|
41 |
|
|
controller is 64bytes for EP1, EP2 and EP3. Therefore, a single packet can be
|
42 |
|
|
up to 64 bytes in size. As soon as a packet smaller than the endpoint size
|
43 |
|
|
(64byte) is received, the end of that particular USB transfer is detected.
|
44 |
|
|
If the transfer size is an integral size of the endpoint size, a zero-length-packet (ZLP) is sent to explicitly signal the end of the transfer.
|
45 |
|
|
</para>
|
46 |
|
|
<para>
|
47 |
|
|
The buffer management inside the SAM7 firmware can deal with USB transfers of
|
48 |
|
|
up to 2048 bytes in size. To optimize memory efficiency, all buffers are
|
49 |
|
|
statically pre-allocated, and the majority of USB buffers is only 64bytes in
|
50 |
|
|
size. This way, the memory consumption for small transfers (such as register read/write transfers) can be kept low.
|
51 |
|
|
</para>
|
52 |
|
|
<para>
|
53 |
|
|
Large transfers (> 64 bytes, but &let; 2024 bytes) should be used only
|
54 |
|
|
when they are absolutely required.
|
55 |
|
|
</para>
|
56 |
|
|
</section> <!-- USB packets, transfers -->
|
57 |
|
|
|
58 |
|
|
<section>
|
59 |
|
|
<title>Host software interaction with USB Endpoints</title>
|
60 |
|
|
<para>
|
61 |
|
|
Any host software operating the USB device should take into consideration
|
62 |
|
|
that memory is a scarce resource on the SAM7, especially for
|
63 |
|
|
applications with relatively high speed compared to the USB 1.1 full speed bandwith), such as higher-bitrate 847kHz ISO14443 communication.
|
64 |
|
|
</para>
|
65 |
|
|
<para>
|
66 |
|
|
Therefore it is important to serve device requests on the BULK IN and
|
67 |
|
|
INTERRUPT IN endpoints as soon as possible. In most cases, the application
|
68 |
|
|
will simply keep those two pipes open all the time, by re-submitting an USB
|
69 |
|
|
request block as soon as the previous one at that endpiont has completed.
|
70 |
|
|
</para>
|
71 |
|
|
<para>
|
72 |
|
|
The BULK OUT endpoint will obviously only be filled with requests from the
|
73 |
|
|
host software when there are any such requests.
|
74 |
|
|
</para>
|
75 |
|
|
<para>
|
76 |
|
|
On the highest level of the protocol, there are three different classes of device requests:
|
77 |
|
|
</para>
|
78 |
|
|
<para>
|
79 |
|
|
1. uni-directional without high-level acknowledgement, such as a register
|
80 |
|
|
write without explicit request for a response. This means that the host
|
81 |
|
|
software will only send a single BULK OUT transfer. This transfer is
|
82 |
|
|
acknowledged inherently by the USB protocol, and the host software can be sure
|
83 |
|
|
that the transfer was correctly received by the device.
|
84 |
|
|
</para>
|
85 |
|
|
<para>
|
86 |
|
|
2. bi-directional with a single response, such as a register read. This means
|
87 |
|
|
that the host sends a single BULK OUT transfer, to which the device replies
|
88 |
|
|
with a single BULK IN transfer.
|
89 |
|
|
</para>
|
90 |
|
|
<para>
|
91 |
|
|
3. bi-directional with multiple responses. This means that even though the
|
92 |
|
|
host only sends a single BULK OUT transfer, there will be multiple BULK IN
|
93 |
|
|
transfers in response.
|
94 |
|
|
</para>
|
95 |
|
|
</section> <!-- Host software interaction -->
|
96 |
|
|
|
97 |
|
|
<section>
|
98 |
|
|
<title>The usb transfer header</title>
|
99 |
|
|
<para>
|
100 |
|
|
Application data transferred over EP1, EP2 and EP3 is prefixed with a
|
101 |
|
|
four-byte header, 'struct openpcd_hdr'.
|
102 |
|
|
</para>
|
103 |
|
|
<para>
|
104 |
|
|
The first byte is the command byte. The high nibble of the command byte
|
105 |
|
|
specifies the command class, whereas the the low nibble selects the particular
|
106 |
|
|
command within a given class.
|
107 |
|
|
</para>
|
108 |
|
|
<para>
|
109 |
|
|
The second byte specifies flags. There are currently two flags:
|
110 |
|
|
</para>
|
111 |
|
|
<para>
|
112 |
|
|
The RESPOND flag signifies that the sender of this transfer explicitly
|
113 |
|
|
requests a response back from the other side.
|
114 |
|
|
</para>
|
115 |
|
|
<para>
|
116 |
|
|
The ERROR flag signifies that this transfer indicates some error
|
117 |
|
|
</para>
|
118 |
|
|
<para>
|
119 |
|
|
The MULTIPLE flag signifies that this is part of a response that consists of
|
120 |
|
|
multiple transfers.
|
121 |
|
|
</para>
|
122 |
|
|
<para>
|
123 |
|
|
The LAST flag signifies that the current transfer is the last transfer
|
124 |
|
|
of a multiple-transfer response.
|
125 |
|
|
</para>
|
126 |
|
|
<para>
|
127 |
|
|
The third byte is called 'register' for historical purpose. It should
|
128 |
|
|
actually rather be called address or index. Its significance differs
|
129 |
|
|
according to the actual command that is being performed.
|
130 |
|
|
</para>
|
131 |
|
|
<para>
|
132 |
|
|
The fourth byte is called 'val' for 'value'. Again, its purpose is command
|
133 |
|
|
specific. In case of e.g. a register write, it is the value to be written
|
134 |
|
|
into the register.
|
135 |
|
|
</para>
|
136 |
|
|
</section> <!-- USB Transfer Header -->
|
137 |
|
|
|
138 |
|
|
<section>
|
139 |
|
|
<title>The individual USB protocol commands</title>
|
140 |
|
|
|
141 |
|
|
<section>
|
142 |
|
|
<title>Generic USB commands: CMD_CLS_GENERIC</title>
|
143 |
|
|
|
144 |
|
|
<section>
|
145 |
|
|
<title>CMD_GET_VERSION</title>
|
146 |
|
|
<para>
|
147 |
|
|
This command is used to obtain the version number of the USB device. This
|
148 |
|
|
might be used to differentiate different hardware revisions by the host software.
|
149 |
|
|
</para>
|
150 |
|
|
<para>
|
151 |
|
|
The response to this command contains the version number in the
|
152 |
|
|
variable-length 'data' section of the transfer.
|
153 |
|
|
</para>
|
154 |
|
|
</section>
|
155 |
|
|
|
156 |
|
|
<section>
|
157 |
|
|
<title>CMD_SET_LED</title>
|
158 |
|
|
<para>
|
159 |
|
|
Using this command, the host software can control the LED's present in the
|
160 |
|
|
OpenPICC. The LED can be specified in the 'reg' section of the header.
|
161 |
|
|
Currently there are two LED's, LED 1 (green) and LED 2 (red). The 'val'
|
162 |
|
|
header field controls whether the LED should be switched on (1) or off (0).
|
163 |
|
|
</para>
|
164 |
|
|
</section>
|
165 |
|
|
|
166 |
|
|
<section>
|
167 |
|
|
<title>CMD_GET_SERIAL</title>
|
168 |
|
|
<para>
|
169 |
|
|
This command is used to obtain the serial number of the OpenPICC device.
|
170 |
|
|
The serial number is returned in the 'data' section of the response transfer.
|
171 |
|
|
</para>
|
172 |
|
|
</section>
|
173 |
|
|
|
174 |
|
|
</section> <!-- Generic USB commands -->
|
175 |
|
|
|
176 |
|
|
<section>
|
177 |
|
|
<title>USB Testing commands</title>
|
178 |
|
|
<section>
|
179 |
|
|
<title>CMD_USBTEST_IN</title>
|
180 |
|
|
<para>
|
181 |
|
|
</para>
|
182 |
|
|
</section>
|
183 |
|
|
<section>
|
184 |
|
|
<title>CMD_USBTEST_OUT</title>
|
185 |
|
|
<para>
|
186 |
|
|
</para>
|
187 |
|
|
</section>
|
188 |
|
|
</section> <!-- USB testing commands -->
|
189 |
|
|
|