当前位置：首页 > news >正文

FreeRtos——7、时序模型：软定时器与中断的“底半部”机制

news 2026/3/27 5:38:40

前言

裸机开发时，我们习惯用HAL_Delay()或者在中断（ISR）里处理所有逻辑。但在 RTOS 中，这样做会造成灾难：HAL_Delay()会让整个 CPU 处于忙等状态，导致低优先级任务直接“饿死”；而在中断里停留太久，则会屏蔽掉其他紧急中断，让系统失去实时性。

为什么系统响应总是慢半拍？

中断越权：在串口接收中断里解析复杂的 JSON 协议，导致高优先级的电机控制任务被延迟。
延时滥用：任务里到处是osDelay，导致逻辑执行的时序点不断漂移。
定时器陷阱：软件定时器回调函数里写了阻塞操作（如osDelay），导致整个系统的定时器全部失效。

把中断给硬件，把逻辑留给任务

2.1 中断延迟处理（Deferred Interrupt Handling）

这是 RTOS 架构的核心思想。

上半部（Top Half）：硬件中断（ISR）。只做最紧急的事：清除标志位、读取寄存器、发信号量。
下半部（Bottom Half）：任务（Task）。获取信号量后，慢慢解析数据。

2.2 软件定时器（Software Timer）

它是由内核的一个守护任务（Daemon Task）管理的。

优点：不占用硬件定时器资源，适合做低频、非精确任务（如 LED 闪烁、超时检测）。
代价：它在守护任务的上下文中运行。如果你的回调函数阻塞了，守护任务就挂了，所有定时器都会停摆。

实操：中断“底半部”处理真实案例

场景：当串口接收到一帧数据时，我们不在中断里处理，而是唤醒一个任务去处理。

3.1 任务通知：最快的中断唤醒方式

osThreadId_t ParserTaskHandle; /* 串口中断回调函数 (ISR 上半部) */ void HAL_UART_RxCpltCallback(UART_HandleTypeDef *huart) { // 1. 发送 Thread Flag 唤醒解析任务 // 注意：在 ISR 中必须使用带 FromISR 结尾的底层 API 或 CMSIS 兼容 API osThreadFlagsSet(ParserTaskHandle, 0x01); } /* 数据解析任务 (下半部) */ void StartParserTask(void *argument) { for(;;) { // 2. 阻塞等待标志位，不占用 CPU uint32_t flags = osThreadFlagsWait(0x01, osFlagsWaitAny, osWaitForever); if (flags == 0x01) { // 3. 执行耗时的协议解析逻辑 // Protocol_Parse(); } } }

软件定时器：避开“上下文陷阱”

我们要创建一个定时器，每 500ms 检查一次按键状态。

3.2 创建与回调

osTimerId_t KeyTimerHandle; // 定时器回调函数：千万不能加 osDelay 或死循环！ void KeyTimer_Callback(void *argument) { // 扫描按键逻辑 // Scan_Keys(); } void Init_Timers(void) { // 创建周期性定时器 KeyTimerHandle = osTimerNew(KeyTimer_Callback, osTimerPeriodic, NULL, NULL); // 启动定时器，500ms 周期 osTimerStart(KeyTimerHandle, 500); }

深度解析：周期性任务的“漂移”

如果你在任务里用osDelay(10)，你的实际周期是 10ms + 任务逻辑耗时。为了实现绝对 10ms的周期，必须使用osDelayUntil。

void AbsoluteTask(void *argument) { uint32_t tick = osKernelGetTickCount(); for(;;) { // 逻辑处理... tick += 10; // 下一个执行点 osDelayUntil(tick); // 即使逻辑跑了 2ms，也会在下一个 10ms 点准时唤醒 } }