ISR best practices (keep it short) in Embedded C - Deep Dive

Overview - ISR best practices (keep it short)

What is it?

An ISR (Interrupt Service Routine) is a special function that runs automatically when a hardware event occurs. It helps the microcontroller respond quickly to things like button presses or sensor signals. ISRs must be short and fast to avoid slowing down the main program. They work by temporarily pausing the main code to handle urgent tasks.

Why it matters

Without good ISR practices, the system can become slow, miss important events, or behave unpredictably. Poorly written ISRs can cause bugs that are hard to find and fix. Using best practices ensures the device runs smoothly and reliably, which is critical in real-time embedded systems like medical devices or cars.

Where it fits

Before learning ISRs, you should understand basic C programming and how microcontrollers work. After mastering ISRs, you can learn advanced topics like real-time operating systems and interrupt prioritization.

Mental Model

Core Idea

An ISR is a quick helper that pauses the main program to handle urgent hardware events and then returns control immediately.

Think of it like...

An ISR is like a fire alarm in a building: when it rings, everyone stops what they’re doing briefly to respond, then goes back to their tasks.

Main Program Loop ──▶ [Interrupt Occurs] ──▶ ISR Runs Quickly ──▶ Return to Main Program Loop

Build-Up - 6 Steps

1

Foundation

What is an ISR and why use it

Concept: Introduce the basic idea of an ISR and its purpose.

An ISR is a function triggered by hardware events like timers or buttons. It lets the microcontroller react immediately instead of waiting in the main program loop.

Result

You understand that ISRs handle urgent tasks quickly and automatically.

Knowing that ISRs interrupt normal flow helps you see why they must be fast and simple.

2

Foundation

Basic ISR structure in C

Concept: Show how to write a simple ISR function in embedded C.

Use the correct syntax and attributes to define an ISR. For example: void __attribute__((interrupt)) ISR_Name(void) { // ISR code here } This tells the compiler this function is special.

Result

You can write a basic ISR that the microcontroller will call on an interrupt.

Understanding the special syntax prevents common mistakes that stop ISRs from working.

3

Intermediate

Keep ISRs short and fast

🤔Before reading on: do you think it's okay to do complex calculations inside an ISR? Commit to your answer.

Concept: Explain why ISRs should do minimal work and return quickly.

ISRs block other interrupts and the main program. Doing long tasks inside ISRs causes delays and missed events. Instead, set flags or store data and handle complex work outside the ISR.

Result

You learn to write ISRs that only do essential, quick actions.

Knowing to keep ISRs short avoids system slowdowns and hard-to-debug timing issues.

4

Intermediate

Avoid using non-reentrant functions in ISRs

🤔Before reading on: do you think calling printf inside an ISR is safe? Commit to your answer.

Concept: Teach that some functions are unsafe inside ISRs because they can cause crashes or data corruption.

Functions like printf or malloc are not safe in ISRs because they use shared resources or take too long. Use simple operations or special ISR-safe functions instead.

Result

You avoid common pitfalls that cause system crashes.

Understanding function safety in ISRs prevents subtle bugs and system instability.

5

Advanced

Use volatile and atomic operations correctly

🤔Before reading on: do you think normal variables are safe to share between ISR and main code without special care? Commit to your answer.

Concept: Explain how to safely share data between ISRs and main code using volatile and atomic operations.

Variables changed in ISRs must be declared volatile to prevent compiler optimizations. For multi-byte data, use atomic operations or disable interrupts briefly to avoid corrupted reads/writes.

Result

You can safely communicate between ISRs and main code without bugs.

Knowing how to handle shared data prevents unpredictable behavior and data corruption.

6

Expert

Prioritize and nest interrupts carefully

🤔Before reading on: do you think all interrupts should be allowed to interrupt each other freely? Commit to your answer.

Concept: Discuss interrupt priority levels and nesting to manage multiple ISRs efficiently.

Microcontrollers allow setting priorities so critical ISRs can interrupt less critical ones. Nesting interrupts improves responsiveness but adds complexity. Use priorities wisely to balance speed and safety.

Result

You understand how to design systems that handle many interrupts without chaos.

Mastering interrupt priorities and nesting is key for building reliable, real-time embedded systems.

Under the Hood

When a hardware event occurs, the microcontroller saves the current program state and jumps to the ISR address. After the ISR finishes, it restores the saved state and resumes the main program. This requires special CPU instructions and hardware support to save registers and program counters.

Why designed this way?

ISRs were designed to allow immediate response to urgent events without waiting for the main program. Saving and restoring state ensures the main program continues correctly. Alternatives like polling waste CPU time and miss fast events.

┌───────────────┐
│ Main Program  │
└──────┬────────┘
       │ Interrupt Occurs
       ▼
┌───────────────┐
│ Save Context  │
├───────────────┤
│ Run ISR       │
├───────────────┤
│ Restore Context│
└──────┬────────┘
       │ Return to Main
       ▼
┌───────────────┐
│ Main Program  │
└───────────────┘

Myth Busters - 4 Common Misconceptions

Quick: Is it safe to do long calculations inside an ISR? Commit yes or no.

Common Belief: It's fine to do any processing inside an ISR since it runs immediately.

Reality: Long processing inside ISRs blocks other interrupts and delays the main program, causing missed events and system lag.

Why it matters: Ignoring this leads to slow, unreliable systems that can miss critical signals.

Quick: Can you safely call printf inside an ISR? Commit yes or no.

Common Belief: You can use any function inside an ISR, including printf for debugging.

Reality: Functions like printf are not reentrant and can cause crashes or corrupt data if called inside ISRs.

Why it matters: Using unsafe functions in ISRs causes hard-to-find bugs and system crashes.

Quick: Do normal variables shared between ISR and main code always work correctly without special care? Commit yes or no.

Common Belief: Variables shared between ISR and main code work fine without special keywords or precautions.

Reality: Without volatile and atomic handling, compilers optimize away changes or partial updates cause corrupted data.

Why it matters: Mismanaging shared variables leads to unpredictable behavior and bugs that are difficult to debug.

Quick: Should all interrupts be allowed to interrupt each other freely? Commit yes or no.

Common Belief: All interrupts can safely interrupt each other without any priority or control.

Reality: Without priority control, critical ISRs can be delayed, or nesting can cause stack overflows and race conditions.

Why it matters: Ignoring interrupt priorities risks system instability and missed critical events.

Expert Zone

1

Some microcontrollers have special registers to optimize ISR entry and exit, reducing latency significantly.

2

Using minimal stack space in ISRs is crucial because stack overflow in interrupts can crash the system silently.

3

Certain compiler optimizations can break ISR behavior if volatile and interrupt attributes are not used correctly.

When NOT to use

Avoid complex logic or blocking calls inside ISRs; instead, use deferred processing techniques like flags or message queues handled in the main loop or RTOS tasks.

Production Patterns

In real systems, ISRs often just set flags or copy data to buffers, then signal tasks or main code to process later. Interrupt priorities are carefully assigned to balance responsiveness and system stability.

Connections

Real-Time Operating Systems (RTOS)

Builds-on

Understanding ISRs is essential before learning RTOS because RTOS manages interrupts and tasks together for real-time responsiveness.

Event-driven programming

Same pattern

ISRs are a hardware-level example of event-driven programming where code reacts to events instead of running sequentially.

Emergency response systems (non-technical)

Similar pattern

Like ISRs, emergency systems interrupt normal activities to handle urgent situations immediately, showing how interrupt concepts apply beyond computing.

Common Pitfalls

#1 Doing heavy processing inside the ISR.

Wrong approach:

void ISR() {
for(int i=0; i<100000; i++) {
// heavy calculation
}
}

Correct approach:

volatile int flag = 0;
void ISR() {
flag = 1; // just set a flag
}
// main loop checks flag and does heavy work

Root cause:

Misunderstanding that ISRs should be quick and not block other code.

#2 Calling non-reentrant functions like printf inside ISR.

Wrong approach:

void ISR() {
printf("Interrupt occurred\n");
}

Correct approach:

volatile int event = 1;
void ISR() {
event = 1; // set flag only
}
// main code prints message

Root cause:

Not knowing which functions are safe inside ISRs.

#3 Not declaring shared variables as volatile.

Wrong approach:

int flag = 0;
void ISR() {
flag = 1;
}
int main() {
while(flag == 0) {}
}

Correct approach:

volatile int flag = 0;
void ISR() {
flag = 1;
}
int main() {
while(flag == 0) {}
}

Root cause:

Ignoring compiler optimizations that remove variable checks without volatile.

Key Takeaways

ISRs are special functions that handle urgent hardware events by interrupting the main program.

Keep ISRs short, simple, and fast to avoid slowing down the system or missing events.

Avoid calling unsafe or complex functions inside ISRs to prevent crashes and bugs.

Use volatile and atomic operations to safely share data between ISRs and main code.

Proper interrupt prioritization and nesting are crucial for building reliable real-time systems.