Specifications

8
8
Packet Identifiers (PID)
 The PID signals to the receiver that what the packet structure and content will be
and how the receiver has to respond
0010b
1010b
1110b
ACK
NAK
STALL
Handshake
0011b
1011b
DATA0
DATA1
Data
0001b
1001b
0101b
1101b
OUT
IN
SOF
SETUP
Token
PID Value <3:0>PID NamePID Type
PID - indicates transaction type and has different
meaning based on the transaction. Lower nibble is the
inversion of the upper nibble provided for error
checking.
Data – any information for the application
Handshake – status information
Start of Frame Marker (SOF) – Host can send this
marker at 1 mS intervals as a time base for peripherals
PID0 PID1 PID2 PID3 PID0 PID1 PID2 PID3
PID Format
IN – data transfers to the host
OUT – data transfers from the host
SOF – Timing marker at 1mS
Setup – Specifies control transfers
Data0 – data transfer with data toggle clear
Data1 – data transfer with data toggle set
ACK – data received without error
NAK – Device busy or no data available
Stall – Unsupported control request, control
request failed, or endpoint failed
Here we see the Packet Identifier (PID) structure. Be aware that “PID” is used for
two different things in USB (the second reference we will discuss later). The PID
we refer to here is what is sent out on the USB to define the transaction type. An
example PID, the Start of Frame (SOF) PID, is sent to provide a 1ms time base and
tells the receiving devices that the frame number associated with the current 1ms
timer marker follows the PID. The Data PID tells the system that the data for the
associated transfer is located in this transaction. Remember in USB the host always
initiates the transfer and data direction is with respect to the host. IN transfers data
from a peripheral device to the host. OUT transfers data from the host to the device.
From the table we can see that there are separate PID values associated with each of
the transaction types, IN or OUT and we can write the firmware to respond
accordingly based on the token that we receive. Do we need to be concerned with
the PID at the firmware level? No, as the hardware engine manages moving the
data between the FIFOs and the USB.
We mentioned the that the host in a USB system is responsible for power
management. The host sends the SOF every 1ms as mentioned. Devices are
required to enter a Suspend state after 3mS of inactivity per the USB specification.
Since there is constant activity on the bus when sending SOF PIDs, the peripheral
devices will stay out of suspend mode as the spec states that there is a 3mS
inactivity window before peripherals should enter suspend.
The Setup transaction specifies a control transfer. Control transfers MUST be
supported by all devices and their functions are defined by the USB spec. With
these, the host can gather data about the endpoint, set addresses etc. We get into
control transfers in detail later in the class.