← Roadmap/Robotics Infrastructure

Embedded & Real-Time

Microcontrollers, RTOS, timing — robots in real time.

Progress0/6 questions

hardRobotics InfrastructureSkip to practice questions ↓

Prerequisites

Actuators & Motors Sensors & How They Work

Why it matters in robotics

Robots run on embedded controllers, where real-time behavior beneath the high-level stack decides whether control loops meet their deadlines. Hardware events can pause running code to be serviced immediately, so that handler must stay short, and a scheduler decides which of several competing tasks runs next; what matters is a bounded worst-case delay and consistent timing, not average throughput, along with the problem of a high-priority task getting stuck waiting on a low-priority one, and the tradeoffs between common communication buses for connecting sensors and motor drivers. Thinking in terms of preemption, bounded latency, and shared-resource contention is what keeps a control loop deterministic.

What to study

✓Polling (fixed-rate) vs. interrupt-driven (event-based) I/O — the fundamental tradeoff in latency, CPU cost, and determinism — plus ISR latency, keeping ISRs short, volatile/shared-data hazards, and hardware timers for periodic control loops and PWM.
✓RTOS scheduling: fixed-priority preemptive scheduling, round-robin time-slicing, priority inversion and priority inheritance, jitter, and choosing task priorities for a control loop.
✓Real-time determinism: hard vs soft deadlines, worst-case execution time and latency, sources of jitter, and how to budget a periodic loop so it never misses its deadline.
✓Communication buses: CAN (arbitration, differential, multi-node), I2C (addressing, multi-device, pull-ups), SPI (full-duplex, chip-select, speed), and UART (async, framing) — and when to pick each.

Where to study

Cheatsheet

Symbols used below

C

task worst-case execution time (WCET)

T

task period

U

CPU utilization,

\sum C_i / T_i

n

number of periodic tasks

Polling vs. interrupts

Polling burns CPU checking a flag on a fixed schedule — simple and jitter-free, but latency is bounded by the poll period, and it wastes cycles when nothing changed.

Interrupts react immediately when the hardware event fires, so they save CPU and cut latency, but ISR code must stay short (do the minimum, then defer real work to a task) and any data it shares with normal code needs to be `volatile` and protected — a variable updated inside an ISR can change between any two instructions of the main code that reads it.

Rate-monotonic schedulability

Fixed-priority preemptive scheduling: shorter-period tasks get higher priority (rate-monotonic). A task set of $n$ tasks is guaranteed schedulable if

$U = \sum_{i=1}^n \frac{C_i}{T_i} \le n(2^{1/n}-1)$

The bound shrinks from 1.0 ( $n{=}1$ ) toward $\ln 2 \approx 0.69$ as $n \to \infty$ — so more tasks means you need more slack, not less, to guarantee every deadline is met.

Priority inversion and inheritance

A high-priority task blocks on a mutex held by a low-priority task, and an unrelated medium-priority task preempts the low-priority holder — the high-priority task now waits on a task it doesn't even depend on, for unbounded time.

Priority inheritance fixes this: the lock holder is temporarily boosted to the waiter's priority so it finishes and releases the resource quickly. This is exactly what happened to the Mars Pathfinder in 1997.

Hard vs. soft real-time

Hard deadline: missing it is a system failure (an airbag controller, a motor commutation loop). Soft deadline: missing it degrades quality but the system survives (a video frame arriving late).

What's being bounded is the *worst case*, not the average — a control loop that's on time 99.9% of the time but occasionally misses by 50 ms is not real-time if that miss is unacceptable even once.

Bus tradeoffs

CAN: multi-drop differential pair, message-based with priority arbitration (lowest ID wins, non-destructive), tens of kbps to 1 Mbps (up to 5+ Mbps for CAN FD) — the standard for distributed control on a car or robot.

I2C: 2-wire (SDA/SCL) multi-device bus with 7-bit addressing and pull-up resistors, ~100 kHz–3.4 MHz, good for many low-speed sensors on short board-level runs.

SPI: full-duplex, one chip-select line per device, no addressing needed, fastest of the four (10s of MHz) — good for high-rate sensors like IMUs but doesn't scale to many devices or long cables.

UART: simple async point-to-point (TX/RX, no shared clock), framed by start/stop bits — used for debug consoles and point-to-point links, not a real multi-node bus.

	CAN	I2C	SPI	UART
Topology	Multi-drop bus	Multi-drop bus	Star (one CS per device)	Point-to-point
Wires	2 (differential)	2 (SDA, SCL)	4+ (MOSI, MISO, SCK, CS)	2 (TX, RX)
Typical speed	≤1 Mbps (5+ Mbps FD)	100 kHz–3.4 MHz	10s of MHz	Up to ~1 Mbps
Arbitration	Priority-based, non-destructive	Software addressing	None (dedicated CS)	None (dedicated link)
Best for	Distributed control, fault tolerance	Many low-speed sensors	High-rate single sensor/actuator	Debug console, simple links

Application focus

Select an application above.