2022-03-25 06:18 AM
2022-03-25 06:33 AM
UART
JW
2022-03-25 07:17 AM
Or SPI if you need higher bandwidth. Definitely not I2C.
2022-03-25 07:49 AM
UART:
SPI:
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
2022-03-25 08:31 AM
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...
2022-03-25 09:22 AM
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
2022-03-25 11:01 AM
Paul
2022-03-26 07:27 PM
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.
2022-03-28 03:17 AM
2022-03-29 04:49 AM
UART and FDCAN