Embedded Systems & Firmware

What should be avoided inside an interrupt handler?

  1. AWriting 1 to a flag variable to notify the main code
  2. BClearing the bit that indicates the interrupt source
  3. CTime-consuming work such as printing long strings with printf or loops that wait for something to happen
Show answer and explanation

Answer: C. Time-consuming work such as printing long strings with printf or loops that wait for something to happen

While an interrupt handler runs long, other interrupts cannot be serviced and the main code stalls. printf takes time to finish and may itself rely on interrupts, so it is especially risky. A handler should do only the minimum, such as moving received data into a buffer or setting a flag, and leave heavy work to the main loop or a task. It must also remember to clear the interrupt source bit.

  • A. Notifying main with a short action is good practice.
  • B. Without clearing it, the same interrupt fires repeatedly.
  • C. Correct. It holds up other interrupts and the main code for a long time.
Practice this topic Back to topic

More Embedded Systems & Firmware questions

  1. When the program above is compiled with optimization, led_on() may never be called even after the timer interrupt fires. Which pairs the cause with the fix correctly?
  2. On an 8-bit microcontroller, a timer interrupt increments the 32-bit variable ticks, and the main code reads ticks to compute elapsed time. Why is a wildly wrong value occasionally read?
  3. What is a characteristic of serial communication with a UART?
  4. On a 115200 bps UART using 8 data bits, no parity and 1 stop bit (8N1), roughly how many bytes can be sent per second?
  5. A small baud-rate mismatch between UART transmitter and receiver can garble characters. Why is the tolerance limited to roughly a few percent?