在学FREERTOS中，用的是STM32hal库函数，用STM32CUBE_MX生成的初始化代码（真的很好用），小弟遇到个问题。
第一步创建了2个任务LED0和LED1，任务都是灯亮500ms，灭500ms，这两个任务的优先级我都设成一样的，比如都是3，然后在创建任务后开始任务调度。这时两个灯几乎是同时亮同时灭的。说明这两个任务是论循的，LED0任务运行，对应的IO口响应了变化，然后论循到了LED1任务运行，对应的LED1的IO口响应了变化，之后在这样论循，就这样一直在两个任务间论循；

第二步、我改变了一下，将两个任务设置不同的优先级，比如LED0的优先级设为4，LED1的优先级设为3，这样编译后观看结果还是LED0和LED1同时亮500ms，同时灭500ms，这应该是高优先级的LED0先开始运行，在运行到LED0的IO翻转指令后，进行了延时（这里和上面的延时用的都是FREERTOS自带的延时），延时中发生了任务调度，LED0释放了CPU的使用权，LED1抢到了CPU的使用权（这应该就是抢占式的原因吧），系统继续运行到LED1的IO翻转指令后，IO电平进行翻转，然后进入延时发生任务调度。就这样一直在两个高低优先级的任务间发生循环调度，因为响应IO的速度是非常快的，所以看起来又是同时亮500ms，灭500ms；

第三步、我将系统的延时去掉了，用上了自己写的延时（里面没有任务调度的函数），任务的优先级也改成了相同的了，编译后烧写到芯片中看到的现象是LED0和LED1同时亮500ms，灭500ms。这里我就不理解了，在这里用的是自己的延时函数，是不会发生任务调度的。按理说应该是其中一个LED的IO口进行电平翻转之后进入自己的延时，然后再等延时之后另一个LED的IO口进行电平翻转，接着又进入了延时等待。这样一直轮询下去。我想这样的话那么现象不应该是两个LED同时亮灭的；

第四步、我将两个任务换成不一样的优先级，比如LED0的优先级设为4，LED1的优先级设为3，用的还是自己的延时函数。则现象是高优先级的LED一直在亮500ms，灭500ms。因为是高优先级的任务一直没有发生任务调度，所以CPU的使用权都没有释放。

结果小弟就在想了，是不是这同一优先级的任务是不是的运行是不是就是所谓的时间轮转调度，跟抢占式的调度的机理不一样，他不需要任务调度函数，时间到了就会自己发生调度，所以才会出现第三步中的情况。还有大神帮忙看看我分析的第一步到第四步是不是对的呢、、、


还有就是这个STM32CUBE软件里面为什么添加任务的时候任务的优先级只有7个选择，难道不能像UCOS一样用的是0~255的数值可以设置255个任务优先级吗？

楼主对RTOS的机制理解还差了一点。第3个实验，因为是同一优先级，所以这2个任务的切换是按时间片轮询的，如果是LED0先亮，那么LED1会慢一个周期（通常是1ms）后才点亮。为什么LED0亮1ms之后就跳去执行LED1点亮的程序，是因为1ms时间到了，触发了systick中断，systick中断再触发pendsv中断，在pendsv中断例程中执行任务切换。
如果不切换到LED1任务，那么LED1就永远不会被点亮了。这是你第4个实验的现象。因为LED1的优先级低，而LED0的任务又不肯放弃CPU的使用权。那么每1ms触发中断进入任务切换函数时，由于LED0是高优先级，且不放弃CPU使用权，那么任务切换时仍然使得高优先级的LED0处于运行态。

1、STM32CUBE_MX生成的FreeRTOS任务调度是自动的，所以第三步你的延时函数是什么已经不重要了
2、任务优先级高的一般会占的时间片多，优先级低的占的时间片少，所以第四步中的低优先级任务不运行，我自己试过十七的任务同时开也是这样的情况
3、FreeRTOS理论上可以开无限个任务，前提是在STM32CUBE_MX设定中分配足够的内存，而相比之下uCOS只能开有限的任务

学习了。。。

学习了

同优先级的任务是按 时间片轮询 运行的，如 5ms 为一个时间片，则同优先级的任务会各运行 5ms 后进行任务切换，如果运行时间到（不足 5ms）也会进行任务切换。
FreeRTOS所支持的最大任务数是可以设置的，不过建议不要超过  32 个，因为超过 32 个会使用另一种相对低效的任务切换算法。
具体可参考  安富莱  的教程：1200页的FreeRTOS教程发布，支持F103，F407和F429https://www.stmcu.org.cn/module/ ... amp;fromuid=3135760
(出处: 意法半导体STM32/STM8技术社区)

感觉楼主的想法是正确的。

谢谢分享，学习了，