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]

---

@LCE wrote:

...  minimum data rate ...

... highest speed ... 

---

These seem contradictory!

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

[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 ...

[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.

[LCE]

Also leaning towards SPI right now.

[Andrew Neil]

A challenge with SPI can be that the 2 directions happen simultaneously - which can make it difficult if you want the Master to send a command/request, and the Slave give some reply ...

[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 ...