Article details
Almost everyone who works in embedded systems remembers the first time they blinked an LED. You wire up a board, flash a few lines of code, and a light starts flashing on command. It feels like magic. But there is a long, quiet distance between that first blinking LED and a device that ships, survives a warehouse full of temperature swings, and keeps running for years without anyone touching it. That distance is where intermediate embedded work actually lives.
If you already know your way around GPIO, can write C without reaching for a tutorial every five minutes, and have wired up a sensor or two, this is the territory that comes next. It is less about learning new syntax and more about changing how you think. Below are the shifts that tend to define that transition.
From the Loop to the Interrupt
Most people start with a while(1) loop that does everything in order: read the sensor, check the button, update the display, repeat. It works, and for a lot of small projects it is perfectly fine. The trouble starts when the loop gets busy. If your display update takes 40 milliseconds and a button press happens during that window, you might miss it entirely. Your program was simply looking somewhere else at the wrong moment.
The intermediate move is to stop asking the processor to constantly check on things and start letting the hardware tell you when something happens. That is what interrupts are for. Instead of polling a button in a loop, you configure the pin to fire an interrupt on a falling edge, and the processor drops whatever it is doing to run a short handler. The mental shift here is real: your code stops being a single predictable sequence and becomes a set of things that can happen at any time, in almost any order.
This is powerful, but it comes with a new class of bugs. The moment two pieces of code can touch the same variable one in your main loop, one in an interrupt: you have a concurrency problem, even on a single-core microcontroller. A variable shared between an interrupt and the main code needs the volatile keyword so the compiler does not optimize away reads it thinks are pointless. And if you are updating a multi-byte value, you may need to briefly disable interrupts around that update so you never read half of an old value and half of a new one. These are the small disciplines that separate code that mostly works from code that always works.
The other rule worth burning into memory: keep interrupt handlers short. An interrupt handler is not the place to run a long calculation or wait for an I2C transaction to finish. Set a flag, grab a value, and get out. Let the main loop do the heavy lifting when it sees the flag. A handler that overstays its welcome will block every other interrupt behind it, and that is how real-time systems quietly fall apart.
Timers Are Your Best Friend
Once you stop polling, you need another way to make things happen on schedule, and that is where hardware timers earn their keep. A timer is a counter that ticks along independently of your code and can fire an interrupt when it reaches a target. Want to sample a sensor exactly every 10 milliseconds? Do not put a delay() in your loop and hope the timing holds: configure a timer to fire at 100 Hz and do your sampling in the timer interrupt.
The difference matters more than it first appears. A delay() is a promise you cannot keep, because the actual gap between samples ends up being your delay plus however long the rest of the loop took, and that varies. A timer gives you a rhythm the rest of the code cannot disturb. Once you start thinking in terms of periodic timer ticks driving your system's heartbeat, a lot of timing-sensitive work suddenly gets easier: sensor sampling, debouncing, generating precise PWM signals, scheduling tasks. Timers are also how you build a simple software scheduler without an operating system, which is often all a modest project needs.
Talking to the World: The Protocol Trio
Sooner or later your microcontroller has to talk to something else a sensor, a memory chip, a display, another board. In practice that conversation almost always happens over one of three protocols, and getting comfortable with all three is a genuine milestone.
UART is the simplest and the one you will reach for constantly, if only for debug messages over a serial line. It is asynchronous, meaning there is no shared clock, so both sides have to agree on a baud rate ahead of time. Get that rate wrong on one side and you get garbage characters, which is a rite of passage everyone goes through at least once.
SPI is fast and straightforward, using separate lines for clock, data out, data in, and a chip-select line for each device. It is the protocol of choice when speed matters driving a display, reading a fast ADC, talking to flash memory. The cost is wiring: every extra device wants its own chip-select line.
I2C is the clever one. It puts many devices on just two wires by giving each a unique address, which is wonderful for connecting a handful of small sensors without running out of pins. The tradeoff is that it is slower and, frankly, fussier pull-up resistors matter, bus contention is a real thing, and a single misbehaving device can lock up the whole bus. Learning to read an I2C transaction on a logic analyzer, watching the address and the acknowledge bits go by, is one of those skills that pays for itself many times over.
The deeper lesson across all three is that a datasheet is not optional reading. The intermediate engineer learns to sit down with a sensor's datasheet, find the register map, and translate "write 0x01 to register 0x6B to wake the device" into working code. That translation from a document written by someone else into bytes on a bus is a huge part of the job.
Memory Is Not Infinite, and It Shapes Everything
On a desktop you rarely think about memory until something goes badly wrong. On a microcontroller with, say, 64 kilobytes of RAM, memory is a constant background consideration that quietly shapes every decision you make.
The first habit to build is a healthy suspicion of dynamic memory. On a small embedded system, calling malloc in the middle of your program is often a bad idea. Heap fragmentation on a device that runs for months can slowly carve your free memory into unusable little pieces until an allocation fails at the worst possible time. Many embedded codebases avoid the heap almost entirely, preferring statically allocated buffers whose size is known and fixed at compile time. It feels restrictive at first, and then it feels like freedom, because you always know exactly how much memory you are using.
It also helps to understand where your data actually lives. Constants and lookup tables can often stay in flash rather than being copied into precious RAM. The stack, where your local variables and function calls pile up, can silently overflow if you nest calls too deeply or declare a large array inside a function and a stack overflow on an embedded target frequently shows up as a bizarre, hard-to-reproduce crash rather than a friendly error message. Getting into the habit of checking your build's memory map, and knowing roughly how much stack and RAM you are consuming, turns a whole category of mysterious failures into things you can see coming.
When You Actually Need an RTOS
At some point you will hit a project where the simple loop-and-interrupt model starts to strain. You have several things that all need to happen on their own schedules, some more urgent than others, and juggling them by hand in one big loop turns into a tangle. This is usually the moment people start reaching for a real-time operating system.
An RTOS like FreeRTOS lets you split your program into separate tasks, each written as though it owns the processor, while a scheduler decides who runs when based on priority. A high-priority task handling a motor can preempt a low-priority task updating a screen, which is exactly what you want when some deadlines matter more than others. It is a genuinely liberating way to structure complex firmware.
But it is worth saying plainly: an RTOS is not a badge of seriousness, and reaching for one too early is a common mistake. It brings its own weight you now have to think about task priorities, stack sizes for each task, and a fresh set of concurrency concerns like mutexes and queues for passing data safely between tasks. For a device that reads one sensor and blinks a light, an RTOS is overkill, and a clean timer-driven loop will be simpler to reason about and easier to debug. The intermediate skill is not "knowing how to use an RTOS." It is knowing when a project has genuinely outgrown the simpler approach, and being honest with yourself about it.
Debugging Without a Screen
Perhaps the biggest adjustment coming from other kinds of programming is that when something goes wrong, there is often nothing to look at. No stack trace, no console, sometimes not even a working serial port. The device just sits there, or resets, or does something subtly wrong, and it is on you to figure out why.
The humble approach is to light up an LED or print over UART to confirm the code reached a certain point. It is crude, and it is also genuinely useful more often than anyone likes to admit. The next step up is a hardware debugger a JTAG or SWD probe that lets you set breakpoints, step through code, and inspect memory on the actual chip. Learning to use one properly changes your relationship with the hardware; suddenly you can pause the processor mid-crash and look around.
And then there is the logic analyzer, which is close to indispensable once you are dealing with communication protocols. When your I2C sensor returns nonsense, the fastest way to the truth is usually to watch the actual signals on the wire and compare them against what the datasheet says should be there. Very often the bug is not in your logic at all — it is a wrong address, a missing pull-up, a clock running too fast. You cannot reason your way to that answer, but you can see it in about thirty seconds with the right tool.
Building for the Long Haul
The last shift is about reliability, and it is what most clearly marks the move from hobby to product. A demo only has to work once, while someone is watching. A product has to work at three in the morning, six months in, with nobody around and no chance to press reset.
Two small features do a lot of quiet work here. The watchdog timer is a hardware counter that will reset the whole system if your code fails to periodically tell it "I am still alive." If your firmware ever hangs an infinite loop, a wedged bus, a corrupted state the watchdog notices the silence and restarts the device instead of leaving it frozen. Brownout detection handles the other common failure: when the supply voltage dips too low, the chip can behave unpredictably, so a brownout detector holds it safely in reset until the voltage recovers.
Neither of these is glamorous, and neither shows up in a demo. But they are exactly the sort of thing that separates a device you would trust in the field from one you would only trust on your desk. Thinking about how your system fails, and making sure it fails safely, is the mindset that ties all of this together.
The Real Shift
None of this requires exotic knowledge. It is mostly a handful of concepts interrupts, timers, protocols, memory discipline, and a respect for failure applied consistently. What changes at the intermediate level is not the size of your vocabulary but the way you think about the machine. You stop treating the microcontroller as a small computer that runs your program and start treating it as a physical system with timing, limits, and moods of its own. Once that click happens, the blinking LED stops being the destination and becomes what it always should have been: the very first step.
