Embedded Communication Protocols

CH01 · ON-BOARD

Chips on the same board

When multiple chips (a sensor, EEPROM, display) sit on one board, distance is measured in centimeters. Speed and simplicity matter most here.

I2C 2 wires

Master–Slave · a few cm · dozens of devices

Addressed communication over SDA/SCL. The standard choice for reading sensors, RTCs, and EEPROMs.

SPI 4 wires

Master–Slave · a few cm · high speed

Faster than I2C and synchronous. SD cards, displays, and CAN controllers like the MCP2515 connect to the MCU over SPI.

1-Wire 1 wire

Single line · a few meters

Data (and sometimes power) on one wire. DS18B20-style temperature sensors are the classic example.

CH02 · BOARD-TO-BOARD

An ESP32 ↔ BBB style link

Boards are now physically separate — distance is measured in meters. Reliability and noise immunity take priority.

Protocol	Connection type	Device count	Distance	Purpose
UART	Point-to-point (1-1)	2	A few meters	Simple, direct serial transfer between two devices
I2C	Master-Slave, same board	Dozens	A few cm	Addressing sensors/chips on the same board
CAN	Multi-master bus	Dozens	~40 m	Reliable, bidirectional board-to-board link in noisy environments
RS-485	Multi-drop bus	Dozens	~1200 m	Industrial sensor/PLC network via Modbus RTU
LIN	Master-Slave bus	~16	~20 m	Cheaper, lower-speed alternative to CAN for in-vehicle actuators

100 kbit/s note: both ends of a CAN bus must run at the same baud rate — matching TWAI_TIMING_CONFIG_100KBITS() on the ESP32 with ip link set can0 type can bitrate 100000 on the BBB.

CH03 · NETWORK / INTERNET

Where the board opens up to the outside world

No longer a physical wire — TCP/IP over WiFi or Ethernet. No distance limit; setup and messaging take center stage.

SmartConfig WiFi

Phone → board · UDP broadcast

The phone broadcasts SSID/password over the air; the ESP32 listens and joins the network.

MQTT TCP/IP

Board → Broker · Publish/Subscribe

The standard way to move CAN data to the cloud or a dashboard.

BLE short range

Phone ↔ board · low power

Built into the ESP32. An alternative to SmartConfig for short-range setup and control.

HTTP/HTTPS TCP/IP

Board ↔ Server · request/response

For one-off requests to REST APIs; MQTT is preferred for continuous streams.

CoAP UDP

Board ↔ Server · lightweight

Similar to MQTT but lighter — used on constrained IoT devices.

WebSocket TCP/IP

Board ↔ Dashboard · persistent link

Real-time, bidirectional dashboards — an alternative to MQTT.

CH04 · VIDEO OUTPUT

Board → monitor (one-way)

Unlike the others, these aren't a two-way messaging protocol — just one-way video output. Only present on the BBB, not the ESP32.

HDMI one-way

BBB → Monitor

Displaying the Debian desktop, or a live log screen, directly.

DisplayPort one-way

Board → Monitor

The professional / monitor-side counterpart to HDMI.

MIPI DSI one-way

SoC → LCD/OLED panel

The low-level protocol small display modules use to connect directly to the SoC.

CH05 · CAT5 CARRIER

One cable, several protocols

Cat5 isn't a protocol on its own — it's a carrier. The same cable can carry several protocols using different pairs or signal levels.

Protocol	How it rides on Cat5	Feasible on embedded	Extra hardware
Ethernet	Directly over RJ45	Yes	Already on the BBB; needs an external PHY (LAN8720) on the ESP32
CAN	One twisted pair as CAN_H/CAN_L	Yes	The same CAN transceiver you already use — only the cable changes
RS-485	One differential twisted pair	Yes	UART + MAX485 transceiver
PoE	Power + data over unused pairs	Yes	PoE HAT on the BBB; external PoE module on the ESP32
HDMI/USB extender	Via a balun/extender chip	Partly	Implemented in an external extender box, not on the board itself

CH06 · PROJECT MAP

Board ↔ user-screen pairing

How the board "shows up" to the user varies across LogicLab's project ideas.

Project	Board	User screen	Connection method
OBD-II gateway	ESP32	In-car / external dashboard	OBD-II cable (CAN) + WiFi/MQTT
HIL test rig	BBB / ESP32	Monitor or computer	HDMI or UART/USB terminal
CAN fuzzer + logger	BBB	Terminal / log screen	UART/USB terminal or live HDMI log
CAN → MQTT bridge	ESP32 / BBB	Web dashboard, phone	WiFi + MQTT → Grafana/Node-RED
AUTOSAR BSW prototype	ESP32 / BBB	Diagnostic terminal	UART/USB terminal debug output

CH07 · BIT RATE

Typical speed values by protocol

Every protocol has its own standard speed tiers. The rule is always the same: both ends of the line have to agree on the same value, or data gets read wrong — or not at all.

Protocol	Typical speed values	Note
UART	9600 · 19200 · 38400 · 57600 · 115200 bps	Must match exactly on both devices; debug output usually runs at 115200
I2C	100 kHz · 400 kHz (Fast) · 1 MHz (Fast+)	Set by the master; must not exceed what the slave supports
SPI	A few MHz – 50+ MHz	Upper limit set by the chip's datasheet
CAN	100 kbit/s · 125 kbit/s · 250 kbit/s · 500 kbit/s · 1 Mbit/s	Standard ISO 11898 tiers; must match exactly across every node
RS-485 (Modbus)	9600 · 19200 · 115200 bps	Modbus RTU typically runs at 9600 or 19200
LIN	19.2 kbit/s (upper limit)	Usually runs at 9.6 or 19.2 kbit/s
Ethernet	10 · 100 · 1000 Mbit/s	The BBB's RJ45 port supports 10/100 Mbit/s
WiFi (802.11n/ac)	Tens to hundreds of Mbit/s	MQTT traffic uses only a small fraction of this

If you see two speed values in the code: opening main.cpp in VS Code / PlatformIO, you'll usually run into two different speed lines — these belong to two separate physical links, not one.

Serial.begin(115200);   // (1) Computer <-> board — UART/USB, debug output only

TWAI_TIMING_CONFIG_100KBITS();  // (2) Board <-> board — CAN bus, the actual data link

(1) is always the UART/USB serial link between your computer and the board — it exists purely so you can read text in the Serial Monitor; it doesn't need to match anything on another board.

(2) is the real communication line between boards, and it can be CAN, I2C, SPI, or even another UART (board-to-board) — depending on which protocol you're using. If two boards talk over UART, for instance, you'll see a second line like Serial1.begin(9600); — that one is entirely independent from the computer-board line, and it's the line that must match the other board exactly.

In short: however many different speed lines show up in the code, that's how many separate physical links there are. To tell which line belongs to which link, just check the object/function name (Serial vs Serial1/Serial2 vs twai_/CAN. vs Wire.).