Firmware and peripheral bring-up
Most of my embedded work has been close to the silicon — register-level configuration of UART, I²C, SPI, ADC and PWM on AVR and ARM Cortex-M devices, with signal-level debugging via logic analyzer when the datasheet and the reality disagree.
Bring-up is the part nobody glamorizes. It is also the part where you find out whether you actually understand the chip or have just been copying example code. The first time I had to bring a UART up without the Arduino HAL — clock config, baud divisor, pin mux, register flags, the works — was a humbling weekend. It was also the weekend embedded stopped feeling like magic and started feeling like a craft.
Now, bring-up is the part I look forward to. You read the datasheet section, write the smallest possible setup, light up an LED on a successful read, and move on to the next peripheral. Boring. Methodical. Deeply satisfying when the whole board finally talks to itself.
Interrupt-driven design
On Vibro-Volt I built a charge/discharge state machine on an Arduino Nano using ISRs, so the MCU could sleep until the energy-harvesting circuit had something interesting to report. Polling worked for the proof of concept; interrupts made it deterministic. The lesson generalizes — if your firmware loop is busy-waiting on anything, you have not finished designing it.
Interrupts also force you to think about state in a way the polling version never does. What runs in the ISR? What gets deferred to the main loop? Which variables need `volatile`? Where can a race condition sneak in? The first time I shipped a stable interrupt-driven design without a single race bug, I knew something had clicked.
The related rule I have internalized: keep ISRs short, side-effect free, and write to a single shared flag or queue. Everything else belongs in the main loop. Following that one rule has prevented more bugs than any tool ever has.
Tools I actually use
Embedded C, C/C++, Proteus and Multisim for simulation, VS Code and the Arduino IDE for day-to-day work. A cheap logic analyzer and a multimeter close the loop. Nothing exotic — just the boring toolkit, applied carefully.
The logic analyzer was the single best ~₹2000 I have ever spent. The number of bugs I used to chase by adding `Serial.print` statements that the logic analyzer would have shown me in five seconds is genuinely embarrassing. If you do embedded work and do not have one, get one before your next paycheck.
Proteus and Multisim get a lot of hate online, but for student-level circuit and firmware verification they are honestly fine. I have caught real bugs in simulation before I touched a breadboard. That counts.
What embedded teaches you that nothing else does
Web bugs eventually surface. Embedded bugs surface at a customer site at midnight on a Saturday and reset on power-cycle so you cannot reproduce them. That changes how you write code.
You start defending against the universe. Every input could be garbage. Every clock could drift. Every power rail could glitch. Every cable could be on its way out. Code that survives that mindset is code I trust everywhere — including in the parts of my career that have nothing to do with hardware.