What is the best/easiest way to communicate between 2 STM32's (SPI,I2C, ...?)

[waclawek.jan]

UART

JW

[TDK]

Or SPI if you need higher bandwidth. Definitely not I2C.

[Peter BENSCH]

UART:

• Advantages
  • easy wiring, minimum requirement RX, TX
• Disadvantages
  • asynchronous, requires some stable frequeny with a certain accuracy
  • rather slow
  • dedicated handling for handshake required (when used with RX/TX only)

SPI:

• Advantages
  • synchronous, no specific clock required (well, in wide limits)
  • fast (as mentioned by @TDK​)
  • can logically be seen as a shift register with TX and RX buffer in a daisy chain
• Disadvantages
  • at least 3 wires to connect (MISO, MOSI, CLK, maybe CS too)

I also agree with TDK about I2C, although it was once developed for interboard communication. Because of the open-drain connection used, the susceptibility to interference is significantly higher than with the aforementioned.

Regards

/Peter

[Nikita91]

The SCI requires a master: the 2 devices are not equal.

With a UART both can initiate a broadcast.

The speed of a UART is not slow: several Mega bits/s...

[JPeac.1]

As the UART speed increases it becomes more sensitive to clock jitter between the endpoints. Sure, you can run at megabit speeds, IF you can guarantee the source clocks for the baud rate generator will remain stable and very close in frequency (as in well under 1% deviation), as pointed out above. You're also limited to TTL levels and very short cable distances unless you add a high-speed RS-485 transceiver at each end.

Clock jitter on asynchronous UARTs is one of those nasty surprises no one mentions in classrooms or textbooks. (Help! My UART stops working after a few minutes/hours/days!) I discovered it while debugging a high-speed RS-485 Modbus network. Back in RS-232 days it wasn't an issue since slew rate limitations capped the speed at around 115Kbaud. But when you go to high baud rates, even with RS-485, the longer the block length of a message the more likely framing errors start to show up. A Modbus ASCII message in excess of 512 bytes running at 1Mbaud all but guarantees eventual random packet loss.

Still, long as you keep the data rate reasonable UART is the easiest way to connect adjacent boards. If you need some speed, then SPI is the better choice since it shares a common clock at both ends. Hardware is simple but the driver can be complicated when handling SPI bi-directional transfers.

You can use an STM32 USART port with external clock support and configured for synchronous mode. That solves the jitter issue but adds two more wires for a clock in each direction, plus you have to allocate two more pins for the clocks. The driver is a bit more complicated since you need to use a preamble to sync up transmitter and receiver (in each direction). This is a very old technology from the 1960s. Google BISYNC protocol and the IBM 2780 if you're curious.

Jack Peacock

[Paul1]

1. How far apart are the STM32's (inches, feet, yards, more)?
2. On same PCB? Within Same Enclosure? Separate enclosures with a removable cable?
3. How much data? (bytes/message, data rate, response time...)
4. If going any distance add checksums
5. Will there be a need for more than two CPUs in future? (Multidrop)

Paul

[S.Ma]

It depends on the constrains.

Distance and average bitrate would be first criteria.

Highest bitrate would be SPI, which also enables more than 2 devices with 3+ pins

Little coding needed as provided examples are closer to SPI peripheral validation than application style. As the link includes the clock, if mcus have not precise clocks, they will still work. Distance less than a meter for 10 MBPs. Communication between boards through connectors.

Otherwise, UART will enable asynchroneous links and highest speed will depends on the clock core mismatch between both devices.

Longer distances through RS485 transceiver

Communication between buildings

Alternatively, CAN or FDCAN interface, communication within a car.... wity a proper tranceiver.

I2C or I3C requires some SW and timing, with 2 wires bus.

Historically, UART, then SPI 4 wires, then 3 wiree, then I2C, now USB (to host) or Ethernet.

[HBleu.1]

1. Not far apart, but the connections will go through a cheap slipring which might introduce some noise/jitter: https://www.adafruit.com/product/736
2. So different enclosures
3. Very little data. Mostly to communicate status bits.
4. Checksums might come in handy
5. No

[Ahmet Yasin CİVAN]

UART and FDCAN