When to use different types of MCU communication? (SPI, I2C..) What is your fav?

[corrado33]

I've been reading a lot lately on SPI and I2C and I've noticed that people are very opinionated in which they use.  Generally, I've noticed that people tend to learn one and stick with it. 

I don't want to know the differences here, because that can be found on tons of sites elsewhere, but I want to know which do you use and why?

And where does UART/USART come into play?  I know USART is hardware and SPI and I2C are protocols... right?  And (I'm probably saying this wrong), but UART is asynchronous while SPI and I2C are synchronous.  That means that SPI and I2C use the MCU's clock source while UART uses something different? 

I've also read that for synchronous data transfer... SPI is less complex to set up, but uses more wires, while I2C is more complex to set up but uses less wires.  Both can have multiple things connected, right?  There are different ways to address the things connected too, right?  One was developed by one company and the other was developed by someone else. 

So, what do you use and why?  And if you do use both, in what situations do you use one over the other?

[waltr]

I use all three depending on the requirements.

I2C is more complicated but only requires two lines and a ground for up the 127 devices (using 7-bit addressing). It is limited to about 400kHz clock so I use this for devices that do not need a to transfer lots of data fast. My small Bot uses I2C to read a compass chip, read/write an external EEPROM and write servo positions to another processor (that does all the servo pulse timing).

SPI has 3 wires, plus ground, common to all the devices on the bus then each device has it own /CS line. So the total number of wires (processor pins) is 3 + #devices. SPI can run at much faster speeds than I2C so when lots of data needs to move fast I use SPI. A project I'm doing at work is using an FPGA with 8- 48MHz SPI busses to set DACs and read ADCs.

I use the UART, or asyn data with an RS232 level translator to connect a processor to a PC usually just for diagnostic and debugging.

Is this helpful?

[corrado33]

Very much so waltr!!  Thank you so much.

I didn't catch the part that SPI needs 3+gnd+ number of devices.  I thought it was just four total, no matter how many devices you had hooked up.  So I2C has it's bit addressing to determine which device to talk to, and SPI has a wire to do it?  That's probably why people say I2C is more complicated.  You have to transmit the bit address before you can talk to anything. 

[waltr]

Very much so waltr!!  Thank you so much.

I didn't catch the part that SPI needs 3+gnd+ number of devices.  I thought it was just four total, no matter how many devices you had hooked up.  So I2C has it's bit addressing to determine which device to talk to, and SPI has a wire to do it?  That's probably why people say I2C is more complicated.  You have to transmit the bit address before you can talk to anything. 

Yep, and the data line on I2C is bi-directional so that the pin need to change from output to input at the correct times.

[Webbot]

Just to add my '2 cents'....

I2C is a broadcast protocol - ie each message is received by every device on the bus. But part of the message is a unique 'address' (bit like a phone number) - and each device must have been set up with its own unique one. So when the message is sent then 'all but one' of the devices will ignore the message as its not their phone number.
I2C does allow you to send a special message (with an address of 0) that ALL devices will receive - but none are allowed to respond to (as they would be talking on top of each other). This is useful to send a message like 'I have just been reset so please will you all reset/initialize yourselves'. You can also simulate I2C in software which is only really worthwhile if you have two devices with the same address and they cannot be modified (or if you have more than 127 devices!). You cant put them on the same bus as they conflict. So putting one onto a software simulated bus avoids the problem.

SPI on the other hand uses a digital output to select the one (and ONLY one) device that the message is being sent to. Hence adding +1 pin per device as per Waltr's post. If you have lots of devices then you can reduce this a bit by adding an extra IC to decode a value. IE if you have 8 devices then you would need 3 processor pins (as 2^3 = going into the IC and it would then set one of its 8 output pins accordingly. Cant think of the name or part number off the top of my head but its probably something like a 'multiplexer' or 'de-multiplexer'. Another advantage with SPI is that its very easy to simulate in software. By doing so then you can forget the the device selection pin and just tie it on the target device to ground so that its permanently selected (since its the only device on the software simulated bus).


Another consideration is 'what needs to talk to what?'.
SPI only ever has ONE master and MANY slaves. The 'master' initiates all phone calls and hence a 'slave' can only reply if it has been asked a question. Hence if the master is your Axon and the slave is a distance sensor then the Axon would need to keep polling the distance sensor to see if there is an obstruction ahead.


I2C on the other hand allows (in theory) each device to be a slave AND/OR a master (at any one point in time) - so anything can talk to anything else. With the above 'example' this means that rather than continuously polling the distance sensor you could make the distance sensor broadcast a message (to anything thats interested) to say 'I see something'. Unfortunately the ATmel/AVR hardware implementation for this is a bit flaky.