5 exercises on interrupt-driven firmware terminology: interrupt, ISR, interrupt latency, critical section, and atomic operation. Advanced
0 / 14 completed
1 / 14
An engineer says: "The UART fired an interrupt as soon as a byte arrived."
What is an interrupt in embedded systems?
Correct: B. An interrupt is an asynchronous event mechanism. When a peripheral (UART, timer, GPIO, etc.) needs CPU attention, it asserts an interrupt line. The CPU finishes its current instruction, saves its state, and jumps to the interrupt handler. This is far more efficient than polling.
Type
Source
Example
Hardware interrupt
Peripheral signals CPU
UART RX, timer overflow, GPIO edge
Software interrupt
Instruction triggers handler
SVC (system call) on ARM Cortex-M
Exception / fault
CPU detects error condition
HardFault, MemManage on ARM
2 / 14
During a code review your lead comments: "Keep your ISR as short as possible — just set a flag and defer all processing to a task."
What is an ISR?
Correct: B. An ISR (Interrupt Service Routine) is the C function (or assembly routine) that executes when an interrupt fires. Because ISRs run with the normal task scheduler suspended or at elevated priority, keeping them brief is critical. The recommended pattern is to set a flag or post to a queue in the ISR, then process the data in a regular task.
Rule
Reason
No blocking calls
ISR cannot wait; it would hang the system
Minimal work
Keeps interrupt latency low for other interrupts
ISR-safe RTOS calls
Use xQueueSendFromISR(), not xQueueSend()
3 / 14
A spec requirement states: "The system must achieve an interrupt latency of less than 5 µs for the safety shutdown interrupt."
What is interrupt latency?
Correct: B.Interrupt latency is the end-to-end delay from interrupt assertion to ISR entry. It is a critical real-time metric. Sources of latency include: CPU pipeline flush cycles, interrupt controller arbitration, and — most significantly in RTOS systems — critical sections that temporarily disable interrupts.
Latency component
Description
Hardware latency
CPU pipeline + interrupt controller cycles
Software latency
Time interrupts are disabled in critical sections
Interrupt response time
Latency + time to finish current ISR if nested
4 / 14
A senior engineer instructs you: "Wrap that GPIO read-modify-write sequence in a critical section — it's not safe to be interrupted mid-operation."
What is a critical section?
Correct: B. A critical section guards shared data from race conditions. In bare-metal code this usually means disabling all interrupts for the duration. In RTOS code it may mean disabling the scheduler (taskENTER_CRITICAL()) or acquiring a mutex. Critical sections must be as short as possible to minimize interrupt latency impact.
Implementation
Trade-off
Disable all interrupts
Simplest; increases interrupt latency
RTOS scheduler lock
Allows ISRs; prevents task preemption only
Mutex
Per-resource; caller may block if already held
5 / 14
Your team's coding standard states: "Use an atomic read-modify-write instruction to update the status flag shared between the ISR and the main task."
What makes an operation atomic?
Correct: B. An atomic operation is one that, from the perspective of all other concurrent actors, either has not started or has fully completed — there is no observable intermediate state. On ARM Cortex-M this is achieved with exclusive load/store instructions (LDREX/STREX) or single-width volatile reads/writes on naturally aligned data, or via compiler intrinsics like __atomic_fetch_or().
Technique
Notes
Single-width aligned RW
Naturally atomic on most 32-bit MCUs
LDREX / STREX
ARM exclusive access; retry on failure
C11 _Atomic / stdatomic.h
Portable; compiler generates correct instructions
6 / 14
PR Description:
"Fixes a race condition where the sensor reading could be lost if the ISR ran concurrently with the main task. Added a mutex to protect access to the shared sensor data."
During a Slack discussion about this PR, another developer asks: 'Why did you need a mutex here? What's going on under the hood that makes this necessary?' Which of the following best describes the underlying reason for using a mutex in this context?
The correct answer highlights the core function of a mutex: resource protection.
It's crucial to understand that in embedded systems with shared memory and concurrent execution (like ISRs interacting with tasks), multiple components trying to modify the same data simultaneously can lead to race conditions – unpredictable outcomes due to interleaved operations. A mutex acts as a lock, preventing one task from accessing the shared sensor data until it's safely released, thus avoiding corruption. Options A and D are partially correct but miss the fundamental purpose of mutexes; option B focuses on blocking/priority which is a consequence, not the root cause.
7 / 14
PR Description:
"Fixes a race condition where the sensor reading could be lost if the ISR ran concurrently with the main task. Added a mutex to protect access to the shared sensor data."
During a Slack discussion about this PR, another developer asks: 'Why did you need a mutex here? What's going on under the hood that makes this necessary?' Which of the following best describes the underlying reason for using a mutex in this context?
The correct answer highlights the core function of a mutex: resource protection.
It's crucial to understand that in embedded systems with shared memory and concurrent execution (like ISRs interacting with tasks), multiple components trying to modify the same data simultaneously can lead to race conditions – unpredictable outcomes due to interleaved operations. A mutex acts as a lock, preventing one task from accessing the shared sensor data until it's safely released, thus avoiding corruption. Options A and D are partially correct but miss the fundamental purpose of mutexes; option B focuses on blocking/priority which is a consequence, not the root cause.
8 / 14
PR Description:
"Fixes a race condition where the sensor reading could be lost if the ISR ran concurrently with the main task. Added a mutex to protect access to the shared sensor data."
During a Slack discussion about this PR, another developer asks: 'Why did you need a mutex here? What's going on under the hood that makes this necessary?' Which of the following best describes the underlying reason for using a mutex in this context?
The correct answer highlights the core function of a mutex: resource protection.
It's crucial to understand that in embedded systems with shared memory and concurrent execution (like ISRs interacting with tasks), multiple components trying to modify the same data simultaneously can lead to race conditions – unpredictable outcomes due to interleaved operations. A mutex acts as a lock, preventing one task from accessing the shared sensor data until it's safely released, thus avoiding corruption. Options A and D are partially correct but miss the fundamental purpose of mutexes; option B focuses on blocking/priority which is a consequence, not the root cause.
9 / 14
PR Description:
"Fixes a race condition where the sensor reading could be lost if the ISR ran concurrently with the main task. Added a mutex to protect access to the shared sensor data."
During a Slack discussion about this PR, another developer asks: 'Why did you need a mutex here? What's going on under the hood that makes this necessary?' Which of the following best describes the underlying reason for using a mutex in this context?
The correct answer highlights the core function of a mutex: resource protection.
It's crucial to understand that in embedded systems with shared memory and concurrent execution (like ISRs interacting with tasks), multiple components trying to modify the same data simultaneously can lead to race conditions – unpredictable outcomes due to interleaved operations. A mutex acts as a lock, preventing one task from accessing the shared sensor data until it's safely released, thus avoiding corruption. Options A and D are partially correct but miss the fundamental purpose of mutexes; option B focuses on blocking/priority which is a consequence, not the root cause.
10 / 14
During a standup update, your team lead asks: 'What's the purpose of using an ISR for handling button presses on this device?' You respond with:
'It allows the microcontroller to immediately react to the button press without waiting for the main task to process it.'
An Interrupt Service Routine (ISR) is specifically designed for rapid response. It's triggered *immediately* when an event occurs (like a button press), bypassing the main task's normal processing loop to minimize latency and ensure the device reacts quickly. The misconception here is that ISRs are only for basic hardware, or that they reduce power – their primary benefit is speed.
11 / 14
A colleague sends you this Slack message: 'I'm seeing unpredictable behavior with the temperature sensor readings. The ISR seems to be triggering intermittently and corrupting the data.' What is the *most* likely underlying issue?
'The ISR isn't properly synchronized with the main task, leading to race conditions when accessing shared resources.'
Race conditions arise due to concurrent access to shared resources. In this scenario, multiple tasks (the ISR and the main task) attempting to read or modify data related to the temperature sensor simultaneously can lead to unpredictable results because their operations are interleaved in an undefined order. This is a common problem when ISRs operate without proper synchronization mechanisms like mutexes.
12 / 14
During a code review, your manager comments: 'The response time to the timer interrupt is currently 8ms. That's significantly longer than our target of 1ms. What should we do?'
'Optimize the ISR code and the associated hardware to reduce its execution time.'
Interrupt latency refers to the time taken from an event occurring (in this case, the timer interrupt) to the ISR executing its code. Reducing this latency directly addresses the problem. Optimizing the ISR's code and hardware components—such as reducing processing overhead or utilizing faster peripherals—is the most effective approach to meeting the target response time.
13 / 14
A senior engineer is reviewing your code and says: 'This GPIO interrupt handler doesn't have any safeguards. If another task needs access to the GPIO pin at the same time, you'll have a serious problem.' What does this statement imply?
'The ISR must be protected using a critical section or other synchronization primitive to prevent data corruption.'
A critical section is a code segment that guarantees exclusive access to shared resources. Without it, multiple tasks accessing the same GPIO pin simultaneously can lead to data corruption or unpredictable behavior due to race conditions. This highlights the importance of synchronization primitives like mutexes or semaphores to manage concurrent access and maintain data integrity.
14 / 14
You are writing a PR description for fixing a sensor reading issue. The text reads: 'Implemented a mutex to prevent race conditions when the ISR updates the sensor data.' What does the term 'mutex' refer to in this context?
'A synchronization mechanism that ensures only one task can access and modify shared resources at any given time.'
A mutex (mutual exclusion) is a fundamental synchronization tool. It acts as a 'lock' that only one task can hold at a time, ensuring exclusive access to shared resources like the sensor data. This prevents multiple tasks from modifying the data concurrently, which would lead to corruption and unpredictable results.
What does the "Interrupts & ISR Vocabulary — Embedded & RTOS Language Exercises" exercise cover?
Practice English vocabulary for interrupt-driven embedded programming: interrupt, ISR, interrupt latency, critical section, and atomic operation used in real-time firmware engineering.
Is this exercise free to use?
Yes. Every exercise on CoderSlingo, including this one, is free to use with no account, sign-up, or paywall.
How many questions are in "Interrupts & ISR Vocabulary — Embedded & RTOS Language Exercises"?
This exercise has 14 questions. Each one gives instant feedback with an explanation, so you can see exactly why an answer is right or wrong.
Do I need to create an account to save my progress?
No account is required. The progress bar and score are tracked in your browser for the current session -- the exercise is designed to be a quick, repeatable drill rather than something you resume later.
What happens if I get an answer wrong?
You'll see the correct answer highlighted immediately, along with a short explanation of why it's correct. Wrong answers aren't penalized beyond your score, and you can keep going through every question.
How is this exercise different from reading an article?
Articles explain vocabulary and concepts through prose, while exercises like this one are interactive drills -- multiple-choice questions -- that test and reinforce your recall of specific terms and phrasing.
Can I retry this exercise?
Yes -- use the "Try again" button on the results screen to reset your score and go through all the questions again from the start.
Where can I find more Embedded & RTOS exercises?
Browse the full Embedded & RTOS hub for related drills, or check the site-wide exercises index for other IT English topics.
Is this exercise suitable for beginners?
This exercise assumes basic familiarity with IT terminology. If a term feels unfamiliar, check the site Glossary for a plain-English definition before attempting the questions.
How often is new content like this published?
New exercises are added regularly across all categories, alongside new vocabulary sets and articles. Check back on the exercises hub to see what's new.