嵌入式裸机用定时器模拟任务：从超级循环到轻量级时间片调度

嵌入式软件开发到后期，很多人都会遇到同一个坎：功能越加越多，主循环里的if堆成一座山，一个功能改动就要扒开整段逻辑；想上 RTOS，又担心资源不够、学习成本高、项目周期紧。这时候，一种很接地气的解法就派上用场了：用定时器模拟任务。它本质上是在裸机上实现一个轻量级的时间片轮询调度，让 LED 闪烁、按键扫描、通信处理这些“同时发生”的逻辑各干各的，代码结构清楚，也方便以后平滑迁移到 RTOS。

这次我们就把这套设计思路拆开看一遍：从架构分层到软定时器，再到任务调度器，最后给出一份可以直接套用的 C 语言实现。重点解决三个问题：主循环怎么从“超级大循环”变成“多任务”；定时器中断里到底该干什么、不该干什么；任务多了以后如何保证每个功能都能被及时执行。

文章按“设计思路 → 代码实现 → 验证方法 → 排查清单”的顺序来。不想看原理的可以直接跳到第 5 节拿代码，但建议把第 4 节架构设计过一遍，因为代码能跑通只是开始，后面改需求、加功能，拼的才是架构能力。

1. 核心能力速览

这套方案的核心不是“用定时器写延时”，而是把定时器当成系统心跳，通过中断维护一个时间基准，应用层任务统一挂在调度器上。它不像 RTOS 有任务栈、信号量、互斥锁，但解决“多个功能同时跑”的问题已经够用。

2. 适用场景与使用边界

2.1 适合什么场景

• 裸机多任务场景：需要同时处理按键、LCD 刷新、传感器轮询、串口命令解析的项目。
• 资源受限 MCU：RAM / Flash 很小，上 RTOS 太紧张，但主循环又已经乱到维护不动。
• 过渡期项目：团队准备用 RTOS，但当前项目已经接近交付，不想推倒重写。
• 教学和原型验证：快速验证多个任务的调度逻辑，再决定是否换更重的操作系统。
• 需要可移植性的工程：通过统一的调度接口，换芯片时只需改定时器驱动。

2.2 不适合什么场景

• 强实时任务：比如电机控制中的电流环、飞控中的姿态解算，这类任务需要精确到微秒级且支持抢占，应该用硬件中断或专门的控制单元处理，而不是放在软件调度器里。
• 任务间复杂同步：需要信号量、互斥锁、消息队列才能实现的逻辑，用裸机模拟会非常痛苦。
• 长时间阻塞型任务：比如大块 Flash 擦写、慢速传感器长时间等待，这类行为会卡死调度循环，必须拆成状态机或放到低优先级间隙执行。
• 多核 / 复杂外设依赖：任务调度只解决 CPU 时间分配问题，不解决硬件资源竞争，外设互斥仍然要自己管理。

3. 从“超级大循环”到定时器模拟任务

3.1 前后台系统的痛点

传统裸机程序长这样：

int main(void) { HAL_Init(); while (1) { Led_Process(); Key_Scan(); Uart_Process(); Sensor_Read(); Display_Update(); } }

功能少时没问题。功能一多就出问题：Sensor_Read()内部如果有一个while等待转换完成，后面所有函数都要等；Key_Scan()为了消抖用了HAL_Delay(20)，整个循环的节奏全被打乱；想给某个功能不同的执行频率，只能靠一个不断增加的switch-case计数器。这种代码最大的问题不是慢，而是不可预测。你永远不知道某个任务什么时候会被卡住、什么时候能等到 CPU。

3.2 用定时器做“节拍”

定时器模拟任务的思路是：让一个硬件定时器产生固定周期的中断，比如 1ms。每次中断就把一个全局变量tick++。主循环不再按“顺序执行每个函数”，而是按“每个任务自己的周期是否到点”来决定要不要执行它。

这样，Led 任务可以每 500ms 执行一次，Key 任务每 10ms 执行一次，Uart 任务每 1ms 检查一次接收缓冲。它们的代码还是在一个 while 里，但因为每个任务都被拆成了短小、非阻塞的片段，整体行为接近“并行”。

3.3 与 RTOS 的对比

如果你只需要周期性地跑若干函数，定时器模拟是性价比最高的解。

4. 架构设计：分层思想

写嵌入式代码，越往后越会发现，拷贝功能容易，搭架构难。一套能长期维护的定时器模拟任务框架，至少应该分三层：

4.1 硬件抽象层（HAL）

这一层负责封装具体芯片的定时器。上层不关心你用的是 STM32 的 SysTick 还是 GD32 的 TIM0，只关心你能提供：

• Timer_Init(uint32_t period_us)
• Timer_Start(void)
• 一个周期回调入口，比如SysTick_Handler里调用Timer_IsrTick()

好处是换平台时只改这一层。

4.2 调度层（Scheduler）

这一层维护任务表：

• 任务控制块结构体
• 注册函数
• 轮询函数
• 软定时器计数

所有任务都以“函数指针 + 周期 + 运行计数器”的形式存在。调度层在while(1)里不断扫描任务表，判断哪个任务就绪，然后调用它。这一层也负责提供Scheduler_Delay()一类的非阻塞延时，方便任务内部使用。

4.3 应用层（App）

这一层是真正干活的任务。每个任务一个.c文件，内部尽量用状态机实现，不写死循环等待。应用层只依赖调度层提供的注册和执行接口，不直接操作寄存器，这样随便增删任务都不影响调度核心。

4.4 状态机思想

在模拟多任务里，任务内最常见的问题就是阻塞。解决办法就是“把任务拆成状态”。例如一个按键任务：

• 状态 A：等待按下
• 状态 B：消抖中（记录连续读到低电平的 tick 次数）
• 状态 C：确认触发，产生事件

每个状态执行完就返回，等待下一次调度。这样主循环永远不会被HAL_Delay卡住。后面示例代码会体现这一点。

5. 定时器模块代码实现

下面开始写代码。本节先实现一个通用的软定时器模块，它用来驱动后续的调度器。

5.1 timer.h

#ifndef __TIMER_H #define __TIMER_H #include <stdint.h> #define TICK_PERIOD_MS 1u /* 系统时基 1ms */ void Timer_Init(void); void Timer_Delay(uint32_t ms); uint32_t Timer_GetTick(void); #endif

5.2 timer.c

#include "timer.h" #include "main.h" /* 具体平台相关 */ static volatile uint32_t s_tick; void Timer_Init(void) { /* 这里以 SysTick 为例，1ms 中断 */ SysTick_Config(SystemCoreClock / 1000u); } uint32_t Timer_GetTick(void) { uint32_t tick; __disable_irq(); tick = s_tick; __enable_irq(); return tick; } void Timer_Delay(uint32_t ms) { uint32_t start = Timer_GetTick(); while (Timer_GetTick() - start < ms) { /* 空等待 */ } } /* 在 SysTick_Handler 中调用 */ void Timer_IsrTick(void) { s_tick++; }

说明：

• Timer_IsrTick()应该在芯片的定时器中断服务函数里调用。比如 STM32 的SysTick_Handler。
• Timer_GetTick()在读取时关闭中断，避免 32 位计数翻转瞬间读到脏数据。
• Timer_Delay()是阻塞延时，仅用于初始化等少数非任务场景。应用任务里更推荐使用调度器提供的软延时。

5.3 通用定时器兼容写法

如果你的平台没有 SysTick，或者你想用某个通用定时器，比如 TIM2，只要让它的更新中断里调用Timer_IsrTick()即可：

void TIM2_IRQHandler(void) { if (TIM_GetITStatus(TIM2, TIM_IT_Update) != RESET) { Timer_IsrTick(); TIM_ClearITPendingBit(TIM2, TIM_IT_Update); } }

主频、预分频和自动重装值需要按芯片手册计算：

/* 假如主频 72MHz，希望 1ms 中断： prescaler = 72 - 1 period = 1000 - 1 最终定时器频率 = 72MHz / 72 / 1000 = 1kHz */

具体寄存器配置取决于平台，但这部分不影响上层调用。

6. 模拟任务调度器实现

6.1 scheduler.h

#ifndef __SCHEDULER_H #define __SCHEDULER_H #include <stdint.h> #define TASK_MAX_NUM 8u #define TASK_INVALID_ID 0xFFu typedef void (*task_func_t)(void); typedef struct { task_func_t func; /* 任务函数 */ uint32_t period_ms; /* 执行周期 */ uint32_t counter; /* 剩余计数 */ uint8_t is_running; /* 是否注册可运行 */ } task_tcb_t; void Scheduler_Init(void); uint8_t Scheduler_Register(task_func_t func, uint32_t period_ms); void Scheduler_Run(void); void Scheduler_Delay(uint32_t ms); void Scheduler_TickHandler(void); #endif

6.2 scheduler.c

#include "scheduler.h" #include <string.h> static task_tcb_t s_task_list[TASK_MAX_NUM]; void Scheduler_Init(void) { memset(s_task_list, 0, sizeof(s_task_list)); } uint8_t Scheduler_Register(task_func_t func, uint32_t period_ms) { uint8_t i; if (func == 0 || period_ms == 0) { return TASK_INVALID_ID; } for (i = 0; i < TASK_MAX_NUM; i++) { if (s_task_list[i].func == 0) { s_task_list[i].func = func; s_task_list[i].period_ms = period_ms; s_task_list[i].counter = period_ms; s_task_list[i].is_running = 1; return i; } } return TASK_INVALID_ID; } void Scheduler_TickHandler(void) { uint8_t i; for (i = 0; i < TASK_MAX_NUM; i++) { if (s_task_list[i].func != 0 && s_task_list[i].is_running) { if (s_task_list[i].counter > 0) { s_task_list[i].counter--; if (s_task_list[i].counter == 0) { s_task_list[i].counter = s_task_list[i].period_ms; /* 置就绪标志，实际可用位图提高效率 */ } } } } } void Scheduler_Run(void) { uint8_t i; for (;;) { for (i = 0; i < TASK_MAX_NUM; i++) { if (s_task_list[i].func != 0 && s_task_list[i].is_running) { if (s_task_list[i].counter == 0) { /* 重新计下一个周期 */ s_task_list[i].counter = s_task_list[i].period_ms; s_task_list[i].func(); } } } } }

但上面这个版本有一个问题：Scheduler_TickHandler()在中断中递减计数器，Scheduler_Run()在主循环中判断counter == 0。中断里修改counter，主循环读counter，存在临界区竞争。简单任务问题不大，但更稳妥的做法是任务里用“就绪标志位”，中断只负责“计数到 0 时置位就绪”，主循环扫描“就绪位”，运行后清除。

6.3 升级版：用 ready 标志避免临界区误判

typedef struct { task_func_t func; uint32_t period_ms; uint32_t counter; volatile uint8_t ready; uint8_t is_running; } task_tcb_t;

中断函数：

void Scheduler_TickHandler(void) { uint8_t i; for (i = 0; i < TASK_MAX_NUM; i++) { if (s_task_list[i].func != 0 && s_task_list[i].is_running) { if (s_task_list[i].counter > 0) { s_task_list[i].counter--; if (s_task_list[i].counter == 0) { s_task_list[i].counter = s_task_list[i].period_ms; s_task_list[i].ready = 1; } } } } }

主循环扫描：

void Scheduler_Run(void) { uint8_t i; for (;;) { for (i = 0; i < TASK_MAX_NUM; i++) { if (s_task_list[i].func != 0 && s_task_list[i].is_running) { if (s_task_list[i].ready) { s_task_list[i].ready = 0; s_task_list[i].func(); } } } } }

这样中断里只修改counter和ready，主循环只在ready==1时清标志并执行任务，逻辑更清晰。

6.4 非阻塞延时

任务内部如果想延时 20ms，不能用HAL_Delay，可以借助全局 tick：

void Scheduler_Delay(uint32_t ms) { uint32_t start = Timer_GetTick(); while (Timer_GetTick() - start < ms) { /* 注意：这是阻塞延时，仅建议在任务初始化阶段使用 */ } }

但在调度任务里使用阻塞延时会卡住其它任务，所以更好的方式是基于状态机实现，下面示例中会演示。

7. 应用示例：三位模拟任务

为了验证调度器，设计三个任务：

1. LED 闪烁：周期 500ms。
2. 按键扫描：周期 10ms，带状态机消抖，按下时翻转一个标志。
3. 串口打印：周期 1000ms，打印当前 tick 值和按键计数。

7.1 app_led.c

#include "app_led.h" #include "scheduler.h" #include "bsp_led.h" static uint8_t s_led_state = 0; void App_LedTask(void) { s_led_state ^= 1u; Led_Set(s_led_state); }

注册时周期传入 500。

7.2 app_key.c

#include "app_key.h" #include "scheduler.h" #include "bsp_key.h" #include <stdint.h> #define KEY_DEBOUNCE_CNT 3u /* 连续 3 次读到有效电平才确认 */ typedef enum { KEY_ST_IDLE, KEY_ST_CHECK } key_state_t; static volatile uint32_t s_key_press_cnt; void App_KeyTask(void) { static key_state_t state = KEY_ST_IDLE; static uint8_t cnt = 0; switch (state) { case KEY_ST_IDLE: if (Key_IsPressed()) { cnt = 0; state = KEY_ST_CHECK; } break; case KEY_ST_CHECK: if (Key_IsPressed()) { cnt++; if (cnt >= KEY_DEBOUNCE_CNT) { s_key_press_cnt++; state = KEY_ST_IDLE; } } else { state = KEY_ST_IDLE; } break; default: state = KEY_ST_IDLE; break; } } uint32_t App_Key_GetPressCnt(void) { return s_key_press_cnt; }

按键任务每 10ms 执行一次，状态机保证不会因为一个毛刺误触发，也不会阻塞调度器。

7.3 app_uart.c

#include "app_uart.h" #include "scheduler.h" #include "bsp_uart.h" #include "app_key.h" void App_UartTask(void) { char buf[32]; snprintf(buf, sizeof(buf), "tick=%lu key=%lu\r\n", Timer_GetTick(), App_Key_GetPressCnt()); Uart_SendString(buf); }

周期设为 1000ms。

7.4 main 集成

#include "timer.h" #include "scheduler.h" #include "app_led.h" #include "app_key.h" #include "app_uart.h" int main(void) { Timer_Init(); Scheduler_Init(); Scheduler_Register(App_LedTask, 500); Scheduler_Register(App_KeyTask, 10); Scheduler_Register(App_UartTask, 1000); Scheduler_Run(); }

定时器中断里需要调用模块接口：

void SysTick_Handler(void) { Timer_IsrTick(); Scheduler_TickHandler(); }

注意：Timer_IsrTick()会在中断里累加s_tick，Scheduler_TickHandler()会遍历任务表更新计数器。任务表很小，在 1ms 中断里做完这些操作完全没有问题。

8. 功能测试与效果验证

8.1 验证目标

• LED 每隔 500ms 翻转一次。
• 按下按键约 30ms 后计数增加，不会在一次按下中重复增加。
• 串口每 1000ms 输出一行信息，tick 值递增约 1000，按键计数最终与实际次数一致。

8.2 操作步骤

1. 编译烧录，打开串口助手，波特率按 bsp_uart 配置（常见 115200）。
2. 观察 LED，判断周期是否稳定。
3. 按下按键 5 次，观察串口输出中key=5。
4. 用示波器或逻辑分析仪观察一个 GPIO 翻转，测量任务调度的实际周期是否等于设定值。

8.3 判断成功标准

• LED 翻转误差在 ms 量级内，长时间运行不漂移。
• 按键不会“跳数字”，也不会“漏数字”。
• 串口输出的 tick 差值接近 1000，说明调度周期准确。
• 任何任务内部都没有出现长时间卡住主循环的现象。

8.4 常见的失败原因

9. 资源占用与性能观察

9.1 CPU 占用估算

如果 tick 为 1ms，任务表有 8 个任务，每次中断循环 8 次判断，加上简单的递减操作，在 72MHz 主频下通常只占用不到 1% 的 CPU。真正的大头是任务函数本身。LED 任务便宜，按键任务也便宜，但如果某个任务里有浮点运算或大循环，调度周期会变长。

9.2 如何观察实时性

可以通过任务执行时间戳来测量：

static volatile uint32_t task_start, task_end;

在任务入口记录 tick，出口记录 tick，差值的最大值就是任务最坏执行时间。如果最坏执行时间接近任务周期，说明 CPU 已经满载，需要优化任务逻辑或降低执行频率。

9.3 如何降低 CPU 占用

• 降低 tick 频率，比如从 1ms 改为 5ms，但按键消抖和串口接收节拍要重新评估。
• 只在 ready 时扫描对应任务，避免每次中断遍历全表。
• 把不紧急的任务放到低频率，比如传感器二次计算每 100ms 一次就够了，不要每 10ms 做。
• 任务内避免复杂计算，能查表的查表，能定点的不浮点。

9.4 内存占用

任务控制块每个任务约 20 字节，8 个任务不到 200 字节。相比 RTOS 每个任务至少几百字节的栈，可以说非常省。

10. 常见问题与排查方法

11. 最佳实践与使用建议

11.1 任务要短，能不阻塞就不阻塞

调度的前提是每个任务都能快速返回。如果一个任务需要等待外部事件，典型的做法是把它拆成“发起点、轮询点、完成点”三个状态，配合全局状态变量。

11.2 统一时基，不要在应用层乱改定时器

所有任务周期都基于调度器的tick派发，不要在应用代码里直接操作定时器寄存器。这样换芯片时只改 HAL 层，应用层完全不动。

11.3 给调度器留出扩展接口

如果产品后续要上 RTOS，可以把Scheduler_Register映射为创建线程的 API，把Scheduler_Run改成vTaskStartScheduler()。前期架构做得好，后面迁移成本很低。

11.4 先小参数验证，再逐步加任务

第一次跑通时，先只注册 LED 任务，确认调度周期正确；再添加按键，最后加串口。每加一个任务都观察是否影响之前的任务，定位问题会容易很多。

11.5 保留日志与断言

在调度器模块里加一个#define SCHEDULER_DEBUG开关，打印注册失败、任务运行超时等信息。这对排查“偶发卡死”非常有价值。

11.6 注意安全和合规

嵌入式代码如果用于产品发布，要按项目规范做代码评审和硬件在环测试。涉及对外通信、协议处理、用户数据存储时，应遵守相关数据安全与隐私合规要求。任何功能模块在集成前都要经过完整测试，尤其是和定时器相关的任务时序，不能只在开发板上验证一次就上线。

12. 总结与下一步

这次聊的定时器模拟任务方案，最适合用在“裸机项目功能多、又不想立刻上 RTOS”的中间态。它用很低的资源开销，把超级大循环拆成了可管理、可扩展的任务集合，核心代码只有几十行，却能显著改善项目的可维护性。最值得先验证的功能是：用 1ms tick 驱动三个不同周期的任务，观察它们是否互不干扰、周期是否准确。最容易踩的坑是：任务里写HAL_Delay或 while 等待，把整个调度卡死。

下一步可以继续扩展的方向包括：给调度器加入任务优先级、任务挂起恢复、消息邮箱、软件定时器回调，甚至实现一个简单的“裸机版信号量”。这套框架跑稳之后，再去学习 RTOS 的任务切换和同步机制，你会发现很多概念是相通的，只是底层从“主循环遍历”变成了“上下文切换”。

代码建议按“timer 层 → scheduler 层 → app 层”组织，保留一份最小可运行工程。后续每次加功能，先在 app 层建新文件，再注册任务，思考“这个功能适合用 10ms 还是 100ms 轮询”，之后就不会再被满屏的 if 和 delay 困住了。