Interfaces: SPI, Microwire and I2C Protocol Formats
By Volker Soffel
This article is part 2 in a series about various microcontroller communication interfaces. In part 1 of the series, I discussed some typical applications and implementations of the SPI, Microwire and I2C interfaces. I looked at their general differences, basic features, advantages and disadvantages. In this part, I'll cover the specifics of their protocol formats. In Part 3 we will start to take a closer look at asynchronous interfaces (UART based RS232C/RS485/LIN, CAN, USB and Ethernet).
I2C Bus
I2C is a 2-wire, half-duplex, serial bus, as shown in Figure 1. The two I2C signals are serial clock (SCL) and serial data (SDA). Both lines are bidirectional and must be connected to Vcc via pull-up resistors.
The device initiating data transfers and providing the clock signal on the bus is called a "master". A device being addressed by the master is called a "slave".
The addressed I2C slave can slow down or stop the master by keeping the SCL line pulled low (clock stretching) until it is ready to continue. This way a slow slave device can still keep up with a fast master.
I2C supports multiple masters on the bus through its built in bus arbitration. In case of multiple masters trying to send data at the same time, priority is given to the master that first sends a "0" bit.
I2C Communication Protocol
Data can be transferred at rates up to 100kbps in Standard mode, up to 400kbps in Fast mode and up to 3.4Mbps in High-Speed mode (finding peripherals that are that fast though is a challenge). In Standard mode 7-bit addressing is used. In the other modes, slaves can either have 7- or 10-bit addresses. The total capacitive bus load of all devices connected to the bus can not exceed 400pF.
Figure 2 shows the I2C Communication Protocol. The data transmission format is most significant bit (MSB) first. I2C is level sensitive; therefore SDA must be stable while SCL is high. The SDA line can only change when SCL is low, with two exceptions:
- Start Condition: The master signals the beginning of a transfer by sending a 1-to-0 transition while SCL is high.
- Stop Condition: A 0-to-1 transition issued by the master while SCL is high, signals the end of a transfer.
The start condition is followed by 8-bits of data with the first 7 bits being the unique slave address in standard mode. 10-bit addressing is indicated by transmitting the bit pattern 11110 followed by address bits A9 and A8. The 7-bit address field is followed by the read/not-write (R - /W) bit, which tells the slave whether to receive (0) or transmit (1) data.
This pattern of 8-data bits and 1 acknowledge bit is repeated if more bytes need to be transmitted. The device that is receiving data asserts the acknowledge signal. In case of the master transmitting, it monitors the slave's acknowledge after the last byte to be transmitted and then issues the stop condition. In case of the slave transmitting, the master acknowledges all bytes but the last one received, to indicate to the slave that transmission is to be stopped. The master then issues the stop condition.
SPI and Microwire
Both SPI and Microwire are full-duplex, (3+n)-wire serial busses. (n= # of slaves). In single master, multiple slave configurations, as shown in Figure 3, each slave device requires a dedicated Slave Select (SS) signal, which is created by the master using standard I/O pins.
A Microwire multiple slave configuration looks similar, with the difference that the master's SO pin is connected to the slaves' SI pins and the slaves' SO pins are connected to the master's SI pin.
SPI Signals
|
Microwire Signals
|
SCLK- Serial Shift Clock
|
SK – Serial Shift Clock
|
MOSI - Master Out Slave In
|
SO – Serial Out (both master & slave)
|
MISO – Master In Slave Out
|
SI – Serial In (both master & slave)
|
/SS – Slave Select
|
/CS – Chip Select
|
Most SPI interfaces have two configuration bits, called clock polarity (CPOL) and clock phase (CPHA). CPOL determines whether the shift clock's idle state is low (CPOL=0) or high (CPOL=1). CPHA determines on which clock edges data is shifted in and out (CPHA=0 MOSI data is shifted out on falling edge, MISO data is shifted in on rising edge). As each bit has two states, this allows for four different combinations, all of which are incompatible with each other. For two SPI devices to talk to each other, they need to be set to use the same clock polarity and phase settings.
Why would you want 4 different settings? Two of the four settings allow the SPI interface to talk to different flavors of Microwire devices and vice versa.
Figure 4 shows the original Microwire protocol (which is older than SPI) that has fixed clock polarity and clock phase: SI is latched (data shifted in) on the rising edge of the SK clock and SO changes (data shifted out) on the falling edge. SK is always low if no data is transmitted.
Many early SPI devices implemented only SPI mode 0 that does the opposite of Microwire, namely shift data out on the rising edge and in on the falling. Therefore Microwire/Plus was created that allows selecting an alternate shift clock via the SKSEL (shift clock select) bit. Nowadays Microwire/Plus with alternate shift clock is compatible to SPI mode 0 and Microwire with standard shift clock is compatible with SPI mode 1.
Both Microwire and SPI do not explicitly define any maximum data rates. Different peripherals on the market each have their own maximum speed limit - most of them in the several Mbit range. There is no means of slaves to slow the master down and also no acknowledgement on received data, like with I2C. To accommodate a wide range of SPI/Microwire speeds, microcontrollers usually feature a programmable shift clock divider.
Conclusions
SPI's and Microwire's full duplex capability and fast data rates make those interfaces very efficient and simple for single master - single slave applications. In practical applications, the requirement for dedicated slave select signals severely limits the number of slave devices that can be connected to a microcontroller. Multi-master systems significantly increase complexity and are very rarely used with those two interfaces.
I2C's lower speed and more complex protocol put it at a disadvantage in single master-single slave applications. Its weakness turns into strength if a larger number of slave devices needs to be connected or a multi-master system is needed.
All three interfaces have the advantage of being tolerant to large oscillator variations, as all data transfers are synchronized to the master's shift clock. As synchronous interfaces they are, however, limited to bridging short distances on a single PCB or between PCBs within a smaller system. When it comes to bridging larger distances or connecting external devices, asynchronous interfaces play a dominant role and we will start looking at some of them in part 3 of this series.
About the Author
Volker Soffel is the General Manager of MicroController Pros Corporation (uCPros). uCPros offers services in: Electronic system design with a focus on embedded systems; marketing and management consulting; employee training; technical writing and translations. uCPros also publishes a free monthly Embedded News Digest email newsletter, covering the latest events in the microcontroller industry.
Beagle I2C/SPI Protocol Analyzer
Introduction
These getting started guidelines are intended to facilitate the first use of the Beagle I2C/SPI analyzer. The Beagle I2C analyzer can be used with Data Center or Beagle API to monitor any standard I2C/SPI devices. Use the Beagle I2C/SPI analyzer with Data Center, and follow the instructions below to monitor a standard I2C/SPI device.All current downloads for the Beagle I2C/SPI analyzer can be found at the bottom of this page in the Downloads section
Getting Started Guidelines
- Download and run the latest version of the Total Phase USB Drivers Installer.
- Connect the Beagle analyzer to the PC via the USB connector.
- Download and unzip the latest version of Data Center. (?)
- Launch Data Center. (?)
- Connect to the Beagle Analyzer. (?)
- Click Analyzer > Connect to Analyzer.
- Select the Beagle analyzer.
- Click OK to connect to the Beagle analyzer.
- Connect the analyzer's 10-pin header to the target system. (?)
- If you have the Aardvark I2C/SPI Host Adapter and the I2C/SPI Activity Board, you can use these tools to setup a target system to test the capabilities of the devices. For additional information, take a look at the Aardvark adapter datasheet, and I2C/SPI activity board datasheet.
- The Beagle analyzer is capable of monitoring I2C or SPI traffic. Depending on the system requirements, configure the device accordingly.
- Configure the Device Settings for I2C. (?)
- Click Analyzer > Device Settings.
- Choose I2C in the Capture Protocol option.
- Choose 10MHz for the Sampling Rate option.
- Enable Target Power and I2C Pull-ups based on the parameters of the target system.
- Click OK to close the Device Settings.
- Configure the Device Settings for SPI. (?)
- Click Analyzer > Device Settings.
- Choose SPI in the Capture Protocol option.
- Choose 50MHz for the Sampling Rate option.
- Enable Target Power based on the parameters of the target system.
- Configure the MSB First, Rising edge, and Slave Select polarity based on the parameters of the target system.
- Click OK to close the Device Settings.
- Configure the Device Settings for I2C. (?)
- Start the capture. (?)
- Click Analyzer > Run Capture.
- The Capture Started record will be displayed in the Transaction window along with the data captured from the bus, if there was any.
- Stop the capture. (?)
- Click Analyzer > Stop Capture.
- Save or export the capture.
Notes
For additional information, take a look at the Beagle analyzer datasheet, and Data Center manual.Downloads
| USB Drivers (Windows) v2.11 2013-02-08 Download |
USB drivers for the Aardvark I2C/SPI Host Adapter, Beagle Analyzers, Cheetah Host Adapters, and Komodo Interfaces. Ensure the drivers are installed before plugging in any Total Phase device. The Windows installer contains the 32-bit and 64-bit USB drivers. Refer to the device datasheet for more information regarding which versions of Windows are supported. |
| USB Drivers (Linux) v2.10 2011-07-01 Download |
USB drivers for the Aardvark I2C/SPI Host Adapter, Beagle Analyzers, Cheetah Host Adapters, and Komodo Interfaces. Ensure the drivers are installed before plugging in any Total Phase device. This package contains the configuration files for all Total Phase devices. Refer to README.txt and the datasheet for more details on how the Total Phase devices use the built-in USB drivers in Linux. |
| Beagle Protocol Analyzer Datasheet v4.51 2012-10-19 Download | HTML |
Complete datasheet for the Beagle analyzers, covering usage, programming, engineering notes. |
| Data Center Software v6.52 2012-11-09 Windows (32-bit) | Windows (64-bit) Linux (32-bit) | Linux (64-bit) Mac OS X (32-bit) | Mac OS X (64-bit) |
GUI Application for the Beagle analyzers Note that this software requires an update of the Beagle 5000 firmware to version 2.00 and an update of the Komodo CAN Interface firmware to at least version 1.10. Refer to the User's Manual for system requirements. |
| Data Center Software User's Manual v6.52 2012-11-09 Download | HTML |
User's manual for the Data Center Software |
| Beagle Software API and Shared Library v4.51 2012-10-19 Windows (32-bit) | Windows (64-bit) Linux (32-bit) | Linux (64-bit) Mac OS X (32-bit) | Mac OS X (64-bit) |
Rosetta Language Bindings - 32-bit and 64-bit Software API and Shared Library for C, C#, Python, .NET, VB.NET, and VB6 Note that this software requires an update of the Beagle 5000 firmware to version 2.00.Please read the UPGRADE.txt in the package because some API calls have been changed. [+] Beagle LabVIEW Driver (Windows) v3.06 2009-02-16 Download |
Introduction to Serial Peripheral Interface
Another option for low-cost, low-speed communication "inside the box" is the serial peripheral interface.
Several months ago in Beginner's Corner, we covered the inter-integrated circuit bus. I2C is a popular technology for low-cost, low-speed, communication "inside the box" ("I2C," August 2001, p. 87 ). Another choice to consider is the serial peripheral interface (SPI).
SPI vs. I2C
Both SPI and I2C provide good support for communication with slow peripheral devices that are accessed intermittently. EEPROMs and real-time clocks are examples of such devices. But SPI is better suited than I2C for applications that are naturally thought of as data streams (as opposed to reading and writing addressed locations in a slave device). An example of a "stream" application is data communication between microprocessors or digital signal processors. Another is data transfer from analog-to-digital converters.
SPI can also achieve significantly higher data rates than I2C. SPI-compatible interfaces often range into the tens of megahertz. SPI really gains efficiency in applications that take advantage of its duplex capability, such as the communication between a "codec" (coder-decoder) and a digital signal processor, which consists of simultaneously sending samples in and out.
SPI devices communicate using a master-slave relationship. Due to its lack of built-in device addressing, SPI requires more effort and more hardware resources than I2C when more than one slave is involved. But SPI tends to be simpler and more efficient than I2C in point-to-point (single master, single slave) applications for the very same reason; the lack of device addressing means less overhead.
Inside the box
SPI is a serial bus standard established by Motorola and supported in silicon products from various manufacturers. SPI interfaces are available on popular communication processors such as the MPC8260 and microcontrollers such as the M68HC11. It is a synchronous serial data link that operates in full duplex (signals carrying data go in both directions simultaneously).
Devices communicate using a master/slave relationship, in which the master initiates the data frame. When the master generates a clock and selects a slave device, data may be transferred in either or both directions simultaneously. In fact, as far as SPI is concerned, data are always transferred in both directions. It is up to the master and slave devices to know whether a received byte is meaningful or not. So a device must discard the received byte in a "transmit only" frame or generate a dummy byte for a "receive only" frame.
Figure 1: Single master, single slave SPI implementation
SPI specifies four signals: clock (SCLK); master data output, slave data input (MOSI); master data input, slave data output (MISO); and slave select (ÇSS). Figure 1 shows these signals in a single-slave configuration. SCLK is generated by the master and input to all slaves. MOSI carries data from master to slave. MISO carries data from slave back to master. A slave device is selected when the master asserts its ÇSS signal.
If multiple slave devices exist, the master generates a separate slave select signal for each slave. These relationships are illustrated in Figure 2.
Figure 2: Single master, multiple slave SPI implementation
The master generates slave select signals using general-purpose discrete input/output pins or other logic. This consists of old-fashioned bit banging and can be pretty sensitive. You have to time it relative to the other signals and ensure, for example, that you don't toggle a select line in the middle of a frame.
While SPI doesn't describe a specific way to implement multi-master systems, some SPI devices support additional signals that make such implementations possible. However, it's complicated and usually unnecesary, so it's not often done.
A pair of parameters called clock polarity (CPOL) and clock phase (CPHA) determine the edges of the clock signal on which the data are driven and sampled. Each of the two parameters has two possible states, which allows for four possible combinations, all of which are incompatible with one another. So a master/slave pair must use the same parameter pair values to communicate. If multiple slaves are used that are fixed in different configurations, the master will have to reconfigure itself each time it needs to communicate with a different slave.
At a higher level
SPI does not have an acknowledgement mechanism to confirm receipt of data. In fact, without a communication protocol, the SPI master has no knowledge of whether a slave even exists. SPI also offers no flow control. If you need hardware flow control, you might need to do something outside of SPI.
Slaves can be thought of as input/output devices of the master. SPI does not specify a particular higher-level protocol for master-slave dialog. In some applications, a higher-level protocol is not needed and only raw data are exchanged. An example of this is an interface to a simple codec. In other applications, a higher-level protocol, such as a command-response protocol, may be necessary. Note that the master must initiate the frames for both its command and the slave's response.
Both SPI and I2C offer good support for communication with low-speed devices, but SPI is better suited to applications in which devices transfer data streams.
SPI's full duplex communication capability and data rates (ranging up to several megabits per second) make it, in most cases, extremely simple and efficient for single master, single slave applications. On the other hand, it can be troublesome to implement for more than one slave, due to its lack of built-in addressing; and the complexity only grows as the number of slaves increases.
Far from being just a dumb "byte port," SPI is often an elegant solution for modest communication needs. It can also serve as a platform on which to create higher-level protocols.
沒有留言:
張貼留言
注意：只有此網誌的成員可以留言。