简介面向Arduino开发者与单片机并发编程学习者的SCoop多线程库完整源码包适合在资源受限的AVR等平台上组织多任务、提升程序响应与执行效率。压缩包共58个文件、约726KB以29个ino示例、12个txt说明与变更日志、7个h头文件、7个cpp实现为主并附PDF用户指南便于从接口定义、调度实现到示例验证逐层理解库的结构与用法。已有735人学习关注说明其在Arduino多线程实践中有一定参考价值。读者可据此掌握任务创建与调度、定时器上下计数、IO过滤及性能测试等模块的用法结合多任务闪烁与综合示例体会资源分配、线程同步和异常处理等要点为在具体硬件条件下编写稳定、可维护的并发程序提供较完整的参考。1. 一块 2KB SRAM 的板子同时跑三件事SCoop 解决的是什么问题手里这块 Arduino 板子只有 2KB SRAM却要同时管按键消抖、传感器采样和一路串口输出。用delay()排时间三个功能互相按住按键响应一慢采样就丢点这是单核也得并发的典型场面。SCoop-master.zip 就是冲这个来的一个纯协作式的轻量调度库不占定时器、不开中断、不要 RTOS 那套内存池把每个任务写成看着像死循环的函数用sleep()交还 CPU。它适合引脚和内存都紧、又不想被抢占式调度折腾的 8 位项目反过来要求毫秒级硬实时的场合别用它一个任务卡住全板陪着卡。2. 协作式调度是怎么转起来的从 yield 到任务栈的那条链路2.1 没有定时器中断切换点到底在哪抢占式内核靠一个周期性的定时器中断强行打断当前代码把寄存器压栈、换栈、恢复现场。SCoop 走的是另一条路它完全不接管任何定时器切换点只出现在任务主动调用sleep()或yield()的那一刻。这个选择直接决定了它的三个特性。第一millis()、micros()、PWM、舵机库、红外接收这些依赖定时器的功能不会被搅乱这在 8 位板上是很大的实惠因为可用定时器本来就只有那么两三个。第二任务之间是纯串行执行的A 任务改一个全局变量改到一半绝不会被 B 任务插进来读所以任务之间不需要互斥锁、不需要信号量很多从抢占式内核迁过来的人在这里过度设计白白吃掉几百字节 SRAM。第三代价同样明确任何一段不让出的代码无论是delay()、while轮询还是某个第三方库里的长阻塞都会把整个调度器按住其它任务一律停摆。切换动作本身并不神秘。库里给每个任务在 SRAM 中划出一小块独立栈区任务控制块里存着栈指针和唤醒时间戳。调度器本质就是一个循环从任务链表头开始走看谁的时间戳已经过期就把当前现场程序计数器、通用寄存器、栈指针存进当前任务的控制块再把下一个任务的栈指针装回去一个返回指令就跳到了另一个函数的中间。这一套在 AVR 上是一小段汇编级的上下文切换具体实现随版本有差异打开库的源码搜yield、switch、context这类字样基本能定位到。还有一点必须提前说清否则后面所有参数都会算错sleep(ms)不让 CPU 睡觉。它的全部工作是把自己在任务表里的唤醒时间改成millis() ms然后立刻切回调度器。调度器发现所有任务都没到期就回到主循环空转。所以功耗不会因为sleep()而下降真要省电得配合休眠模式自己写而休眠和协作式调度天然打架这是后话。2.2 defineTask 和 defineTaskLoop 展开之后是什么库提供两种写法。defineTaskLoop(name)最省事只写循环体等价于一个永远跑下去的任务defineTask(name)多给一个入口你可以写name::setup()做一次性初始化再写name::loop()做循环。两者都是宏展开的骨架大致如下细节随版本略有差别但结构就是这个意思// 你写的 // defineTaskLoop(blinkTask) { ...任务体... } // // 展开后大致等价于 class blinkTask_class : public Task { // 继承库里的任务基类 public: void loop(); // 只有循环体没有 setup }; blinkTask_class blinkTask; // 全局实例构造时把自己挂进任务链表 void blinkTask_class::loop() { // 你写的那对花括号成了函数体 // ...任务体... }看明白这层展开两个硬性约束就顺理成章了。其一这两个宏只能写在全局作用域因为它要定义一个类和一个全局对象塞进函数里编译器直接报错。其二任务名实际是一个全局对象的名字所以别跟已有的变量、库名撞车命名为task1、timer、serial之类的很容易踩雷我一般统一加前缀写成tkSensor、tkBlink。defineTask版本还多一个好处任务对象上带着自己的成员函数setStackSize()这类配置可以直接在setup()里调作用域清楚不会误改到别的任务。2.3 把 zip 装进 IDE 并跑通两个任务拿到 SCoop-master.zip 之后先别急着装解压看一眼目录层级。正确的结构是压缩包解开后第一层目录里直接能看到SCoop.h、SCoop.cpp、examples/、library.properties这些文件。很多时候解压工具会多套一层变成SCoop-master/SCoop-master/SCoop.h这种结构放进库目录后 IDE 扫不到头文件编译时会报找不到SCoop.h而报错信息完全不会提示你是目录问题属于典型的无效排查方向。安装有两条路。用 IDE 菜单里的「项目 → 加载库 → 添加 .ZIP 库」直接选压缩包最省事但要注意有些老版本对 zip 内部结构挑剔多一层目录就会装歪。手工装更可控把解压出来的目录整个挪到 Arduino 的 libraries 目录下Windows 在用户目录的文档/Arduino/librariesLinux 和 macOS 在~/Arduino/libraries目录名建议改短成SCoop去掉-master后缀。改完重启 IDE在「文件 → 示例」里能翻到 SCoop 的例程就说明装对了。下面这个最小工程可以直接抄两个任务一个闪灯一个每秒打一行串口。#include SCoop.h // 任务一闪灯。亮 200ms、灭 800ms周期约 1 秒 defineTaskLoop(tkBlink) { digitalWrite(LED_BUILTIN, HIGH); sleep(200); // 让出 CPU 200ms别的任务照跑 digitalWrite(LED_BUILTIN, LOW); sleep(800); } // 任务二串口心跳计数每秒加一 defineTaskLoop(tkHeart) { static uint32_t n 0; Serial.print(F(heartbeat )); Serial.println(n); sleep(1000); } void setup() { Serial.begin(115200); pinMode(LED_BUILTIN, OUTPUT); mySCoop.start(); // 启动调度器跑各任务的 setup然后进入调度 } void loop() { mySCoop.sleep(50); // 主循环也要让出 CPU否则任务是跑不起来的 }三个地方容易看漏。sleep()在任务体里调用时是库提供的全局函数单位毫秒它记录唤醒时间后立刻切走不会真的忙等所以任务里绝不能再出现delay()。mySCoop.start()放在setup()末尾它会把所有defineTask任务的setup()跑一遍然后开始调度如果你在它之前还有没配好的外设任务一上来就可能读到脏数据。最后那句mySCoop.sleep(50)是给主循环用的主循环本身也算一个任务它不让出 CPU其它任务永远轮不到这是新手最常见的第一个翻车点。烧进去之后验收标准很清楚串口每行间隔稳定在 1 秒附近LED 的亮灭不受串口打印影响两者的节奏互不牵连。如果串口只打印了一行就停住八成是主循环里漏了yield()或sleep()。3. 参数怎么定sleep 周期、任务栈与 CPU 占用的量化算法3.1 sleep(ms) 的真实周期不是 ms把sleep(100)理解成「这个任务每 100ms 跑一次」是最常见的误解真实周期得按排队算。任务被唤醒后并不会立刻获得 CPU它要等当前正在跑的那个任务主动让出调度器才会轮到它。所以实际周期是任务体自身耗时、sleep声明的时间、以及排队等待时间三者之和排队时间最短为 0最长等于所有任务体耗时里最大的那一个。写成公式实际周期 ≈ 体耗时 sleep(ms) (0 ~ 最长体耗时)。这个式子直接给出两条设计准则。第一所有任务体的耗时之和要压在最短周期的 10% 以内剩下的 90% 是给抖动留的余量如果最短周期是 10ms那么全部任务体的耗时加起来不该超过 1ms。第二别指望sleep(1)能得到 1ms 的精度在 16MHz 的 8 位板上光是一次调度器遍历加切换就有几十微秒的开销再叠上排队时间1ms 周期基本没有意义实际能用的下限大概在 5 到 10ms。还有个细节sleep(0)和yield()效果接近都是立刻让出但下一轮马上又被检查到。它适合放在大循环末尾当「礼让」用防止一个纯计算任务霸占 CPU但如果所有任务都写sleep(0)调度器会空转CPU 占用率飙到满耗电和发热都会上来。3.2 栈给多少一份 SRAM 预算表每个任务独占一块栈这块内存是从 SRAM 里静态切走的给多了浪费给少了就是随机复位。默认值在不同平台不一样AVR 上量级在一两百字节对只做引脚操作的任务够用但凡任务里出现Serial.print格式化、浮点运算、递归或者几十字节的局部数组就得往上加。预算项典型占用8 位 AVR2KB SRAM 级别说明单个任务栈128256 BsetStackSize()可调默认偏保守任务控制块与链表节点每任务十余字节库自身静态开销改不了串口收发缓冲通常 64 64 B由核心决定任务里打印会用到浮点格式化临时占用数十字节出现在任务栈上容易漏算建议保留余量300500 B低于这个数栈溢出只是时间问题调整的方式很直接在任务的setup()里调setStackSize()。成员名在不同版本里可能略有出入打开库的头文件搜stack字样确认一下即可。defineTask(tkSensor) void tkSensor::setup() { pinMode(A0, INPUT); setStackSize(256); // 任务里有浮点运算和 Serial 格式化栈给到 256 字节 } void tkSensor::loop() { int raw analogRead(A0); float v raw * 5.0f / 1023.0f; Serial.println(v, 2); sleep(100); }栈给少了不会立刻报错而是随机时刻表现成「变量自己变值」「函数返回后跳到不存在的地址」「跑几分钟复位一次」这类问题用串口日志基本查不出来因为崩的时候串口缓冲还没发完。实操中我用的办法是从 256 起步每加一个任务就重新压测一轮观察freeMemory()的剩余量低于 300 字节就回头砍功能或者合并任务。3.3 用 micros() 打点把每个任务的占用测出来参数拍脑袋定完之后得有办法验证。最省事的探针是一个专门测抖动的任务它名义上sleep(100)然后记录每次实际间隔与 100ms 的偏差偏差就是被别的任务挤掉的排队时间。defineTaskLoop(tkJitter) { static uint32_t tLast micros(); uint32_t now micros(); uint32_t dt now - tLast; // 实际间隔单位微秒无符号相减天然扛溢出 tLast now; Serial.print(dt); // 名义值 100000。持续大于 110000 就说明有任务在拖后腿 Serial.print(F( us, over)); Serial.println(dt - 100000UL); sleep(100); }逻辑上有两个关键点。时间差必须用无符号减法算micros()大约 71 分钟回绕一次有符号减法在回绕点会算出负数无符号减法自动得到正确的小差值这是血泪经验别改成if (now tLast)那种写法。差值要保留原始微秒数打印不要一开始就除以 1000 取整抖动往往只有几百微秒取整之后全变成 0什么都看不出来。判读方法over长期稳定在几百微秒以内说明调度健康偶尔跳到几千微秒多半是某个任务里做了Serial.print长字符串或者analogRead之类如果over单调增长、越来越大那就是有个任务根本没让出 CPU回头去翻谁没写sleep()。4. 任务之间怎么配合共享变量、临界区和阻塞改造4.1 volatile 不够用的那几种情况先说结论任务与任务之间共享变量在协作式调度下什么都不用加。理由前面提过任务只在sleep()和yield()处切换一段不调用这两个函数的代码是天然原子的编译器也不会把两条语句拆到切换点两侧。很多人一上手就给所有全局变量加volatile、加关中断结果代码又慢又乱问题一个没少。真正需要处理的是中断服务函数与任务之间的共享。中断随时会来它可以在任务读变量的两条指令中间插进去改值所以这类变量必须加volatile告诉编译器每次都从内存里读别缓存到寄存器。但volatile只解决「读到旧值」不解决「读到半截值」8 位机上一次读 16 位或 32 位变量要拆成两三条指令中断正好在中间改掉任务就会读到一个高字节是新的、低字节是旧的组合值症状是数值偶尔跳变成完全不合逻辑的数。#include util/atomic.h volatile uint32_t gPulseCount 0; // 由外部中断累加任务里读取 // 任务侧读取保证拿到的是一个完整快照 uint32_t readPulseCount() { uint32_t snapshot; ATOMIC_BLOCK(ATOMIC_RESTORESTATE) { // 关中断、拷值、恢复原中断状态 snapshot gPulseCount; } return snapshot; }这段里ATOMIC_BLOCK的两个参数缺一不可ATOMIC_RESTORESTATE负责在块结束时把中断标志恢复成进入前的样子如果你原本就在关中断的上下文里它不会强行把中断打开。手写cli()加sei()的问题就在这嵌套调用一次就把外层的关中断状态破坏了症状是某个中断偶尔丢一次极难复现。临界区里只做拷贝不要放Serial.print打印本身依赖中断在关中断状态下会卡死。4.2 用标志位和环形缓冲替代信号量小板上跑协作式调度绝大多数通信需求用两种结构就够了单比特的「有新数据」标志位和一块定长的环形缓冲。标志位适合「任务 A 采到了任务 B 去处理」这种一次性通知环形缓冲适合连续流比如中断里收字节、任务里消费。#define RB_SIZE 16 // 必须是 2 的幂取模才能用位与代替 volatile uint8_t rbHead 0; // 只由生产者写 volatile uint8_t rbTail 0; // 只由消费者写 volatile uint8_t rbBuf[RB_SIZE]; // 生产者侧满了就丢绝不在这里等 inline bool rbPush(uint8_t b) { uint8_t next (uint8_t)((rbHead 1) (RB_SIZE - 1)); if (next rbTail) return false; // 追尾即满牺牲一个槽位换判断简化 rbBuf[rbHead] b; rbHead next; // 最后一步才发布新下标 return true; } // 消费者侧没数据立刻返回靠 sleep() 决定多久再来问一次 inline bool rbPop(uint8_t *out) { if (rbTail rbHead) return false; // 空 *out rbBuf[rbTail]; rbTail (uint8_t)((rbTail 1) (RB_SIZE - 1)); return true; }几个参数是有讲究的。容量取 2 的幂是为了把% RB_SIZE换成 (RB_SIZE - 1)8 位机上省下一条除法指令除法在 AVR 上没有硬件支持一次要几十个周期。索引必须用uint8_t8 位读写单指令完成天然原子换成uint16_t就得分两步head和缓冲内容之间会出现撕裂。rbHead的赋值必须放在数据写入之后这是唯一的顺序要求写反了消费者可能先看到新下标、再读到还没写进去的旧数据。生产者如果来自中断rbPush里除了上面这些不要再加任何关中断因为它已经是「单写者」模型中断自己不会被自己打断。只有当生产者不止一个比如两个中断都往里塞时才需要给rbPush套临界区那种结构设计本身就说明该合并成一个入口了。4.3 把 delay() 和 while 等待改造成合作式任务体里最致命的写法是同步等待一次delay(2000)让全板停摆两秒。改造的思路不是把delay换成sleep因为sleep之后代码会从下一行继续语义变了正确做法是把「等待」拆成一串状态用状态机加sleep重新组织。以超声波测距为例改造前是一个任务按住调度器两秒多// 改造前这 2 秒里别的任务全部停摆 defineTaskLoop(tkBad) { digitalWrite(TRIG, LOW); delayMicroseconds(2); digitalWrite(TRIG, HIGH); delayMicroseconds(10); digitalWrite(TRIG, LOW); uint32_t us pulseIn(ECHO, HIGH, 25000); // 最长阻塞 25ms Serial.println(us / 58); delay(2000); }改造后拆成三个状态任何一步都不会长时间占住 CPUdefineTaskLoop(tkGood) { enum { FIRE, WAIT_ECHO, REPORT } st FIRE; static uint32_t t0 0, us 0; switch (st) { case FIRE: digitalWrite(TRIG, LOW); delayMicroseconds(2); digitalWrite(TRIG, HIGH); delayMicroseconds(10); digitalWrite(TRIG, LOW); t0 micros(); st WAIT_ECHO; break; case WAIT_ECHO: // 轮询也能接受因为有 25ms 上界 if (digitalRead(ECHO) HIGH) { us micros() - t0; st REPORT; } else if (micros() - t0 25000UL) { us 0; st REPORT; } // 超时放弃本次 break; case REPORT: Serial.println(us / 58); sleep(2000); // 让出 CPU 两秒别的任务照跑 st FIRE; break; } sleep(1); // 每轮小睡避免状态机空转吃满 CPU }WAIT_ECHO状态里的轮询看着像忙等实际是安全的因为回波要么很快到来要么 25ms 后被超时分支结束最坏情况只占 25ms比原来两秒好两个数量级。末尾那句sleep(1)是兜底防止状态机在某几个状态间快速循环时空转。us / 58是厘米换算的常用系数换成别的测距模块要按手册重算这个系数错了会表现成「距离一直在飘」而不是明显报错。5. 五个把板子跑挂的场景现象、原因和排查顺序5.1 现象编译通过串口只打印一行就没了原因几乎总是主循环没让出 CPU。loop()里如果写的是while(1){}、delay(1000)或者干脆什么都没写但也没调yield()调度器就永远轮不到看起来就是「只有一个任务跑了一下」。另一个变体是mySCoop.start()被放在了setup()里某个提前return的分支之后压根没执行到。解决loop()里至少放一句mySCoop.sleep(10)或yield()。排查时先把主循环清空成只有这一句验证任务是活的确认活了之后再把业务代码一行行加回去加到哪一行任务停住问题就在那一行。5.2 现象跑几分钟复位一次或者某个变量自己变成离谱的值栈溢出。任务栈不够用时任务会写穿到隔壁任务的栈或者全局变量区破坏的通常是别的任务的数据。表现极具随机性同一个固件烧两片板子一片正常一片抽风室温低的时候更容易崩。这类问题用日志完全查不到因为崩的瞬间串口还没把话说完。解决把带浮点、带Serial.print格式化、带局部数组的任务栈翻倍逐个排除。稳定之后不要贪心砍回去栈这种东西就是花钱买确定性的。另外检查任务体里有没有递归调用协作式任务里递归几乎必然溢出。5.3 现象某个任务越跑越慢周期从 1 秒漂到 3 秒有别的任务在拖后腿或者这个任务自己写了sleep之外的长阻塞。典型嫌疑是某处Serial.print打了一长串字符在低波特率下Serial.print会阻塞等待发送完成115200 下发 60 个字符接近 5ms波特率降到 9600 就是 60ms 量级。解决把 3.3 节那个抖动探针任务加进去看over值是稳定的小抖动还是持续增长。前者是正常的排队后者说明有任务没让出。再把串口波特率提到 115200把长打印拆成短行或者干脆省掉问题基本就消失了。5.4 现象编译报sleep重定义或者提示找不到SCoop.h两种完全不同的原因。找不到头文件先看 libraries 目录下是不是多套了一层SCoop-master/SCoop-master/这是解压工具干的。装的时候目录名带-master也能被新版本 IDE 识别但老版本会挑改短成SCoop最稳。sleep重定义则是符号冲突库把sleep()定义成了全局函数如果你的工程里另外包含了带同名函数的头文件链接阶段就冲突。解决办法是只在一个地方#include SCoop.h优先用mySCoop.sleep()这个带作用域的写法绕开实在绕不开就把冲突的那个头文件挪到单独的编译单元里别让它和 SCoop 出现在同一个.ino里。5.5 现象外设偶发卡死或者串口吐出乱码任务里调用了阻塞式或者依赖中断时序的库。软件串口在收发时会长时间关中断如果在收的过程中被调度器切走位时序就乱了表现为乱码某些 I2C 从设备在一次不完整的读之后会一直拉住总线下次Wire调用就永远不返回。解决把这几个库的调用集中到同一个任务里并且在这个任务体内不要跨库调用。I2C 场景加一条超时判据读之前记millis()超过几十毫秒没回来就重新初始化总线。更稳的做法是让这类库独占一个任务其它任务只跟它通过标志位交换数据别让两个任务同时碰同一路总线。6. 再往前一步用心跳表把任务时序变成可验证的指标调好参数、踩完坑之后最后一件事是把「感觉还行」变成「能证明它行」。我的习惯是给每个任务维护一个自增心跳计数再开一个监督任务定期巡检谁的心跳停了就点名。先把时序写成表贴在工程说明里任务名义周期体耗时预算栈依赖tkBlink1000 ms 1 ms128 B无tkSensor100 ms 3 ms256 B模拟口tkReport2000 ms 5 ms256 B串口tkMonitor1000 ms 1 ms128 B无有了表代码就好写volatile uint8_t gHb[3] {0, 0, 0}; // 三个业务任务各占一格 defineTaskLoop(tkMonitor) { static uint8_t last[3] {0, 0, 0}; static uint8_t miss[3] {0, 0, 0}; for (uint8_t i 0; i 3; i) { if (gHb[i] last[i]) { // 这一秒没动过 if (miss[i] 3) { // 连续三次判定为卡死 Serial.print(F(stalled: )); Serial.println(i); miss[i] 0; } } else { miss[i] 0; // 动了就清零 last[i] gHb[i]; } } sleep(1000); }三个业务任务里各加一句gHb[i]就完事。判据选三次而不是一次是因为抖动导致某轮晚到很正常连续三秒不动才是真卡。这个结构比板载看门狗有用得多看门狗只会复位心跳表能告诉你「是哪个任务先死的」事后复现的价值完全不同。代价是几十字节 SRAM 和每秒一次遍历在 2KB 的板子上完全付得起。我在早期一个采集项目里没写这个东西现场反馈「偶尔停几秒又自己好了」回来查了两天没结论最后是栈溢出让某个任务悄悄跑飞恢复靠的是别的任务恰好不依赖它。从那以后我每次起一个带两个以上任务的项目都强制先把这张时序表和心跳监督写进去再往里塞业务代码。希望帮到你。本文还有配套的精品资源点击获取
