SPI versus I2C protocols - Revision history

Rijk at 13:31, 18 July 2014

2014-07-18T13:31:20Z

Rijk: /* I2C Clock stretching */

2014-07-18T12:45:20Z

I2C Clock stretching

Rijk: /* Full-duplex/Half-duplex */

2014-07-18T12:43:00Z

Full-duplex/Half-duplex

Rijk at 12:41, 18 July 2014

2014-07-18T12:41:48Z

Rijk at 12:41, 18 July 2014

2014-07-18T12:41:17Z

Rijk at 12:41, 18 July 2014

2014-07-18T12:41:04Z

Rijk at 12:31, 18 July 2014

2014-07-18T12:31:54Z

Rijk at 10:04, 16 July 2014

2014-07-16T10:04:55Z

Rew at 14:35, 11 May 2012

2012-05-11T14:35:44Z

Rew: Created page with "The bitwizard expansion boards speak the same protocol whether you have the SPI or the I2C version. The I2C protocol is inherently half-duplex. The SPI protocol is inherentl..."

2012-05-11T14:31:02Z

Created page with "The bitwizard expansion boards speak the same protocol whether you have the SPI or the I2C version. The I2C protocol is inherently half-duplex. The SPI protocol is inherentl..."

New page

The bitwizard expansion boards speak the same protocol whether you have the SPI or the I2C version.

The I2C protocol is inherently half-duplex. The SPI protocol is inherently full-duplex.

When designing the SPI protocol we noticed that most of the time we didn't have data to send one direction anyway. When you WANT to read from the device, you have to send "dummy bytes" to the device to trigger the clock signal that allows the slave to send data. Similarly, the slave doesn't really have anything to report back when you are actually sending data to the slave.

So from the software point-of-view both protocols are now half-duplex.

To write data using SPI send a number of bytes (usually 3 or 4).

<address> <register> <data byte1> <data byte2> ....

For I2C: Exactly the same!

On SPI you activate (make it low!) the slave select line before the transaction. On I2C you cause a start condition before the transaction. After the transaction, you deactivate the slave select line (make it high) on SPI and cause a STOP condition on I2C.

To read data from the slaves, on I2C you first make a write transaction of just two bytes, the address and the register number. Next you read the data. On SPI this must be done in one transaction: write the address and register number, then write dummy bytes while reading the data.

To read on I2C:
<start> <address + WRITE> <register> <stop>
<start> <address + READ> <byte 1> <byte 2>

To read on SPI:
MOSI <address> <register> <dummy byte> <dummy byte>
MISO xxx xxx <byte 1> <byte 2>

@@ Line 1: / Line 1: @@
 When buying a BitWizard expansion board, either I2C or SPI can be selected as the interface. This page will help you choose.
-= Physical Differences =
-The only physical difference between I2C and SPI is that I2C is two-wire, while SPI is four-wire.
+= Introduction =
+I2C and SPI are both bus protocols that allow short-distance, serial data transfer. I2C originates from the Philips semiconductor devision, while SPI was created by Motorola. Both protocols are commonly used in electronic devices like smartphones, TV's and laptops to control peripherals like power management chips, input devices and DACs. For instance, Microsoft uses I2C for the detachable keyboard on their Surface tablet.
 = Technical Differences =
+== General Differences ==
+I2C allows multiple masters and slaves on the bus. On the other hand SPI can only work with one master device controlling multiple slaves. In both I2C and SPI the master device controls the clock for all slaves, but an I2C slave device can modify the main bus clock. We will talk about this feature later.
 == Full-duplex/Half-duplex ==
 The I2C protocol is inherently half-duplex, while the SPI protocol is inherently full-duplex. So with SPI, every read is also a write. This could in theory double the speed of the bus, however, when implementing the SPI protocol we noticed that most of the time we didn't have data to send one direction. When you want to read from the device, you have to send "dummy bytes" to the device to trigger the clock signal that allows the slave to send data. Similarly, most of time the slave does not have anything to report back when you are actually sending data to the slave.
@@ Line 12: / Line 13: @@
 I2C has a feature called 'clock stretching'. If the slave device cannot send the data fast enough, it can hold down the clock so data will be transfered slower. This way, the bitrate is decreased, but the slave can keep up with the processing of the data. This feature can be very useful, since the clock rate can be high, and the slave will delay only when it needs to. The only problem is that the SoC on the Raspberry Pi has a bug in this feature. If clock stretching is used at the wrong time, the received might be corrupt. All BitWizard I2C boards work around this issue by carefully timing all I2C messages. The performance penalty is small, but as a result, all BitWizard I2C boards only work at a bus speed of 100kHz.
-== Implementation ==
+== Sending/Writing data ==
 The addresses on the bus are 7 bits wide. The lower bit specifies if the transaction is to be a read or a write. Write transactions have the lower bit cleared (0), read transactions have the lower bit set (1).

@@ Line 10: / Line 10: @@
 == I2C Clock stretching ==
-I2C has a feature called 'clock stretching'. If the slave device cannot send the data fast enough, it can hold down the clock so data will be transfered slower. This way, the bitrate is decreased, but the slave can keep up with the processing of the data. This feature can be very useful, since the clock rate can be high, and the slave will delay only when it needs to. The only problem is that the SoC on the Raspberry Pi has a bug in this feature. This bug makes clock stretching unusable on the RPi. All BitWizard I2C boards work around this issue by carefully timing all I2C messages. The performance penalty is small, but as a result, all BitWizard I2C boards only work at a bus speed of 100kHz.
+I2C has a feature called 'clock stretching'. If the slave device cannot send the data fast enough, it can hold down the clock so data will be transfered slower. This way, the bitrate is decreased, but the slave can keep up with the processing of the data. This feature can be very useful, since the clock rate can be high, and the slave will delay only when it needs to. The only problem is that the SoC on the Raspberry Pi has a bug in this feature. If clock stretching is used at the wrong time, the received might be corrupt. All BitWizard I2C boards work around this issue by carefully timing all I2C messages. The performance penalty is small, but as a result, all BitWizard I2C boards only work at a bus speed of 100kHz.
 == Implementation ==

@@ Line 6: / Line 6: @@
 = Technical Differences =
 == Full-duplex/Half-duplex ==
-The I2C protocol is inherently half-duplex. The SPI protocol is inherently full-duplex. So with SPI, every read is also a write. This could in theory double the speed of the bus, however, when implementing the SPI protocol we noticed that most of the time we didn't have data to send one direction. When you want to read from the device, you have to send "dummy bytes" to the device to trigger the clock signal that allows the slave to send data. Similarly, most of time the slave does not have anything to report back when you are actually sending data to the slave.
+The I2C protocol is inherently half-duplex, while the SPI protocol is inherently full-duplex. So with SPI, every read is also a write. This could in theory double the speed of the bus, however, when implementing the SPI protocol we noticed that most of the time we didn't have data to send one direction. When you want to read from the device, you have to send "dummy bytes" to the device to trigger the clock signal that allows the slave to send data. Similarly, most of time the slave does not have anything to report back when you are actually sending data to the slave.
 With dummy packets, both protocols are essentially half-duplex.
 == I2C Clock stretching ==

@@ Line 12: / Line 12: @@
 I2C has a feature called 'clock stretching'. If the slave device cannot send the data fast enough, it can hold down the clock so data will be transfered slower. This way, the bitrate is decreased, but the slave can keep up with the processing of the data. This feature can be very useful, since the clock rate can be high, and the slave will delay only when it needs to. The only problem is that the SoC on the Raspberry Pi has a bug in this feature. This bug makes clock stretching unusable on the RPi. All BitWizard I2C boards work around this issue by carefully timing all I2C messages. The performance penalty is small, but as a result, all BitWizard I2C boards only work at a bus speed of 100kHz.
-== Implentation ==
+== Implementation ==
 The addresses on the bus are 7 bits wide. The lower bit specifies if the transaction is to be a read or a write. Write transactions have the lower bit cleared (0), read transactions have the lower bit set (1).

@@ Line 5: / Line 5: @@
 = Technical Differences =
-== Full-duplex/Half-duplex
+== Full-duplex/Half-duplex ==
 The I2C protocol is inherently half-duplex. The SPI protocol is inherently full-duplex. So with SPI, every read is also a write. This could in theory double the speed of the bus, however, when implementing the SPI protocol we noticed that most of the time we didn't have data to send one direction. When you want to read from the device, you have to send "dummy bytes" to the device to trigger the clock signal that allows the slave to send data. Similarly, most of time the slave does not have anything to report back when you are actually sending data to the slave.
 With dummy packets, both protocols are essentially half-duplex.

@@ Line 1: / Line 1: @@
-The bitwizard expansion boards speak the same protocol whether you have the SPI or the I2C version.
+When buying a BitWizard expansion board, either I2C or SPI can be selected as the interface. This page will help you choose.
+= Physical Differences =
-The I2C protocol is inherently half-duplex. The SPI protocol is inherently full-duplex.
+The first difference between I2C and SPI is that I2C is two-wire, while SPI is four-wire.
+= Technical Differences =
-When designing the SPI protocol we noticed that most of the time we didn't have data to send one direction anyway. When you WANT to read from the device, you have to send "dummy bytes" to the device to trigger the clock signal that allows the slave to send data. Similarly, the slave doesn't really have anything to report back when you are actually sending data to the slave.
+The I2C protocol is inherently half-duplex. The SPI protocol is inherently full-duplex. So with SPI, every read is also a write. This could in theory double the speed of the bus, however, when implementing the SPI protocol we noticed that most of the time we didn't have data to send one direction. When you want to read from the device, you have to send "dummy bytes" to the device to trigger the clock signal that allows the slave to send data. Similarly, most of time the slave does not have anything to report back when you are actually sending data to the slave.
-So from the software point-of-view both protocols are now half-duplex.
+With these dummy packets, both protocols are now half-duplex.
 The addresses on the bus are 7 bits wide. The lower bit specifies if the transaction is to be a read or a write. Write transactions have the lower bit cleared (0), read transactions have the lower bit set (1).
@@ Line 13: / Line 14: @@
 After the address a single byte indicates the "port" on the board that the data is written to. The software can thus define 256 ports on each board.
-To write data using SPI send a number of bytes (usually 3 or 4).
+To write data using SPI or I2C send a number of bytes (usually 3 or 4).
  <address> <register> <data byte1> <data byte2> ....
-For I2C: Exactly the same!
 On SPI you activate (make it low!) the slave select line before the transaction. On I2C you cause a start condition before the transaction. After the transaction, you deactivate the slave select line (make it high) on SPI and cause a STOP condition on I2C.