A Love Letter To Embedded Systems By V. Hunter Adams

Why Adams’ “Love Letter” Hits So Hard

Adams’ message lands because it treats embedded engineering like a creative craft, not a job title.
He’s not just saying “embedded is useful.” He’s saying embedded is meaningfulbecause it lets
you build complete, understandable systems that touch the physical world.

There’s also something refreshingly human in his framing. He pulls in ideas from outside engineering
(yes, including birds and birdsong, and yes, the legendary “how did Leonardo da Vinci have time for
all that?” energy) to point out a truth we don’t say enough: the best engineers are often curious
generalists who use projects as a way to learn everything else.

And embedded projects are uniquely good at that, because they force you to care about constraints
timing, memory, power, noise, heat, costwithout becoming so massive that you need a small committee
and three cloud dashboards to understand what’s happening.

Embedded Systems, Explained Like You’re Not Trying to Impress Anyone

An embedded system is a computer built into a bigger device to do a dedicated job. It’s not trying to
be your laptop. It’s trying to be the world’s most reliable button reader, motor controller, sensor
sampler, packet router, or “please don’t let the airbag deploy late” decision-maker.

Most modern embedded devices use microcontrollers: chips that combine a CPU with memory and
peripherals (timers, ADCs, serial interfaces, GPIO). You write firmware that configures those
peripherals and reacts to the outside worldoften with real-time requirements.

That’s the core romance: embedded systems are where software stops being purely virtual and starts
behaving like a physical tool. Your code becomes a tiny set of rules that govern a tiny universe.
And your universe will absolutely punish you for ignoring physics.

Constraints Are Not a BuzzkillThey’re the Point

In Adams’ “love letter,” constraints aren’t framed as limitations. They’re framed as creative structure
like the rules of a sonnet. You don’t get infinite RAM, infinite CPU, infinite battery, or infinite time.
You get a box. And inside that box, you make something elegant.

Memory: Where Your Ambitions Meet 64 KB

Embedded memory budgets have a way of turning “clean architecture” into “okay but can this fit in flash?”
You learn to love tight data structures, fixed-size buffers, and the comforting honesty of knowing
exactly where your bytes are going.

• Static allocation becomes your friend when predictability matters.
• Copying less becomes a performance strategy, not just a micro-optimization.
• Logging becomes a careful negotiation with storage and bandwidth.

The best part: the constraints force you to understand your system at a deeper level. You don’t just
“use a library.” You understand why it costs what it costs.

Timing: Deadlines, Latency, and the Art of Not Being Late

“Real-time” doesn’t mean “fast.” It means “predictable.” The system needs to respond within a known
deadline, and it needs to keep doing that reliably.

Some deadlines are hard (miss it and people can get hurt). Some are soft
(miss it and your user gets annoyed). Many are “firm-ish” (miss it and the data becomes useless).
Embedded engineers spend a lot of time designing so the worst-case behavior is still acceptable.

This is why embedded folks talk about latency and jitter like they’re
characters in a drama series. Because they are.

Power: The Battery Is Always Watching

Power constraints make you clever. You stop thinking “run code” and start thinking “sleep until
something important happens.” You use interrupts to wake the CPU, timers to schedule work,
and low-power modes to keep the device alive long enough to be useful.

If cloud engineering is about scaling up, embedded is often about chilling outpolitely, efficiently,
and with minimal current draw.

The “Right-Sized” Complexity Advantage

One of the most compelling points in Adams’ talk is that embedded systems often sit at a sweet spot:
complex enough to be interesting, but small enough that you can still understand the whole thing.

That matters. In a world where software stacks can span dozens of services and countless dependencies,
it’s refreshing to build something where the boundaries are clear: pins, buses, interrupts, tasks,
buffers, drivers, and the physical signal you can literally see on a scope.

This is also why embedded projects are such powerful learning engines. You can’t hide behind abstractions
forever. Eventually you have to answer questions like:

• What is the clock rate and where does it come from?
• What happens on an interrupt, mechanically?
• How do you avoid missing an event when two things happen “at the same time”?
• What does your system do in the worst case, not the average case?

Where Software Touches Physics (And Physics Touches Back)

Embedded systems are basically a treaty between code and reality. Sensors turn the world into signals.
Actuators turn signals into motion, heat, light, sound, and sometimes mild chaos.

Example: Sampling a Sensor and Driving an Output

Imagine a simple closed-loop system:

1. Sample a temperature sensor (analog input → ADC).
2. Filter the reading (because the world is noisy).
3. Adjust a fan speed (PWM output).
4. Repeat at a fixed rate (timer interrupt or RTOS task).

This is “basic” embedded work, and it contains more real engineering than people give it credit for:
signal conditioning, sampling theory, timing, control behavior, and careful handling of edge cases.
It’s also incredibly satisfying when it works, because you can feel the system respond.

A lot of embedded education emphasizes these fundamentals: UART/SPI communication, periodic interrupts,
ADCs, FIFO queues, and the ability to reason about the whole control loop end-to-end.
That skillthinking in systemsis the superpower Adams is trying to spread.

Interrupts and DMA: Two Ways to Stay Sane Under Pressure

Embedded systems are event-driven by nature. Buttons get pressed, packets arrive, timers tick,
sensors complete conversions. If you try to handle everything by constantly polling, you’ll waste CPU,
burn power, and still somehow miss the one event that matters.

Interrupts: “Hey! Deal With This. Now.”

At a high level, an interrupt sets a flag, jumps to an interrupt service routine (ISR), and returns.
The key is discipline: keep ISRs short, do the minimum work needed, and hand off heavier processing
to the main loop or an RTOS task.

A classic beginner moment is learning that “enabling an interrupt” implies “you now owe the chip an ISR.”
The chip is not being dramatic. It is simply holding you to your commitments.

DMA: “Move the Data Without Bothering the CPU”

Direct Memory Access (DMA) is what you use when you want data moved efficientlyADC samples into a buffer,
SPI bytes into memory, audio frames into a ring bufferwithout interrupting the CPU for every byte.

Done well, DMA reduces jitter and frees the CPU for actual decisions. Done poorly, DMA becomes a haunted
house of race conditions: half-full buffers, missed events, and “why is this pointer sometimes wrong?”

Mature DMA implementations usually include a completion interrupt and a clear workflow for servicing it:
handle the event, clear the interrupt, and ensure you don’t miss pending work that arrived while you
were inside the ISR. It’s not glamorous, but it’s the kind of detail that turns fragile demos into
robust systems.

RTOS vs Bare-Metal: Choosing Your Flavor of Control

Not every embedded project needs a real-time operating system. Many systems are perfectly happy with a
well-structured “superloop” plus interrupts.

But as requirements growmultiple periodic activities, communication stacks, UI, control loops, logging,
safety monitoringan RTOS can make the system easier to reason about. An RTOS helps by structuring work
into tasks with priorities and predictable scheduling behavior.

What an RTOS Actually Buys You

• Determinism: predictable scheduling under known conditions.
• Priorities: critical work preempts less important work.
• Synchronization: queues, semaphores, mutexes for safe sharing.
• Timing tools: delays, periodic tasks, timeouts.

A common RTOS pattern is: do quick work in an ISR, then signal a task to do the heavier processing.
This keeps interrupt latency low while preserving responsiveness.

The Cautionary Tale: Priority Inversion (a.k.a. “How Mars Almost Got Taken Out by a Mutex”)

Priority inversion happens when a high-priority task gets blocked waiting for a resource held by a
low-priority task, and then a medium-priority task prevents the low-priority task from running long
enough to release the resource. The result: the “important” thing waits behind the “less important” thing,
while the “moderately important” thing hogs the CPU. It’s as rude as it sounds.

The famous case involves the Mars Pathfinder mission, where resets were traced back to a priority inversion
scenario involving a shared “information bus” protected by a mutex. The fix included enabling priority
inheritanceallowing the low-priority task holding the mutex to temporarily inherit a higher priority so it
could finish and release the lock.

The lesson isn’t “RTOS bad.” The lesson is: in embedded systems, design details matter.
A one-line configuration choice can be the difference between “flawless mission” and “why did it reboot again?”

Debugging Is Part of the Love Story

Embedded debugging is not just printing logs. Sometimes there’s no console. Sometimes your bug
disappears when you add a printf. Sometimes the system crashes so early you can’t even blink an LED
to scream for help.

So you learn the classic embedded toolchain romance:

• Oscilloscope: because the signal never lies (it just quietly humiliates you).
• Logic analyzer: because serial buses are innocent until proven guilty.
• JTAG/SWD debugger: because single-stepping can be therapy.
• Tracing: because timelines reveal the real story.

One of the most practical “love letter” lessons: build systems with observability. Leave yourself hooks.
A trace buffer. A way to toggle internal state. A safe-mode boot option. A method to update firmware
when something goes wrong. Future-you will write you a thank-you note.

How to Start Your Own Embedded “Love Letter” Project

Adams emphasizes getting started with projectsnot because projects are trendy, but because projects make
knowledge stick. If you want a roadmap, here’s one that grows your skills without requiring you to become
a full-time wizard on day one.

Stage 1: Blink and Believe

• Blink an LED (GPIO output).
• Read a button (GPIO input) and handle debouncing.
• Use a timer to blink at an exact frequency.

Stage 2: Sense the World

• Read an analog sensor (ADC) and do basic filtering.
• Talk to a digital sensor over I2C or SPI.
• Log values over UART so you can graph them.

Stage 3: Act on the World

• Drive a motor or servo using PWM.
• Control something with a closed loop (even a simple one).
• Handle faults (timeouts, missing sensors, unplugged cables).

Stage 4: Get Fancy (But Stay Honest)

• Add a communication interface (BLE, Wi-Fi, CAN, USB).
• Use DMA to reduce CPU load and jitter.
• Introduce an RTOS when coordination gets complex.

If you do this progression, you’ll gain something bigger than “embedded skills.” You’ll gain the habit of
turning curiosity into a working systemand that’s the real point of the love letter.

Common Myths That Deserve to Be Flashed and Rewritten

Myth: Embedded is just “Arduino stuff.”

Arduino is a great doorway. Embedded is the whole building: timing, power, reliability, safety, security,
manufacturing realities, and long-term maintainability.

Myth: You have to be “hardware-first” to belong here.

You can come from software, physics, music, robotics, or pure curiosity. Embedded will teach you the rest.
What you need most is the willingness to learn from systems that don’t forgive hand-waving.

Myth: Embedded is dying because everything is just Linux now.

Linux-based embedded systems are everywhere, surebut so are microcontrollers. In fact, the “edge” keeps
getting more capable: faster MCUs, better peripherals, cheaper sensors, and new classes of applications
that demand low power and instant response. The embedded world is not shrinking. It’s multiplying.

Closing Love Note

The best argument for embedded systems is not a market forecast. It’s the experience of building something
real: a system you can understand, tune, and trust. A system that obeys your code and the laws of physics
at the same time.

Adams’ “love letter” is ultimately an invitation: fall in love with making. Fall in love with constraints.
Fall in love with the moment your firmware meets reality and the world responds.

And when your first prototype works for ten minutes before failing mysteriouslycongratulations. Embedded
systems love you back. They’re just shy about it.

of Embedded Systems Experiences (The Kind You’ll Recognize)

Let’s add the lived-in texturethe shared experiences that make embedded engineers instantly nod at each other
like members of a secret society whose password is “it worked yesterday.”

First, there’s The LED Era: that magical day you blink an LED on bare metal and realize you can
control reality with a few register writes. You’ll blink it too fast, too slow, then “exactly right,” and you’ll
swear it looks brighter when you’re proud (it doesn’t, but don’t ruin the moment).

Then comes The Button Lie: you wire a button, read it once, and think you’re doneuntil you learn
about bouncing. Suddenly your device registers five presses from one human finger and you understand why embedded
systems teach humility. You add a delay, then you add a timer-based debounce, then you realize you just invented
user experience.

Next is The Serial Console Bargain: you set up UART logging and feel unstoppableuntil the bug
disappears because printing changes the timing. You learn to log less, log smarter, and sometimes toggle a GPIO
pin and watch it on a scope like it’s a heart monitor for your code.

Eventually you meet The Bus That Hangs. I2C gets stuck because a device held SDA low. SPI behaves
until you change the cable length. CAN works perfectly until it doesn’t. You learn that “digital” signals are
still analog creatures wearing square costumes.

You’ll also experience The Interrupt Lesson: you write an ISR that does “just a little work,” and
somehow your whole system becomes sluggish. You refactor, move heavy work into a task, and discover the joy of a
clean interrupt-to-task handoff.

Then comes The DMA Glow-Up: you move data without waking the CPU every time, your jitter improves,
and you feel like you unlocked a new class in a role-playing game. And right after that, you meet The
Buffer Off-by-One Poltergeist, and you learn to respect ring buffers.

Finally, there’s The Shipping Reality: you add a watchdog, a safe boot path, and a firmware update
plan because you’ve accepted a truthdevices leave your desk and enter the world, where users do unspeakable things
like unplugging power mid-write. When you design for that, you’re not being pessimistic. You’re being professional.

These experiences aren’t just “war stories.” They’re the curriculum. They’re why embedded systems feel like a craft.
And they’re exactly why a “love letter” to embedded systems makes sense: the relationship is real, demanding, and
surprisingly rewarding.