Actions
Forum Thread Details
  • Replies 4 replies
  • Subscribers 462 subscribers
  • Views 374 views
  • Users 0 members are here
Related

I2C or SPI

Former Member

which protocal is best in any microcontroller

i2c or SPI ?

  • It depends on what you want to do - there are many pros and conns - that's why both are in common use.

    Did you have a specific problem in mind ?

     

    MK

  • The best protocol is the one that lets you talk to the device you want to talk to.

     

    SPI is generally much faster, though this depends on the device you're talking to.  However, you do have to be careful about clock signal integrity.

     

    I2C is slower, but there are lots of devices that only have I2C.  With I2C you don't need to worry about signal integrity because the devices filter the input signals so they can ignore ringing -- at least that's my understanding.

     

    SPI requires more signals: you need clock, MISO, and MOSI, plus a chip select for each device.  I2C only requires two signals: SCL and SDA.

  • As with everything, there are pros and cons of both methods.

    I2C

    • Tends to be a bit slower but still fast enough for most applications
    • Only needs two pins (SDA and SCL)
    • has a reasonable range (I've used 5ft of screened cable with 4.7k pullup resistors at the far end and it has worked fine)
    • Allows many devices to be connected as there are many possible address bytes

     

    SPI

    • Faster as has separate Transmit and Receive lines (MOSI and MISO) as well as clock
    • Uses pins to select which IC it is talking to. Good as it doesn't have to send address bytes. Bad as it needs a pin for each device, the Raspberry Pi for example only has 2 SPI address pins

    My advice?

    Use I2C in general (easier to wire and change over. can handle many devices) and reserve the SPI bus for something requiring the high speed.

    Any problems, just ask image

    Dan McGraw

    M0WUT

  • in reply to danielmcgraw

    Good overview!

    I2C has one extra benefit: the slaves acknowledge the transfer, so you're sure a slave is listening.

    It also has a drawback, and that is that uses an open collector drive, and with long cables and / or many devices on one bus you risk very bad data transfers (when it takes too long to pull up). The other drawback of the bus structure is that if you plan to use many devices of the same type, you get bus conflicts, which can only be solved by adding I2C multiplexers, which add even more lag to your communication.