2、RTOS核心概念速览：任务、调度器、临界区、内核对象在照明场景中的映射

好，咱们直接进入正题。这一章我打算用最快的速度，把RTOS里最核心的几个概念给你捋一遍。你可能会问：「这些概念我书上都看过，但到底怎么用到照明系统里？」

嗯，这正是我要讲的。咱们不搞纯理论，每个概念我都给你对应到一个具体的照明场景。你想想看，一个智能灯泡里跑着RTOS，它到底在忙些什么？

2.1 任务（Task）—— 照明系统里的「小工人」

任务，说白了就是一段独立执行的代码。在RTOS里，每个任务都有自己的栈空间和优先级。它们轮流占用CPU，看起来就像「同时」在运行。

在照明场景里，任务是怎么映射的？

我举个例子。一个智能筒灯，它可能需要同时干这几件事：

• 调光控制任务：负责接收PWM指令，改变LED亮度
• 通信处理任务：处理来自手机App的蓝牙或Zigbee消息
• 状态上报任务：每隔几秒把当前亮度、色温上报给网关
• 按键扫描任务：检测物理按键是否被按下

你看，每个任务就是一个独立的小工人。它们各司其职，互不干扰。我在做一款舞台追光灯项目时，就遇到过一个问题：通信任务卡住了，结果调光任务也跟着停摆。后来改成多任务架构，每个任务独立运行，问题就解决了。

2.2 调度器（Scheduler）—— 谁先干活？谁让一让？

调度器是RTOS的大脑。它决定：此时此刻，哪个任务该运行。

照明场景里的调度策略

我常用的调度方式有两种：

• 抢占式调度：高优先级任务来了，低优先级任务立刻让路。比如，紧急的过温保护任务优先级最高，一旦温度超标，立刻打断正在执行的调光任务。
• 时间片轮转：同优先级的任务，每人分一小段时间。比如两个状态上报任务，轮流上报，谁也不饿着。

我个人习惯在照明项目里用抢占式调度。为什么？因为照明系统里有些事真的不能等。比如，你按了关灯键，结果调度器还在让调光任务慢慢跑，那用户体验就太差了。

2.3 临界区（Critical Section）—— 别抢我的数据！

临界区，就是一段「不允许被打断」的代码。通常用来保护共享数据。

照明场景里的临界区

举个例子。你的调光任务和通信任务，都可能修改同一个变量——target_brightness（目标亮度）。如果通信任务刚把亮度值改成50%，还没来得及写入硬件，调光任务突然插进来读走了旧值……嗯，灯泡就会闪一下。

解决办法很简单：在读写这个变量时，进入临界区。

// 进入临界区
taskENTER_CRITICAL();
target_brightness = new_value;
// 退出临界区
taskEXIT_CRITICAL();

说白了，临界区就是给共享数据上了一把锁。谁要动它，就得先拿钥匙。

2.4 内核对象：信号量、队列、事件标志组

这三个东西，是任务之间通信和同步的「工具」。咱们一个一个看。

2.4.1 信号量（Semaphore）—— 资源够不够用？

信号量，本质上是一个计数器。它用来管理有限资源的访问。

照明场景里的信号量

假设你的照明系统里只有1个I2C总线，用来控制多个LED驱动芯片。多个任务都想用这个总线，怎么办？

• 创建一个二值信号量，初始值为1（表示总线空闲）
• 任务想用总线时，先获取信号量（xSemaphoreTake）
• 用完后释放信号量（xSemaphoreGive）

这样就能保证同一时刻只有一个任务在使用I2C总线。不会出现数据错乱。

2.4.2 队列（Queue）—— 传个消息给你

队列，就是任务之间传递数据的「信箱」。一个任务往里放，另一个任务从里取。

照明场景里的队列

最常见的用法：通信任务收到手机App发来的调光指令，把指令打包成一个结构体，扔进队列。调光任务从队列里取出指令，然后执行。

// 定义消息结构体
typedef struct {
    uint8_t command;    // 0: 调光, 1: 调色温
    uint16_t value;     // 亮度或色温值
} LightMsg_t;

// 发送到队列
LightMsg_t msg = {.command = 0, .value = 80};
xQueueSend(lightQueue, &msg, portMAX_DELAY);

// 接收队列
LightMsg_t receivedMsg;
xQueueReceive(lightQueue, &receivedMsg, portMAX_DELAY);

你想想看，如果没有队列，通信任务直接调用调光函数，那通信任务就会被阻塞住。有了队列，通信任务只管发消息，调光任务慢慢处理，互不耽误。

2.4.3 事件标志组（Event Group）—— 多个条件都满足才干活

事件标志组，就是一组二进制标志位。每个位代表一个事件是否发生。任务可以等待多个事件同时满足，或者任意一个满足。

照明场景里的事件标志组

举个例子。一个智能灯带，需要同时满足以下条件才能启动「日落模式」：

• 位0：时间到了18:00（定时器触发）
• 位1：光线传感器检测到环境变暗
• 位2：用户没有手动干预（按键未按下）

你可以创建一个事件标志组，让「日落模式任务」等待这三个位同时置1。只有全部满足，才执行模式切换。

// 定义事件位
#define EVENT_TIME      (1 << 0)
#define EVENT_DARK      (1 << 1)
#define EVENT_NO_TOUCH  (1 << 2)

// 等待三个事件同时发生
EventBits_t bits = xEventGroupWaitBits(
    eventGroup,
    EVENT_TIME | EVENT_DARK | EVENT_NO_TOUCH,
    pdTRUE,   // 退出时清除事件位
    pdTRUE,   // 等待所有位
    portMAX_DELAY
);

说白了，事件标志组就是「多条件触发」的利器。比用多个信号量组合要方便得多。

2.5 小结：一张表看懂映射关系

最后，我整理了一张表。你可以把它当作速查手册。

RTOS概念	照明场景映射	典型用途
任务	调光、通信、按键、上报	每个独立功能一个任务
调度器	决定哪个任务先运行	抢占式保证实时性
临界区	保护共享变量（如亮度值）	防止数据竞争
信号量	管理I2C总线、同步初始化	资源互斥、任务同步
队列	传递调光指令、状态消息	任务间数据传递
事件标志组	多条件触发模式切换	等待多个事件同时发生

嗯，这一章的内容就到这里。这些概念你看着可能觉得简单，但真正用起来，每个都有不少坑。后面的章节，我会带着你一步步把这些概念落地到代码里。到时候你就知道，RTOS不是玄学，它就是一套帮你把复杂系统管好的工具。