SPI versus I2C protocols

From BitWizard Wiki
Revision as of 15:31, 11 May 2012 by Rew (talk | contribs) (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...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

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>   ....

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>