企业官网建设流程全解析

最近在整理嵌入式项目的可维护性时，有个问题经常被同事、学员反复问到：裸机程序到底怎么组织，才既能跑得稳，又不会一加功能就崩？

这个问题没有标准答案，但有一条被大量项目验证过的路径非常值得推荐：从“超级大循环”升级到“定时器驱动的任务调度架构”。简单来说，就是用一个硬件定时器产生固定节拍，在节拍里维护多个软件定时器/任务计数，再配合一个轻量调度循环，让不同模块按各自周期运行。它不需要引入 RTOS，也不需要很高的硬件资源，却能让代码从“一坨 while 循环”变成“分层清晰、可裁剪、易移植”的工程结构。

这次我们来看一套可以直接落地的实现思路：从分层思想到状态机，再到定时器模拟任务的具体 C 代码。

1. 核心能力速览

先给结论。三种常见裸机架构方案，适合什么场景、成本多高、实时性如何，一张表讲清楚：

本文要实现的方案，适合大多数 STM32、GD32、ESP32 裸机、51 等资源有限的嵌入式项目。它不抢占，不解决“两个任务同时抢 CPU”的问题，但可以解决“任务周期混乱、代码不停堆叠、一个按键抖动影响整屏刷新”这一类最常见的问题。

2. 为什么要从超级大循环升级到定时器驱动架构

很多人刚开始写嵌入式代码时，用的都是“超级大循环”：

int main(void) { while (1) { key_scan(); display_refresh(); uart_handle(); led_toggle(); } }

这种写法在项目只有两三个功能时，完全没有问题。但做过一年以上嵌入式开发的人，大概率会遇到下面这些情况：

• display_refresh()里有一处 while 等待标志位，卡了两毫秒，结果key_scan()按键扫描的周期被拉长，按键变得“迟钝”。
• 想在系统里加一个“长按 3 秒保存参数”的逻辑，发现 if 嵌套越来越深，状态分散在多个函数里，根本不敢改。
• 某个模块改了一行延时，整个系统的响应节奏全变了，排查半天不知道是谁影响的谁。

根因就一句话：所有任务都挤在同一个主循环里，按照“函数调用顺序”执行，而不是按照“时间周期”执行。

超级循环里，任务 A 多花 1ms，任务 B 就被推迟 1ms。所有模块的时间基准互相污染。只要有一个函数不是快速返回，整个系统实时性就崩了。

而定时器驱动架构要解决的核心问题，就是把“时间基准”从主循环手里拿出来，交给硬件定时器。主循环负责的是“有没有到执行时间，到了就执行”，而不是“从头到尾顺序跑一遍”。

这个升级思路，和从“面向过程堆代码”到“分层 + 状态机”是同步发生的。换句话说：

1. 用定时器产生统一的时间心跳，比如 1ms。
2. 每个模块注册自己的执行周期，比如按键扫描 5ms、显示刷新 50ms、数据上报 200ms。
3. 主循环按时间表查询并执行到期任务。
4. 每个任务内部尽量使用状态机，而不是阻塞延时。

这样做的直接收益是：

• 模块和模块之间时间上不再互相干扰。
• 任务执行的周期误差只取决于定时器准确度，而不是主循环长度。
• 增加新功能时，只需注册一个新任务，不用动主循环顺序。
• 后续想升级到 RTOS，任务划分方式和状态机代码几乎可以平移过去。

3. 环境准备与前置条件

本文的代码基于 STM32 平台，但原理对所有带硬件定时器的 MCU 通用。如果你手头是 GD32、MM32、复旦微、极海等芯片，只需要改定时器初始化函数，调度器本身不依赖任何 HAL 库封装。

3.1 硬件环境

• 一块 STM32 开发板，推荐 STM32F103 系列或 STM32G0/G4 系列，成本低、资料多。
• 一个 LED、一个按键、一块串口转 USB 模块，用于验证任务运行效果。
• 可选的逻辑分析仪，观察各任务真实的执行时间点。

3.2 软件环境

• Keil MDK 或 IAR 或 STM32CubeIDE，任意一个都可以。
• 标准外设库或 HAL 库都能用，本文调度器部分不包含具体厂商 API，定时器初始化会分别给出寄存器级和 HAL 级两种示意。
• 一个串口调试助手，用来打印任务运行日志。

3.3 需要掌握的基础知识点

• 定时器中断的基本概念：周期中断、中断服务函数、中断优先级。
• 结构体数组和函数指针的使用。
• 状态机的基本写法：用 switch-case 根据当前状态执行不同逻辑。

这些知识其实都不难，难的是把它们组合成工程结构。下面的实现会把每一步拆开。

4. 架构设计：分层、状态机与定时器调度的关系

在写代码之前，先说明架构分层。这一节是整个工程可维护性的根基。

4.1 三层结构：应用层、调度层、驱动层

我推荐把裸机代码分成三层：

大多数项目变成“屎山”的原因，是把这三层混在一起。典型表现是：

// 反面示例：业务逻辑和寄存器操作写在一起 void key_scan(void) { if (GPIO_ReadInputDataBit(GPIOA, GPIO_Pin_0) == RESET) { Delay_ms(10); // 阻塞来了 if (GPIO_ReadInputDataBit(GPIOA, GPIO_Pin_0) == RESET) { EEPROM_Write(0x00, 0x01); // 业务逻辑直接操作 EEPROM } } }

如果把按键扫描、去抖、业务逻辑、存储操作全部塞到一起，那这个功能一旦要换存储芯片、换按键引脚、改触发逻辑，都会互相影响。

在定时器驱动架构中，这三层可以分别推进：

• 驱动层负责“让定时器每 1ms 进一次中断，让 GPIO 能读能写”。
• 调度层负责“哪个任务到时间了，该跑了”。
• 应用层负责“按键按下之后，翻转一个 LED，或者启动一个 5 秒超时状态”。

4.2 定时器就是系统的“心跳”

定时器的作用，可以理解成给整个系统一个稳定的心跳。

假设配置 SysTick 定时器，让它每 1ms 触发一次中断。每次中断，调度器就把一个全局的 tick 计数加 1，同时遍历所有已注册任务，把它们的倒计时计数器减 1。如果某个任务的计数器减到 0，就标记它“本轮需要执行”。

主循环里反复做一件事：检查哪些任务被标记了“需要执行”，然后调用对应的函数指针。

这本质上就是一个协作式调度器。任务一旦开始执行，必须自己尽快退出，不能阻塞。它不像 RTOS 那样能强制切换，但它占用的资源极小，逻辑清晰，在裸机项目中非常好用。

4.3 任务内部为什么推荐状态机

任务被调度器调用了，不代表一次调用就要把所有事情干完。

比如“长按按键 3 秒保存参数”这个逻辑，如果用阻塞写法：

if (key_pressed) { delay_ms(3000); // 卡住三秒，其他任务全废 save_param(); }

显然不行。换成状态机写法后，任务每隔 10ms 被调用一次，每次只判断当前处于哪个状态，并决定是否切换状态：

• 状态 IDLE：检测到按键按下，进入 WAIT 状态，启动超时计数。
• 状态 WAIT：每 10ms 检查一次按键状态和超时计数，如果按键持续为按下且计数超过 300，进入 SAVE 状态；如果按键提前松开，回到 IDLE。
• 状态 SAVE：执行存储操作，结束后回到 IDLE。

这样整个逻辑不会阻塞任何其他任务。定时器驱动架构与状态机结合起来，才能在裸机上构建出“多任务并行”的错觉，而且代价极小。

5. 定时器模拟任务代码实现

现在进入正题：用 C 代码实现这套调度器。整个实现只包含两个文件：scheduler.h 和 scheduler.c，再加一个示例 main.c。

5.1 scheduler.h：任务定义与接口声明

#ifndef __SCHEDULER_H #define __SCHEDULER_H #include <stdint.h> #define SCHEDULER_MAX_TASKS 8 // 最大任务数，按项目扩展 typedef void (*TaskFunc)(void); typedef struct { TaskFunc func; // 任务函数指针 uint32_t interval; // 任务周期，单位 ms uint32_t counter; // 当前倒计时 uint8_t enabled; // 是否使能 uint8_t run_flag; // 本轮是否需要执行 } SchedulerTask; void Scheduler_Init(void); uint8_t Scheduler_RegisterTask(TaskFunc func, uint32_t interval_ms); void Scheduler_SetTaskEnable(uint8_t index, uint8_t enable); void Scheduler_TickProcess(void); void Scheduler_Run(void); #endif

头文件里暴露了 5 个接口：

• Scheduler_Init：初始化任务表。
• Scheduler_RegisterTask：注册一个任务，并设置执行周期。
• Scheduler_SetTaskEnable：按索引使能或暂停某个任务。
• Scheduler_TickProcess：给定时器中断调用，用于更新任务倒计时。
• Scheduler_Run：主循环调度函数，不返回。

任务数量上限定义为 8，实际项目中建议按需调整。STM32F103 这类芯片跑裸机，8 到 16 个任务足够覆盖绝大多数场景。

5.2 scheduler.c：调度器的核心实现

#include "scheduler.h" static SchedulerTask s_tasks[SCHEDULER_MAX_TASKS]; static uint8_t s_task_count = 0; static volatile uint32_t s_tick = 0; void Scheduler_Init(void) { uint8_t i; s_task_count = 0; s_tick = 0; for (i = 0; i < SCHEDULER_MAX_TASKS; i++) { s_tasks[i].func = 0; s_tasks[i].interval = 0; s_tasks[i].counter = 0; s_tasks[i].enabled = 0; s_tasks[i].run_flag = 0; } } uint8_t Scheduler_RegisterTask(TaskFunc func, uint32_t interval_ms) { if (func == 0) { return 0; } if (s_task_count >= SCHEDULER_MAX_TASKS) { return 0; } s_tasks[s_task_count].func = func; s_tasks[s_task_count].interval = interval_ms; s_tasks[s_task_count].counter = interval_ms; // 注册后第一个周期立即执行一次 s_tasks[s_task_count].enabled = 1; s_tasks[s_task_count].run_flag = 0; s_task_count++; return (uint8_t)(s_task_count - 1); } void Scheduler_SetTaskEnable(uint8_t index, uint8_t enable) { if (index >= s_task_count) { return; } s_tasks[index].enabled = enable; } void Scheduler_TickProcess(void) { uint8_t i; s_tick++; for (i = 0; i < s_task_count; i++) { if (s_tasks[i].enabled == 0) { continue; } if (s_tasks[i].counter > 0) { s_tasks[i].counter--; } if (s_tasks[i].counter == 0) { s_tasks[i].counter = s_tasks[i].interval; // 重新装载周期 s_tasks[i].run_flag = 1; // 标记需要执行 } } } void Scheduler_Run(void) { uint8_t i; while (1) { for (i = 0; i < s_task_count; i++) { if (s_tasks[i].run_flag) { s_tasks[i].run_flag = 0; if (s_tasks[i].func) { s_tasks[i].func(); } } } } }

这段代码有四个关键设计点，值得逐一说清楚。

第一，中断里不执行任务函数，只置 run_flag。这是架构上最重要的一条红线。如果直接在定时器中断里调用任务函数，任务执行时间过长会拖垮中断，造成后续节拍丢失；如果任务函数里有临界区或外部中断，还可能引发不可预知的竞争。把 run_flag 交给主循环消费，中断服务函数就能保证非常短，也方便排查问题。

第二，counter 初值等于 interval。这样任务注册后第一个周期立即执行一次，适合 LED 翻转、状态初始化这类场景。如果想注册后延迟一个周期再执行，把初值改为 0 或 interval + 1 即可。

第三，run_flag 是主循环与中断之间的交接点。虽然代码里没有用临界区保护，但在单核 Cortex-M 裸机场景下，中断对 run_flag 的写入与主循环对 run_flag 的清零是串行发生的，配合编译器的 volatile 约束，问题不大。如果项目编译优化等级很高，且 use 了多个外设中断，建议在置位和清零处加__disable_irq()/__enable_irq()保护。

第四，任务表中的 enabled 位用于暂停任务。系统级休眠、低功耗模式、或者某个业务场景下需要暂停上报，直接把它关掉，不需要删除任务条目。

5.3 定时器底层配置

调度器本身不关心你用哪个定时器，它只要一个可靠的节拍源。下面给出两种常见配置方式。

方式一：寄存器方式配置 SysTick，1ms 中断。

#include "stm32f1xx.h" void BSP_Timer_Init(void) { uint32_t reload = SystemCoreClock / 1000; // 1ms 中断 SysTick_Config(reload); NVIC_SetPriority(SysTick_IRQn, 3); // 低优先级 }

方式二：HAL 库方式，沿用 SysTick 默认勾选。

很多 STM32CubeMX 生成的项目，在HAL_Init()中会调用HAL_InitTick()，默认就是 1ms 一个 tick。此时可以不用单独配置定时器，直接在SysTick_Handler()里加一行：

void SysTick_Handler(void) { HAL_IncTick(); Scheduler_TickProcess(); }

如果 CubeMX 生成的代码在HAL_IncTick()之后还有自定义回调，也一样在回调里调用Scheduler_TickProcess()。

除了 SysTick，也可以用 TIM2、TIM3、TIM6 等通用定时器来产生周期中断。这在低功耗项目中很常见：SysTick 在休眠时可能被关闭，而低功耗定时器 LPTIM 可以在休眠中维持节拍。

使用通用定时器时，初始化的核心参数是：预分频 PSC、自动重载 ARR，两者结合得到中断周期：

// 假设时钟 72MHz，预分频 72-1=72，ARR=1000-1=1000 // 中断频率 = 72MHz / 72 / 1000 = 1kHz，即 1ms TIM_HandleTypeDef htim2; htim2.Instance = TIM2; htim2.Init.Prescaler = 72 - 1; htim2.Init.Period = 1000 - 1; htim2.Init.CounterMode = TIM_COUNTERMODE_UP; HAL_TIM_Base_Init(&htim2); HAL_TIM_Base_Start_IT(&htim2);

然后实现中断回调：

void HAL_TIM_PeriodElapsedCallback(TIM_HandleTypeDef *htim) { if (htim->Instance == TIM2) { Scheduler_TickProcess(); } }

需要注意，HAL_TIM_PeriodElapsedCallback是由 HAL 库统一处理的，如果项目里多个定时器都使用该回调，就必须用htim->Instance或htim == &htim2做区分。

5.4 应用层任务示例：LED 翻转、按键扫描、模拟数据上报

调度器搭好后，应用层就是往里面注册任务。下面给出一组典型示例。

// app_led.c #include "scheduler.h" static uint8_t led_state = 0; static void App_LedProcess(void) { led_state ^= 1; // 翻转 if (led_state) { BSP_LED_On(); } else { BSP_LED_Off(); } }

// app_key.c #include "scheduler.h" static uint8_t key_counter = 0; static void App_KeyProcess(void) { // 每 5ms 执行一次，10ms 去抖 if (BSP_Key_Read() == KEY_PRESSED) { key_counter++; if (key_counter >= 2) { key_counter = 2; // 饱和计数 if (!key_repeat_flag) { key_repeat_flag = 1; App_KeyEventNotify(KEY_EVENT_SINGLE_CLICK); } } } else { key_counter = 0; key_repeat_flag = 0; } }

// app_report.c #include "scheduler.h" static uint32_t report_count = 0; static void App_ReportProcess(void) { report_count++; // 模拟采集并上传数据 printf("report period=%d, count=%lu\r\n", 200, (unsigned long)report_count); }

5.5 main.c：任务注册与启动

#include "scheduler.h" void BSP_Timer_Init(void); // 定时器初始化，见上文 void BSP_LED_Init(void); void BSP_Key_Init(void); void BSP_UART_Init(void); void App_LedProcess(void); void App_KeyProcess(void); void App_ReportProcess(void); int main(void) { SystemInit(); BSP_LED_Init(); BSP_Key_Init(); BSP_UART_Init(); Scheduler_Init(); BSP_Timer_Init(); Scheduler_RegisterTask(App_LedProcess, 100); // 100ms Scheduler_RegisterTask(App_KeyProcess, 5); // 5ms Scheduler_RegisterTask(App_ReportProcess, 200); // 200ms Scheduler_Run(); // 永不返回 return 0; }

Scheduler_Run()是一个死循环，因此main()永远不会走到 return。MCU 的 main 入口后就没有其他事情了。这里要注意，定时器初始化放在任务注册之前还是之后，功能上都可以，但建议先注册任务再启动定时器，避免定时器一启动就立刻触发 tick，而任务表还没注册完，导致首轮调度漏掉某些任务。

6. 功能测试与效果验证

代码写完，怎么验证调度器真的按预期工作？建议按下面几个用例依次测试。

6.1 测试一：LED 周期翻转

预期现象：LED 以约 100ms 周期翻转，即闪烁周期 200ms。用示波器测量 LED 引脚波形，应该能看到方波周期约 200ms，占空比约 50%。

把任务周期改小到 10ms，观察现象是否随之变化。如果波形周期偏差巨大，优先排查 SysTick 配置是否正确。

6.2 测试二：任务间互不阻塞

这是调度器是否生效的核心验证。在某个任务中临时加一个阻塞延时，验证其他任务是否被拖慢。

• 在App_ReportProcess中加delay_ms(30)（模拟一次耗时操作）。
• 观察 LED 翻转周期变化。

在超级循环架构中，这个 30ms 的阻塞会直接影响 LED 相位，因为所有任务顺序执行。在定时器驱动架构中，只要每个任务的单次执行时间明显小于 1ms 的节拍间隔，LED 翻转周期应基本保持在 200ms。如果delay_ms(30)确实阻塞了 30ms，而任务周期是 100ms，主循环会有 30ms 无法响应其他任务，实际效果是 LED 周期被拉长到约 230ms。这个误差能暴露问题：调度器只负责“到点提示”，不负责“强制按时执行”。任务内部不应该出现长时间阻塞。

6.3 测试三：按键扫描不卡顿

在超级循环中，按键扫描往往被显示刷新、数据上报拖累。使用调度器后，按键扫描任务以 5ms 周期独立运行，不管其他任务是否耗时，按键响应基本稳定。

测试方式：运行数据上报任务，同时快速操作按键，观察按键触发事件是否丢失。如果数据上报任务中有长时间阻塞，按键仍可能丢失，这时要优化任务内部结构，把阻塞操作拆成状态机。

6.4 测试四：模拟多任务时间片

把App_ReportProcess的周期改为 500ms，再打开串口打印日志。稳定运行 10 分钟，正常情况下每次打印的间隔会在 500ms 附近波动，波动主要来自主循环中其他任务的执行时间和中断响应延迟。如果波动超过 20%，说明存在任务执行时间过长或调度器被阻塞。

建议在调度器中增加一个调试接口，统计主循环的循环周期：

volatile uint32_t s_loop_us = 0; // 在 Scheduler_Run 的 while(1) 首尾记录 SysTick 当前值，求差

这样可以在后续排查性能问题时提供数据支撑。

7. 资源占用与性能观察

7.1 中断开销

调度器核心逻辑在Scheduler_TickProcess中，也就是每次定时器中断都要遍历一遍任务表。

假设任务数 N=8，一次遍历只是做减法、比较、标志位置位，在 72MHz 主频下，整个中断执行时间大约在几微秒到十几微秒，最坏情况大概几十微秒。对 1ms 的节拍来说，CPU 占用率不高。但如果任务数增加到 50 个，且每个任务判断里都访问外设，中断时间会显著上升。因此实际项目建议把任务数控制在 16 个以内，如果超过，要么合并任务，要么直接上 RTOS。

7.2 主循环负载

主循环里只做两件事：查询 run_flag、调用任务函数。任务函数的耗时是主要负载来源。

如果某个任务单次执行时间接近或超过 1ms，它就可能在一次 tick 间隔内占用大量 CPU，导致主循环来不及及时处理其他任务的 run_flag。这种情况不属于调度器 bug，而是任务设计问题。解决方案是：

• 把耗时操作拆成多步，每步只执行一部分，并通过状态机记录进度。
• 把高负载任务降频，比如数据上报从 10ms 改成 100ms。
• 把硬实时要求高的操作放在中断回调里，但必须保证执行时间极短。

7.3 如何观察 CPU 占用

裸机上最朴素的观察方式：翻转一个空闲 GPIO。

在主循环while(1)的循环体里翻转一个 GPIO，用示波器测量高电平时间，能直观看到主循环空闲占比。任务执行变多时，空闲高电平时间会变短。这个“空闲指示器”是嵌入式调优非常实用的手段。

static inline void Idle_Pin_High(void) { GPIOB->BSRR = GPIO_PIN_1; } static inline void Idle_Pin_Low(void) { GPIOB->BRR = GPIO_PIN_1; } while (1) { Idle_Pin_High(); // 开始任务调度 for (i = 0; i < s_task_count; i++) { ... } Idle_Pin_Low(); // 空闲，可进入低功耗 __WFI(); // 可选：等待中断 }

注意，如果使用__WFI()进入休眠，定时器中断仍然能唤醒 CPU，从而形成“低功耗 + 定时调度”的组合，这对功耗敏感的设备很有意义。

7.4 显存、内存与存储开销

嵌入式裸机场景没有“显存”概念，但 RAM 和 Flash 占用同样重要。

本调度器的 RAM 占用主要来自s_tasks数组。以 STM32F103 为例，单个SchedulerTask结构体大小取决于编译器的对齐与优化，实际大致为 16 到 24 字节。8 个任务对应的 RAM 占用只有 128 到 192 字节左右。这在绝大多数 MCU 上都可以接受。

Flash 占用方面，调度器本身的代码量很小，几百字节到一两 KB。真正的 Flash 占用大头是应用层的业务逻辑、库函数和 printf 重定向。也就是说，调度器引入的资源开销可以忽略不计，这是它比直接上 RTOS 更适合小资源项目的关键优势。

8. 常见问题与排查方法

实现这套调度器后，最常遇到的问题集中在下表这些场景。

需要特别提醒的是，中断里不要调用 printf。printf的重定向往往涉及串口发送，如果发送缓冲区满了或串口被占用，中断会被长时间阻塞，轻则丢失 tick，重则造成任务漂移。

另外，定时器中断优先级建议设置得比外部事件中断低一些。如果按键、外部中断的优先级比 tick 高，那么在极端情况下，外部中断耗时过长，tick 会连续丢失，导致所有任务周期漂移。更稳妥的做法是：外部中断只置软件标志，真正处理逻辑放到应用任务中。

9. 最佳实践与使用建议

9.1 任务周期设计成整倍数

多个任务同时到点时，主循环会串行执行它们。比如 5ms 的按键扫描和 200ms 的数据上报同时就绪，按键扫描就会晚执行几微秒到几十微秒，这在绝大多数场景下无感知。

但最好不要出现 7ms 和 100ms 这种非整倍数组合，因为它们的对齐点会游走，导致某些时刻两个任务同时执行，某些时刻错开。整倍数周期能让任务之间的耦合关系更稳定，也容易在测试时预测行为。

9.2 任务内部不要阻塞

调度器只负责“提醒到点”，不负责“打断正在运行的任务”。如果App_ReportProcess里有一个 500ms 的延时，即使按键任务周期只有 5ms，在这 500ms 内按键任务也会被卡住。这是协作式调度的基本约束。

正确的做法：

• 使用非阻塞方式：设置一个软件标志，任务多次被调度时轮询标志。
• 使用状态机：把耗时操作拆成“启动”、“等待完成”、“处理结果”三个状态。
• 使用 DMA：比如串口发送数据时用 DMA，任务里只检查 DMA 完成标志。

9.3 增加调试统计接口

建议在 scheduler.c 里增加几个调试变量，方便开发期排查：

volatile uint32_t s_tick_count = 0; // 总 tick 数 volatile uint32_t s_max_task_used = 0; // 最大任务数，观察是否溢出 volatile uint32_t s_loop_start_tick = 0; // 主循环起始 tick，便于计算循环周期

这些变量在最终发布版本里可以用条件编译关掉。

9.4 模块化边界与可移植性

调度器是高度可移植的。它不依赖任何具体 MCU 寄存器，只依赖一个 1ms 的节拍源。迁移到 51 单片机时，你可以把定时器 0 做成 1ms 中断，然后在中断里调用Scheduler_TickProcess()，任务代码完全不用改。迁移到 MSP430、GD32、瑞萨 RA 系列时，也是同样的逻辑。

这也是分层思想的直接收益：驱动层负责硬件差异，调度层和应用层保持稳定。如果暂时不打算上 RTOS，这套结构已经足够支撑一个中规模裸机项目的迭代。

9.5 安全与合规提醒

在嵌入式软件架构设计中，如果项目涉及电机控制、锂电池管理、医疗设备、工业安全控制等场景，必须评估任务调度失败带来的后果。定时器模拟任务的协作式调度，适合对实时性要求中等、任务间无强耦合的通用产品；如果涉及“超时未响应可能导致硬件烧毁或人员受伤”的功能，应该使用 RTOS 或更高可靠性的方案，并增加看门狗、冗余检测、故障安全状态等机制。

同时，在参考开源代码和库时，注意保留许可证声明。STM32 HAL、CMSIS、FreeRTOS 等都有各自的许可证要求，商用前要确认是否符合归属和开源义务。

10. 总结与下一步

定时器模拟任务调度，是嵌入式裸机开发中性价比极高的一次架构升级。它不引入 RTOS，不需要额外栈空间，不改变你对 MCU 资源的使用方式，却能把“时间基准”从主循环的泥潭里解放出来，让多个模块各自按周期运行，也让代码分层和状态机改造更容易落地。

最容易踩的坑有三个：任务函数里写阻塞延时、中断里执行耗时逻辑、任务周期设计成非整倍数。这三点只要在代码评审时重点盯住，这套架构就能稳定跑很久。

这篇文章给出的代码可以直接复制到你的工程里改一改就能用。如果后续需要更高实时性、任务间通信、消息队列这些能力，可以在这个调度器基础上扩展事件标志和消息队列，也可以考虑移植 FreeRTOS。把裸机任务划分和状态机设计做好之后，再切 RTOS，你会发现思路基本是连续的。

如果手里正好有 STM32 开发板，建议先把 LED、按键、串口三个任务跑通，再用空闲 GPIO 观察主循环占用，你会对“任务调度到底发生了什么”有非常直观的理解。建议收藏备用，动手试一遍比读十遍理论都有用。