RTOS重构-多任务架构的优雅解耦

// 传感器采集任务：周期性执行，专注数据采集
void Task_Sensor(void *argument) {
sensor_data_t sensor_data;
osMessageQueueId_t data_queue = (osMessageQueueId_t)argument;

for(;;) {
// 执行采集
sensor_data.temperature = read_temperature();
sensor_data.humidity = read_humidity();

// 非阻塞发送到队列，即使队列满也不会死等
osMessageQueuePut(data_queue, &sensor_data, 0, 0);

// 主动阻塞100ms，期间CPU释放给其他任务
osDelay(100);
}
}

// 按键处理任务：高优先级，确保实时响应
void Task_Key(void *argument) {
osEventFlagsId_t event_flags = (osEventFlagsId_t)argument;

for(;;) {
// 阻塞等待按键中断信号（通过IRQ sem或GPIO中断）
osSemaphoreAcquire(key_sem, osWaitForever);

// 消抖处理后设置事件标志
if(Key_ConfirmedPressed()) {
osEventFlagsSet(event_flags, KEY_EVENT_FLAG);
}
}
}

// 通信任务：低优先级，专注数据传输
void Task_Comm(void *argument) {
sensor_data_t sensor_data;
osMessageQueueId_t data_queue = (osMessageQueueId_t)argument;
osEventFlagsId_t event_flags = (osEventFlagsId_t)argument;
uint32_t flags;

for(;;) {
// 等待数据或按键事件（50ms超时）
flags = osEventFlagsWait(event_flags,
KEY_EVENT_FLAG,
osFlagsWaitAny | osFlagsNoClear,
50);

// 处理按键事件：高优先级响应
if(flags & KEY_EVENT_FLAG) {
UART_SendString(“Key Pressed!\r\n”);
osEventFlagsClear(event_flags, KEY_EVENT_FLAG);
}

// 处理传感器数据：队列非阻塞读取
if(osMessageQueueGet(data_queue, &sensor_data, NULL, 0) == osOK) {
UART_SendFormatted(“Temp:%.1fC Humi:%.1f%%\r\n”,
sensor_data.temperature,
sensor_data.humidity);
// UART_Send内部可用DMA，任务立即返回
}

// 无事件时进入阻塞，等待50ms后自动唤醒
// 或使用osDelayUntil实现严格周期
}
}

// 初始化与启动
int main(void) {
HAL_Init();
// 创建内核对象
data_queue = osMessageQueueNew(8, sizeof(sensor_data_t), NULL);
event_flags = osEventFlagsNew(NULL);
key_sem = osSemaphoreNew(1, 0, NULL); // 按键中断释放信号量

// 创建任务
osThreadNew(Task_Sensor, data_queue, &sensor_attr);
osThreadNew(Task_Key, event_flags, &key_attr);
osThreadNew(Task_Comm, &comm_args, &comm_attr);

osKernelStart(); // 启动调度器
}

RTOS架构的核心优势
实时性保障
Task_Key设置为高优先级（如osPriorityHigh），当按键中断释放信号量时，即使Task_Comm正在执行UART发送，调度器也会立即在PendSV中切换至高优先级任务。实际响应延迟可控制在几十μs（中断延迟+调度延迟），相较于裸机因阻塞导致的不可预测延迟，RTOS提供了确定性的微秒级响应边界。

模块化设计
三个任务职责单一，符合单一职责原则（SRP）。Task_Sensor只关心数据采集，Task_Comm只负责数据传输，Task_Key专注用户交互。它们通过DataQueue和EventFlags解耦，无需了解彼此的实现细节。新增Task_Display只需订阅data_queue，消费传感器数据，完全不影响现有任务逻辑。

可扩展性
当系统需要添加WiFi数据上传功能时，只需创建Task_Cloud任务，以osMessageQueueGet(data_queue, …)方式竞争消费数据。由于调度器保证所有就绪任务都能执行，新增任务不会导致原有任务”饿死”。通过调整优先级，可精确控制各功能的实时性要求，而无需改动任务内部代码。