Defensive programming in firmware isn’t about null pointers. It’s about distrusting physics.
A typical C mindset looks like this:
if (ptr != NULL) {
*ptr = value;
}
That protects you from software mistakes.
Firmware lives in a different world.
A defensive firmware engineer does this:
// Enable peripheral clock
RCC->APB1ENR |= RCC_APB1ENR_USART2EN;
// Assert the hardware actually responded
assert(READ_BIT(RCC->APB1ENR, RCC_APB1ENR_USART2EN) != 0);
You don’t assume the write worked.
You verify the register changed.
Because hardware lies.
Crystals fail to start.
Regulators brown out.
Clocks glitch.
Watchdogs reset you for reasons no simulator will ever explain.
Your code is not running in an abstract C machine.
It’s wrestling with analog reality.
Good firmware constantly asks:
Did that peripheral really turn on.
Is the clock actually running.
Is the voltage still inside spec.
Did the watchdog get serviced.
This kind of “paranoia” isn’t overengineering. It’s survival.
What’s the most paranoid check or assert you’ve added that ended up saving a system in the field?
#embedded #firmware #defensiveprogramming #microcontrollers #systemsengineering #hardware #reliability #engineering