1 General Overview

1.1 USB Background

USB History

Universal Serial Bus (USB) is a standard interface for connecting peripheral devices to a host computer. The USB system was originally devised by a group of companies including Compaq, Digital Equipment, IBM, Intel, Microsoft, and Northern Telecom to replace the existing mixed connector system with a simpler architecture.

USB was designed to replace the multitude of cables and connectors required to connect peripheral devices to a host computer. The main goal of USB was to make the addition of peripheral devices quick and easy. All USB devices share some key characteristics to make this possible. All USB devices are self-identifying on the bus. All devices are hot-pluggable to allow for true Plug’n’Play capability. Additionally, some devices can draw power from the USB which eliminates the need for extra power adapters.

To ensure maximum interoperability the USB standard defines all aspects of the USB system from the physical layer (mechanical and electrical) all the way up to the software layer. The USB standard is maintained and enforced by the USB Implementer’s Forum (USB-IF). USB devices must pass a USB-IF compliance test in order to be considered in compliance and to be able to use the USB logo.

The USB standard specifies different flavors of USB: low-speed, full-speed and high-speed. USB-IF has also released additional specs that expand the breadth of USB. These are On-The-Go (OTG) and Wireless USB. Although beyond the scope of this document, details on these specs can be found on the USB-IF website.

The key difference between low, full, and high speed is bandwidth.

Low	1.5 Mbps
Full	12 Mbps
High	480 Mbps

The USB specification can be viewed and downloaded on the USB-IF website.

Architectural Overview

USB is a host-scheduled, token-based serial bus protocol. USB allows for the connection of up to 127 devices on a single USB host controller. A host PC can have multiple host controllers which increases the maximum number of USB devices that can be connected to a single computer.

Devices can be connected and disconnected at will. The host PC is responsible for installing and uninstalling drivers for the USB devices on an as-needed basis.

A single USB system comprises of a USB host and one or more USB devices. There can also be zero or more USB hubs in the system. A USB hub is special class of device. The hub allows the connection of multiple downstream devices to an upstream host or hub. In this way, the number of devices that can be physically connected to a computer can be increased.

A USB device is a peripheral device that connects to the host PC. The range of functionality of USB devices is ever increasing. The device can support either one function or many functions. For example a single multi-function printer may present several devices to the host when it is connected via USB. It can present a printer device, a scanner device, a fax device, etc.

All the devices on a single USB must share the bandwidth that is available on the bus. It is possible for a host PC to have multiple buses which would all have their own separate bandwidth. Most often, the ports on most motherboards are paired, such that each bus has two downstream ports.

The USB has a tiered star topology (Figure 1). At the root tier is the USB host. All devices connect to the host either directly or via a hub. According to the USB spec, a USB host can only support a maximum of seven tiers.

USB works through a unidirectional broadcast system. When a host sends a packet, all downstream devices will see that traffic. If the host wishes to communicate with a specific device, it must include the address of the device in the token packet. Upstream traffic (the response from devices) are only seen by the host or hubs that are directly on the return path to the host.

There are, however, a few caveats when dealing with devices that are of different speeds. Low-speed and high-speed devices are isolated from traffic at speeds other then their own. They will only see traffic that is at their respective speeds. Referring to Figure 2, this means that downstream traffic to device H1 will be seen by device H2 (and vice versa). Also, downstream traffic to device L1 will be seen by L2 (and vice versa). However, full-speed devices can see traffic at its own speed, as well as low-speed traffic, using a special signaling mode dubbed low-speed-over-full-speed. This means that downstream traffic to F1 will be seen by F2 (and vice versa) with standard full-speed signaling, and downstream traffic to either L1 or L2 will also be seen by both F1 and F2 through the special low-speed-over-full-speed signaling.

Theory of Operations

This introduction is a general summary of the USB spec. Total Phase strongly recommends that developers consult the USB specification on the USB-IF website for detailed and up-to-date information.

USB Connectors

USB cables have two different types of connectors: “A” and “B”. “A” type connectors connect towards the host or upstream direction. “B” connectors connect to downstream devices, though many devices have captive cables eliminating the need for “B” connectors. The “A” and “B” connectors are defined in the USB spec to prevent loopbacks in the bus. This prevents a host from being connected to a host, or conversely a device to a device. It also helps enforce the tiered star topology of the bus. USB hubs have one “B” port and multiple “A” ports which makes it clear which port connects to the host and which to downstream devices.

The USB spec has been expanded to include Mini-A and Mini-B connectors to support small USB devices. The USB On-The-Go (OTG) spec has introduced the Micro-A plug, Micro-B plug and receptacle, and the Micro-AB receptacle to allow for device-to-device connections. (The previous Mini-A plug and Mini-AB receptacle have now been deprecated.)

USB Signaling

All USB devices are connected by a four wire USB cable. These four lines are V, GND and the twisted pair: D+ and D-. USB uses differential signaling on the two data lines. There are four possible digital line states that the bus can be in: single-ended zero (SE0), single-ended one (SE1), J, and K. The single-ended line states are defined the same regardless of the speed. However, the definitions of the J and K line states change depending on the bus speed. Their definitions are described in Table 1. All data is transmitted through the J and K line states. An SE1 condition should never be seen on the bus, except for allowances during transitions between the other line states.

The actual data on the bus is encoded through the line states by a nonreturn-to-zero-inverted (NRZI) digital signal. In NRZI encoding, a digital 1 is represented by no change in the line state and a digital 0 is represented as a change of the line state. Thus, every time a 0 is transmitted the line state will change from J to K, or vice versa. However, if a 1 is being sent the line state will remain the same.

USB has no synchronizing clock line between the host and device. However, the receiver can resynchronize whenever a valid transition is seen on the bus. This is possible provided that a transition in the line state is guaranteed within a fixed period of time determined by the allowable clock skew between the receiver and transmitter. To ensure that a transition is seen on the bus within the required time, USB employs bit stuffing. After 6 consecutive 1s in a data stream (i.e. no transitions on the D+ and D- lines for 6 clock periods), a 0 is inserted to force a transition of the line states. This is performed regardless of whether the next bit would have induced a transition or not. The receiver, expecting the bit stuff, automatically removes the 0 from the data stream.

Bus Speed

The bus speed determines the rate at which bits are sent across the bus. There are currently three speeds at which wired USB operates: low-speed (1.5 Mbps), full-speed (12 Mbps), and high-speed (480 Mbps). In order to determine the bus speed of a full-speed or low-speed device, the host must simply look at the idle state of the bus. Full-speed devices have a pull-up resistor on the D+ line, whereas low-speed devices have a pull-up resistor on the D- line. Therefore, if the D+ line is high when idle, then full-speed connectivity is established. If the D- line is high when idle, then low-speed connectivity is in effect. A full-speed device does not have to be capable of running at low-speed, and vice versa. A full-speed host or hub, however, must be capable of communicating with both full-speed and low-speed devices.

With the introduction of high-speed USB, high-speed hosts and hubs must be able to communicate with devices of all speeds. Additionally, high-speed devices must be backward compatible for communication at full-speed with legacy hosts and hubs. To facilitate this, all high-speed hosts and devices initially operate at full-speed and a high-speed handshake must take place before a high-speed capable device and a high-speed capable host can begin operating at high-speed. The handshake begins when a high-speed capable host sees a full-speed device attached. Because high-speed devices must initially operate at full-speed when first connected, they must pull the D+ line high to identify as a full-speed device. The host will then issue a reset on the bus and wait to see if the device responds with a Chirp K, which identifies the device as being high-speed capable. If the host does not receive a Chirp K, it quits the high-speed handshake sequence and continues with normal full-speed operation. However, if the host receives a Chirp K, it responds to the device with alternating pairs of Chirp K’s and Chirp J’s to tell the device that the host is high-speed capable. Upon recognizing these alternating pairs, the device switches to high-speed operation and disconnects its pull-up resistor on the D+ line. The high-speed connection is now established and both the host and the device begin communicating at high-speed. See the USB specification for more details on the high-speed handshake.

To accommodate high-speed data-rates and avoid transceiver confusion, the signaling levels of high-speed communication is much lower than that of full and low-speed devices. Full and low-speed devices operate with a logical high level of 3.3 V on the D+ and D- lines. For high-speed operation, signaling levels on the D+ and D- lines are reduced to 400 mV. Because the high-speed signaling levels are so low, full and low-speed transceivers are not capable of seeing high-speed traffic.

To accommodate the high-speed signaling levels and speeds, both hosts and devices use termination resistors. In addition, during the high-speed handshake, the device must release its full-speed pull-up resistor. But during the high-speed handshake, often times the host will activate its termination resistors before the device releases its full-speed pull-up resistor. In these situations the host may not be able to pull the D+ line below the threshold level of its high-speed receivers. This may cause the host to see a spurious Chirp J (dubbed a Tiny J) on the lines. This is an artifact on the bus due to the voltage divider effect between the device’s 1.5 Kohm pull-up resistor and the host’s 45 ohm termination resistor. Hosts and devices must be robust against this situation. Once the device has switched to high-speed operation the Tiny J will no longer be present, since the device will have released its pull-up resistor.

Endpoints and Pipes

The endpoint is the fundamental unit of communication in USB. All data is transferred through virtual pipes between the host and these endpoints. All communication between a USB host and a USB device is addressed to a specific endpoint on the device. Each device endpoint is a unidirectional receiver or transmitter of data; either specified as a sender or receiver of data from the host.

A pipe represents a data pathway between the host and the device. A pipe may be unidirectional (consisting of only one endpoint) or bidirectional (consisting of two endpoints in opposite directions).

A special pipe is the Default Control Pipe. It consists of both the input and output endpoints 0. It is required on all devices and must be available immediately after the device is powered. The host uses this pipe to identify the device and its endpoints and to configure the device.

Endpoints are not all the same. Endpoints specify their bandwidth requirements and the way that they transfer data. There are four transfer types for endpoints:

Control

Non-periodic transfers. Typically, used for device configuration, commands, and status operation.

Interrupt

This is a transaction that is guaranteed to occur within a certain time interval. The device will specify the time interval at which the host should check the device to see if there is new data. This is used by input devices such as mice and keyboards.

Isochronous

Periodic and continuous transfer for time-sensitive data. There is no error checking or retransmission of the data sent in these packets. This is used for devices that need to reserve bandwidth and have a high tolerance to errors. Examples include multimedia devices for audio and video.

Bulk

General transfer scheme for large amounts of data. This is for contexts where it is more important that the data is transmitted without errors than for the data to arrive in a timely manner. Bulk transfers have the lowest priority. If the bus is busy with other transfers, this transaction may be delayed. The data is guaranteed to arrive without error. If an error is detected in the CRCs, the data will be retransmitted. Examples of this type of transfer are files from a mass storage device or the output from a scanner.

USB Packets

All USB packets are prefaced by a SYNC field and then a Packet Identifier (PID) byte. Packets are terminated with an End-of-Packet (EOP).

The SYNC field, which is a sequence of KJ pairs followed by 2 K’s on the data lines, serves as a Start of Packet (SOP) marker and is used to synchronize the device’s transceiver with that of the host. This SYNC field is 8 bits long for full/low-speed and 32 bits long for high speed.

The EOP field varies depending on the bus speed. For low- or full-speed buses, the EOP consists of an SE0 for two bit times. For high-speed buses, because the bus is at SE0 when it is idle, a different method is used to indicate the end of the packet. For high-speed, the transmitter induces a bit stuff error to indicate the end of the packet. So if the line state before the EOP is J, the transmitter will send 8-bits of K. The exception to this is the high-speed SOF EOP, in which case the high-speed EOP is extended to 40-bits long. This is done for bus disconnect detection.

The PID is the first byte of valid data sent across the bus, and it encodes the packet type. The PID may be followed by anywhere from 0 to 1026 bytes, depending on the packet type. The PID byte is self-checking; in order for the PID to be valid, the last 4 bits must be a one’s complement of the first 4 bits. If a received PID fails its check, the remainder of the packet will be ignored by the USB device.

There are four types of PID which are described in Table 2.

The format of the IN, OUT, and SETUP Token packets is shown in figure 4. The format of the SOF packet is shown in figure 5. The format of the Data packets is shown in figure 6. Lastly, the format of the Handshake packets is shown in Figure 7.

Data Transactions

Data transactions occur in three phases: Token, Data, and Handshake.

All communication on the USB is host-directed. In the Token phase, the host will generate a Token packet which will address a specific device/endpoint combination. A Token packet can be IN, OUT, or SETUP.

IN	The host is requesting data from the addressed dev/ep.
OUT	The host is sending data to the addressed dev/ep.
SETUP	The host is transmitting control information to the device.

In the data phase, the transmitter will send one data packet. For IN requests, the device may send a NAK or STALL packet during the data phase to indicate that it isn’t able to service the token that it received.

Finally, in the Handshake phase the receiver can send an ACK, NAK, or STALL indicating the success or failure of the transaction.

All of the transfers described above follow this general scheme with the exception of the Isochronous transfer. In this case, no Handshake phase occurs because it is more important to stream data out in a timely fashion. It is acceptable to drop packets occasionally and there is no need to waste time by attempting to retransmit those particular packets.

Polling Transactions

It is possible that when a host requests data or sends data that the device will not be able to service the request. This could occur if the device has no new information to provide the host or is perhaps too busy to send/receive any data. In these situations the device will NAK the host. If the data transfer is a Control or Bulk transfer, the host will retry the transaction. However, if it is Isochronous or Interrupt transfer, it will not retry the transaction.

On a full or low-speed bus, if the transaction is repeated, it is repeated in its entirety. This is true regardless of the direction of the data transfer. If the host is requesting information, it will continue to send IN tokens until the device sends data. Until then, the device responds with a NAK, leading to the multitude of IN+NAK pairs that are commonly encountered on a bus. This does not have much consequence as an IN token is only 3 bytes and the NAK is only 1 byte. However, if the host is transmitting data there is the potential for graver consequences. For example, if the host attempted to send 64 bytes of data to a device, but the device responded with a NAK, the host will retry the entire data transaction. This requires sending the entire 64-byte data payload repeatedly until the device responds with an ACK. This has the potential to waste a significant amount of bandwidth. It is for this reason that high-speed hosts have an additional feature when the device signals the inability to accept any more data.

When a high-speed host receives a NAK after transmitting data, instead of retransmitting the entire transaction, it simply sends a 3 byte PING token to poll the device and endpoint in question. (Alternatively, if the device responds to the OUT+DATA with a NYET handshake, it means that the device accepted the data in the current transaction but is not ready to accept additional data, and the host should PING the device before transmitting more data.) The host will continue to PING the device until it responds with an ACK, which indicates to the host that it is ready to receive information. At that point, the host will transmit a packet in its entirety.

Hub Transactions

Hubs make it possible to expand the number of possible devices that can be attached to a single host. There are two types of hubs that are commercially available for wired USB: full-speed hubs and high-speed hubs. Both types of hubs have mechanisms for dealing with downstream devices that are not of their speed.

Full-speed hubs can, at most, transmit at 12 Mbps. This means that all high-speed devices that are plugged into a full-speed hub are automatically downgraded to full-speed data rates. On the other hand, low-speed devices are not upgraded to full-speed data rates. In order to send data to low-speed devices, the hub must actually pass slower moving data signals to those devices. The host (or high-speed hub) is the one that generates these slower moving signals on the full-speed bus. Ordinarily the low-speed ports on the hub are quiet. When a low-speed packet needs to be sent downstream, it is prefaced with a PRE PID. This opens up the low-speed ports. Note that the PRE is sent at full-speed data rates, but the following transaction is transmitted at low-speed data rates.

High-speed hubs only communicate at 480 Mbps with high-speed host. They do not downgrade the link between the host and hub to slower speeds. However, high-speed hubs must still deal with slower devices being downstream of them. High-speed hubs do not use the same mechanism as full-speed hubs. There would be a tremendous cost on bandwidth to other high-speed devices on the bus if low-speed or full-speed signaling rates were used between the host and the hub of interest. Thus, in order to save bandwidth, high-speed hosts do not send the PRE token to high-speed hubs, but rather a SPLIT token. The SPLIT token is similar to the PRE in that it indicates to a hub that the following transaction is for a slower speed device, however the data following the SPLIT is transmitted to the hub at high-speed data rates and does not choke the high-speed bus.

Although all SPLIT transactions have the same PID, there are two over-arching types of SPLITs: Start SPLITs (SSPLIT) and Complete SPLITs (CSPLIT). SSPLITs are only used the first time that the host wishes to send a given transaction to the device. Following that, it polls the hub for the device’s response with CSPLITs. The hub may respond many times with NYET before supplying the host with the device’s response. Once this transaction is complete, it will begin the next hub transaction with an SSPLIT. Figure 9 illustrates an example of hub transaction.

Start-of-Frame Transactions

Start-of-Frame (SOF) transactions are issued by the host at precisely timed intervals. These tokens do not cause any device to respond, and can be used by devices for timing reasons. The SOF provides two pieces of timing information. Because of the precisely timed intervals of SOFs, when a device detects an SOF it knows that the interval time has passed. All SOFs also include a frame number. This is an 11-bit value that is incremented on every new frame.

SOFs are also used to keep devices from going into suspend. Devices will go into suspend if they see an idle bus for an extended period of time. By providing SOFs, the host is issuing traffic on the bus and keeping devices from entering their suspended state.

Full-speed hosts will send 1 SOF every millisecond. High-speed hosts divide the frame into 8 microframes, and send an SOF at each microframe (i.e., every 125 microseconds). However, the high-speed hub will only increment the frame number after an entire frame has passed. Therefore, a high-speed host will repeat the same frame number 8 times before incrementing it.

Low-speed devices are never issued SOFs as it would require too much bandwidth on an already slower-speed bus. Instead, to keep low-speed devices from going into suspend, hosts will issue a keep-alive every millisecond. These keep-alives are short SE0 events on the bus that last for approximately 1.33 microseconds. They are not interpreted as valid data, and have no associated PID.

Extended Token Transactions

The new Link Power Management addendum to the USB 2.0 Specification has expanded the number of PIDs through the use of the previously reserved PID, 0xF0. The extended token format is a two phase transaction that begins with a standard token packet that has the EXT PID. Following this packet is the extended token packet, which takes a similar form. It begins with an 8-bit SubPID and ends with a 5-bit CRC, however the 11 remaining bits in the middle will have different meaning depending on the type of SubPID.

Following this token phase, the device will respond with the appropriate data or handshake, depending on the protocol associated with that SubPID. Currently, the only defined SubPID is for link power management (LPM). For more details, please refer to the Link Power Management addendum.

Enumeration and Descriptors

When a device is plugged into a host PC, the device undergoes Enumeration. This means that the host recognizes the presence of the device and assigns it a unique 7-bit device address. The host PC then queries the device for its descriptors, which contains information about the specific device. There are various types of descriptors as outlined below.

• Device Descriptor: Each USB device can only have a single Device Descriptor. This descriptor contains information that applies globally to the device, such as serial number, vendor ID, product ID, etc. The device descriptor also has information about the device class. The host PC can use this information to help determine what driver to load for the device.

• Configuration Descriptor: A device descriptor can have one or more configuration descriptors. Each of these descriptors defines how the device is powered (e.g. bus powered or self powered), the maximum power consumption, and what interfaces are available in this particular setup. The host can choose whether to read just the configuration descriptor or the entire hierarchy (configuration, interfaces, and alternate interfaces) at once.

• Interface Descriptor: A configuration descriptor defines one or more interface descriptors. Each interface number can be subdivided into multiple alternate interfaces that help more finely modify the characteristics of a device. The host PC selects particular alternate interface depending on what functions it wishes to access. The interface also has class information which the host PC can use to determine what driver to use.

• Endpoint Descriptor: An interface descriptor defines one or more endpoints. The endpoint descriptor is the last leaf in the configuration hierarchy and it defines the bandwidth requirements, transfer type, and transfer direction of an endpoint. For transfer direction, an endpoint is either a source (IN) or sink (OUT) of the USB device.

• String Descriptor: Some of the configuration descriptors mentioned above can include a string descriptor index number. The host PC can then request the unicode encoded string for a specified index. This provides the host with human readable information about the device, including strings for manufacturer name, product name, and serial number.

Device Class

USB devices vary greatly in terms of function and communication requirements. Some devices are single-purpose, such as a mouse or keyboard. Other devices may have multiple functionalities that are accessible via USB such as a printer/scanner/fax device.

The USB-IF Device Working Group defines a discreet number of device classes. The idea was to simplify software development by specifying a minimum set of functionality and characteristics that is shared by a group of devices and interfaces. Devices of the same class can all use the same USB driver. This greatly simplifies the use of USB devices and saves the end-user the time and hassle of installing a driver for every single USB device that is connected to their host PC.

For example, input devices such as mice, keyboards and joysticks are all part of the HID (Human Interface Device) class. Another example is the Mass Storage class which covers removable hard drives and keychain flash disks. All of these devices use the same Mass Storage driver which simplifies their use.

However, a device does not necessarily need to belong to a specific device class. In these cases, the USB device will require its own USB driver that the host PC must load to make the functionality available to the host.

On-The-Go (OTG)

The OTG supplement to the USB 2.0 spec provides methods for mobile devices to communicate with each other, actively switch the role of host and device, and also request sessions from each other when power to the USB is removed.

The initial role of host and device is determined entirely by the USB connector itself. All OTG capable peripherals will have a 5-pin Micro-AB receptacle which can receive either the Micro-A or Micro-B plug. If the peripheral receives the Micro-A plug, then it behaves as the host. If it receives the Micro-B plug, then it behaves as the device. However, there may be certain situations where a peripheral received the Micro-B plug, but needs to behave as the host. Rather than request that the user swap the cable orientation, the two peripherals have the ability to swap the roles of host and device through the Host Negotiation Protocol (HNP).

The HNP begins when the A-device finishes using the bus and stops all bus activity. The B-device detects this and will release its pull-up resistor. When the A-device detects the SE0, it responds by activating its pull-up. Once the B-device detects this condition, the B-device issues reset and begins standard USB communication as the host.

In order to conserve power, A-devices are allowed to stop providing power to the USB. However, there could be situations where the B-device wants to use the bus and V is turned off. It is for this reason that the OTG supplement describes a method for allowing the B-device to request a session from the A-device. Upon successful completion of the Session Request Protocol (SRP), the A-device will power the bus and continue standard USB transactions.

The SRP is broken up into two stages. From a disconnected state, the B-device must begin an SRP by driving one of its data lines high for a sufficient duration. This is called data-line pulsing. If the A-device does not respond to this, the B-device will drive the V above a specified threshold and release it, thereby completing V pulsing. If the A-device still does not begin a session, the B-device may start the SRP over again, provided the correct initial conditions are met.

For more details on OTG, please see the On-The-Go Supplement to the USB 2.0 Specification.

References

• USB Implementers’ Forum

1.2 I2C Background

I2C History

When connecting multiple devices to a microcontroller, the address and data lines of each devices were conventionally connected individually. This would take up precious pins on the microcontroller, result in a lot of traces on the PCB, and require more components to connect everything together. This made these systems expensive to produce and susceptible to interference and noise.

To solve this problem, Philips developed Inter-IC bus, or I2C, in the 1980s. I2C is a low-bandwidth, short distance protocol for on board communications. All devices are connected through two wires: serial data (SDA) and serial clock (SCL).

Because all commnication takes place on only two wires, all devices must have a unique address to identify it on the bus. Slave devices have a predefined address, but the lower bits of the address can be assigned to allow for multiples of the same devices on the bus.

I2C Theory of Operation

I2C has a master/slave protocol. The master initiates the communication. Here is a simplified description of the protocol. For precise details, please refer to the Philips I2C specification. The sequence of events are as follows:

1. The master device issues a start condition. This condition informs all the slave devices to listen on the serial data line for their respective address.

2. The master device sends the address of the target slave device and a read/write flag.

3. The slave device with the matching address responds with an acknowledgment signal.

4. Communication proceeds between the master and the slave on the data bus. Both the master and slave can receive or transmit data depending on whether the communication is a read or write. The transmitter sends 8 bits of data to the receiver, which replies with a 1 bit acknowledgment.

5. When the communication is complete, the master issues a stop condition indicating that everything is done.

Figure 13 shows a sample bitstream of the I2C protocol.

I2C Features

I2C has many features other important features worth mentioning. It supports multiple data speeds: standard (100 kbps), fast (400 kbps) and high speed (3.4 Mbps) communications.

Other features include:

• Built in collision detection,

• 10-bit Addressing,

• Multi-master support,

• Data broadcast (general call).

For more information about other features, see the references at the end of this section.

I2C Benefits and Drawbacks

Since only two wires are required, I2C is well suited for boards with many devices connected on the bus. This helps reduce the cost and complexity of the circuit as additional devices are added to the system.

Due to the presence of only two wires, there is additional complexity in handling the overhead of addressing and acknowledgments. This can be inefficient in simple configurations and a direct-link interface such as SPI might be preferred.

I2C References

• I2C bus – NXP (Philips) Semiconductors Official I2C website

• I2C (Inter-Integrated Circuit) Bus Technical Overview and Frequently Asked Questions – Embedded Systems Academy

• Introduction to I2C  – Embedded.com

• I2C  – Open Directory Project Listing

1.3 SPI Background

SPI History

SPI is a serial communication bus developed by Motorola. It is a full-duplex protocol which functions on a master-slave paradigm that is ideally suited to data streaming applications.

SPI Theory of Operation

SPI requires four signals: clock (SCLK), master output/slave input (MOSI), master input/slave output (MISO), slave select (SS).

Three signals are shared by all devices on the SPI bus: SCLK, MOSI and MISO. SCLK is generated by the master device and is used for synchronization. MOSI and MISO are the data lines. The direction of transfer is indicated by their names. Data is always transferred in both directions in SPI, but an SPI device interested in only transmitting data can choose to ignore the receive bytes. Likewise, a device only interested in the incoming bytes can transmit dummy bytes.

Each device has its own SS line. The master pulls low on a slave’s SS line to select a device for communication.

The exchange itself has no pre-defined protocol. This makes it ideal for data-streaming applications. Data can be transferred at high speed, often into the range of the tens of megahertz. The flipside is that there is no acknowledgment, no flow control, and the master may not even be aware of the slave’s presence.

SPI Modes

Although there is no protocol, the master and slave need to agree about the data frame for the exchange. The data frame is described by two parameters: clock polarity (CPOL) and clock phase (CPHA). Both parameters have two states which results in four possible combinations. These combinations are shown in Figure 15.

SPI Benefits and Drawbacks

SPI is a very simple communication protocol. It does not have a specific high-level protocol which means that there is almost no overhead. Data can be shifted at very high rates in full duplex. This makes it very simple and efficient in a single master single slave scenario.

Because each slave needs its own SS, the number of traces required is n+3, where n is the number of SPI devices. This means increased board complexity when the number of slaves is increased.

SPI References

• Introduction to Serial Peripheral Interface – Embedded.com

• SPI – Serial Peripheral Interface

1.4 MDIO Background

MDIO History

Management Data Input/Output, or MDIO, is a 2-wire serial bus that is used to manage PHYs or physical layer devices in media access controllers (MACs) in Gigabit Ethernet equipment. The management of these PHYs is based on the access and modification of their various registers.

MDIO was originally defined in Clause 22 of IEEE RFC802.3. In the original specification, a single MDIO interface is able to access up to 32 registers in 32 different PHY devices. These registers provide status and control information such as: link status, speed ability and selection, power down for low power consumption, duplex mode (full or half), auto-negotiation, fault signaling, and loopback.

To meet the needs the expanding needs of 10-Gigabit Ethernet devices, Clause 45 of the 802.3ae specification provided the following additions to MDIO:

• Ability to access 65,536 registers in 32 different devices on 32 different ports

• Additional OP-code and ST-code for Indirect Address register access for 10 Gigabit Ethernet

• End-to-end fault signaling

• Multiple loopback points

• Low voltage electrical specification

MDIO Theory of Operation

The MDIO bus has two signals: Management Data Clock (MDC) and Managment Data Input/Ouput (MDIO).

MDIO has specific terminology to define the various devices on the bus. The device driving the MDIO bus is identified as the Station Management Entity (STA). The target devices that are being managed by the MDC are referred to as MDIO Manageable Devices (MMD).

The STA initiates all communication in MDIO and is responsible for driving the clock on MDC. MDC is specified to have a frequency of up to 2.5 MHz.

Clause 22

Clause 22 defines the MDIO communication basic frame format (Figure 16) which is composed of the following elements:

The frame format only allows a 5-bit number for both the PHY address and the register address, which limits the number of MMDs that the STA can interface. Additionally, Clause 22 MDIO only supports 5V tolerant devices and does not have a low voltage option.

Clause 45

In order to address the deficiencies of Clause 22, Clause 45 was added to the 802.3 specification. Clause 45 added support for low voltage devices down to 1.2V and extended the frame format (Figure 17) to provide access to many more devices and registers. Some of the elements of the extended frame are similar to the basic data frame:

The primary change in Clause 45 is how the registers are accessed. In Clauses 22, a single frame specified both the address and the data to read or write. Clause 45 changes this paradigm. First an address frame is sent to specify the MMD and register. A second frame is then sent to perform the read or write.

The benefits of adding this two cycle access are that Clause 45 is backwards compatible with Clause 22, allowing devices to interoperate with each other. Secondly, by creating a address frame, the register address space is increased from 5 bits to 16 bits, which allows an STA to access 65,536 different registers.

In order to accomplish this, several changes were made in the composition of the data frame. A new ST code (00) is defined to identify Clause 45 data frames. The OP codes were expanded to specify an address frame, a write frame, a read frame, or a read and post read increment address frame. Since the register address is no longer needed, this field is replaced with DEVTYPE to specify the targeted device type. The expanded device type allows the STA to access other devices in addition to PHYs.

Additional details about Clause 45 can be found on the IEEE 802.3 workgroup website.

MDIO References

• IEEE 802 LAN/MAN Standards Committee

• Use The MDIO Bus To Interrogate Complex Devices – Electronic Design Magazine