7.1 RTOS兼容的中断服务程序（ISR）
7.1.1 RTOS中断模型的范式转变
在传统的裸机（Bare-Metal）或前后台系统中，中断服务程序（ISR）是响应外部事件的唯一核心机制。其设计目标是极致的响应速度和最低的执行延迟，因此ISR通常直接处理硬件操作、更新全局变量或设置标志位，所有计算和决策都在中断上下文中完成。这种“中断处理一切”的模型简单直接，但在引入实时操作系统（RTOS）后，其固有的缺陷在复杂的多任务环境中会被放大，主要体现在以下三个方面：
阻塞风险与实时性破坏：在RTOS中，ISR运行于一个与所有任务隔离的、更高优先级的“中断上下文”。若ISR执行时间过长，它会阻塞所有更低优先级的任务，包括那些高优先级的实时任务。一个执行时间不定的冗长ISR会直接破坏任务调度的确定性，使得最坏情况响应时间（Worst-Case Response Time, WCRT）分析失效，这对于硬实时系统是致命的。
内核对象访问的约束：RTOS内核的许多功能（如互斥量、任务挂起/恢复、某些队列操作）在中断上下文中是禁止使用的，因为它们可能引发任务阻塞或复杂的上下文切换，而ISR不具备任务控制块（TCB）等完整的上下文环境，强行使用会导致系统崩溃。
优先级管理的复杂性：在具有嵌套中断的系统中，ISR之间的优先级关系需要精心设计。若一个低优先级ISR持有关键资源（如通过简单的关中断进行保护），它可能被高优先级ISR抢占，从而引入中断层面的“优先级反转”问题。
因此，FreeRTOS提倡一种新的中断处理范式：中断仅作为“事件触发器”和“数据采集器”，而将耗时的“数据处理”和“业务逻辑”推迟到“任务上下文”中执行。这种“中断延迟处理”（Deferred Interrupt Processing）的模型，是设计RTOS兼容ISR的核心思想。它将中断响应时间（Interrupt Response Time）与中断处理时间（Interrupt Processing Time）解耦，在保证对硬件事件快速响应的同时，将不确定性的处理负载转移到可被RTOS规范调度的任务中，从而维护了系统整体的实时性和稳定性。
7.1.2 延迟中断处理（Deferred Interrupt Processing）
这是FreeRTOS中最常用、最经典的中断处理模式。其核心是将ISR的工作划分为两个阶段：
- 第一阶段（在ISR中执行）：
- 确认和清除硬件中断标志（防止重复进入）。
- 执行必需的、时间紧迫的硬件操作（如读取ADC数据寄存器、清空UART接收缓冲区）。
- 通过非阻塞、线程安全的RTOS API（以
FromISR结尾），向一个等待处理的任务发送信号或数据。
- 第二阶段（在任务中执行）：
- 一个专门的任务阻塞在某个RTOS对象（如信号量、队列）上。
- 当ISR发送信号后，该任务被解除阻塞，随后执行所有耗时的数据处理、状态计算和业务逻辑。
这种模式的关键在于，ISR与任务之间通过一个RTOS通信对象进行同步。以二进制信号量为例的典型流程如下图所示：
