【第19期】逻辑模型：同步阻塞 vs 异步事件驱动

裸机与RTOS关键差异：裸机依靠“不断检查标志位”来发现变化；RTOS 依靠“等待信号量/通知”来被动激活。

1. 经典场景：串口数据处理

假设我们需要通过串口接收一包数据，解析它，然后执行命令。

裸机做法：状态机 + 全局 Flag

这也是标准的“前后台系统”（ISR 是前台，Main 是后台）。

• 中断 (ISR)：只负责收字节，存入缓冲区，收到包尾时置位 rx_flag = 1。

• 主循环 (Main)：

• // 全局变量

// 全局变量
volatile uint8_t rx_flag = 0;

while (1) {
    // 轮询检查：你有信吗？你有信吗？
    if (rx_flag == 1) {
        Process_Data(); // 处理数据
        rx_flag = 0;    // 清除标志
    }

    // ... 执行其他几百个任务 ...
}

痛点：

1. 响应延迟：如果主循环很长（例如跑了一遍 GUI 刷新耗时 20ms），那么 rx_flag 变 1 后，最坏要等 20ms 才能被 if 语句检测到。

2. 资源浪费：如果串口很久没数据，CPU 依然要每秒几万次地执行 if (rx_flag == 1)，结果全是 False。

RTOS 做法：同步阻塞 (Synchronous Blocking)

RTOS 的逻辑看起来是“线性的”，但执行起来是“异步的”。我们通常使用 信号量 (Semaphore) 或 任务通知 (Task Notification)。

• 处理任务 (Task)：

void vTaskProcess(void *pvParameters) {
    while (1) {
        // 核心语句：死等！
        // 只要没收到通知，我就一直阻塞在这里，CPU 去跑别的任务。
        // 参数 portMAX_DELAY 表示“不见不散，等到天荒地老”。
        ulTaskNotifyTake(pdTRUE, portMAX_DELAY);

        // 能运行到这一行，说明一定有数据来了！
        // 不需要再写 if(flag)，直接处理。
        Process_Data();
    }
}

• 中断 (ISR)：

void USART_IRQHandler(void) {
    // ... 接收数据 ...
    if (Packet_Received) {
        // 定向叫醒：直接给处理任务发个通知
        vTaskNotifyGiveFromISR(xTaskProcessHandle, &xHigherPriorityTaskWoken);

        // 如果叫醒的任务优先级很高，这里会触发一次调度，
        // 退出中断的一瞬间，CPU 直接跳到 vTaskProcess 去执行 Process_Data()。
    }
}

优势：

1. 零延迟：一旦 ISR 发出通知，如果处理任务优先级够高，RTOS 会立即切换上下文。主循环里的其他低优先级任务根本挡不住。

2. 零空转：没数据的时候，vTaskProcess 根本不占 CPU 资源。

---

2. 思维转变：从“分散”到“集中”

在裸机代码中，我们习惯把逻辑打散。 比如一个按键消抖功能：

• Timer 中断里：tick++。

• 主循环里：if (tick > 10ms) Check_IO();。

逻辑是割裂的，你看代码时得在中断和主循环之间来回跳。

而在 RTOS 中，我们可以写出符合人类直觉的线性代码：

void vTaskKey(void *pvParameters) {
    while (1) {
        // 1. 等待按键中断触发的信号量 (阻塞)
        xSemaphoreTake(Sem_KeyIRQ, portMAX_DELAY);
        
        // 2. 只有按键按下了才会醒来，现在延时 10ms 消抖 (阻塞)
        vTaskDelay(10); 
        
        // 3. 再次读取 IO，确认按键
        if (Read_GPIO() == LOW) {
            // 确认按下，执行逻辑
        }
    }
}

注意到了吗？等待事件 -> 延时 -> 处理，这三步完全写在一个函数里，逻辑连续且清晰，中间的等待过程完全由 OS 接管，不消耗 CPU。

这就是同步阻塞编程模型的力量：代码写起来像是同步的（一步接一步），但执行起来是异步的（中间会挂起等待事件）。

---

3. RTOS 的“事件驱动”本质

裸机程序的驱动力是 轮询 (Polling)。 RTOS 程序的驱动力是 事件 (Event)。

• 裸机：我要不断问前台“快递到了吗？”

• RTOS：我把手机号留给前台（注册等待事件），前台收到快递给我打电话（发送 Signal/Notification），我被电话铃声叫醒（解除阻塞）。

这种模型彻底消灭了全局变量 Flag。在优秀的 RTOS 工程中，你很少会看到 extern volatile int flag; 这种东西，取而代之的是各种 Queue, Semaphore 和 Event Group。

---

本章关键点

1. 裸机痛点：if(flag) 轮询既浪费 CPU 又有延迟。

2. RTOS 方案：Take(Semaphore) 阻塞等待，精准唤醒。

3. 代码美学：RTOS 允许你用“线性”的思维写出“异步”的高效逻辑，将业务逻辑与时间管理解耦。