1300_FreeRTOS中的优先级相关知识点分析

全部学习汇总： GreyZhang/g_FreeRTOS: learning notes about FreeRTOS. (github.com)

前面基本把任务调度相关的接口大概看了一下，接下来回归对FreeRTOS整体的认识学习。有了基础的代码分析之后，现在了解了更多的概念，相信接下来的学习可能会更加顺利一些。

关于这部分，官方有一个网页可以参考： RTOS task priorities in FreeRTOS for pre-emptive and co-operative real time operation

上面的网页中的信息不是很多，但是结合自己之前的一些经验或者想法，可以做一个简单的品读。

知识点相对来说简单：

1. configMAX_PRIORITIES决定的其实是OS支持的优先级数目而不是优先级的最大数字值，这个在之前做内核的代码分析的时候就分析过了。代码中有的地方会对此进行检查。

2. 优先级的数字越大意味着优先级越高，最低优先级的idle task的优先级是0。

3. 任务的选择机制有一个优化的实现，借用了计算前导零的硬件功能可以快速选出来已经就绪的任务中的最高优先级。不过，这样就把OS支持的优先级的数目限制在了最大32个。因为，这个计算前导零其实是一个寄存器的操作。

4. 优先级多了，RAM上会有更多的占用。这个在之前分析OS内核的时候也看到了，尤其是就绪任务链表可能就是很大的一个消耗点。针对这部分，可以再看一下代码。

FreeRTOS.h中虽然有这个量的使用，但是都是做检查用，不涉及到存储的分配。

在portmacro.h中，这个也是一样，只是用来做检查。

接下来的结果中，队列不是一个基础的OS内核功能，属于偏应用的部分，这里直接跳过看看task.c文件。

这个地方应该是RAM占用会受影响的部分。其他task.c中的内容，基本上也是对这个数值的应用。接下来，直接测试一下这个链表的基础存储占用情况。查看链表结构的空间占空的同时，也看一下总体工程的资源占用情况，具体的测试结果如下：

这是初始的状态，这个时候OS支持最多7个优先级。

这个时候，就绪任务链表占用了140个字节。

进一步，把支持的任务优先级减少2个测试，看一下整体的资源占用情况。

从上面的结果，两次对比可以看得出来减少了40个字节。因此，就绪任务链表节省了40个字节的信息。

这个结论从数组大小的变化也可以直接看得出来。

有些MCU上RAM资源特别宝贵，因此类似的资源的消耗还是一个很重要的指标。针对我之前接触过的项目处理场景，有时候优先级也不见得需要那么多。或许，三四个优先级的调度也是可以满足基本的功能诉求的。毕竟，这样的设计总该好过前后台的设计。

一个可以尝试的配置列出来，以后可以做一个尝试：4个优先级（idle + 高、中、低）、采用优化的任务选择 、抢占式内核、idle支持让步（如果这样，或许只需要3个优先级即可）。其他的基础功能，可以根据实际的情况来看。这样的模式下，中断的处理其实也不见得需要做很多的拆分，直接全都让OS托管即可。后面，找到合适的使用场景之后，这个倒是可以作为尝试。