8
\$\begingroup\$

I'm designing an embedded device that I would like to make interoperable with third party peripherals through a serial bus. Should I choose SPI, I²C, or some other bus?

The peripherals will be pretty low bandwidth (some sensors that communicate over the bus, polled periodically) and most likely within a metre or less of the controller. The controller's sole task is to collect the sensor data, package it in some way, and then send it off to a wireless module via another bus (although the sensor bus could potentially be reused for this too).

\$\endgroup\$

closed as not constructive by W5VO Aug 22 '12 at 15:06

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 3
    \$\begingroup\$ It depends which peripherals you want to interoperate with, at what voltages, at what speeds and at what distance. \$\endgroup\$ – Toby Jaffey Jul 14 '10 at 12:33
  • 1
    \$\begingroup\$ I added more details to the question \$\endgroup\$ – pfyon Jul 14 '10 at 13:37
  • 1
    \$\begingroup\$ I can't believe UART hasn't been mentioned at all... I'm just saying. \$\endgroup\$ – vicatcu Jul 15 '10 at 15:52
  • \$\begingroup\$ Correct me if I'm wrong, but I didn't think UART was a bus. I thought it was just serial communication between two devices. \$\endgroup\$ – pfyon Jul 19 '10 at 13:10
  • \$\begingroup\$ So a bus isn't for serial communication between two devices? Are you discounting it because it's sometimes just used point-to-point? PCIe, SATA, HT are all generally point-to-point. Regardless, most UART peripherals can be used for RS-422, RS-485, or LIN which are multi-drop. \$\endgroup\$ – Nick T Nov 11 '10 at 16:47
12
\$\begingroup\$

If you're uncertain, and your requirements are pretty vague, I'd pick I²C.

The major difference between SPI and I²C is that SPI requires a chip-select line for every peripheral. I²C broadcasts a peripheral address at the start of communication, so it doesn't need chip-select lines. Chip-select lines get cumbersome after the first few.

On the other hand, SPI is probably easier to implement and debug. It could be the winner if you just want to connect to a couple of devices.

I'd rule out USB unless you need high data rates over relatively long distances (m rather than cm). I'd also rule out RS-232 unless it's still 1976 and your peripherals need a massive signal to distinguish a bit from noise.

You might consider Dallas 1-wire, but I suspect it's not as common as I²C, and a "1-wire" bus that needs 2 wires to operate has always seemed a little fishy to me.

\$\endgroup\$
  • 1
    \$\begingroup\$ I think if you have a very simple controller and you need to use bit-banging (basically manually operating the clock) it is much easier to implement SPI on a 4 left over GPIO ports. \$\endgroup\$ – Wouter Simons Jul 14 '10 at 13:28
  • 1
    \$\begingroup\$ I think you're right about it being easier to bitbang SPI than I2C. I'm hoping it won't come down to bit banging though. \$\endgroup\$ – pfyon Jul 14 '10 at 13:38
  • 3
    \$\begingroup\$ +1 for the fishy-ness of the 2 wire system marketed as "1-wire". \$\endgroup\$ – semaj Jul 14 '10 at 15:14
  • \$\begingroup\$ And to make it worse, many chips which implement the 1-wire (+ground) system require a third pin - Vcc - because they can't operate off of parasitic power! When I think of a 1-wire bus, I'm imagining some capacitively coupled setup, with a current-limited bridge rectifier, and some self-clocking line code; not 2 or 3 wires. \$\endgroup\$ – Kevin Vermeer Jul 14 '10 at 19:15
  • \$\begingroup\$ "1-wire" should have been called "1-data-wire", since that is more what it is. The extra wires are GND and (sometimes) a stable Power line. \$\endgroup\$ – Johan Mar 4 '12 at 11:16
3
\$\begingroup\$

Since you said that it would be low bandwidth I would allocate enough IO to handle both SPI and I2C. I would also if possible have additional CS lines so you can run multiple SPI devices. Also don't forget to look at how you are going to power the peripheral. If you are running off of a battery to get max life you need to put the device in low power mode or remove power when not in use. Also use you controllers serial controller module if possible a lot of controllers will mux SPI, I2C and serial. If you can and split the wireless from the sensor this makes it easier to shut down devices when not in use. Also some sensors have a line that will tell the controller when they need to be serviced so you also want to have an extra IO going into a pin ideally one you can generate an interrupt from.

\$\endgroup\$
2
\$\begingroup\$

The question is a bit of a problem because of definition issues.

Serialized communication is basically what you need if you want to communicate with some external peripherial without using umpteen ports on your controller. Basically every serial communication method needs a clock and a configuration on how to handle data connections.

SPI is a 4 wire bus. I2C is a 2 wire bus.

Each has different characteristics. What you need to answer is how fast does your communication need to be, how reliable does it need to be, what options does your microcontroller offer, etc.

This wikipedia article and this reference site explains much more clearly than I can, also follow the references to learn even more!

\$\endgroup\$
2
\$\begingroup\$

Basically, you should choose between I2C and SPI.

Regardless of which bus you use, you should consider the voltage level of your sensors and third party peripherials. You can do this by making your own converter with two MOSFETS (Only goes one way - Pick up/no change or down/no change; only a problem if you need to run your sensors at 3.3 and interface with 1.8 and 5V masters). See NXP's AN10441 [PDF]. This will also work for SPI (Just remove the pullups). You will need to add a line to your connector to establish a reference voltage (if you're not doing so already.)

One downside of I2C is that you're limited to the slowest clock on the bus. If one sensor is only capable of 100kHz and you want to talk to your memory at 400kHz or 1MHz (both valid speeds), your slower sensor's behavior is unspecified. If you use SPI, the chip select line means that the slower sensor won't even be listening to what's on the bus, and you can run different speeds for different sensors.

\$\endgroup\$
1
\$\begingroup\$

I would use I2C. Just make sure that you can get a wireless module that can communicate over I2C if you want to have it on the same bus as your sensors. Most communications peripherals I've seen use SPI not I2C.

\$\endgroup\$

Not the answer you're looking for? Browse other questions tagged or ask your own question.