Choosing the Right Embedded Protocol - A Practical Decision Guide
Every protocol in this series makes different trade-offs. Speed, distance, node count, noise immunity, wiring cost. here is a structured way to think through the decision for your specific project.
Choosing the Right Embedded Protocol. A Practical Decision Guide
There's no universally correct answer to "which protocol should I use?" Anyone who tells you there is has either only built one kind of thing or isn't being honest. But there is a structured way to think through the trade-offs that leads to a defensible decision quickly.
The comparison table
| Protocol | Typical speed | Range | Nodes | Wires | Duplex | Noise immunity |
|---|---|---|---|---|---|---|
| UART | 115kbps – 4Mbps | <1m TTL | 2 only | 2+GND | Full | Low |
| SPI | 1 – 80+ Mbps | <30cm | 1M + N slaves | 4+1/slave | Full | Low |
| I2C | 100kHz – 1MHz | <1m | 127 | 2+GND | Half | Low |
| CAN | 125kbps – 8Mbps (FD) | 40m @ 1Mbps | ~110 | 2 diff + GND | Half | Very high |
| RS-485 | 100kbps – 10Mbps | 1200m | 32–256 | 2 diff + GND | Half | High |
Decision flowchart
Rendering diagram...
Concrete rules by use case
UART for: anything that came with an AT command set or a debug port. GPS modules, cellular modems, ESP-AT firmware, Bluetooth classic modules, serial consoles. Not for multi-device buses.
SPI for: anything that needs speed and is close by. Display drivers (ST7789, ILI9341), flash and EEPROM (W25Q, AT25), high-speed ADCs and DACs, SD cards, RF transceivers (CC1101, nRF24L01). One CS pin per device.
I2C for: sensors. Temperature (BME280, TMP117), IMUs (BNO055, ICM-20948), RTC (DS3231), gas gauges, small OLEDs. Speed doesn't matter much, wire count does. If you're connecting more than 4–5 external I2C devices, think about address conflicts before you start ordering parts.
CAN for: anything in a vehicle, anything with multiple nodes that all need to publish data simultaneously, anything in a high-vibration or high-noise environment where you genuinely need fault confinement. CAN transceivers are cheap. Use CAN FD if the design is new. the cost is identical.
RS-485 for: PLCs, energy meters, VFDs, flow meters, anything with an RJ45-Modbus connector. Required when cable runs exceed a few metres and the other end is industrial equipment. Also the right choice for connecting embedded nodes in a factory cell where CAN's arbitration complexity is unnecessary and Modbus polling is sufficient.
The questions that matter most
Before choosing, answer these:
-
How far does the signal travel? Under 30cm → SPI or I2C. Under 1m → UART or I2C. Metres → CAN or RS-485. Hundreds of metres → RS-485.
-
How many devices? Two → UART or SPI. Up to 15 on-board → I2C or SPI. Dozens over a cable → CAN or RS-485.
-
Does noise matter? Office/lab environment → any of them. Automotive/industrial → CAN or RS-485 only.
-
Do multiple nodes send spontaneously, or is one always in charge? Spontaneous multi-master → CAN. Master-slave polling → Modbus/RS-485 or I2C.
-
What does the other device already speak? If it ships with a Modbus address map, use RS-485. If it ships with an SPI datasheet, use SPI. Don't fight existing standards.
Final thought
The protocols in this series have stayed dominant for decades because they're genuinely good fits for their problem domains. not because nobody invented anything better. UART is still alive because a module that speaks a serial AT interface is dead simple to integrate. Modbus is still in every factory because it works, the tools exist, and the installed base is enormous. CAN is in every car because no replacement has offered a better cost-to-robustness ratio at automotive volumes.
When you're choosing, optimise for the simplest thing that will actually work reliably in the environment it'll live in. That's usually the right call.