3
\$\begingroup\$

I'm designing a system that has 2 SPI slaves and 3 I2C slaves. The master for all of the communication is STM32F429, which has 6 SPI and 3 I2C peripherals. I think I have two options: 1) use a different peripheral for each slave device (5 peripherals in total), we'll call this SEPARATE or 2) use one SPI for both SPI slaves and one I2C for all 3 I2C slaves (2 peripherals in total), we'll call this COMBINED.

My question is:

What are the pros/cons of using SEPARATE vs COMBINED?

  • Pro COMBINED: Routing for COMBINED is simpler because shared lines don't have to all go all the way back to the micro.
  • Pro COMBINED: Extra pull-up resistors will be required for SEPARATE for each I2C bus.
  • Pro SEPARATE: If I use the DMA, I can initiate every transfer simultaneously without taking up cpu time, and perform cpu operations once all the data arrives (is this true?)
  • Pro SEPARATE: Any I2C devices that are slower won't hold up the other I2C slaves since they're on separate buses.
  • What other pros/cons are there?
\$\endgroup\$
3
  • \$\begingroup\$ remotely related question: Why the need for multiple I2C ports? \$\endgroup\$ Commented Oct 26, 2015 at 1:03
  • \$\begingroup\$ You seem to have it pretty well covered already. \$\endgroup\$ Commented Oct 26, 2015 at 10:10
  • \$\begingroup\$ I2C is slow, so I don't think that the overhead of starting a new DMA transfer to the same port after the previous one has completed would be a major concern. In fact, if the DMA support is good enough to 'chain' transfers to multiple devices, this could be a pro for combined. However, separate interfaces would allow transfers to proceed in parallel, which may be important if you are transferring a lot of data over I2C. \$\endgroup\$ Commented Oct 27, 2015 at 0:11

2 Answers 2

Reset to default
1
\$\begingroup\$

You have covered the 'electrical' and 'finished state' issues pretty well.

However, think of the process of building, debugging and testing the system.

The potential advantages of SEPARATE seem to be quite compelling:

  • Any electrical problems or bugs should only effect one device
  • Software for each slave device should be independent, so testing parts of the incomplete system should be easier because of this
  • The devices might need slightly different I2C (and maybe SPI) setups. For example, the data and clock may be in different phases, or worse, may use the same I2C address.
  • Finally, it would be relatively easy to combine slaves on a common peripheral, once everything is working, but getting the whole system working will be harder on shared peripheral interfaces.
\$\endgroup\$
2
  • \$\begingroup\$ As an aside, an SPI bus can typically work with multiple slaves that require different clock phases (i.e. different SPI modes). The master can change the SPI mode on a transaction-by-transaction basis. When CS# is deasserted for one slave, it ignores the SPI traffic that goes to some other slave, including the "foreign" clock phase. (I have implemented SPI with slaves requiring different modes. Having said that, SPI is more of a custom than a standard, and it's not inconceivable that there are oddball SPI slaves that don't work well with others.) \$\endgroup\$ Commented Nov 3, 2015 at 3:49
  • \$\begingroup\$ @NickAlexeev - interesting point. I think, in the context of questions like this one, I'd still suggest it would be easier to get two SPI device working on separate SPI peripheral interfaces first, then try to combine, rather than try to get them both working sharing the same SPI peripheral interface. But a good point none the less. \$\endgroup\$ Commented Nov 3, 2015 at 18:00
0
\$\begingroup\$

Pro combined (sort of): What I see missing are the capabilities of the peripherals itself. Not all peripherals have the same capabilities even though they are named in the same scheme.

SPI1, SPI4, SPI5 and SPI6 can communicate up to 45 Mbit/s whereas SPI2 and SPI3 can only communicate at 22.5 Mbit/s.

While this is only a small limitation on this microcontroller it might be more severe on a different one.

Pro separate: Another point for SPI is the hardware controlled slave select pin which is only working for one pin, so in case of multiple slaves you have to set this per software which slows down the transfers. (This might also be different for other controllers).

For some slaves you have to implement the slave select pin in software anyways (special timing requirements) so this might not be a pro in all cases.

Pro combined: A point which you mention not explicitly is the less needed pins on the microcontroller which might lead to a smaller footprint package when a single peripheral is used.

Trade-off: DMA is a limited resource, you have 16 streams in total available and not every stream can be used for every peripheral. See the reference manual (page 309). I haven't analysed if all SPIs and I2Cs are usable at the same time, but with 2 SPI and 3 I2C it should be doable to get a DMA stream for each of them (you need 10 if you want to have RX and TX done by DMA). Your pro should be valid but might be an issue if you need more DMA streams and the channels conflict.

Pro separate: I encountered a buggy I2C device which would behave very strange if you addressed another device on the same bus, for using it, it had to be alone on a separate I2C "bus". So this might happen again and putting each on one peripheral will prevent those issues from arising.

EMI performance might also be better as a malformed address is going to be ignored if only one device is connected to a bus.

\$\endgroup\$
1
  • \$\begingroup\$ The SPI controller on the Atmel SAM7 series of microcontrollers places the chip select field and the data field in the same register. The advantage of doing this is now you can very easily set up a single DMA operation that can hit every SPI device on the bus. The controller also lets you specify different timing parameters per chip select. It's one of the most impressive SPI controllers that I have seen on a microcontroller, and it's the only one that I know of with that particular feature. \$\endgroup\$ Commented Oct 27, 2015 at 0:30

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.