Everyone knows you shouldn't do heavy processing in an ISR.
What nobody warns you about is how easy it is to accidentally violate this rule without realizing it. You think you're just reading a register and clearing a flag. But that innocuous call to memcpy to buffer incoming UART data? That's a function call with potential overhead. That bit of math to compute a checksum? That's branching and arithmetic that takes unpredictable cycles.
The compiler optimizes away your simple loop into something unrecognizable. The HAL layer you're using hides a mutex lock behind that innocent-looking write_reg macro. That peripheral you're accessing happens to be on a slow bus that stalls for several cycles per access.
Suddenly your 50-cycle ISR is taking 800 cycles. Your interrupt latency spikes. Your high-priority task misses its deadline. The watchdog fires. The system resets.
You debug for days because the timing looks fine in isolation but collapses under load when multiple peripherals fire simultaneously.
Modern embedded C isn't straightforward. Every innocent-looking line of code might be hiding complexity you never put there.
What is the most innocent-looking ISR code that turned out to be a disaster?
#EmbeddedSystems #FirmwareDevelopment #EmbeddedEngineering #RTOS #InterruptLatency #EmbeddedC #RealTimeSystems #MicrocontrollerProgramming #ProductionDebugging #HardwareDevelopment #ElectronicsEngineering #FirmwarePerformance