Preferred serial interface between 2+ STM32

[LCE]

Heyho,

I have an application with an STM32H7x3, which might be talking to some other STM32 (type TBD, probably something <= G4) on another stacked PCB.

This is only a control interface, so no data streaming with a minimum data rate.

I am looking for the "best" interface, with that I mean "highest speed at lowest complexity". 

 

Hardware limits:

• trace length max 30 cm, probably over 1 or 2 connectors 
• max. 4 pins (+1 chip select for each participant also okay)
• max. 4 STM32x + STM32H7x3 on the "lines"

So, I2C or SPI - or anything else ?

For reliability I like the I2C's acknowledge, SPI is surely faster and has no address "overhead".

Thanks in advance for your input!

 

 

[Andrew Neil]

---

@LCE wrote:

I am looking for the "best" interface, with that I mean "highest speed at lowest complexity". 

---

Give some actual numbers - what kind of speeds are you talking about ?

 

---

@LCE wrote:

So, I2C or SPI - or anything else ?

---

You could also consider UART in multiprocessor mode ...

These are all well-established standard interfaces, well-suited to such applications: the pros & cons are all well-known and widely-discussed - nothing specific to STM32 here.

 

---

@LCE wrote:

SPI ... has no address "overhead".

---

Maybe no software overhead, But SPI has the hardware overhead of requiring more data lines, and multiple select lines...

 

[LCE]

Thanks @Andrew Neil !

UART in multi-processor mode, I'll have to check that, never used it.

Right now the main STM32H7 is talking to some slooow ATmegas via I2C (at 30 kHz...), and there are some dedicated spare pins which could be re-used for SPI chip select lines.

Compared to the ~ 30 kHz above, even I2C at 400 kHz would be an improvement. "Fast mode plus" at 1 MHz would definitely be good enough.

What I'd like about SPI is that no address is required, full duplex at least possible, and eventually the higher speed.

Choices...

[TDK]

> highest speed at lowest complexity

Seems SPI is the winner based on those rules. I'm not convinced it's the best one for the job though, if the data rate is minimal.

> minimum data rate.

I would use I2C here, but it's considerably more complicated in terms of the protocol but signal count is way fewer.

UART is simpler but is more difficult with multi-drop.

CAN is another option, similar to I2C.

 

No doubt any of these could work so choose the one you're most comfortable with and meets the needs.

[Andrew Neil]

---

@TDK wrote:

UART is simpler but is more difficult with multi-drop.

---

It doesn't have to be complicated - simple open-drain drive with pullups should work in this scenario.

And (some?) STM32s support half-duplex ...

[Andrew Neil]

---

@LCE wrote:

 

...  minimum data rate ...

... highest speed ... 

---

These seem contradictory!

If you only want a "minimum data rate", then why does "highest speed" matter ?

[LCE]

I wasn't clear enough, what I meant that this is not for an interface which must have a certain minimum data rate.

Higher data rate would be nice as long as it doesn't complicate things.

Coming from our 30 kHz I2C something like the regular 400 kHz I2C would be acceptable.

 

[Andrew Neil]

Another potential issue with SPI and I2C is that they give no way for the Slave(s) to initiate contact with the Master - you end up having to have some sort of "interrupt" or "attention" line, or the Master has to just keep polling.

 

That may or may not be significant in your particular application ...

[LCE]

Good point, I have these extra lines in the existing system - and wanted to keep them.

Currently each slave has an extra interrupt line, plus one spare line (which is used for something completely different now than intended).

[waclawek.jan]

I once experimented with an SPI "ring" - data output of one mcu goes to input of other, common clock, common slave select, one master and all other slaves. DMA took care of shoveling data from input to output wihin the mcu; I don't remember how was the "injection" of given mcu's data solved, but maybe another DMA triggered by the slave select. Such scheme is efficient only if there is a need to dispatch the same amount of information amongst (or from) N slaves, but this is often the case. I don't say it's better or worse than any other scheme, just wanted to throw in one more idea to the pool.

JW

[LCE]

This will be a modular system where some "in-between" module slots may not be occupied, so a daisy chain / ring would be broken - unless some jumper would be set.

I think I'd prefer "broadcasting" to several modules by simply pulling down multiple CS/SS pins. 
Or would that be some "forbidden" action for SPI?

Until now I have used SPI mostly only with a single device connected.

[Andrew Neil]

---

@LCE wrote:

I think I'd prefer "broadcasting" to several modules by simply pulling down multiple CS/SS pins. 
Or would that be some "forbidden" action for SPI?

---

The problem there is that you'll enable multiple MISO outputs at the same time onto the one MISO line ...

[waclawek.jan]

That indeed disqualifies immediately any idea of ring (not that it would be unimaginable, but it makes it quite impractical). Also, if there's often a need to "broadcast", this would be a wasteful scheme.

I personally would go for single-wire UART (used much like the ubiquitous RS485), although ~0.5MBaud may require some care.

JW