https://gitee.com/gitee_caowent/sloop

sloop 是一个专为裸机设计的轻量化协作式多任务调度框架，它完全契合咱们之前聊的 “裸机协作式调度核心逻辑”——无内核强制抢占、任务主动配合释放 CPU、摒弃冗余时间片设计，同时通过封装标准化的任务管理 API，解决了裸机手动实现多任务的代码混乱、耦合度高的问题。

结合框架文档和之前的讨论，拆解 sloop 的核心设计亮点和运行逻辑：

一、核心定位：裸机的 “调度胶水层”，非 OS

sloop 不是 RTOS，它没有特权级内核，也没有强制上下文切换能力，本质是对裸机前后台架构的升级封装，核心目标是：

1. 用统一的 API 管理裸机的超时任务、周期任务、并行任务、互斥任务，替代杂乱的标志量和定时器中断回调；
2. 实现非阻塞等待（sys_wait/sys_wait_bare），让单个任务挂起时不阻塞其他任务，接近 RTOS 的任务阻塞体验；
3. 保持裸机的轻量化、低延时优势，无额外调度开销，适配 MCU 资源紧张的场景。

二、核心设计：契合裸机协作式调度的 “减法原则”

sloop 的设计完全避开了裸机时间片的冗余问题，同时强化了协作式调度的核心能力，关键设计如下：

1. 任务动态注册，替代静态轮询

   • 所有需要轮询的任务必须通过 sys_task_start 注册，不允许直接写在 main 的 while(1) 中。
   • 支持运行时启停任务，停止后无副作用，解决了裸机静态轮询任务无法灵活启停的问题。
   • 替代了大量模块间的标志量同步，降低代码耦合度。

2. 非阻塞等待：裸机协作式调度的核心升级

   • 提供 sys_wait/sys_wait_bare 两个核心 API，仅在互斥任务中生效。
   • 调用后会挂起当前互斥任务，但不阻塞并行任务，实现了 “单任务挂起、多任务并行” 的效果。
   • 支持 sys_wait_break 强制中断等待，比裸机手动判断标志量更灵活可控。

3. 无时间片设计，回归裸机纯协作本质

   • sloop 没有时间片计时和强制切换逻辑，任务的执行完全依赖主动挂起和触发条件。
   • 这和咱们之前的结论一致：裸机任务有明确退出机制时，时间片是冗余设计，sloop 彻底摒弃了这一点，保证了调度的低延时。

4. 中断与主线程的严格分工

   • 中断被定义为 “超高优先级短暂线程”，仅做最轻量化操作，比如置标志位、读传感器数据。
   • 复杂逻辑通过 sys_task_once 下放至主线程执行，避免中断耗时过长阻塞系统。
   • 中断配置为不可抢占，杜绝了中断嵌套导致的栈溢出和延迟不可预测问题。

三、任务类型：覆盖裸机常见的多任务场景

sloop 把裸机任务分成 4 类，用标准化 API 管理，解决了裸机任务形态混乱的问题：

四、工程化亮点：提升裸机开发效率和可靠性

sloop 不只是调度框架，还提供了很多裸机开发的工程化工具，降低调试和维护成本：

1. 系统控制台：通过 RTT 终端执行命令，支持重启、查询任务状态、CPU 负载、GPIO 控制、串口 / CAN 发送等。
   • 开发阶段无需烧录代码，直接在线调试硬件，大幅提升调试效率。
2. 行为日志与错误日志：开启后可打印 API 调用流程和错误位置，方便追溯业务执行过程和问题。
3. 看门狗支持：可配置启用 1s 超时看门狗，作为系统最后一道防线，解决任务死循环问题。
4. 内存操作规范：文档明确列出非法内存操作类型和预防方法，从编码层面减少裸机常见的崩溃问题。

五、关键使用约束：避免协作式调度的坑

sloop 是协作式调度，所以有明确的使用约束，核心是任务必须主动配合，否则会阻塞整个系统：

1. sys_wait/sys_wait_bare 不允许嵌套调用，否则日志会报错。
2. 互斥任务是核心业务载体，并行任务仅作为辅助，不能执行耗时逻辑。
3. 禁止在 main 的 while(1) 中直接添加任务函数，必须通过 sys_task_start 注册。
4. 同一个回调函数不能同时开启多种超时 / 周期任务，否则会被覆盖。

总结

sloop 是一个非常贴合裸机开发实际需求的协作式调度框架，它没有像 RTOS 那样引入复杂的内核和时间片机制，而是在裸机的基础上做了精准的封装和升级—— 既保留了裸机的轻量化和低延时优势，又解决了裸机手动实现多任务的代码混乱、耦合度高、调试困难等问题。

对于 MCU 资源紧张、追求低延时的裸机场景，sloop 是比 RTOS 更优的选择，它完全符合 “裸机协作式调度 = 任务拆分 + 主动释放 CPU” 的核心逻辑。