先问一个问题你在裸机开发中写过多层if else嵌套的任务调度吗或者用过“超级大循环 标志位”的方式处理多个周期性任务我刚接触嵌入式软件开发时最常见的代码结构就是while(1)里面堆业务一个函数套一个函数全靠延时和标志位硬撑。前期功能少的时候还能跑后面需求一多问题就全冒出来了延时堵塞 CPU、任务优先级不好控制、代码模块之间互相影响、想移植到新板子几乎等于重写。后来慢慢接触到“定时器 任务表”的软件架构思路才意识到嵌入式软件并不是只能靠“裸奔大循环”硬扛用定时器模拟多任务调度是很多没有 RTOS 的 MCU 工程里非常实用的一招。这篇文章就把这套架构从思路、代码、到优化讲透帮你从“能跑”走向“会设计”。1. 为什么嵌入式软件需要架构而不是堆代码1.1 嵌入式软件架构到底解决什么问题嵌入式软件架构简单说就是在写代码之前先规划好代码的组织方式、模块边界和数据流向。很多初学者会觉得MCU 资源那么紧张搞架构是浪费时间不如直接写逻辑。但真实项目里问题不在于“代码能不能跑”而在于“跑起来之后还敢不敢改”。比如你要给一个按键加一个长按功能结果发现按键扫描逻辑散落在三个模块里你想把某个外设驱动从 STM32 移植到 GD32结果发现驱动代码和业务逻辑混在一起根本没法抽出来。架构的作用就是解决这类问题。它让代码具备几个基本能力可维护改一个功能不影响其他模块。可移植硬件相关代码与业务逻辑分离。可扩展新增一个任务不用推翻重写。可测试逻辑单元可以独立验证。1.2 裸机开发中的架构演进路线嵌入式软件架构并不是只有 RTOS实时操作系统这一条路。很多项目因为成本、资源、实时性等原因仍然选择裸机开发。裸机架构的常见演进路线大概是这样的阶段架构方式特点适用场景第一阶段超级大循环 阻塞延时代码简单但 CPU 利用率低功能很少的 demo第二阶段大循环 状态机提高响应性但仍较难扩展按键、通信协议解析第三阶段定时器 任务调度任务按时间片执行结构清晰多路采集、多任务处理第四阶段事件驱动 任务队列实时性好逻辑解耦需要异步处理的复杂系统第五阶段引入 RTOS提供完整的任务管理能力高实时性、多任务复杂场景大多数中小型嵌入式项目做到第三阶段就已经能获得非常好的代码结构。本文重点讲解的就是基于定时器模拟任务调度这一阶段的架构思路和代码实现。2. 定时器在嵌入式软件中的定位2.1 定时器的分类与作用嵌入式 MCU 中的定时器通常分为几类基本定时器只能计时一般用于产生定时中断或时基。通用定时器支持输入捕获、输出比较、PWM 等功能。高级定时器在通用定时器基础上增加了互补输出、死区时间控制常用于电机控制。在软件架构中定时器最重要的作用不是“延时”而是产生一个稳定的“时间基准”。这个时间基准就是任务调度的核心。常见的时间基准来源包括SysTick滴答定时器Cortex-M 内核自带常用于操作系统时钟节拍。通用定时器如 STM32 的 TIM2、TIM3 等可配置周期中断。外部 RTC 闹钟用于低功耗唤醒。软件定时器基于硬件时基进行计数的逻辑定时器不额外占用硬件资源。2.2 为什么用定时器模拟多任务用定时器模拟多任务的核心思想是在一个固定周期的时间中断里“打拍子”主程序按照时间表轮流执行不同的任务。这个方式和 RTOS 的时间片轮询有相似之处但实现成本低很多不需要操作系统也不需要额外的资源开销。这种方式的优势非常明显任务之间不会因为阻塞延时而互相影响。每个任务有独立的执行周期。代码模块化程度高新增任务方便。对硬件资源要求低几乎任何 MCU 都能用。当然它也有局限如果某个任务执行时间过长仍然会阻塞其他任务。所以这种架构适合任务执行时间短、周期稳定的场景。2.3 与 RTOS 任务调度的区别很多初学者会问既然定时器能模拟多任务那还有必要学 RTOS 吗答案是看情况。定时器模拟任务调度属于“协作式调度”的范畴任务主动让出 CPU而 RTOS 属于“抢占式调度”高优先级任务可以打断低优先级任务。如果项目需求简单、实时性要求不高、MCU 资源有限用定时器模拟任务的性价比非常高。但如果任务数量多、实时性要求高、任务之间存在复杂的同步与通信RTOS 会更合适。对比项定时器模拟任务RTOS资源占用极低需要额外 RAM/ROM实时性取决于任务执行时间抢占式响应更快任务通信自己实现提供队列、信号量等开发难度较低较高适用场景中小型裸机项目复杂多任务系统3. 基于定时器模拟任务的架构设计3.1 整体分层设计基于定时器模拟任务的裸机架构通常可以分成三层应用层业务逻辑任务 ↓ 调度层任务表、定时器中断、调度入口 ↓ 驱动层板级驱动、外设驱动驱动层负责具体的硬件操作例如 LED 点亮、ADC 采集、串口发送、按键读取。调度层负责统一管理任务的注册、执行和周期调度。应用层则实现具体的业务逻辑例如温度上报、按键处理、状态切换。如果驱动层的接口设计得好应用层甚至可以做到和硬件平台无关。这个分层思想是嵌入式软件架构中最重要的一环。3.2 任务表设计的核心思路任务调度的核心是一个“任务表”。任务表本质上是一个结构体数组typedef struct { void (*func)(void); // 任务函数指针 uint32_t period; // 执行周期ms uint32_t tick; // 当前计数值 uint8_t enable; // 使能标志 } Task_t;func保存任务函数的地址period表示这个任务每隔多少毫秒执行一次tick是当前累加计数当tick period时执行一次任务并把tick清零enable表示这个任务是否参与调度。使用函数指针可以让任务注册变得非常灵活。新增任务时只需要把任务函数加进任务表即可不需要改调度器的代码。3.3 调度原理与时间片计算调度器的工作原理可以概括为三句话定时器每隔 1ms或其它固定周期产生一次中断。中断服务函数中遍历任务表把所有已使能任务的tick加 1。主循环中检查每个任务是否达到执行周期达到则执行任务函数。这里需要注意的是中断里只做计数不执行任务函数。任务函数在主循环中执行避免在中断上下文中运行耗时逻辑减少对中断响应的影响。时间片的选择取决于项目需求。比如系统需要 10ms 的任务周期那么定时器时基可以设置为 1ms任务表中对应任务的period配置为 10。如果定时器时基为 100us虽然计时精度更高但中断频繁CPU 开销也随之增加。3.4 时间基准选择建议实际项目中时间基准的选择可以按以下原则参考时基周期精度CPU 开销适用场景10ms较低很低对实时性要求不高的任务1ms适中适中通用场景的首选100us较高较高需要较高时间精度的控制场景对于大多数嵌入式裸机项目1ms 是一个比较平衡的时基选择。4. 完整代码实现基于定时器的任务调度框架接下来进入实战环节。以 STM32F103 为例演示一个基于 SysTick 的裸机任务调度框架。示例工程中会包含 LED 闪烁任务、按键扫描任务、串口打印任务方便验证调度效果。4.1 创建项目结构建议的项目文件结构如下project/ ├── Core/ │ ├── Inc/ │ │ ├── main.h │ │ └── scheduler.h │ └── Src/ │ ├── main.c │ ├── scheduler.c │ └── stm32f1xx_it.c ├── Drivers/ │ ├── Inc/ │ │ └── bsp_led.h │ └── Src/ │ └── bsp_led.c └── app/ ├── app_led.h ├── app_led.c ├── app_key.h ├── app_key.c ├── app_uart.h └── app_uart.c不要求读者完全按照这个目录来但建议把“调度器、驱动、应用”分开存放这是保持代码清晰的第一步。4.2 调度器头文件设计文件路径Core/Inc/scheduler.h#ifndef __SCHEDULER_H #define __SCHEDULER_H #include stm32f1xx_hal.h #define SCH_MAX_TASKS 8 // 最大任务数量 #define SCH_TICK_MS 1 // 时基周期单位 ms typedef struct { void (*func)(void); // 任务函数指针 uint32_t period; // 任务周期ms uint32_t tick; // 当前计数值 uint8_t enable; // 使能标志 } Task_t; void Scheduler_Init(void); void Scheduler_Register(void (*func)(void), uint32_t period); void Scheduler_Enable(uint8_t index); void Scheduler_Disable(uint8_t index); void Scheduler_TickHandler(void); void Scheduler_Dispatch(void); #endif任务数量上限SCH_MAX_TASKS根据实际项目调整如果任务较多可以增大该宏定义。4.3 调度器实现文件路径Core/Src/scheduler.c#include scheduler.h static Task_t taskTable[SCH_MAX_TASKS]; static uint8_t taskCount 0; void Scheduler_Init(void) { for (uint8_t i 0; i SCH_MAX_TASKS; i) { taskTable[i].func NULL; taskTable[i].period 0; taskTable[i].tick 0; taskTable[i].enable 0; } taskCount 0; } uint8_t Scheduler_Register(void (*func)(void), uint32_t period) { if (taskCount SCH_MAX_TASKS) { return 0xFF; } taskTable[taskCount].func func; taskTable[taskCount].period period; taskTable[taskCount].tick 0; taskTable[taskCount].enable 1; taskCount; return (taskCount - 1); } void Scheduler_Enable(uint8_t index) { if (index taskCount) { taskTable[index].enable 1; } } void Scheduler_Disable(uint8_t index) { if (index taskCount) { taskTable[index].enable 0; } } void Scheduler_TickHandler(void) { for (uint8_t i 0; i taskCount; i) { if (taskTable[i].enable taskTable[i].func ! NULL) { taskTable[i].tick; } } } void Scheduler_Dispatch(void) { for (uint8_t i 0; i taskCount; i) { if (taskTable[i].enable taskTable[i].func ! NULL) { if (taskTable[i].tick taskTable[i].period) { taskTable[i].taskTable[i].tick 0; taskTable[i].func(); } } } }这里有一个细节需要特别注意tick 清零必须在调用任务函数之前完成还是之后完成建议在调用任务函数前清零。如果任务执行时间较长放在后面清零会导致计时不准确。但也要注意如果任务执行时间超过一个时基周期任务内部逻辑应该做好重入保护。另外调度核心代码中有一处笔误taskTable[i].taskTable[i].tick 0;实际使用时写成taskTable[i].tick 0;即可。4.4 应用任务示例下面注册三个简单的任务。先是 LED 闪烁任务文件路径app/app_led.c#include app_led.h #include bsp_led.h static uint8_t ledState 0; void App_LedTask(void) { if (ledState 0) { BSP_LED_On(); ledState 1; } else { BSP_LED_Off(); ledState 0; } }按键扫描任务#include app_key.h #include bsp_key.h void App_KeyScanTask(void) { uint8_t keyVal BSP_Key_Scan(); if (keyVal KEY_PRESSED) { // 处理按键逻辑 } }串口打印任务#include app_uart.h #include bsp_uart.h static uint32_t printCount 0; void App_UartPrintTask(void) { char buf[32]; snprintf(buf, sizeof(buf), count: %lu\r\n, printCount); BSP_UART_SendString(buf); }4.5 主函数初始化与运行文件路径Core/Src/main.c#include main.h #include scheduler.h #include app_led.h #include app_key.h #include app_uart.h int main(void) { HAL_Init(); SystemClock_Config(); BSP_LED_Init(); BSP_Key_Init(); BSP_UART_Init(); Scheduler_Init(); Scheduler_Register(App_LedTask, 500); // LED 每 500ms 翻转一次 Scheduler_Register(App_KeyScanTask, 20); // 按键每 20ms 扫描一次 Scheduler_Register(App_UartPrintTask, 1000); // 串口每 1000ms 打印一次 while (1) { Scheduler_Dispatch(); } }4.6 SysTick 中断配置如果使用 HAL 库最简单的方式是在 SysTick 中断服务函数中调用调度器的时基处理函数文件路径Core/Src/stm32f1xx_it.cvoid SysTick_Handler(void) { HAL_IncTick(); Scheduler_TickHandler(); }如果希望定时周期不是 1ms可以使用硬件定时器实现更灵活的时间基准。比如将 TIM3 配置为 1ms 中断void TIM3_IRQHandler(void) { if (__HAL_TIM_GET_FLAG(htim3, TIM_FLAG_UPDATE) ! RESET) { __HAL_TIM_CLEAR_IT(htim3, TIM_IRQn); Scheduler_TickHandler(); } }注意Scheduler_TickHandler执行体量非常小只做tick所以放在中断里是安全的。这也是任务执行与计数分离的工程设计原则。5. 架构的关键设计与进阶优化5.1 为什么在中断中只计数不执行任务一个常见的错误写法是直接在定时器中断中调用任务函数void TIM3_IRQHandler(void) { App_LedTask(); App_KeyScanTask(); App_UartPrintTask(); }这种写法在中断里执行大量业务逻辑会带来严重问题中断响应时间变长影响系统实时性。多个任务之间互相阻塞。如果任务代码中有耗时操作会拖垮整个系统。正确做法是中断只负责记录时间主循环负责执行任务。这样即使某个任务执行时间稍长也不会阻塞中断系统整体响应更加平滑。5.2 使用 volatile 修饰共享变量由于tick在中断中修改、在主循环中读取主循环中需要将任务表指针或相关变量标记为volatile防止编译器过度优化导致读取不到最新值。可以把调度器内部的状态量做如下调整static Task_t taskTable[SCH_MAX_TASKS]; static volatile uint8_t taskCount 0;如果整个taskTable都需要被中断读取可以这样static volatile Task_t taskTable[SCH_MAX_TASKS];这样可以确保每次访问都从内存中读取而不是从寄存器缓存中读取。5.3 任务分类周期任务与事件任务实际工程中任务并不全是周期执行的。有些任务是“事件触发”的比如串口收到一帧数据后需要解析数据、更新显示、上报主机。在任务调度架构中可以在时间中断里置一个事件标志主循环检测到标志后执行相应逻辑volatile uint8_t uartEventFlag 0; void UART_RxCpltCallback(UART_HandleTypeDef *huart) { uartEventFlag 1; } // 主循环或任务中 void App_UartProcessTask(void) { if (uartEventFlag) { uartEventFlag 0; // 处理串口数据 } }这种方式将“事件产生”和“事件处理”分离类似在裸机中实现了一个轻量级的事件驱动机制。5.4 任务执行时间统计与超时保护如果项目对实时性要求较高可以给每个任务增加执行时间统计功能。方法很简单在调用任务函数之前读取一个硬件计数器调用之后再读一次差值就是任务执行时间。如果某个任务执行时间过长可以打印警告日志方便定位性能瓶颈。这里给出一个思路示例uint32_t startTick DWT-CYCCNT; taskTable[i].func(); uint32_t costTick DWT-CYCCNT - startTick;利用 Cortex-M 内核的 DWT 寄存器可以获取 CPU 时钟周期数在高精度调试中很有用。5.5 与状态机的结合任务调度器与状态机是同一层级的技术。任务调度器解决“什么时候执行什么模块”的问题状态机解决“模块内部在不同条件下做什么”的问题。两者结合非常常见调度器周期执行 KeyProcessTask() ↓ 状态机按键扫描中的 IDLE / PRESS / RELEASE / LONG_PRESS 状态切换调度器提供时间维度状态机提供逻辑维度两者配合能够构建出结构清晰的控制系统。6. 常见问题与排查思路6.1 任务不执行或者执行周期不对问题现象常见原因解决思路任务完全不执行任务未注册或未使能检查 Scheduler_Register 返回值任务完全不执行中断未配置或未开启检查 SysTick/TIM 中断是否触发任务执行周期不对时基精度设置错误确认中断周期与任务 period 单位一致任务执行周期不对tick 在中断中和主循环中互相干扰确保共享变量使用 volatile排查时可以先用示波器或逻辑分析仪观察某一个 GPIO 电平翻转频率确认时基周期是否准确。6.2 任务执行时间过长导致卡顿如果某个任务函数执行时间超过任务周期调度器主循环中可能一直执行该任务导致其他任务长时间得不到调度。这种现象在调试时非常隐蔽因为代码逻辑看起来没有死循环。建议在任务函数入口和出口翻转一个 GPIO 引脚用示波器测量任务执行时间。对耗时操作进行拆分将任务分成多个小段逐步完成。必要时将耗时任务的周期调大。6.3 中断中修改变量与主循环冲突时基中断中tick主循环中要先判断tick period再清零如果中断恰好在中途触发可能出现问题。对于 8 位或者 16 位 MCU情况需要特别关注。建议修改为uint32_t currentTick; void Scheduler_TickHandler(void) { for (uint8_t i 0; i taskCount; i) { if (taskTable[i].enable) { taskTable[i].tick; } } } void Scheduler_Dispatch(void) { for (uint8_t i 0; i taskCount; i) { if (taskTable[i].enable) { currentTick taskTable[i].tick; if (currentTick taskTable[i].period) { taskTable[i].tick 0; taskTable[i].func(); } } } }把tick先读入局部变量再比较可以在很大程度上避免中断交叉访问的问题。6.4 任务数量超出上限任务表是静态数组容量固定。如果注册任务时返回0xFF说明任务数已经满了。需要调大SCH_MAX_TASKS或者评估是否有些任务可以通过合并优化减少数量。6.5 低功耗模式下定时器停摆在低功耗模式下定时器时钟可能被关闭导致调度停止。解决方案通常是进入低功耗前暂停调度。通过外部唤醒源或 RTC 闹钟唤醒后重新初始化时间基准。对于周期性不强的任务允许在唤醒后重新同步时间。7. 工程实践中的架构建议7.1 命名规范与文件组织嵌入式工程中命名规范直接影响团队协作效率。建议调度器模块用Scheduler_前缀。驱动层用BSP_前缀表示板级支持包。应用层用App_前缀表示业务逻辑。任务函数统一带Task后缀便于在任务表中快速识别。文件组织方面坚持“驱动、调度、应用”三层分离。不要让应用代码直接操作寄存器而是通过驱动接口访问硬件。7.2 任务函数设计原则任务函数应该遵循以下原则函数体积尽量小一个任务只做一件事。不得使用阻塞延时任务中尽量避免使用HAL_Delay或delay_ms否则会阻塞整个调度器。不依赖其他任务的执行顺序任务之间通过全局变量或事件标志解耦。有明确的退出路径任务不要出现隐藏的死循环。如果某个任务确实需要等待一段时间可以依靠任务周期自然产生延时效果或使用状态机拆分等待过程。7.3 任务优先级如何实现定时器模拟任务的协作式调度本身没有优先级概念所有任务按注册顺序依次执行。如果任务之间有优先级需求可以考虑两种方案方案一任务表按优先级从高到低排列。调度器遍历时高优先级任务总是先执行。方案二在调度器中增加“优先级”字段每次调度时选择优先级最高且到期的任务执行。typedef struct { void (*func)(void); uint32_t period; uint32_t tick; uint8_t enable; uint8_t priority; } Task_t;void Scheduler_Dispatch(void) { uint8_t highPriorityIndex taskCount; uint8_t found 0; for (uint8_t i 0; i taskCount; i) { if (taskTable[i].enable taskTable[i].tick taskTable[i].period) { if (!found || taskTable[i].priority taskTable[highPriorityIndex].priority) { highPriorityIndex i; found 1; } } } if (found) { taskTable[highPriorityIndex].tick 0; taskTable[highPriorityIndex].func(); } }这种方式在每次调度时只执行一个任务适用于“同周期高优先级优先”的场景但由于每次只执行一个任务所有任务循环一轮的时间会变长。7.4 移植性优化为了让架构更容易移植到不同 MCU 平台可以做到调度器核心代码不依赖任何 HAL 库只用标准 C 类型。时基触发函数Scheduler_TickHandler由外部中断统一调用。驱动层提供统一接口比如BSP_LED_On、BSP_LED_Off不同平台分别实现。做到这几点后换 MCU 时只需要改驱动层和中断配置调度器代码直接复用。7.5 安全与可靠性建议在生产环境中使用这套架构时建议注意看门狗在主循环中喂狗避免任务卡死导致系统复位。参数校验任务注册时检查函数指针和周期是否合法。边界检查任务表索引操作前判断是否越界。日志输出关键任务执行状态可以输出调试信息方便远程定位问题。例如注册函数的边界检查uint8_t Scheduler_Register(void (*func)(void), uint32_t period) { if (func NULL || period 0) { return 0xFF; } if (taskCount SCH_MAX_TASKS) { return 0xFF; } ... }8. 总结回过头来看嵌入式软件架构并不是什么高深的概念它本质上是在回答“代码怎么组织才能更容易维护、扩展和移植”。定时器模拟任务调度是裸机 MCU 项目中性价比非常高的一种架构方案。这篇文章主要讲了以下几点从超级大循环到定时器任务调度的架构演进逻辑。定时器在软件架构中的定位和作用。使用函数指针任务表完成任务注册、周期调度和使能管理。中断中计数、主循环执行任务的协作式调度模型。任务与事件结合、任务与状态机结合的进阶设计方法。常见问题、排查思路以及工程实践建议。下一步建议你动手把调度器代码移植到自己手头的开发板上先点亮一个 LED再跑两个周期不同的任务感受一下“任务表 定时器中断”这个模型的魅力。然后再试试把按键扫描、串口处理、显示刷新都加进来你会发现代码结构比之前的超级大循环清晰太多了。如果你后续感兴趣还可以沿着这个方向继续探索事件驱动架构、协作式调度器与状态机的深度结合甚至尝试切换到 FreeRTOS对比不同调度模型下系统表现的差异。好的嵌入式软件架构能力就是在一次次这样的小项目迭代中积累出来的。
先问一个问题你在裸机开发中写过多层if else嵌套的任务调度吗或者用过“超级大循环 标志位”的方式处理多个周期性任务我刚接触嵌入式软件开发时最常见的代码结构就是while(1)里面堆业务一个函数套一个函数全靠延时和标志位硬撑。前期功能少的时候还能跑后面需求一多问题就全冒出来了延时堵塞 CPU、任务优先级不好控制、代码模块之间互相影响、想移植到新板子几乎等于重写。后来慢慢接触到“定时器 任务表”的软件架构思路才意识到嵌入式软件并不是只能靠“裸奔大循环”硬扛用定时器模拟多任务调度是很多没有 RTOS 的 MCU 工程里非常实用的一招。这篇文章就把这套架构从思路、代码、到优化讲透帮你从“能跑”走向“会设计”。1. 为什么嵌入式软件需要架构而不是堆代码1.1 嵌入式软件架构到底解决什么问题嵌入式软件架构简单说就是在写代码之前先规划好代码的组织方式、模块边界和数据流向。很多初学者会觉得MCU 资源那么紧张搞架构是浪费时间不如直接写逻辑。但真实项目里问题不在于“代码能不能跑”而在于“跑起来之后还敢不敢改”。比如你要给一个按键加一个长按功能结果发现按键扫描逻辑散落在三个模块里你想把某个外设驱动从 STM32 移植到 GD32结果发现驱动代码和业务逻辑混在一起根本没法抽出来。架构的作用就是解决这类问题。它让代码具备几个基本能力可维护改一个功能不影响其他模块。可移植硬件相关代码与业务逻辑分离。可扩展新增一个任务不用推翻重写。可测试逻辑单元可以独立验证。1.2 裸机开发中的架构演进路线嵌入式软件架构并不是只有 RTOS实时操作系统这一条路。很多项目因为成本、资源、实时性等原因仍然选择裸机开发。裸机架构的常见演进路线大概是这样的阶段架构方式特点适用场景第一阶段超级大循环 阻塞延时代码简单但 CPU 利用率低功能很少的 demo第二阶段大循环 状态机提高响应性但仍较难扩展按键、通信协议解析第三阶段定时器 任务调度任务按时间片执行结构清晰多路采集、多任务处理第四阶段事件驱动 任务队列实时性好逻辑解耦需要异步处理的复杂系统第五阶段引入 RTOS提供完整的任务管理能力高实时性、多任务复杂场景大多数中小型嵌入式项目做到第三阶段就已经能获得非常好的代码结构。本文重点讲解的就是基于定时器模拟任务调度这一阶段的架构思路和代码实现。2. 定时器在嵌入式软件中的定位2.1 定时器的分类与作用嵌入式 MCU 中的定时器通常分为几类基本定时器只能计时一般用于产生定时中断或时基。通用定时器支持输入捕获、输出比较、PWM 等功能。高级定时器在通用定时器基础上增加了互补输出、死区时间控制常用于电机控制。在软件架构中定时器最重要的作用不是“延时”而是产生一个稳定的“时间基准”。这个时间基准就是任务调度的核心。常见的时间基准来源包括SysTick滴答定时器Cortex-M 内核自带常用于操作系统时钟节拍。通用定时器如 STM32 的 TIM2、TIM3 等可配置周期中断。外部 RTC 闹钟用于低功耗唤醒。软件定时器基于硬件时基进行计数的逻辑定时器不额外占用硬件资源。2.2 为什么用定时器模拟多任务用定时器模拟多任务的核心思想是在一个固定周期的时间中断里“打拍子”主程序按照时间表轮流执行不同的任务。这个方式和 RTOS 的时间片轮询有相似之处但实现成本低很多不需要操作系统也不需要额外的资源开销。这种方式的优势非常明显任务之间不会因为阻塞延时而互相影响。每个任务有独立的执行周期。代码模块化程度高新增任务方便。对硬件资源要求低几乎任何 MCU 都能用。当然它也有局限如果某个任务执行时间过长仍然会阻塞其他任务。所以这种架构适合任务执行时间短、周期稳定的场景。2.3 与 RTOS 任务调度的区别很多初学者会问既然定时器能模拟多任务那还有必要学 RTOS 吗答案是看情况。定时器模拟任务调度属于“协作式调度”的范畴任务主动让出 CPU而 RTOS 属于“抢占式调度”高优先级任务可以打断低优先级任务。如果项目需求简单、实时性要求不高、MCU 资源有限用定时器模拟任务的性价比非常高。但如果任务数量多、实时性要求高、任务之间存在复杂的同步与通信RTOS 会更合适。对比项定时器模拟任务RTOS资源占用极低需要额外 RAM/ROM实时性取决于任务执行时间抢占式响应更快任务通信自己实现提供队列、信号量等开发难度较低较高适用场景中小型裸机项目复杂多任务系统3. 基于定时器模拟任务的架构设计3.1 整体分层设计基于定时器模拟任务的裸机架构通常可以分成三层应用层业务逻辑任务 ↓ 调度层任务表、定时器中断、调度入口 ↓ 驱动层板级驱动、外设驱动驱动层负责具体的硬件操作例如 LED 点亮、ADC 采集、串口发送、按键读取。调度层负责统一管理任务的注册、执行和周期调度。应用层则实现具体的业务逻辑例如温度上报、按键处理、状态切换。如果驱动层的接口设计得好应用层甚至可以做到和硬件平台无关。这个分层思想是嵌入式软件架构中最重要的一环。3.2 任务表设计的核心思路任务调度的核心是一个“任务表”。任务表本质上是一个结构体数组typedef struct { void (*func)(void); // 任务函数指针 uint32_t period; // 执行周期ms uint32_t tick; // 当前计数值 uint8_t enable; // 使能标志 } Task_t;func保存任务函数的地址period表示这个任务每隔多少毫秒执行一次tick是当前累加计数当tick period时执行一次任务并把tick清零enable表示这个任务是否参与调度。使用函数指针可以让任务注册变得非常灵活。新增任务时只需要把任务函数加进任务表即可不需要改调度器的代码。3.3 调度原理与时间片计算调度器的工作原理可以概括为三句话定时器每隔 1ms或其它固定周期产生一次中断。中断服务函数中遍历任务表把所有已使能任务的tick加 1。主循环中检查每个任务是否达到执行周期达到则执行任务函数。这里需要注意的是中断里只做计数不执行任务函数。任务函数在主循环中执行避免在中断上下文中运行耗时逻辑减少对中断响应的影响。时间片的选择取决于项目需求。比如系统需要 10ms 的任务周期那么定时器时基可以设置为 1ms任务表中对应任务的period配置为 10。如果定时器时基为 100us虽然计时精度更高但中断频繁CPU 开销也随之增加。3.4 时间基准选择建议实际项目中时间基准的选择可以按以下原则参考时基周期精度CPU 开销适用场景10ms较低很低对实时性要求不高的任务1ms适中适中通用场景的首选100us较高较高需要较高时间精度的控制场景对于大多数嵌入式裸机项目1ms 是一个比较平衡的时基选择。4. 完整代码实现基于定时器的任务调度框架接下来进入实战环节。以 STM32F103 为例演示一个基于 SysTick 的裸机任务调度框架。示例工程中会包含 LED 闪烁任务、按键扫描任务、串口打印任务方便验证调度效果。4.1 创建项目结构建议的项目文件结构如下project/ ├── Core/ │ ├── Inc/ │ │ ├── main.h │ │ └── scheduler.h │ └── Src/ │ ├── main.c │ ├── scheduler.c │ └── stm32f1xx_it.c ├── Drivers/ │ ├── Inc/ │ │ └── bsp_led.h │ └── Src/ │ └── bsp_led.c └── app/ ├── app_led.h ├── app_led.c ├── app_key.h ├── app_key.c ├── app_uart.h └── app_uart.c不要求读者完全按照这个目录来但建议把“调度器、驱动、应用”分开存放这是保持代码清晰的第一步。4.2 调度器头文件设计文件路径Core/Inc/scheduler.h#ifndef __SCHEDULER_H #define __SCHEDULER_H #include stm32f1xx_hal.h #define SCH_MAX_TASKS 8 // 最大任务数量 #define SCH_TICK_MS 1 // 时基周期单位 ms typedef struct { void (*func)(void); // 任务函数指针 uint32_t period; // 任务周期ms uint32_t tick; // 当前计数值 uint8_t enable; // 使能标志 } Task_t; void Scheduler_Init(void); void Scheduler_Register(void (*func)(void), uint32_t period); void Scheduler_Enable(uint8_t index); void Scheduler_Disable(uint8_t index); void Scheduler_TickHandler(void); void Scheduler_Dispatch(void); #endif任务数量上限SCH_MAX_TASKS根据实际项目调整如果任务较多可以增大该宏定义。4.3 调度器实现文件路径Core/Src/scheduler.c#include scheduler.h static Task_t taskTable[SCH_MAX_TASKS]; static uint8_t taskCount 0; void Scheduler_Init(void) { for (uint8_t i 0; i SCH_MAX_TASKS; i) { taskTable[i].func NULL; taskTable[i].period 0; taskTable[i].tick 0; taskTable[i].enable 0; } taskCount 0; } uint8_t Scheduler_Register(void (*func)(void), uint32_t period) { if (taskCount SCH_MAX_TASKS) { return 0xFF; } taskTable[taskCount].func func; taskTable[taskCount].period period; taskTable[taskCount].tick 0; taskTable[taskCount].enable 1; taskCount; return (taskCount - 1); } void Scheduler_Enable(uint8_t index) { if (index taskCount) { taskTable[index].enable 1; } } void Scheduler_Disable(uint8_t index) { if (index taskCount) { taskTable[index].enable 0; } } void Scheduler_TickHandler(void) { for (uint8_t i 0; i taskCount; i) { if (taskTable[i].enable taskTable[i].func ! NULL) { taskTable[i].tick; } } } void Scheduler_Dispatch(void) { for (uint8_t i 0; i taskCount; i) { if (taskTable[i].enable taskTable[i].func ! NULL) { if (taskTable[i].tick taskTable[i].period) { taskTable[i].taskTable[i].tick 0; taskTable[i].func(); } } } }这里有一个细节需要特别注意tick 清零必须在调用任务函数之前完成还是之后完成建议在调用任务函数前清零。如果任务执行时间较长放在后面清零会导致计时不准确。但也要注意如果任务执行时间超过一个时基周期任务内部逻辑应该做好重入保护。另外调度核心代码中有一处笔误taskTable[i].taskTable[i].tick 0;实际使用时写成taskTable[i].tick 0;即可。4.4 应用任务示例下面注册三个简单的任务。先是 LED 闪烁任务文件路径app/app_led.c#include app_led.h #include bsp_led.h static uint8_t ledState 0; void App_LedTask(void) { if (ledState 0) { BSP_LED_On(); ledState 1; } else { BSP_LED_Off(); ledState 0; } }按键扫描任务#include app_key.h #include bsp_key.h void App_KeyScanTask(void) { uint8_t keyVal BSP_Key_Scan(); if (keyVal KEY_PRESSED) { // 处理按键逻辑 } }串口打印任务#include app_uart.h #include bsp_uart.h static uint32_t printCount 0; void App_UartPrintTask(void) { char buf[32]; snprintf(buf, sizeof(buf), count: %lu\r\n, printCount); BSP_UART_SendString(buf); }4.5 主函数初始化与运行文件路径Core/Src/main.c#include main.h #include scheduler.h #include app_led.h #include app_key.h #include app_uart.h int main(void) { HAL_Init(); SystemClock_Config(); BSP_LED_Init(); BSP_Key_Init(); BSP_UART_Init(); Scheduler_Init(); Scheduler_Register(App_LedTask, 500); // LED 每 500ms 翻转一次 Scheduler_Register(App_KeyScanTask, 20); // 按键每 20ms 扫描一次 Scheduler_Register(App_UartPrintTask, 1000); // 串口每 1000ms 打印一次 while (1) { Scheduler_Dispatch(); } }4.6 SysTick 中断配置如果使用 HAL 库最简单的方式是在 SysTick 中断服务函数中调用调度器的时基处理函数文件路径Core/Src/stm32f1xx_it.cvoid SysTick_Handler(void) { HAL_IncTick(); Scheduler_TickHandler(); }如果希望定时周期不是 1ms可以使用硬件定时器实现更灵活的时间基准。比如将 TIM3 配置为 1ms 中断void TIM3_IRQHandler(void) { if (__HAL_TIM_GET_FLAG(htim3, TIM_FLAG_UPDATE) ! RESET) { __HAL_TIM_CLEAR_IT(htim3, TIM_IRQn); Scheduler_TickHandler(); } }注意Scheduler_TickHandler执行体量非常小只做tick所以放在中断里是安全的。这也是任务执行与计数分离的工程设计原则。5. 架构的关键设计与进阶优化5.1 为什么在中断中只计数不执行任务一个常见的错误写法是直接在定时器中断中调用任务函数void TIM3_IRQHandler(void) { App_LedTask(); App_KeyScanTask(); App_UartPrintTask(); }这种写法在中断里执行大量业务逻辑会带来严重问题中断响应时间变长影响系统实时性。多个任务之间互相阻塞。如果任务代码中有耗时操作会拖垮整个系统。正确做法是中断只负责记录时间主循环负责执行任务。这样即使某个任务执行时间稍长也不会阻塞中断系统整体响应更加平滑。5.2 使用 volatile 修饰共享变量由于tick在中断中修改、在主循环中读取主循环中需要将任务表指针或相关变量标记为volatile防止编译器过度优化导致读取不到最新值。可以把调度器内部的状态量做如下调整static Task_t taskTable[SCH_MAX_TASKS]; static volatile uint8_t taskCount 0;如果整个taskTable都需要被中断读取可以这样static volatile Task_t taskTable[SCH_MAX_TASKS];这样可以确保每次访问都从内存中读取而不是从寄存器缓存中读取。5.3 任务分类周期任务与事件任务实际工程中任务并不全是周期执行的。有些任务是“事件触发”的比如串口收到一帧数据后需要解析数据、更新显示、上报主机。在任务调度架构中可以在时间中断里置一个事件标志主循环检测到标志后执行相应逻辑volatile uint8_t uartEventFlag 0; void UART_RxCpltCallback(UART_HandleTypeDef *huart) { uartEventFlag 1; } // 主循环或任务中 void App_UartProcessTask(void) { if (uartEventFlag) { uartEventFlag 0; // 处理串口数据 } }这种方式将“事件产生”和“事件处理”分离类似在裸机中实现了一个轻量级的事件驱动机制。5.4 任务执行时间统计与超时保护如果项目对实时性要求较高可以给每个任务增加执行时间统计功能。方法很简单在调用任务函数之前读取一个硬件计数器调用之后再读一次差值就是任务执行时间。如果某个任务执行时间过长可以打印警告日志方便定位性能瓶颈。这里给出一个思路示例uint32_t startTick DWT-CYCCNT; taskTable[i].func(); uint32_t costTick DWT-CYCCNT - startTick;利用 Cortex-M 内核的 DWT 寄存器可以获取 CPU 时钟周期数在高精度调试中很有用。5.5 与状态机的结合任务调度器与状态机是同一层级的技术。任务调度器解决“什么时候执行什么模块”的问题状态机解决“模块内部在不同条件下做什么”的问题。两者结合非常常见调度器周期执行 KeyProcessTask() ↓ 状态机按键扫描中的 IDLE / PRESS / RELEASE / LONG_PRESS 状态切换调度器提供时间维度状态机提供逻辑维度两者配合能够构建出结构清晰的控制系统。6. 常见问题与排查思路6.1 任务不执行或者执行周期不对问题现象常见原因解决思路任务完全不执行任务未注册或未使能检查 Scheduler_Register 返回值任务完全不执行中断未配置或未开启检查 SysTick/TIM 中断是否触发任务执行周期不对时基精度设置错误确认中断周期与任务 period 单位一致任务执行周期不对tick 在中断中和主循环中互相干扰确保共享变量使用 volatile排查时可以先用示波器或逻辑分析仪观察某一个 GPIO 电平翻转频率确认时基周期是否准确。6.2 任务执行时间过长导致卡顿如果某个任务函数执行时间超过任务周期调度器主循环中可能一直执行该任务导致其他任务长时间得不到调度。这种现象在调试时非常隐蔽因为代码逻辑看起来没有死循环。建议在任务函数入口和出口翻转一个 GPIO 引脚用示波器测量任务执行时间。对耗时操作进行拆分将任务分成多个小段逐步完成。必要时将耗时任务的周期调大。6.3 中断中修改变量与主循环冲突时基中断中tick主循环中要先判断tick period再清零如果中断恰好在中途触发可能出现问题。对于 8 位或者 16 位 MCU情况需要特别关注。建议修改为uint32_t currentTick; void Scheduler_TickHandler(void) { for (uint8_t i 0; i taskCount; i) { if (taskTable[i].enable) { taskTable[i].tick; } } } void Scheduler_Dispatch(void) { for (uint8_t i 0; i taskCount; i) { if (taskTable[i].enable) { currentTick taskTable[i].tick; if (currentTick taskTable[i].period) { taskTable[i].tick 0; taskTable[i].func(); } } } }把tick先读入局部变量再比较可以在很大程度上避免中断交叉访问的问题。6.4 任务数量超出上限任务表是静态数组容量固定。如果注册任务时返回0xFF说明任务数已经满了。需要调大SCH_MAX_TASKS或者评估是否有些任务可以通过合并优化减少数量。6.5 低功耗模式下定时器停摆在低功耗模式下定时器时钟可能被关闭导致调度停止。解决方案通常是进入低功耗前暂停调度。通过外部唤醒源或 RTC 闹钟唤醒后重新初始化时间基准。对于周期性不强的任务允许在唤醒后重新同步时间。7. 工程实践中的架构建议7.1 命名规范与文件组织嵌入式工程中命名规范直接影响团队协作效率。建议调度器模块用Scheduler_前缀。驱动层用BSP_前缀表示板级支持包。应用层用App_前缀表示业务逻辑。任务函数统一带Task后缀便于在任务表中快速识别。文件组织方面坚持“驱动、调度、应用”三层分离。不要让应用代码直接操作寄存器而是通过驱动接口访问硬件。7.2 任务函数设计原则任务函数应该遵循以下原则函数体积尽量小一个任务只做一件事。不得使用阻塞延时任务中尽量避免使用HAL_Delay或delay_ms否则会阻塞整个调度器。不依赖其他任务的执行顺序任务之间通过全局变量或事件标志解耦。有明确的退出路径任务不要出现隐藏的死循环。如果某个任务确实需要等待一段时间可以依靠任务周期自然产生延时效果或使用状态机拆分等待过程。7.3 任务优先级如何实现定时器模拟任务的协作式调度本身没有优先级概念所有任务按注册顺序依次执行。如果任务之间有优先级需求可以考虑两种方案方案一任务表按优先级从高到低排列。调度器遍历时高优先级任务总是先执行。方案二在调度器中增加“优先级”字段每次调度时选择优先级最高且到期的任务执行。typedef struct { void (*func)(void); uint32_t period; uint32_t tick; uint8_t enable; uint8_t priority; } Task_t;void Scheduler_Dispatch(void) { uint8_t highPriorityIndex taskCount; uint8_t found 0; for (uint8_t i 0; i taskCount; i) { if (taskTable[i].enable taskTable[i].tick taskTable[i].period) { if (!found || taskTable[i].priority taskTable[highPriorityIndex].priority) { highPriorityIndex i; found 1; } } } if (found) { taskTable[highPriorityIndex].tick 0; taskTable[highPriorityIndex].func(); } }这种方式在每次调度时只执行一个任务适用于“同周期高优先级优先”的场景但由于每次只执行一个任务所有任务循环一轮的时间会变长。7.4 移植性优化为了让架构更容易移植到不同 MCU 平台可以做到调度器核心代码不依赖任何 HAL 库只用标准 C 类型。时基触发函数Scheduler_TickHandler由外部中断统一调用。驱动层提供统一接口比如BSP_LED_On、BSP_LED_Off不同平台分别实现。做到这几点后换 MCU 时只需要改驱动层和中断配置调度器代码直接复用。7.5 安全与可靠性建议在生产环境中使用这套架构时建议注意看门狗在主循环中喂狗避免任务卡死导致系统复位。参数校验任务注册时检查函数指针和周期是否合法。边界检查任务表索引操作前判断是否越界。日志输出关键任务执行状态可以输出调试信息方便远程定位问题。例如注册函数的边界检查uint8_t Scheduler_Register(void (*func)(void), uint32_t period) { if (func NULL || period 0) { return 0xFF; } if (taskCount SCH_MAX_TASKS) { return 0xFF; } ... }8. 总结回过头来看嵌入式软件架构并不是什么高深的概念它本质上是在回答“代码怎么组织才能更容易维护、扩展和移植”。定时器模拟任务调度是裸机 MCU 项目中性价比非常高的一种架构方案。这篇文章主要讲了以下几点从超级大循环到定时器任务调度的架构演进逻辑。定时器在软件架构中的定位和作用。使用函数指针任务表完成任务注册、周期调度和使能管理。中断中计数、主循环执行任务的协作式调度模型。任务与事件结合、任务与状态机结合的进阶设计方法。常见问题、排查思路以及工程实践建议。下一步建议你动手把调度器代码移植到自己手头的开发板上先点亮一个 LED再跑两个周期不同的任务感受一下“任务表 定时器中断”这个模型的魅力。然后再试试把按键扫描、串口处理、显示刷新都加进来你会发现代码结构比之前的超级大循环清晰太多了。如果你后续感兴趣还可以沿着这个方向继续探索事件驱动架构、协作式调度器与状态机的深度结合甚至尝试切换到 FreeRTOS对比不同调度模型下系统表现的差异。好的嵌入式软件架构能力就是在一次次这样的小项目迭代中积累出来的。
