Microcontroller vs embedded Linux vs SoC

1. Engineering problem

A motor control loop wants predictable timing; perception wants a lot of compute and software. One processor rarely does both well. The choice sets the toolchain, the debugging tools and what can fail.

2. When is this needed?

• At architecture selection for each subsystem.
• When a control loop misses its deadline on a general-purpose computer.
• When a microcontroller runs out of memory or speed.

3. Selection and design decisions

General characteristics; confirm on the datasheet and board documentation of your parts.

4. Advantages and disadvantages

• One board vs two: one board saves hardware and puts hard-timing loops on a non-real-time OS; two boards cost a link and a protocol.
• RTOS vs bare metal: an RTOS adds scheduling and drivers for a small overhead; bare metal is simplest for one loop.
• Vendor stack lock-in for accelerators.

5. Requirements and constraints

• Loop CPU load ≤ about 50 % of one core on the microcontroller (a margin chosen here, not a standard).
• Memory for code, stacks and buffers fits with margin.
• Interfaces needed (CAN, SPI, Ethernet) exist as hardware peripherals.

6. Architecture

sensors ─▶ microcontroller (control loops, safety I/O) ──CAN/UART/Ethernet──▶ Linux computer (ROS 2, planning, perception)

7. Implementation

1. List the real-time loops with rate and deadline and the compute-heavy tasks.
2. Assign hard-timing loops to a microcontroller and heavy tasks to Linux or a SoC.
3. Estimate the CPU load of each loop from cycles per iteration (below) on the candidate clock.
4. Choose the link between them and its message rate.
5. Keep a safe state that does not depend on the Linux side.

def cpu_load(cycles_per_iter, rate_hz, clock_hz):
    return cycles_per_iter * rate_hz / clock_hz
for name, clk in (("MCU 72 MHz", 72e6), ("MCU 168 MHz", 168e6)):
    u = cpu_load(18000, 1000, clk)
    print(f"{name}: 1 kHz loop of 18000 cycles uses {u * 100:.1f} % of one core", "-> ok" if u <= 0.5 else "-> too tight")

Printed (checked by the site’s tests):

MCU 72 MHz: 1 kHz loop of 18000 cycles uses 25.0 % of one core -> ok
MCU 168 MHz: 1 kHz loop of 18000 cycles uses 10.7 % of one core -> ok

Reading it: a 1 kHz loop of 18 000 cycles needs 18 million cycles per second, which is 25 % of a 72 MHz core and 10.7 % of a 168 MHz core. Both are inside the 50 % margin. The cycle count is illustrative: measure yours on the target.

8. Real examples

• AMR: a microcontroller runs wheel velocity control and the emergency-stop path; a Linux computer runs navigation.

9. Failure scenarios

• A velocity loop on a non-real-time OS that misses deadlines under load.
• A microcontroller loop that uses 95 % of its core, so any added feature breaks timing.
• No safe state when the Linux side crashes.

10. Troubleshooting

1. If a loop jitters, measure its period and the CPU load.
2. If memory runs out, check stack sizes and buffers.
3. If the link is the bottleneck, compute its payload rate.

11. Validation

• The load example prints the lines shown (executed by the site tests).
• The measured loop period error stays within the requirement under full load.

12. Engineering checklist

• Real-time loops listed
• Heavy tasks listed
• Load computed on the real clock
• Memory budget
• Peripherals present
• Safe state defined

13. Further references

• Datasheets and reference manuals of the candidate processors (clock, memory, peripherals).

Related on FixTheRobot

• Front-End and Back-End SLAM SLAM · Lesson