CAN FD

Once you already accept the core judgment of classic CAN, the easiest mistake when reading CAN FD is to think “the payload just grew from 8 bytes to 64 bytes, so it is faster.” That is not wrong, but it is far from enough. What really pushed CAN FD into existence was not only payload size. It was the fact that classic CAN ties arbitration and whole-frame transmission to the same bit rate, so systems increasingly wanted to keep deterministic shared-bus contention while being constrained by payload size and bus time.

UART

Devices do not always need a shared bus, and they do not always need complex arbitration. Debug ports, module links, and data exchange between an MCU and a host often have a simpler requirement: each side gets a transmit line and a receive line, no extra clock, no chip select, and no address broadcast, as long as bytes can be delivered reliably to the other side.

UART solves exactly that kind of point-to-point serial communication. It optimizes first for low implementation cost, direct wiring, and a low barrier for both hardware and software rather than for bus expansion or high throughput. That is why it has stayed in engineering use for decades: often what you need is not a more complex link, but a channel that works as long as both sides agree on the parameters.

1-Wire

In some device scenarios, the first engineering pain is not throughput, and not even many high-speed peripherals. It is that wiring itself is too expensive. Temperature probes may be spread out, a chassis may only tolerate a few wires, and a single controller may need to drive a few simple sensors. In that situation, even I2C’s two signal lines can feel like too many, let alone a dedicated chip-select line for each device.

When a board needs to connect a few low-speed peripherals, the first problem is often not “how do we move more data?” but “how do we use fewer wires and fewer pins while still letting multiple chips work together?” Temperature sensors, EEPROMs, RTCs, and power-management chips are not high-throughput devices, but they all need to be accessed by the host. If every extra chip needs its own dedicated wire set, cost, routing, and packaging pressure rise quickly.

CAN

People often remember CAN through a few surface facts first: two wires, differential signaling, 1 Mbps, common in cars, and no traditional source or destination address in the frame. Those facts are true, but they are not enough for implementation, packet capture, or debugging. What really defines CAN is not what it looks like, but how it lets many nodes watch the same wire and still keep working when they try to send at the same time.

SPI

Not every board-level peripheral link is worth squeezing into a shared-arbitration model like I2C just to save two wires. Devices like Flash, ADCs, and display controllers often care about something else: can the host send a stream of bits steadily, quickly, and directly, then get the result back?

SPI solves exactly that kind of problem. It optimizes first for clear timing, higher throughput, and simple controller implementation rather than for pin savings when many devices share the bus. If I2C tries to keep order on two shared wires, SPI goes the other way: it gives the master stronger control first, then accepts the cost of more wires and weaker scalability.