上下文切换（Context Switch）
上下文切换是RTOS任务调度的核心机制，用于在不同任务之间保存与恢复CPU执行状态， 保证多任务系统在有限CPU资源下的正确运行。
机制定义
相关内核机制： 切换流程模型
/* 任务上下文（TCB核心结构） */
typedef struct tcb {
uint32_t *sp; // 栈指针
uint32_t *pc; // 程序计数器
uint32_t regs[16]; // 通用寄存器
uint8_t state; // Running / Ready / Blocked
uint32_t priority; // 优先级
} tcb_t;
相关API： os_task_function · os_task · os_task_release · os_scheduling
上下文切换背景
上下文切换是硬实时操作系统实现多任务并发的核心机制。在单核CPU环境下，多个任务通过快速切换共享CPU资源，产生并行执行的错觉。上下文切换确保每个任务在切换后能从正确的断点继续执行，不丢失执行状态。
实时系统需要上下文切换机制的原因在于，嵌入式应用通常包含多个并发任务，如传感器采样、数据处理、用户界面、网络通信等。这些任务需要在不同时间片内交替执行，通过上下文切换实现任务隔离与状态保护。
在汽车电子、工业控制、航空航天等典型应用中，上下文切换的延迟直接影响系统实时性。HRTOS通过优化寄存器保存路径与汇编实现，将切换延迟控制在微秒级，满足硬实时系统的响应要求。
寄存器现场保存
寄存器现场保存是上下文切换的第一步。HRTOS保存通用寄存器（R0-R15）、程序计数器（PC）、栈指针（SP）、状态寄存器（CPSR）等关键上下文信息。保存位置为任务TCB中的寄存器快照区域，确保切换后能准确恢复。
不同CPU架构的寄存器集合不同，HRTOS通过架构相关汇编代码实现最优保存路径。ARM Cortex-M架构支持硬件自动保存部分寄存器，HRTOS利用硬件特性减少软件保存开销。寄存器保存必须在中断禁用状态下完成，避免中断破坏上下文一致性。
寄存器保存的完整性直接影响任务切换的正确性。遗漏任何寄存器都可能导致任务恢复后执行错误。HRTOS通过寄存器保存清单与自动化测试确保所有必要寄存器都被正确保存。
堆栈切换机制
堆栈切换确保每个任务使用独立的栈空间。HRTOS为每个任务分配固定大小栈，栈指针保存在TCB中。切换时，系统更新CPU栈指针寄存器，使其指向目标任务栈顶。栈大小规划需考虑任务函数调用深度、局部变量使用量、中断栈需求等因素。
栈溢出是上下文切换的常见错误。当任务栈空间不足时，栈指针可能超出分配范围，导致数据损坏或系统崩溃。HRTOS提供栈溢出检测机制，在栈指针越界时触发异常。开发者需根据任务特性合理规划栈大小，避免溢出风险。
栈切换的原子性是关键要求。切换过程中必须确保栈指针更新与寄存器保存的原子性，避免中断破坏栈一致性。HRTOS通过临界区保护与汇编原子指令确保栈切换的安全性。
任务控制块更新
任务控制块（TCB）是任务在内核中的数据结构，包含栈指针、程序计数器、寄存器快照、状态标识、优先级等关键信息。上下文切换时，系统更新TCB中的状态字段，将当前任务状态从Running转换为Ready或Blocked。
TCB更新还包括时间片计数、等待时间、运行统计等维护信息。这些信息用于调度决策与性能分析。HRTOS的TCB设计紧凑高效，通过字段优化减少内存占用。
TCB的访问必须受保护，避免并发访问导致数据不一致。HRTOS通过自旋锁或关中断保护TCB访问，确保多核环境下的数据一致性。
执行上下文恢复
执行上下文恢复是上下文切换的最后步骤。系统从目标任务TCB中读取保存的寄存器值，写入CPU寄存器。恢复完成后，CPU跳转到任务断点继续执行。恢复操作必须原子性完成，避免中断破坏上下文一致性。
程序计数器恢复决定任务从何处继续执行。PC值保存在TCB中，通常指向任务函数入口或上次切换时的断点。对于首次运行的任务，PC指向任务函数入口；对于被切换的任务，PC指向断点指令。
状态寄存器恢复确保任务在正确的处理器模式下执行。ARM Cortex-M支持Thread模式与Handler模式，不同模式访问权限不同。HRTOS确保任务恢复时处于正确的处理器模式与中断配置。
触发条件
上下文切换通常由以下情况触发：
时间片耗尽
调度器Tick中断触发任务切换。
高优先级任务就绪
新任务进入Ready状态，抢占当前任务。
任务阻塞
等待信号量、消息或资源导致CPU释放。
中断返回调度
中断服务函数结束后触发调度判断。
相关API： os_switch os_task_ready os_wait1 os_delay
时间片耗尽触发
时间片耗尽是周期性上下文切换的常见触发源。HRTOS为每个任务分配固定时间片，任务执行时时间片计数器递减。当时间片减至零时，调度器强制切换到下一个同优先级任务。时间片轮转确保同优先级任务公平分享CPU时间。
时间片大小影响系统吞吐量与响应延迟。时间片过大导致响应延迟增加，时间片过小增加切换开销。HRTOS支持动态时间片调整，根据任务特性优化调度性能。典型时间片设置为10ms至100ms。
高优先级任务就绪触发
高优先级任务就绪是抢占式调度的核心触发源。当高优先级任务从阻塞状态恢复或新创建时，如果其优先级高于当前运行任务，调度器立即触发抢占切换。抢占调度确保关键任务获得及时响应，满足实时性要求。
抢占切换的延迟直接影响系统实时性。HRTOS通过快速调度路径与优先级队列优化，将抢占延迟控制在微秒级。开发者需合理规划任务优先级，避免频繁抢占导致系统抖动。
任务阻塞触发
任务阻塞是主动释放CPU的触发源。任务通过等待信号量、消息队列、延时等系统调用进入阻塞状态。阻塞任务从运行队列移至等待队列，不占用CPU资源。调度器选择下一个就绪任务执行。
阻塞操作的效率影响系统吞吐量。HRTOS支持多级阻塞队列，按事件类型分类管理等待任务。阻塞条件满足后，任务快速恢复就绪状态，减少等待时间。
中断返回调度触发
中断返回调度是异步事件驱动的触发源。中断服务程序执行完成后，系统检查是否需要调度决策。如果中断导致高优先级任务就绪或当前任务被阻塞，触发任务切换。中断返回路径需优化，降低中断延迟。
中断优先级与任务优先级需协调配置。高优先级中断可能触发高优先级任务就绪，形成级联调度。HRTOS支持中断嵌套与中断底半部处理，平衡中断响应时间与任务调度开销。
执行流程
1. 保存当前任务上下文
保存PC、SP、寄存器组到任务控制块（TCB）。
2. 更新任务状态
将Running状态转换为Ready或Blocked。
3. 调度器选择任务
根据优先级或时间片选择下一个执行任务。
4. 恢复任务上下文
恢复目标任务寄存器与堆栈指针。
5. CPU继续执行
跳转到任务断点位置继续运行。
保存现场 → PUSH R0-Rx → 保存SP → 保存PC →
调度器选择 → 恢复SP → POP R0-Rx → 返回PC
相关 API： os_task · os_task_function · os_task_ready · os_task_state
核心结构： os_task os_task_state os_task_function
上下文保存详细流程
上下文保存的第一步是关中断，确保保存过程不被打断。HRTOS通过关中断指令进入临界区，防止中断破坏寄存器现场。关中断时间需尽可能短，避免影响系统实时性。
寄存器保存顺序影响保存效率。HRTOS采用优化的保存顺序，先保存通用寄存器，再保存特殊寄存器如PC、SP、状态寄存器。ARM Cortex-M架构支持硬件自动保存部分寄存器，HRTOS利用硬件特性减少软件保存开销。
保存完成后，系统更新TCB中的状态字段，将当前任务状态从Running转换为Ready或Blocked。状态更新必须与寄存器保存原子性完成，避免状态不一致。HRTOS通过汇编原子指令确保状态更新的原子性。
调度器选择流程
调度器选择是上下文切换的核心决策步骤。调度器从就绪队列中选择最高优先级任务，或按时间片轮转选择下一个任务。调度算法直接影响系统实时性与公平性。
HRTOS调度器采用优先级队列实现，选择时间复杂度为O(1)。就绪队列按优先级排序，高优先级任务位于队列头部。调度器只需读取队列头部即可获得最高优先级任务，无需遍历整个队列。
调度器还需考虑时间片状态。如果当前任务时间片未耗尽且无更高优先级任务就绪，调度器可能选择继续运行当前任务。这种优化减少不必要的切换，提高系统效率。
上下文恢复详细流程
上下文恢复的第一步是从目标任务TCB读取保存的寄存器值。恢复顺序与保存顺序相反，先恢复特殊寄存器，再恢复通用寄存器。恢复过程同样需关中断，确保恢复过程不被打断。
栈指针恢复是恢复过程的关键步骤。系统更新CPU栈指针寄存器，使其指向目标任务栈顶。栈指针恢复后，局部变量与函数调用链正确指向目标任务栈空间。
程序计数器恢复决定任务从何处继续执行。PC值恢复后，CPU从指定地址取指执行。对于首次运行的任务，PC指向任务函数入口；对于被切换的任务，PC指向断点指令。
恢复完成后，系统开中断，允许中断响应。最后通过中断返回指令跳转到目标任务，完成上下文切换。整个过程在微秒级完成，满足硬实时系统的响应要求。
中断返回流程
中断返回是上下文切换的特殊形式。中断服务程序执行完成后，系统检查是否需要调度决策。如果需要，执行任务切换；否则直接返回被中断任务。
HRTOS优化中断返回路径，减少不必要的上下文保存。如果中断未导致调度需求，系统直接恢复被中断任务的上下文，跳过调度器选择步骤。这种优化显著降低中断延迟。
中断返回流程还需考虑中断嵌套。嵌套中断返回时，系统需逐层恢复中断上下文。HRTOS通过中断栈管理嵌套中断，确保每层中断正确返回。
演示代码
/****************************************************************************
* HRTOS Context Switch 实验（基于真实API）
* 依赖：HRTOS_KERNEL.H / HRTOS.H
* 目标：验证任务切换 + 调度器 + 优先级行为
****************************************************************************/
#include
#include
/* =========================
* 任务ID定义
* ========================= */
#define TASK_A_ID 0
#define TASK_B_ID 1
/* =========================
* 任务函数
* ========================= */
/* Task A */
void task_A(void)
{
while(1)
{
os_task_function(TASK_B_ID); // 指定下一个任务（触发切换）
// 模拟运行负载
os_nop();
os_nop();
os_news_send1(0, 0xA1); // 写入邮箱（验证执行路径）
os_task_service(TASK_A_ID); // 任务服务登记（内核行为）
}
}
/* Task B */
void task_B(void)
{
while(1)
{
os_task_function(TASK_A_ID); // 切换回A
os_wait1(5); // 模拟延时（触发调度窗口）
os_news_send1(1, 0xB2); // 邮箱通信验证
os_task_service(TASK_B_ID);
}
}
/* =========================
* 系统初始化
* ========================= */
void system_init(void)
{
/* 初始化调度模式（HRTOS模式） */
os_scheduling(1); // 1 = HRTOS模式
/* 初始化任务 */
os_task((unsigned int)task_A, TASK_A_ID, 3, 0);
os_task((unsigned int)task_B, TASK_B_ID, 2, 0);
/* 初始化邮箱 */
os_mail_init();
/* 初始化锁（可选） */
os_lock_init();
}
/* =========================
* 主函数
* ========================= */
void main(void)
{
system_init();
/* 启动第一个任务 */
os_task_release(TASK_A_ID);
while(1)
{
/* 系统空循环，由RTOS接管 */
os_nop();
}
}
系统意义
上下文切换是RTOS实现多任务并发的基础机制，其开销直接影响系统实时性。 在HRTOS中，该机制被优化为最小寄存器保存路径，以降低中断延迟。
多任务并发基础
上下文切换是实现多任务并发的核心技术。在单核CPU环境下，多个任务通过快速切换共享CPU资源，产生并行执行的错觉。每个任务拥有独立的执行上下文，切换时保存当前状态，恢复目标任务状态，确保任务间互不干扰。
实时系统依赖上下文切换实现任务隔离与状态保护。汽车电子、工业控制等应用包含多个并发任务，如传感器采样、数据处理、用户界面、网络通信。这些任务通过上下文切换交替执行，满足系统功能需求。
实时性影响分析
上下文切换开销直接影响系统实时性。切换延迟包括寄存器保存、调度决策、寄存器恢复等步骤的耗时。切换延迟过大可能导致任务响应不及时，影响硬实时系统的确定性。
HRTOS通过多种优化降低切换延迟。寄存器保存路径采用汇编实现，利用硬件特性减少软件开销。调度器采用O(1)时间复杂度的优先级队列，快速选择目标任务。整体切换延迟控制在微秒级，满足硬实时系统要求。
系统开销平衡
上下文切换开销与系统实时性需平衡。切换频率过高增加CPU开销，切换频率过低影响响应延迟。HRTOS支持可配置的切换策略，根据应用需求调整切换频率与开销。
时间片大小影响切换频率。时间片过大减少切换次数但增加响应延迟，时间片过小增加切换次数但降低响应延迟。HRTOS支持动态时间片调整，根据任务特性优化切换策略。
优先级调度支持
上下文切换是实现优先级调度的关键机制。高优先级任务就绪时，系统通过上下文切换快速抢占CPU。抢占调度确保关键任务获得及时响应，满足实时性要求。
HRTOS支持抢占式调度与非抢占式调度。抢占式调度响应快但开销大，非抢占式调度开销小但响应慢。开发者可根据应用需求选择调度策略，平衡实时性与系统开销。