Embedded architectures

P1. The budget.

‍​‌‌​​‌‌​​‌‌‌​​‌​​‌‌​​‌​‌​‌‌​​‌​‌​​‌​‌‌​‌​‌‌‌​​‌‌​‌‌​​​​‌​‌‌​‌‌​‌​‌‌‌​​​​​‌‌​‌‌​​​‌‌​​‌​‌‍It fits, using 46 percent of 20 KB, leaving 10.7 KB of margin. Comfortable, and comfortable is the right target: a device that fits in 95 percent of its RAM has no room for the next feature, no room for a deeper call path in an error handler, and no margin for the stack being deeper than measured.

Which item to attack first if it did not fit: the filesystem scratch area, 2 KB.

Not because it is the largest (the stack is), but because it is the one whose size is a choice rather than a consequence. A scratch buffer is usually sized to a convenient round number rather than to a requirement, and halving it costs nothing but a few more read-modify-write cycles.

The order after that: the transmit buffer (1 KB is often more than the link needs, and reducing it costs throughput, not correctness), then the ADC ring buffer (its depth is set by how long the consumer may be delayed, which is a measurable number rather than a guess), and the stack last, because reducing the stack means restructuring code.

What happens at run time when RAM is exceeded by 200 bytes.

This is the part worth being precise about, because it is not what a PC programmer expects.

‍​‌‌​​‌‌​​‌‌‌​​‌​​‌‌​​‌​‌​‌‌​​‌​‌​​‌​‌‌​‌​‌‌‌​​‌‌​‌‌​​​​‌​‌‌​‌‌​‌​‌‌‌​​​​​‌‌​‌‌​​​‌‌​​‌​‌‍The linker usually does not tell you. Statics are allocated at link time and the linker will report an overflow of the data section: that case is caught. The dangerous case is the stack, which is allocated at run time and typically grows downward from the top of RAM toward the statics growing up. Nothing checks that they have met.

So the 200 bytes are consumed silently, and the deepest call path writes 200 bytes over the top of your statics. The symptom is:

• A variable somewhere in the program changes value for no reason, at a moment unrelated to any code that touches it
• The corruption depends on the call depth, so it only happens on the error path, or only when an interrupt fires during a particular function, or only once the device has been running long enough to hit an unusual branch
• It is not reproducible, and it appears to be a different bug each time depending on which variable happened to be at that address

This is why embedded practice puts three defences in place that a hosted program does not need:

• Fill the stack region with a known pattern at startup and check at run time how far down the pattern has been overwritten. That converts "how much stack do I use" from a guess into a measurement, and it is a dozen lines of code
• ‍​‌‌​​‌‌​​‌‌‌​​‌​​‌‌​​‌​‌​‌‌​​‌​‌​​‌​‌‌​‌​‌‌‌​​‌‌​‌‌​​​​‌​‌‌​‌‌​‌​‌‌‌​​​​​‌‌​‌‌​​​‌‌​​‌​‌‍Enable the MPU or a stack guard region where the hardware has one, so a stack overflow faults immediately at the point of the overflow rather than corrupting data silently
• Avoid dynamic allocation entirely. malloc in a 20 KB device fragments, has no failure path anybody tests, and makes the worst-case memory use impossible to compute statically. Static allocation means the linker's map file is the truth

P2. (a) Motor current loop, 20 kHz, 2 microsecond jitter: MCU, bare metal or a small RTOS.

‍​‌‌​​‌‌​​‌‌‌​​‌​​‌‌​​‌​‌​‌‌​​‌​‌​​‌​‌‌​‌​‌‌‌​​‌‌​‌‌​​​​‌​‌‌​‌‌​‌​‌‌‌​​​​​‌‌​‌‌​​​‌‌​​‌​‌‍The deciding number: 2 microseconds of jitter on a 50 microsecond period, which is 4 percent.

An MCU running a timer-triggered interrupt has interrupt latency of a few hundred nanoseconds, deterministic and bounded, because there is no cache, no MMU, no scheduler and no other process. Jitter is dominated by whether a longer instruction is executing when the interrupt arrives: tens of nanoseconds.

What an MPU running Linux would do instead: even with PREEMPT_RT, interrupt latency is typically tens of microseconds with occasional excursions into hundreds, because of cache misses, TLB misses, and the scheduler. The occasional excursion is the killer: a control loop that meets its deadline 99.99 percent of the time and misses it by 200 microseconds once a second has a torque glitch once a second, which the motor turns into audible noise and the mechanism turns into wear.

(b) Vision, 10 fps object detection on 640 by 480: MPU, running Linux.

The deciding number: memory. A single 640 by 480 RGB frame is 921 600 bytes. A detector needs several frames plus intermediate tensors plus the model weights, so hundreds of megabytes. ‍​‌‌​​‌‌​​‌‌‌​​‌​​‌‌​​‌​‌​‌‌​​‌​‌​​‌​‌‌​‌​‌‌‌​​‌‌​‌‌​​​​‌​‌‌​‌‌​‌​‌‌‌​​​​​‌‌​‌‌​​​‌‌​​‌​‌‍An MCU with 20 KB, or even 512 KB, cannot hold one frame, let alone run inference on it.

Beyond memory: the software stack. OpenCV, a neural network runtime, camera drivers and a filesystem are Linux software, and porting them to bare metal is not a project anyone should undertake.

What an MCU would do instead: nothing. This is not a performance trade-off, it is a capability boundary. The honest MCU version of this task is a much smaller model on a much smaller image, which is a different product.

(c) Battery management, 8 cells at 1 Hz, five years on a coin cell: MCU, deeply sleeping.

The deciding number: average current. A CR2032 holds about 220 mAh. Five years is 43 800 hours, so the average current must be under 220 / 43 800 = 5 microamps, and that has to include self-discharge, so the budget is really 2 to 3 microamps.

That is achievable only by being asleep essentially all the time: an MCU in deep sleep draws 1 to 2 microamps, wakes on a timer, reads eight channels in a few milliseconds, and sleeps again. The duty cycle is on the order of 0.1 percent.

‍​‌‌​​‌‌​​‌‌‌​​‌​​‌‌​​‌​‌​‌‌​​‌​‌​​‌​‌‌​‌​‌‌‌​​‌‌​‌‌​​​​‌​‌‌​‌‌​‌​‌‌‌​​​​​‌‌​‌‌​​​‌‌​​‌​‌‍What an MPU would do instead: an MPU running Linux idles at tens to hundreds of milliamps, cannot deep-sleep in the same sense (its DRAM must stay refreshed), and takes seconds to boot, so it cannot wake-work-sleep on a 1 second cycle. The coin cell would last hours.

The pattern across the three. The choice is never "MCU is simpler" or "MPU is more capable". It is decided by whichever of these three is binding:

• Determinism, measured in microseconds of jitter: MCU
• Memory and software ecosystem, measured in megabytes and in which libraries exist: MPU
• Average power, measured in microamps: MCU

And a real robot has all three requirements in different places, which is why it has both, and why the interesting engineering is the link between them.

P3.

Two entries in that table are worth dwelling on.

The const table costs no RAM at all, because the processor can fetch from Flash directly. This is the single most useful fact in the model: on a device with 128 KB of Flash and 20 KB of RAM, Flash is six times more plentiful, so anything constant should be there. Drop the const and the table becomes a RAM variable that is initialised from Flash at startup, costing 4 KB of RAM and 4 KB of Flash: it consumes 20 percent of the device's RAM to gain nothing.

An initialised global costs both. The value has to be stored somewhere while the power is off, so it sits in Flash, and the startup code copies it into RAM before main runs. An uninitialised global (or one initialised to zero) goes in .bss‍​‌‌​​‌‌​​‌‌‌​​‌​​‌‌​​‌​‌​‌‌​​‌​‌​​‌​‌‌​‌​‌‌‌​​‌‌​‌‌​​​​‌​‌‌​‌‌​‌​‌‌‌​​​​​‌‌​‌‌​​​‌‌​​‌​‌‍, which costs RAM but no Flash, because the startup code just zeroes it.

The two habits that follow.

Habit 1: mark everything that does not change as const, and check the map file.

What it prevents: silent RAM consumption by data that never needed to be there. Lookup tables, string tables, configuration defaults, font data, calibration curves. On a constrained device this routinely recovers several kilobytes, which is a large fraction of the budget.

The check is the linker's map file, which reports the size of .text (code and constants in Flash), .data (initialised RAM, costing both) and .bss (zero-initialised RAM). Reading the map file after every build is the embedded equivalent of watching a test suite: it is the only place the truth about memory appears, and a 2 KB jump in .bss between two commits is a question worth asking on the day it happens rather than three months later.

Habit 2: allocate statically, never dynamically.

What it prevents: three distinct failures that all look like the same mysterious hang.

• ‍​‌‌​​‌‌​​‌‌‌​​‌​​‌‌​​‌​‌​‌‌​​‌​‌​​‌​‌‌​‌​‌‌‌​​‌‌​‌‌​​​​‌​‌‌​‌‌​‌​‌‌‌​​​​​‌‌​‌‌​​​‌‌​​‌​‌‍Fragmentation. Repeated allocation and freeing of different sizes leaves a heap with enough total free space and no contiguous block large enough. On a device that runs for months, this is a matter of when, not whether
• An untested failure path. malloc returning null is a case almost nobody handles correctly, because it never happens in testing and always happens in the field
• Unanalysable worst case. With static allocation, the linker map tells you the exact memory use, forever. With a heap, the worst case depends on the sequence of allocations, which depends on the sequence of events, which cannot be enumerated

The static version is a fixed pool sized at design time: static uint8_t buffers[N][SIZE]; with an index, or a fixed-capacity ring. It is less elegant and it is computable, and on a device with no display, no console and no operator, computable is worth more than elegant.

Both habits come from the same root: on an embedded device the memory is a fixed resource with no virtual memory, no swap and no operating system to arbitrate it. What you have is what the linker says you have, and every technique above exists to make that number knowable before the device ships.