📚 课程目录第4章任务与调度对比

4、任务与调度对比：裸机中的任务划分与RTOS中的任务模型，任务状态机（就绪、运行、阻塞、挂起）

在嵌入式系统开发中，任务与调度机制是决定系统实时性、可靠性和可维护性的核心要素。裸机系统（Bare-Metal）与实时操作系统（RTOS）在任务划分和调度策略上存在本质差异。裸机系统依赖程序员手动设计主循环和中断服务程序（ISR）来实现多任务并发，而RTOS则通过内核提供的任务管理、调度器和同步机制，将任务抽象为独立执行的实体。理解两者的任务模型差异，以及RTOS中任务状态机的完整转换路径，是嵌入式工程师从裸机开发过渡到RTOS开发的关键一步。本章将深入剖析裸机任务划分的局限性与RTOS任务模型的优势，并详细拆解任务状态机的每个状态及其转换条件。

4.1 裸机系统中的任务划分：从主循环到中断驱动

4.1.1 核心原理：裸机任务的本质是“时间片轮转”与“事件触发”

裸机系统没有内核调度器，所有任务的执行顺序由程序员在代码中显式控制。最常见的任务划分方式是“超级循环”（Super Loop）结构：while(1) 循环中依次调用各个功能模块的处理函数，每个函数执行一小段操作后立即返回，避免长时间占用CPU。另一种方式是“中断驱动”模型，将实时性要求高的任务放在ISR中执行，主循环只处理非实时任务。裸机任务划分的核心原则是：将系统功能拆分为若干个短小的、非阻塞的函数，通过轮询标志位或状态机来协调执行顺序。

4.1.2 判断方法与操作流程：如何合理划分裸机任务

裸机任务划分需要遵循以下步骤：

识别系统功能模块：将系统功能分解为独立模块，如按键扫描、LED显示、传感器读取、通信处理等。
评估实时性要求：对每个模块标注实时性等级（高/中/低）。高实时性任务（如紧急停机）必须放入ISR，中实时性任务（如通信接收）可放入主循环高频轮询，低实时性任务（如数据显示）可低频处理。
设计任务执行周期：为每个任务分配执行频率，例如按键扫描每10ms执行一次，LED刷新每50ms执行一次。
实现任务间通信：使用全局变量、标志位或环形缓冲区传递数据，注意使用 volatile 关键字防止编译器优化。

4.1.3 案例拆解：一个简易温控器的裸机任务划分

假设设计一个温控器，需要完成温度采集（每100ms）、PID计算（每200ms）、加热控制（每500ms）、按键输入（每20ms）和LCD显示（每200ms）。在裸机系统中，任务划分如下：

// 裸机超级循环示例
volatile uint8_t flag_100ms, flag_200ms, flag_500ms, flag_20ms;

void main(void) {
    init_system();
    while(1) {
        if (flag_20ms) { key_scan(); flag_20ms = 0; }
        if (flag_100ms) { temp_read(); flag_100ms = 0; }
        if (flag_200ms) { pid_calc(); lcd_display(); flag_200ms = 0; }
        if (flag_500ms) { heater_control(); flag_500ms = 0; }
    }
}

// 定时器中断中设置标志位
void TIM_ISR(void) {
    static uint16_t cnt = 0;
    cnt++;
    if (cnt % 2 == 0) flag_20ms = 1;    // 20ms
    if (cnt % 10 == 0) flag_100ms = 1;  // 100ms
    if (cnt % 20 == 0) flag_200ms = 1;  // 200ms
    if (cnt % 50 == 0) flag_500ms = 1;  // 500ms
}

这个案例中，任务划分依赖定时器中断产生时间基准，主循环按优先级顺序轮询标志位。但存在明显问题：如果 pid_calc() 执行时间超过20ms，按键扫描就会被延迟，导致按键响应不及时。这就是裸机任务划分的固有缺陷——任务间存在隐式优先级，长任务会阻塞短任务。

4.1.4 常见误区与总结复盘

常见误区：认为裸机系统“没有任务”，或者“任务就是函数”。实际上，裸机任务划分的核心是时间管理——每个任务必须在规定时间内完成执行，否则会破坏整个系统的实时性。另一个误区是过度依赖中断，将所有任务都塞进ISR，导致中断嵌套过深、栈溢出风险增加。

裸机任务划分的复盘要点：任务粒度要适中，过粗会导致实时性差，过细会增加上下文切换开销（虽然裸机没有上下文切换，但函数调用和标志位检查也有成本）。对于任务数少于5个、实时性要求不高的简单系统，裸机方案足够；但一旦任务数增多或实时性要求提高，RTOS的优势就显现出来。

4.2 RTOS中的任务模型：独立栈空间与内核管理

4.2.1 核心原理：任务是被内核调度的独立执行单元

在RTOS中，任务（Task）是一个无限循环的函数，拥有独立的栈空间、优先级和任务控制块（TCB）。内核调度器根据任务优先级和调度策略（抢占式/时间片轮转）决定哪个任务获得CPU使用权。与裸机不同，RTOS任务可以主动阻塞（等待事件或延时），此时CPU会切换到其他就绪任务，实现真正的并发执行。每个任务看起来像是“独占CPU”，实际上由内核在微秒级时间内完成上下文切换。

4.2.2 任务状态机：就绪、运行、阻塞、挂起

RTOS任务在生命周期内会经历多种状态转换，理解状态机是掌握RTOS调度的基础。以下是四种核心状态的定义：

状态	英文	定义	进入条件	退出条件
就绪	Ready	任务已具备运行条件，等待调度器分配CPU	任务创建完成、阻塞/挂起恢复	被调度器选中进入运行态
运行	Running	任务正在占用CPU执行代码	调度器从就绪队列中选择	被更高优先级任务抢占、主动阻塞、延时或挂起
阻塞	Blocked	任务等待某个事件或资源，不占用CPU	调用延时函数、等待信号量/队列/互斥量	事件发生、超时或资源可用
挂起	Suspended	任务被显式暂停，不参与调度	调用 `vTaskSuspend()`	调用 `vTaskResume()`

4.2.3 状态转换的完整路径与调度时机

任务状态转换由内核API触发，具体转换路径如下：

就绪 → 运行：调度器选择最高优先级的就绪任务，分配CPU。在抢占式调度中，当更高优先级任务进入就绪态时，当前运行任务立即被抢占。
运行 → 阻塞：任务调用 vTaskDelay()、xQueueReceive()、xSemaphoreTake() 等阻塞型API，主动让出CPU。
阻塞 → 就绪：等待的事件发生（如信号量释放、队列收到数据）或延时时间到，任务回到就绪队列。
运行 → 挂起：任务调用 vTaskSuspend(NULL) 挂起自身，或由其他任务调用 vTaskSuspend(handle) 挂起它。
挂起 → 就绪：调用 vTaskResume(handle) 恢复任务，任务直接进入就绪态。
阻塞 → 挂起：在阻塞状态下被其他任务挂起，此时任务进入挂起态，但阻塞条件仍然保留。

  关键区别：阻塞是任务“主动等待”某种条件，而挂起是“被动暂停”。阻塞的任务在条件满足后会自动恢复，而挂起的任务必须由外部显式恢复。在实际开发中，挂起常用于调试或临时禁用某个任务，而阻塞是任务间同步的主要手段。

4.2.4 案例拆解：FreeRTOS中多任务温控器实现

使用FreeRTOS重新实现上述温控器，任务划分如下：

// 任务函数定义
void vTaskTempRead(void *pvParameters) {
    for(;;) {
        read_temperature_sensor();
        vTaskDelay(pdMS_TO_TICKS(100));  // 阻塞100ms
    }
}

void vTaskPidCalc(void *pvParameters) {
    for(;;) {
        xQueueReceive(xTempQueue, &temp_val, portMAX_DELAY);  // 阻塞等待温度数据
        pid_compute(&temp_val);
        xQueueSend(xCtrlQueue, &ctrl_val, 0);
    }
}

void vTaskHeaterCtrl(void *pvParameters) {
    for(;;) {
        xQueueReceive(xCtrlQueue, &ctrl_val, portMAX_DELAY);
        heater_set(ctrl_val);
    }
}

void vTaskKeyScan(void *pvParameters) {
    for(;;) {
        key_scan();
        vTaskDelay(pdMS_TO_TICKS(20));
    }
}

// 创建任务
xTaskCreate(vTaskTempRead, "TempRead", 128, NULL, 3, NULL);
xTaskCreate(vTaskPidCalc, "PidCalc", 256, NULL, 2, NULL);
xTaskCreate(vTaskHeaterCtrl, "HeaterCtrl", 128, NULL, 2, NULL);
xTaskCreate(vTaskKeyScan, "KeyScan", 128, NULL, 1, NULL);
vTaskStartScheduler();

在这个案例中，每个任务都是独立的无限循环，通过 vTaskDelay() 或队列接收实现阻塞。当 vTaskPidCalc 等待温度数据时，CPU自动切换到 vTaskKeyScan 执行，实现了真正的并发。任务间通过队列传递数据，避免了全局变量带来的竞态问题。优先级设置确保温度采集（优先级3）优先于按键扫描（优先级1），PID计算和加热控制（优先级2）居中。

4.2.5 常见误区与总结复盘

常见误区一：认为任务状态越多越好。实际上，FreeRTOS还包含“就绪挂起”和“阻塞挂起”等组合状态，但理解四种核心状态已足够应对绝大多数开发场景。
常见误区二：在任务中使用 while(1) 空转等待事件，而不是调用阻塞API。这会浪费CPU资源，且导致低优先级任务饿死。
常见误区三：忽略任务栈大小设置。每个任务独立栈空间，栈溢出会导致系统崩溃，应使用 uxTaskGetStackHighWaterMark() 检查栈余量。

RTOS任务模型的复盘要点：任务划分应遵循“高内聚、低耦合”原则，每个任务只做一件事；任务间通信优先使用队列和信号量，避免直接访问共享变量；合理设置任务优先级，确保实时性要求高的任务优先执行。与裸机相比，RTOS的代价是额外的RAM开销（每个任务栈空间）和上下文切换时间，但对于任务数超过5个、实时性要求高的系统，RTOS的收益远大于成本。

4.3 裸机与RTOS任务模型对比总结

对比维度	裸机任务模型	RTOS任务模型
任务定义	函数 + 标志位轮询	独立栈空间 + TCB + 优先级
调度方式	手动控制执行顺序	内核抢占式/时间片调度
阻塞机制	无，CPU空转等待	支持延时、信号量、队列阻塞
任务间通信	全局变量 + 标志位	队列、信号量、互斥量、事件组
实时性保障	依赖中断优先级和主循环顺序	优先级抢占，高优先级任务立即执行
代码可维护性	任务间耦合度高，修改影响全局	任务独立，模块化程度高
资源开销	极低（仅RAM/ROM）	额外RAM（栈）+ 内核代码空间
适用场景	任务少（≤5）、实时性要求低	任务多、实时性要求高、复杂交互

在实际工程中，选择裸机还是RTOS并非。对于简单的LED闪烁、按键检测等场景，裸机足够；但对于需要多任务并发、复杂同步、严格实时性保障的系统（如无人机飞控、工业PLC、汽车ECU），RTOS是必然选择。理解任务状态机是使用RTOS的基础，开发者需要熟练掌握任务创建、阻塞、挂起、恢复等API，并能够根据系统需求合理设计任务优先级和通信机制。从裸机过渡到RTOS，不仅是代码结构的改变，更是编程思维的转变——从“手动管理一切”到“让内核帮你管理”。