从顺序执行到时间片轮询：裸机多任务架构的轻量化演进
1. 裸机环境下的代码架构演进
记得刚入行嵌入式开发时，前辈给我看的第一段代码就是个死循环。当时很疑惑：这玩意儿能叫程序？后来才明白，这就是裸机开发的常态——没有操作系统加持，所有逻辑都得自己编排。今天我们就聊聊裸机环境下，代码架构从顺序执行到时间片轮询的轻量化演进过程。
裸机开发就像在没有指挥的乐队里演奏，每个乐手（任务）都得自己数拍子。传统顺序执行就像乐手们排着队轮流独奏，而时间片轮询则像乐手们根据节拍器自动切换。这种演进让8位MCU也能处理多任务，比如同时读取传感器、刷新屏幕和响应按键。
2. 传统顺序执行架构
2.1 基础实现方式
顺序执行架构是新手最先接触的模式，代码结构简单到令人发指：
void main() { while(1) { read_sensor(); // 读取传感器 update_display();// 刷新屏幕 check_button(); // 检测按键 } }这种架构的问题在于阻塞式执行——如果某个函数执行时间过长（比如显示屏刷新需要50ms），其他函数就只能干等着。我曾在项目中遇到按键响应延迟的问题，最后发现是显示屏驱动里有个忙等待，把整个系统卡成了幻灯片。
2.2 改良版非阻塞架构
进阶版会加入状态机和时间标记，算是顺序执行的改良方案：
uint32_t last_sensor_time; uint32_t last_display_time; void main() { while(1) { uint32_t now = get_tick(); if(now - last_sensor_time > 100) { read_sensor(); last_sensor_time = now; } if(now - last_display_time > 50) { update_display(); last_display_time = now; } } }这种方式虽然解决了部分阻塞问题，但随着任务增多，代码会变得难以维护。我在一个温控器项目里写过20多个if判断，后来自己都分不清哪个条件对应哪个功能。
3. 时间片轮询架构原理
3.1 核心机制
时间片轮询就像给每个任务发个沙漏，沙漏漏完就执行任务。其核心是三个要素：
- 定时器中断：维持系统心跳（通常1-10ms）
- 任务控制块：记录每个任务的状态
- 调度函数：检查并执行到期任务
typedef struct { uint16_t count; // 当前倒计时 uint16_t interval; // 执行间隔 void (*func)(void); // 任务函数 } Task; Task tasks[] = { {10, 10, task_led}, // 每10个tick执行一次 {20, 20, task_sensor}, // 每20个tick执行一次 };3.2 具体实现
在定时器中断里递减计数器：
void TIMER_IRQHandler() { for(int i=0; i<TASK_NUM; i++) { if(tasks[i].count > 0) { tasks[i].count--; } } }主循环中检查并执行任务：
void task_scan() { for(int i=0; i<TASK_NUM; i++) { if(tasks[i].count == 0) { tasks[i].func(); tasks[i].count = tasks[i].interval; } } }实测在STM32F030上，10个任务的调度开销不到5us。这种架构最妙的是各任务执行时间互不影响——即使某个任务偶尔超时，其他任务仍能按时执行。
4. 进阶优化技巧
4.1 动态优先级调整
通过改变任务间隔实现软优先级：
// 按键检测提升优先级 void key_pressed() { tasks[KEY_TASK_ID].interval = 2; // 改为2ms检测 start_priority_timer(KEY_TASK_ID, 100); // 100ms后恢复 }4.2 任务睡眠机制
避免空转消耗CPU：
void task_sensor() { if(!data_ready) { tasks[SENSOR_TASK_ID].count = 10; // 10个tick后再检查 return; } // ...处理数据 }4.3 时间片分组
将任务分配到不同时间片组，减少调度开销：
// 分组1（偶数tick执行） if(tick_count % 2 == 0) { run_group(GROUP1); } // 分组2（奇数tick执行） else { run_group(GROUP2); }在智能家居网关项目中，这种分组方式将调度开销降低了40%。
5. 与RTOS的对比
5.1 资源消耗对比
| 指标 | 时间片轮询 | FreeRTOS |
|---|---|---|
| RAM占用 | 50-100B | 3-5KB |
| 调度延迟 | 1-10us | 10-30us |
| 中断响应 | 无影响 | 可能被屏蔽 |
| 任务切换时间 | 无 | 1-2us |
对于资源紧张的GD32E230（16KB RAM），时间片轮询是唯一可行的多任务方案。
5.2 适用场景选择
建议按以下条件选择架构：
- 选择时间片轮询当：
- RAM < 4KB
- 任务数 < 15个
- 不需要任务同步/通信
- 选择RTOS当：
- 需要IPC机制
- 有硬实时需求
- 任务存在长时间阻塞
有个很实用的判断标准：如果所有任务都能在1ms内完成，时间片轮询通常更合适。
6. 实战中的坑与经验
第一次实现时，我犯了个低级错误——在任务函数里修改了自身的interval值，导致调度时序全乱。后来定下三条铁律：
- 任务函数永远不要修改任务控制块
- 中断中只做计数递减
- 主循环才是唯一的调度入口
另一个教训是关于时间精度。曾用32位变量存储tick计数，结果系统运行49天后溢出归零。现在要么用64位变量，要么在中断里定期重置计数基准。
对于需要精确时间的任务（如PWM生成），我会单独开硬件定时器。时间片轮询只负责业务逻辑，硬实时需求交给外设硬件。