Interrupt Service Routines (ISRs): The System's First Responders

Definition: An Interrupt Service Routine (ISR), also commonly referred to as an Interrupt Handler, is a special, asynchronous function that is automatically and immediately executed by the CPU in direct response to a hardware interrupt signal. These signals originate from peripherals (e.g., a button press, data ready from a UART, a timer overflow, completion of a Direct Memory Access (DMA) transfer).

Characteristics and Stringent Design Principles for ISRs:
- Atomicity and Brevity: ISRs must be designed to execute as quickly and efficiently as possible, often by momentarily disabling further interrupts during critical internal operations to ensure atomic execution.
- Minimal Work Principle: This is paramount. The primary objective of an ISR should be to perform the absolute minimum, time-critical work required to service the hardware interruption. This typically includes:
- Acknowledging the interrupt at the peripheral's register level.
- Reading/clearing any necessary hardware flags.
- Optionally storing essential, small pieces of raw data (e.g., a single byte from a UART) into a temporary buffer.
- Crucially, signaling a dedicated RTOS task (the 'bottom half' of the interrupt handler) to perform any more complex or time-consuming processing.

Why Keep ISRs Short?
- Minimize Interrupt Latency: A lengthy ISR increases the total time before other higher-priority tasks (which might have become ready due to another interrupt) can begin execution.
- Preserve Predictability: Long ISRs introduce unpredictable delays for all lower-priority tasks, potentially causing them to miss their deadlines and compromising the system's real-time guarantees.
- Limited RTOS API Access: Due to their asynchronous and critical context, most standard RTOS APIs are not safe to call directly from an ISR. RTOSes provide specific 'from ISR' or 'ISR-safe' versions of a very limited set of APIs (e.g., xSemaphoreGiveFromISR(), xQueueSendFromISR()) for signaling purposes, which are optimized and designed to be called from an interrupt context without causing a context switch immediately.
- No Blocking Calls: An ISR must never include any code that can cause it to block or yield the CPU.
- Reentrancy and Data Sharing: Extreme care must be taken if an ISR shares any global variables or data structures with tasks or other ISRs. These shared resources must be protected (e.g., by disabling interrupts briefly) to prevent race conditions.

Interrupt Latency (Detailed Definition)

The total time delay measured from the moment a hardware peripheral asserts an interrupt signal (e.g., pulling a dedicated interrupt line low) to the precise instant the CPU begins executing the very first instruction of the corresponding Interrupt Service Routine (ISR).

Factors Contributing to Interrupt Latency:
- Hardware Latency: Time taken for the interrupt signal to propagate through the interrupt controller to the CPU.
- Processor State Saving: Time taken by the CPU to automatically save its current context (Program Counter, status registers) before jumping to the ISR.
- Critical Sections (Interrupt Disable): Any periods where the RTOS kernel or application code temporarily disables all (or high-priority) interrupts to protect critical data structures. If an interrupt occurs during such a period, its servicing is delayed. The maximum duration of these "interrupt disabled" periods directly determines the worst-case interrupt latency.

Deferred Interrupt Processing (The Top-Half/Bottom-Half Paradigm)

This is a standard, robust design pattern universally adopted in RTOS-based systems to ensure ISRs remain minimal and to manage the complexities of interrupt-driven processing efficiently.

Concept: The overall interrupt handling process is logically divided into two distinct parts:
- The "Top Half" (The ISR): This is the actual Interrupt Service Routine that executes in the CPU's interrupt context. Its role is strictly limited to performing the bare minimum, time-critical hardware interaction (acknowledging the interrupt, reading/clearing flags, quick data buffering). Crucially, its final action is to signal a dedicated RTOS task (the "bottom half") that the interrupt event has occurred. The top half completes and returns as rapidly as possible.
- The "Bottom Half" (The Task): This is a regular RTOS task (often assigned a high priority) that is specifically designed to handle the more complex, time-consuming, or non-urgent processing related to the interrupt. This task remains in the Blocked state until it is signaled by the ISR. When signaled, it transitions to the Ready state and is then scheduled by the RTOS just like any other task. It executes in the normal task context.

Signaling Mechanisms (From ISR to Task): The ISR uses a specific RTOS primitive to signal its corresponding task:
- Binary Semaphore: The ISR calls an ISR-safe V (signal/give) operation on a binary semaphore. The "bottom half" task calls a P (wait/take) operation on the same semaphore and blocks until signaled.
- Message Queue: The ISR calls an ISR-safe send operation to put a message (or a pointer to data) into a message queue. The "bottom half" task calls a receive operation on the queue and blocks until a message arrives.
- Event Flag: The ISR calls an ISR-safe set operation on an event flag. The "bottom half" task waits for that specific flag to be set.

Advantages of Deferred Processing:
- Preserves Responsiveness: By offloading complex work, the ISR remains brief, ensuring that the system can quickly respond to other, potentially more critical, interrupts.
- Simplified ISRs: Keeps the interrupt handler code clean, simple, and less prone to bugs.
- Full RTOS API Access: The "bottom half" task operates in normal task context, allowing it to safely use any standard RTOS API (including blocking calls, complex communication, memory allocation, etc.) without fear of system instability.
- Flexibility: Allows for complex processing to be scheduled according to priorities, potentially allowing other tasks to run if the bottom-half task is of lower priority than other ready tasks.

Precision Time Management Services: The RTOS's Internal Clockwork

An RTOS provides crucial services for managing time, which are fundamental for scheduling periodic tasks, implementing delays, and triggering time-based events.

The System Tick (The Heartbeat of the RTOS):
- Concept: The system tick is a periodic interrupt generated by a dedicated, high-resolution hardware timer peripheral on the microcontroller. This interrupt occurs at a precise, fixed frequency (e.g., every 1 millisecond (ms), 10 ms, or 100 microseconds).
- Role: The system tick interrupt is the absolute fundamental time base for the entire RTOS kernel. It is the core mechanism used for:
- Global Timekeeping: The RTOS kernel maintains a global counter (the "tick count" or "system uptime") that increments with each system tick interrupt. This provides a running measure of the system's operational duration.
- Scheduler Activation: For time-sliced (Round-Robin) scheduling, the tick interrupt triggers the scheduler to re-evaluate which task should run next, potentially switching tasks if a time quantum has expired.
- Managing Timed Blocking: The RTOS uses the tick to decrement internal counters for any tasks that are currently in the Blocked state with a specified timeout (e.g., a task waiting for a semaphore for 500ms). When a timeout counter reaches zero, the task is unblocked and moved back to the Ready state.
- Implementing Task Delays: The vTaskDelay() function relies on the system tick to measure the specified delay duration.

Delay Functions (Voluntary Task Suspension):
- API Examples: vTaskDelay(ticks) (FreeRTOS), osDelay(ms) (CMSIS-RTOS).
- Concept: When a task calls a delay function, it voluntarily relinquishes control of the CPU and enters the Blocked state for a specified duration (measured in system ticks or milliseconds). During this time, the task consumes no CPU cycles, allowing other tasks to execute. After the specified delay period has elapsed (as measured by the system tick), the task is moved back to the Ready state by the scheduler.
- Use Cases:
- Introducing precise, non-blocking pauses in a task's execution.
- Implementing periodic tasks that execute their logic, then delay, then execute again (e.g., while(1) { perform_sensor_read(); vTaskDelay(pdMS_TO_TICKS(100)); }).

Software Timer Management: Event Scheduling without Dedicated Tasks

Concept: Software timers are highly flexible, timer-driven events implemented entirely within the RTOS kernel, driven by the system tick. They are not direct hardware timers, but rather a layer of abstraction. When a software timer expires, a user-defined callback function is executed. This callback function typically runs within a dedicated, high-priority "timer service task" (managed by the RTOS), not within interrupt context.

Types:
- One-Shot Timers: Configured to execute their associated callback function exactly once after a specified delay from when they are started.
- Periodic Timers: Configured to execute their associated callback function repeatedly at fixed, regular intervals.

Advantages:
- Resource Efficiency: More lightweight than creating a full-fledged task for simple periodic events or delays as they don't require their own stack until the callback executes.
- Flexibility: Easily configured and managed at runtime.
- Non-Blocking: Starting a software timer does not block the calling task.

Typical Use Cases:
- Periodically blinking an LED.
- Implementing basic debounce logic for push buttons.
- Setting up watchdog timers to monitor system health.
- Scheduling non-critical periodic activities (e.g., logging data, sending periodic status updates).
- Triggering an action after a specific timeout (e.g., turning off a light after 5 minutes).