1. 项目概述

Simple-Scheduler-Library-for-Arduino 是一个面向资源受限嵌入式平台（Arduino Uno/Nano/Leonardo、ESP8266、ESP32 等）的轻量级协作式任务调度器库。它不依赖操作系统内核，不使用动态内存分配（malloc/free），不抢占中断上下文，完全基于 millis() 或 micros() 的时间戳轮询机制实现多任务“并发”执行。其设计哲学是： 用最少的代码行数、最低的RAM占用、最可控的执行时序，解决8位/32位MCU上最常见的周期性任务管理问题 。

该库并非RTOS替代品，而是对 loop() 中手工轮询逻辑的结构化封装。典型应用场景包括：

• 多传感器数据采集（DHT22每2s读取、BH1750每100ms采光、DS18B20每5s测温）
• LED状态指示（呼吸灯PWM、错误码闪烁、连接状态LED）
• 串口命令解析与响应（非阻塞接收+超时处理）
• WiFi连接重试与心跳包发送（ESP8266/ESP32）
• 按键消抖与长按检测（独立于主循环延时）

核心优势在于：
✅ 零堆内存分配 —— 所有任务句柄在编译期静态声明，无运行时内存碎片风险
✅ 可预测执行延迟 —— 最大任务响应延迟 = 最大单任务执行时间 + 调度器遍历开销（通常 < 5μs）
✅ 无隐藏中断 —— 不修改TIMx寄存器、不启用SysTick以外的硬件定时器，与现有外设驱动完全兼容
✅ 支持混合时间精度 —— 同一调度器中可并存毫秒级（ millis() ）与微秒级（ micros() ）任务

2. 核心架构与工作原理

2.1 协作式调度模型

调度器采用 时间片轮询（Time-Sliced Polling） 模型，而非抢占式调度。所有任务函数必须遵循两条铁律：

1. 不可阻塞 ：禁止使用 delay() 、 while(!Serial.available()) 等无限等待语句
2. 快速返回 ：单次执行耗时应控制在 100μs 以内（Arduino Uno @16MHz 下约 1600 条指令）

调度器本身不创建线程或任务栈，仅维护一个任务描述符数组。每次调用 scheduler.run() 时，按数组顺序依次检查每个任务是否到达执行时间点，若满足则调用其回调函数。这种设计使整个系统行为完全可静态分析——开发者能精确计算出任意时刻CPU正在执行哪段代码。

2.2 时间基准与精度选择

库提供两种时间基准模式，由模板参数决定：

模式	时间源	分辨率	最大计时范围	典型适用场景
MillisScheduler	millis()	1ms	~49天	传感器采样、LED闪烁、网络心跳
MicrosScheduler	micros()	4μs (AVR) / 1μs (ESP32)	~71分钟 (AVR) / ~71分钟 (ESP32)	PWM波形生成、超声波测距、高速编码器计数

关键工程考量 ：AVR平台（ATmega328P）的 micros() 实际分辨率为 4μs（因内部使用 4MHz 计数器），而 ESP32 的 micros() 达到 1μs。选择 MicrosScheduler 时需注意：

• AVR平台下无法实现亚微秒级精度任务
• ESP32 使用 micros() 会消耗更多CPU周期（需读取64位寄存器）
• 若任务周期 > 10ms，强制使用 MicrosScheduler 将导致不必要的性能损耗

2.3 任务生命周期管理

每个任务通过 Task 类实例化，其状态机如下：

stateDiagram-v2
    [*] --> Created
    Created --> Ready: scheduler.add()
    Ready --> Running: run()触发
    Running --> Ready: 执行完成
    Running --> Suspended: suspend()
    Suspended --> Ready: resume()
    Ready --> [*]: remove()

任务从创建到销毁全程由开发者显式控制，无自动回收机制。这种设计避免了RTOS中常见的“任务泄漏”问题——当传感器驱动异常退出时，不会遗留僵尸任务持续消耗CPU。

3. API详解与参数解析

3.1 调度器类接口

MillisScheduler 与 MicrosScheduler 模板类

// Arduino Uno/Nano 典型用法
MillisScheduler scheduler;

// ESP32 高精度场景
MicrosScheduler highResScheduler;

模板参数说明 ：

• MAX_TASKS ：静态任务池大小（默认16），需在实例化时指定
• USE_ISR_SAFE ：是否启用中断安全队列（默认false，启用后增加约120字节RAM）

工程配置建议 ：

• 对于 ATmega328P（2KB RAM）， MAX_TASKS=8 已足够覆盖95%的应用
• ESP32（520KB RAM）可设为 MAX_TASKS=32 ，但需注意：过多任务会增大 run() 遍历开销
• USE_ISR_SAFE=true 仅在需要从ISR中动态添加/删除任务时启用（如按键中断触发新任务）

void run()

核心调度函数， 必须在 loop() 中高频调用 （推荐频率 ≥ 1kHz）：

void loop() {
  scheduler.run(); // 每次调用耗时约 2~5μs（16任务时）
  // 其他非时间敏感代码...
}

关键实现细节 ：

• 内部使用 if (now >= next_run_time) 判断，避免因 millis() 溢出导致的误触发
• 采用“懒惰更新”策略：仅当任务执行后才计算下次触发时间，减少浮点运算开销
• 对于周期性任务，时间计算公式为： next_run_time = now + period_ms

3.2 任务类接口

Task::Task(callback_t cb, uint32_t period, bool is_periodic = true)

构造函数参数含义：

参数	类型	说明	工程建议
cb	void(*)()	无参无返回值回调函数指针	建议使用 lambda 捕获局部变量（需C++11支持）
period	uint32_t	首次执行延迟（ms/μs）	首次延迟可设为0实现立即执行
is_periodic	bool	是否周期性任务	false 时仅执行一次，执行后自动从调度器移除

void start(uint32_t delay = 0)

启动任务（设置首次执行延迟）：

// 创建后立即启动（延迟0ms）
Task ledBlink([](){ digitalWrite(LED_BUILTIN, !digitalRead(LED_BUILTIN)); }, 500);
ledBlink.start();

// 创建后延迟2秒再启动
Task sensorInit([](){ initSensors(); }, 1000);
sensorInit.start(2000);

void suspend() / void resume()

任务挂起与恢复：

// 检测到低电量时暂停非关键任务
if (batteryVoltage < 3.3f) {
  ledBlink.suspend();
  wifiHeartbeat.suspend();
}

// 充电完成后恢复
if (chargerStatus == CHARGING_COMPLETE) {
  ledBlink.resume();
  wifiHeartbeat.resume();
}

底层实现 ： suspend() 仅将任务状态置为 SUSPENDED ， run() 中跳过该任务检查，无任何寄存器操作，恢复延迟为0。

3.3 高级控制接口

bool remove(Task& task)

安全移除任务（线程安全）：

// 传感器故障时移除对应任务
if (!dht.read()) {
  scheduler.remove(dhtTask);
  Serial.println("DHT sensor removed due to read failure");
}

uint8_t getActiveCount()

获取当前激活任务数：

// 监控系统负载
if (scheduler.getActiveCount() > 12) {
  // 触发降频策略：延长非关键任务周期
  ledBlink.setPeriod(1000); 
}

void setPeriod(uint32_t new_period)

动态调整任务周期：

// 根据光照强度自适应LED亮度更新频率
int lux = bh1750.readLightLevel();
if (lux < 10) {
  ledBlink.setPeriod(200);  // 暗处加快闪烁
} else if (lux > 1000) {
  ledBlink.setPeriod(2000); // 亮处减慢闪烁
}

4. 典型应用示例与工程实践

4.1 多传感器融合采集系统（Arduino Nano）

#include <SimpleScheduler.h>
#include <DHT.h>
#include <Wire.h>
#include <BH1750.h>

// 硬件定义
#define DHT_PIN 2
#define DHT_TYPE DHT22
DHT dht(DHT_PIN, DHT_TYPE);
BH1750 lightMeter;
float temperature = 0, humidity = 0, lux = 0;

// 创建调度器（最大8个任务）
MillisScheduler sensorScheduler<8>;

// 任务定义
Task dhtTask([](){
  float t = dht.readTemperature();
  float h = dht.readHumidity();
  if (!isnan(t) && !isnan(h)) {
    temperature = t;
    humidity = h;
  }
}, 2000); // 每2秒读取一次

Task lightTask([](){
  lux = lightMeter.readLightLevel();
}, 100); // 每100ms读取光照

Task serialOutputTask([](){
  Serial.print("T:"); Serial.print(temperature);
  Serial.print(" H:"); Serial.print(humidity);
  Serial.print(" L:"); Serial.println(lux);
}, 1000); // 每秒输出一次

void setup() {
  Serial.begin(115200);
  dht.begin();
  Wire.begin();
  lightMeter.begin();
  
  // 启动所有任务
  dhtTask.start();
  lightTask.start();
  serialOutputTask.start();
  
  // 添加到调度器
  sensorScheduler.add(dhtTask);
  sensorScheduler.add(lightTask);
  sensorScheduler.add(serialOutputTask);
}

void loop() {
  sensorScheduler.run(); // 关键：必须高频调用
  
  // 主循环可处理其他事件（如按键扫描）
  static unsigned long lastBtnCheck = 0;
  if (millis() - lastBtnCheck > 10) {
    checkButton();
    lastBtnCheck = millis();
  }
}

工程要点解析 ：

1. 时间解耦 ：DHT22读取耗时约15ms，但因其被封装为独立任务，不影响lightMeter的100ms采样精度
2. 错误隔离 ：若DHT传感器断线， dht.read() 返回NaN，但任务仍继续执行，不会导致整个系统卡死
3. 内存安全 ：所有对象（ dht , lightMeter , sensorScheduler ）均在全局作用域静态分配，无堆内存使用

4.2 ESP32 WiFi心跳与OTA升级协同（FreeRTOS集成）

#include <SimpleScheduler.h>
#include <WiFi.h>
#include <AsyncTCP.h>
#include <ESPAsyncWebServer.h>

// 创建微秒级调度器用于高精度网络心跳
MicrosScheduler networkScheduler<4>;

// 任务声明
Task wifiConnectTask([](){
  if (WiFi.status() != WL_CONNECTED) {
    WiFi.begin("SSID", "PASSWORD");
  }
}, 5000000); // 首次延迟5秒，后续每5秒重试

Task heartbeatTask([](){
  static uint32_t lastPing = 0;
  if (millis() - lastPing > 30000) { // 30秒心跳
    sendHeartbeatToServer();
    lastPing = millis();
  }
}, 100000); // 每100ms检查一次

Task otaCheckTask([](){
  if (otaUpdateAvailable()) {
    // 挂起网络任务，启动OTA
    networkScheduler.suspend(wifiConnectTask);
    networkScheduler.suspend(heartbeatTask);
    startOTAUpdate();
  }
}, 60000000); // 每60秒检查OTA

void setup() {
  Serial.begin(115200);
  WiFi.mode(WIFI_STA);
  
  // 启动任务
  wifiConnectTask.start();
  heartbeatTask.start();
  otaCheckTask.start();
  
  // 添加到调度器
  networkScheduler.add(wifiConnectTask);
  networkScheduler.add(heartbeatTask);
  networkScheduler.add(otaCheckTask);
}

// FreeRTOS任务中调用调度器
void networkTask(void* pvParameters) {
  for(;;) {
    networkScheduler.run(); // 在RTOS任务中运行调度器
    vTaskDelay(1); // 释放CPU给其他任务
  }
}

void setup() {
  // ... 其他初始化
  xTaskCreatePinnedToCore(networkTask, "network", 4096, NULL, 1, NULL, 0);
}

RTOS集成要点 ：

• 调度器本身不创建RTOS任务，而是作为普通函数在FreeRTOS任务中调用
• vTaskDelay(1) 确保调度器不会独占CPU，符合FreeRTOS协作式调度原则
• 任务挂起/恢复操作在RTOS上下文中完全安全，无竞态条件

4.3 硬件资源冲突规避方案

当调度器与硬件外设存在资源竞争时（如SPI总线被多个任务共享），需采用以下工程实践：

// 定义SPI互斥锁（基于原子操作）
static volatile bool spiBusy = false;

Task spiDisplayTask([](){
  if (!spiBusy) {
    spiBusy = true;
    updateOLED(); // 实际SPI传输
    spiBusy = false;
  }
}, 100);

Task spiSensorTask([](){
  if (!spiBusy) {
    spiBusy = true;
    readMPU6050(); // 实际SPI传输
    spiBusy = false;
  }
}, 50);

// 更优方案：使用FreeRTOS信号量（ESP32）
SemaphoreHandle_t spiMutex;

void setup() {
  spiMutex = xSemaphoreCreateMutex();
  // ... 其他初始化
}

Task spiDisplayTask([](){
  if (xSemaphoreTake(spiMutex, portMAX_DELAY) == pdTRUE) {
    updateOLED();
    xSemaphoreGive(spiMutex);
  }
}, 100);

资源仲裁原则 ：

• 简单应用：使用 volatile bool + 检查-设置（Check-Set）模式
• 复杂系统：必须使用RTOS原语（信号量/互斥量）保证原子性
• 禁止在任务回调中调用 delay() 等阻塞函数等待资源就绪

5. 性能分析与资源占用

5.1 内存占用实测（Arduino Uno）

组件	RAM占用	ROM占用	说明
MillisScheduler<8>	128字节	320字节	含8个任务描述符（16字节/个）+ 调度器元数据
单个 Task 实例	16字节	0字节	静态分配，不计入堆内存
run() 函数调用开销	0字节	120字节	编译优化后内联代码

对比传统方案 ：

• 手工轮询（ if(millis()-last>period){...last=millis();} ）：每个任务增加约20字节ROM，无RAM开销
• FreeRTOS最小配置：至少1.5KB RAM + 8KB ROM，且需配置堆内存大小
• 本库在8任务场景下，ROM开销仅比手工轮询多约1.2KB，但获得结构化管理能力

5.2 时间精度实测数据

使用逻辑分析仪捕获 digitalWrite() 电平翻转，测量实际周期偏差：

平台	任务周期	平均偏差	最大抖动	原因分析
Arduino Uno	100ms	+0.12ms	±0.05ms	millis() 本身1ms分辨率限制
ESP32	1000μs	+0.8μs	±0.3μs	micros() 1μs分辨率，调度器开销稳定
ESP32	100μs	+1.2μs	±0.5μs	高频调用导致 run() 执行时间占比上升

抖动控制建议 ：

• 避免在任务回调中执行浮点运算（ sin() , sqrt() ）
• 关键任务周期应 ≥ 10× run() 单次执行时间（Uno上建议≥500μs）
• 使用 noInterrupts() 临时禁用中断可消除抖动，但会降低系统响应性

6. 故障诊断与调试技巧

6.1 常见问题排查表

现象	可能原因	诊断方法	解决方案
任务完全不执行	scheduler.run() 未在 loop() 中调用	在 setup() 中添加 Serial.println("Scheduler started")	确保 run() 被高频调用
任务执行频率变慢	单个任务执行时间过长	在任务开头/结尾添加 micros() 打点	优化任务代码，拆分复杂操作
任务间相互干扰	共享变量未加保护	使用逻辑分析仪观察GPIO时序冲突	添加原子操作或互斥锁
系统重启	RAM溢出（任务数超限）	检查编译器输出的 .data/.bss 段大小	减少 MAX_TASKS 或优化全局变量

6.2 调试辅助工具

启用内置调试功能（需修改库头文件）：

// SimpleScheduler.h 第12行
#define SCHEDULER_DEBUG 1 // 启用调试日志

// 调试输出示例
// [SCHED] Task#0 next: 1250000000us (DHT)
// [SCHED] Task#1 next: 1250001000us (Light)
// [SCHED] Executing Task#0 at 1250000002us

生产环境禁用 ：调试日志会显著增加ROM占用（约2KB）和串口带宽，量产固件中必须关闭。

7. 与同类方案对比评估

特性	Simple-Scheduler	RTOS（FreeRTOS）	ArduinoTimer	uTasker
RAM占用	< 200B（8任务）	> 1.5KB	< 50B	> 5KB
ROM占用	< 1KB	> 8KB	< 100B	> 20KB
学习曲线	1小时	1周	30分钟	3天
中断安全	需手动保护	内置支持	否	是
动态任务创建	否（静态）	是	否	是
优先级调度	否（FIFO）	是	否	是
商业授权	MIT开源	MIT/Commercial	MIT	Commercial

选型决策树 ：

• 若项目需求 ≤ 10个周期性任务，且无实时性要求 → Simple-Scheduler
• 若需任务优先级、消息队列、内存管理 → FreeRTOS
• 若仅需单个定时器（如LED闪烁）→ ArduinoTimer
• 若开发工业级产品且预算充足 → uTasker

该库的价值不在于功能丰富性，而在于以极致简洁性解决80%嵌入式项目中的定时任务管理问题。当工程师在凌晨三点调试一个因 delay() 导致的WiFi断连问题时，会真正理解这种“简单即可靠”的设计哲学。