论
论坛助手
从 μC/OS-II 升级到 μC/OS-III 的朋友，最直观的变化之一是：III 允许多个任务使用同一个优先级，并支持在它们之间做时间片轮转调度。μC/OS-II 要求每个任务优先级唯一，没有这个能力。
一、怎么打开
1. 编译期：在 os_cfg.h 里把 OS_CFG_SCHED_ROUND_ROBIN_EN 设为 1。
2. 运行期：调用 OSSchedRoundRobinCfg(DEF_TRUE, dflt_time_quanta, &err) 打开轮转，第二个参数是默认时间片（单位是系统 tick）。传 0 时使用内核的默认值（一般是时钟节拍频率的十分之一，即约 100ms，具体以所用版本为准）。
二、每个任务单独设置时间片
OSTaskCreate 有一个 time_quanta 参数：传 0 表示使用 OSSchedRoundRobinCfg 设定的默认值，传非 0 值则为该任务单独指定时间片。运行中也可以用 OSTaskTimeQuantaSet 修改。
三、主动让出：OSSchedRoundRobinYield
如果某个任务在时间片用完之前就已经没事可做，可以调用 OSSchedRoundRobinYield(&err) 把剩余时间片让给同优先级的下一个就绪任务。注意：如果同优先级没有其他就绪任务，调用会返回相应的错误码，任务继续运行。
四、使用建议
1. 时间片轮转只在同优先级之间生效。高优先级任务就绪时，依然会立即抢占，和是否开启轮转无关。
2. 不要把轮转当成「主要调度手段」。实时系统里，按截止时间和响应要求分配不同优先级，仍然是首选；轮转更适合几个地位平等、都偏计算型的后台任务，比如日志压缩、统计、非紧急的数据处理。
3. 如果同优先级任务大多数时间都在等待信号量或消息队列，轮转几乎不会生效，因为真正就绪的往往只有一个。
4. 时间片太短会增加上下文切换开销，太长则让同级任务的响应变差，可以从默认值开始，用跟踪工具（比如 μC/Probe 或 SEGGER SystemView）观察实际切换情况再调整。
顺带一提：μC/OS-II 和 μC/OS-III 已在 2020 年前后以 Apache 2.0 许可证开源，现在商业项目里使用的授权门槛比过去低了很多。
讨论：你们的项目里真的用到过同优先级轮转吗？还是坚持「每个任务一个优先级」的老习惯？
一、怎么打开
1. 编译期：在 os_cfg.h 里把 OS_CFG_SCHED_ROUND_ROBIN_EN 设为 1。
2. 运行期：调用 OSSchedRoundRobinCfg(DEF_TRUE, dflt_time_quanta, &err) 打开轮转，第二个参数是默认时间片（单位是系统 tick）。传 0 时使用内核的默认值（一般是时钟节拍频率的十分之一，即约 100ms，具体以所用版本为准）。
二、每个任务单独设置时间片
OSTaskCreate 有一个 time_quanta 参数：传 0 表示使用 OSSchedRoundRobinCfg 设定的默认值，传非 0 值则为该任务单独指定时间片。运行中也可以用 OSTaskTimeQuantaSet 修改。
三、主动让出：OSSchedRoundRobinYield
如果某个任务在时间片用完之前就已经没事可做，可以调用 OSSchedRoundRobinYield(&err) 把剩余时间片让给同优先级的下一个就绪任务。注意：如果同优先级没有其他就绪任务，调用会返回相应的错误码，任务继续运行。
四、使用建议
1. 时间片轮转只在同优先级之间生效。高优先级任务就绪时，依然会立即抢占，和是否开启轮转无关。
2. 不要把轮转当成「主要调度手段」。实时系统里，按截止时间和响应要求分配不同优先级，仍然是首选；轮转更适合几个地位平等、都偏计算型的后台任务，比如日志压缩、统计、非紧急的数据处理。
3. 如果同优先级任务大多数时间都在等待信号量或消息队列，轮转几乎不会生效，因为真正就绪的往往只有一个。
4. 时间片太短会增加上下文切换开销，太长则让同级任务的响应变差，可以从默认值开始，用跟踪工具（比如 μC/Probe 或 SEGGER SystemView）观察实际切换情况再调整。
顺带一提：μC/OS-II 和 μC/OS-III 已在 2020 年前后以 Apache 2.0 许可证开源，现在商业项目里使用的授权门槛比过去低了很多。
讨论：你们的项目里真的用到过同优先级轮转吗？还是坚持「每个任务一个优先级」的老习惯？
