27

I am examining a way to connect two microcontrollers. On the level of serialization I am thinking of using Nano protobuffers (http://code.google.com/p/nanopb/). This way I can encode/decode messages and send them between two processors.

Basically, one small processor would be the RPC server, capable of doing several functions. Bigger processor will call there RPCs via messages sent, and then when data is ready, it will read it from smaller processor.

What would be the pros/cons of using UART, I2C or SPI?

Messages will be put in the mailbox que prior to sending.

Best regards, Drasko

Drasko DRASKOVIC
  • 335
  • 1
  • 3
  • 8

3 Answers3

28

It depends on your total requirements and how expensive are pins.

I2C only needs two pins, but it's slow and to handle it with or without interrupts is a pain, even with the build in peripheral modules. It's a master/slave system, it's good for controlling many slow devices like temp sensors.
Only two lines for all bus devices, the selection is done via an I2C-Address in the protocol.

Uart needs two pins, it's normally faster, easier to handle, but requires (nearly) the same clocks at both sides. One to one asynchronous system, can be good if both systems needs to be send sometimes data without waiting for a master poll request.
Can also be used as a bus system, but then you need a master/slave structure or more complex protocols.

SPI needs 3 (or 4 with CS) pins, it's the fastest, simple to implement even with DMA, low cpu time overhead, often buffered. When you have enough free pins I would prefer it.

jeb
  • 70,992
  • 15
  • 159
  • 202
  • SPI is master/slave - the master sends the clock, so the slave (each slave if using CS) needs an interrupt line to request a transfer. For me, UART is simplest to implement for situation where you want each end to be able to transmit whenever it wants. – barny Sep 08 '17 at 10:22
2

All of these interfaces have pros/cons.

UART connection in it's basic functionality requires 2 pins: RX and TX. The SW implementation of how to message over that UART is quite a bit more complicated...you'll have to develop your own messenging protocol between the devices and decide what is a good message and what is a bad message. It could get quite complicated because you pretty much have to define how to "communicate" over the physical link, what is an error, retries, etc. Unless you are implementing a serial port connection to a PC or some other external device, I think a UART is highly overkill for a IC to IC communication path. Master and slave are not specifically defined.

SPI is a master-slave relationship and can be a faster interface (I've seen up to 60MHz clock rates, not common) but it also requires more pins, 3 at a minimum for a point-to-point communication scheme but the number of pins increases to 3+n as the number of "slaves" increases above 1. There are no error indications via SPI. SPI is a "de-facto" standard...meaning it can vary in implementation...your mileage may vary depending on how a IC supplier defined "their" SPI implementation. I generally consider the lack of a true standard for SPI to be a "con".

I2C is also a two pin interface and is an actual "standard" developed by Phillips (now NXP.) As a standard, it is well-defined in how it operates, how errors are raised, and is simple to implement. It has an addressing scheme, can send commands, and can support 0 or more data frames in a transaction. CRC (optional) and higher data rates can be supported (up to 5Mbits.) It does have cons, namely bus capacitance can limit actual data rates (rise/fall time) but generally you can design around this "problem".

In their most basic forms, all of these busses are "ground referenced"...and can suffer from system induced noise. Obviously, lower rail voltages can make this even more of issue. Again careful design practice can mitigate many of the problems some people report to be the bain of their existence.

For the point-to-point system initially asked by the poster, if a master-slave arrangement is required, a SPI or I2C interface may be appropriate (data rate dependent.) If a master-master relationship is required, I2C or UART may be required.

For ease of implementation from a software point of view, I'd rank these communication methods in the following order:

  1. I2C, if you need faster data rates than I2C can handle, then SPI
  2. SPI, if you need multi-master, then I2C or UART
  3. UART as a last resort...has a lot more software overhead to manage the communications channel
sranta
  • 21
  • 1
1

I would use UART or CAN or ETH or any protocol that is asynchronous.

If you use a synchronous protocol, the master must always "ask" the slave if it has data and generate unwanted traffic.

Catalin Dumitrescu
  • 52
  • 7