小灰笔记

之后呢，寻找更高优先级的任务，让更高优先级的任务执行。因此，我们的PendSV的Handler中需要完成这个信息的更新。而这里的中断处理涉及到FreeRTOS的中断模型，其实也类似于AUTOSAR OS中的一类中断和二类中断。其他的都是关于逻辑的方法的，其实直接拿成熟的代码直接看或许更好一些。因此，在当前的PendSV阶段，我们需要做好任务优先级判断的处理，确认接下来需要执行哪一个任务。从这部分文档的描述看，其实这个PendSV的作用是非常固定的。这部分的处理，与SVC的处理其实是类似的。

而返回之后，由于之前的SVC等已经设置了PSP的信息，因此接下来的软件会按照PSP中的设定去执行。为什么能够启动，结合之前梳理的任务创建的分析是可以理解的。因为任务创建的时候，把执行入口绑定到了TCB的栈中，在这次的退出时会返回执行。这是上面提到的表17。至于为什么要写入0xD，其实有其他的原因，因为这里的这段代码是一个异常的Handler。这里描述的事向量表的内容，向量表的0地址偏移处刚好是SP的初始值。vPortSVCHandler代码中的信息，代码到124行，其实是获取了当前任务TCB中的栈顶信息。

这两个语句的操作实现的功能更是把Systick以及PendSV中断的优先级设置为15，也就是最低。其实，功能分析到此，现在这两个中断的优先级究竟应该设置为多少是合理的暂且还是不明确的。首先看93行，这个是KEIL中的一个伪指令，主要实现的功能是保证汇编代码中的堆栈能够按照8字节对齐。这个地址区从手册中可以查出来是SRAM的区域，这样，这一句实现的作用就是设置了堆栈在RAM区域的位置。再次结合这一个信息，上面的操作有效的部分其实是把这两个字节的高4bit全都设置为了1。这么看，注释写的应该是更加准确一些。

首先是任务就绪链表的初始化，这个继续链表是按照优先级来分的。通过这部分的代码分析看，其实如果是要让自己的系统资源占用更优一些，尽量按照自己真正的需求来配置优先级。接下来的处理，就是创建任务然后把任务关联到对应的链表中。而任务创建所实现的功能，之前已经分析过，主要是做了一个TCB的信息准备。这里有一个任务控制块的参数处理有一点复杂，主要是因为C语言的写法有不同的表达方式。至于MCU内核相关的一些部分的整理以及分档的对应解读，后面单独拆分出来单独看。可以实现同样的效果，具体的运行效果可以从打印的信息看到。

比如，有的寄存器是用于传递参数的，有的寄存器测试用来存储变量的。这里的变量是局部变量，后面的资料中看到了进一步的解释。这个说法看起来是不准确的，因为常用的float其实是占用4个字节，double才是8个字节。进程以及函数很多时候概念是统一不拆分的，在这个文档中把这两个词语的更加细致的区分点描述了一下。容器化向量的内容对大多数调用来说是不透明的，唯一明确的规定内容为内存布局与调用接口上不同寄存器间的映射关系。这是返回值的传递方式，基本的原则也是能用寄存器则用寄存器，不能再借助于内存通过指针传递。

堆栈在这个接口中其实主要的处理是做了一个对齐的处理，对齐处理的操作是：根据静态任务创建接口xTaskCreateStatic()中传入的静态创建所分配的存储buffer所指向的内存做一个对齐的处理。这个对齐的要求主要是MCU的架构决定的，这里是按照8个字节来对齐，主要就是考虑了浮点运算时候的一个对齐。书中的例子采用了静态创建任务的方式，这个其实我在自己使用这个OS的时候没用过，我创建任务的时候都用的动态的形式。首先要理解这个栈的处理方式，栈的增长是从上到下的，因此上面的地址会是一个递减的处理过程。

这第一次用到了xItemValue的元素，其实这个元素的数值算是一个元素在链表上的位置的权重信息。新的节点的插入，影响到的是链表中最后一个元素的后继以及当前被插入元素的前驱、后继以及归属属性。具体的操作效果为：新的节点更新自己的前驱和后继，而对等的关联信息则是当前pxIndex所指向的前驱和链表的尾结点。而链表的尾结点在初始化的时候，pxIndex存储的其实是指向链表尾结点Item的指针。因此，这里的这个赋值更新，其实是实现了让这个新的节点指向了链表的尾节点。这个跟预期的效果也是一样的。

单向链表可以理解为只能够判断自己的后继，无法直接判断自己的前驱的链表设计。对于链表节点的初始化，只是让这个节点与系统中的链表回到一种正交的关系。在插入一个链表的时候，明确这部分从属信息，进而明确前驱以及后继的关系。当然，对于FreeRTOS来说，还有一个更重要的信息需要在节点插入链表的时候明确，那就是所映射的内核管理对象。虽然，不同的人介绍的时候可能选择不同的类比模型，但是无非还是前后台以及OS在原理概念上的差异。这是岔出去的一个话题点。在根节点上，记录了链表的节点数目、遍历所用的指针以及链表的结束节点。

之前在使用FreeRTOS的时候注意到过这个OS中提供了多种方案的实施选择，而其中的 heap_4的方案有着很多有点也是较为推荐的一种实现方案。传入的参数为申请的内存的字节数目，如果成功则返回一个指向新分配的存储区开始的 指针。而初始化是不必要的， 因为在malloc的实现中借助于链表初始化的状态信息来判断了是否有初始化的必要， 以此实现了初始化的自动调用。链表是一个单向的链表，指向下一个空余的存储块。链表结构中有一个代表块大小的成员，这个成员的最高位用来表征当前的存储块是属于 应用程序的还是已经释放的。

获取当前队列的剩余空间，有了队列的长度以及当前的队列元素个数，做一个减法即可。这个接口是用来获取当前队列中的元素个数的，是一个结构体成员，类似面向对象的属性的处理，比较容易理解。以上就是这次FreeRTOS队列的辅助功能函数接口的实现分析，大概看了一下，目前我所使用的这个工程中涉及到的队列的功能基本也就分析结束了。队列的删除，首先是一个注册表信息的反注册处理，其次是对申请占用的内容的释放。这个是获取当前队列中的元素个数的ISR版本，相比通用的应用版本API来说，少了中断的处理考虑。

接下来，进行了掩码的处理以及数据的搬运，这里跟预想的也是一致的。这一次的接口分析跟之前不同，先猜测了一下可能的设计实现，基本上都在猜测的范畴之内。这个也是前面猜测出来的，毕竟阻塞的处理对系统影响太大了，这里采用这种处理方式更合适一些。如果队列没锁定，也就是现在的任务没有对这个队列进行处理的，那么直接进行任务事件链表的处理，看看是不是会有任务切换的需求。4. 读取搬运的过程中，队列应该没有锁定的必要，毕竟这个接口执行的位置是ISR并且处理了掩码。先看一下函数的原型，看得出来这个是没有阻塞的参数设置的。

如果不等待，那么直接返回队列为空的返回码。以上就是xQueuePeek接口的实现，从这个接口的实现可以联想到一个专用的场景：如果一个队列需要激活多个任务，那么完全可以采用这个接口辅助实现相关的功能。超时处理的部分跟普通的队列接收接口是相似的，同时也加了一个防御式编程的处理。接下来的处理结构看起来跟队列的接收接口也是十分相似的，但是从这部分的信息处理能够看得出来这个接口跟队列接收接口功能上的不同点：不会进行队列消息的移除。这是队列不为空的时候的处理，拷贝完数据之后，激活等待的任务，之后返回成功的返回码。

接下来，又是一个死循环的结构，其实处理的一些机制又是有任务的处理理念了。但是，这个不同于任务的定义，这个处理是有退出返回的可能性的。接下来的处理是等待超时的过程，如果等的过程中队列不再空，那么应该是直接提取信号即可，否则的话等到超时返回为空。如果需要等待，那么这样的返回信息即使是成立也得有一个延迟的时间，这个在后面的代码逻辑中是可以看得到的。超时的很多处理在常规队列处理的时候做了一些防御式的编程，其实这个处理也是差不多的。这样的操作跟队列传递的处理还是很相似的，只是少了数据的处理。

处理其实就是根据一个位置指针直接拷贝一个单元的数据。之前做一些较为复杂的接口分析的时候用到了一些小接口没有分析，这一次选择其中的几个做一个简单的整理。在ISR中判断队列是否为空，处理的过程中居然没有掩码的处理保护，这个为什么这么设计有点没弄清楚。这个是之前分析过的一个接口，其实也很简单，队列的元素个数到了长度值就说明已经满了。在ISR中判断队列是否满了，逻辑简单，但是出现了一个跟前面类似的疑问。这个接口实现很简单，其实就是看一个队列中存在的元素的数目。...

如果队列中有已经通过发送接口填充的数据，那么接下来从队列中搬运走一个数据，之后先看是否还有发送的任务等待，有的话再次搬回一个数据。而之前的数据已经搬出来了，成功的状态也会恢复，接下来等待队列消息的任务会接触阻塞继续运行。队列机制其实是一个很典型的事件触发处理，这么看，其实事件触发的一个基本的原理还是在于对任务链表的基本处理。等待没有超时的时候，需要不断去查询队列的消息状态。大概看了一下队列接收接口的实现，基本的实现机理还是很简单的。最开始的部分，先对队列的基础信息进行了一下判断，确保数据的有效性。...

根本的修改点其实就是2个，其中一个两个都有的是任务的激活处理，而另一个则是只属于队列的数据搬运。这两部分最大的一个差异点在于少了队列中数据的搬运，因此也可以看得出来纯粹的激活信号处理的时候，这个接口的效果更高。这部分的代码做了两件事情，第一个是如果是有等待这个队列中信号的任务，那么这个时候需要激活或者标注后续激活相应的任务。跟前面的接口类似，give的这个接口的不同点在于这个只提供激励信号，不需要传输数据。设置了ISR中的中断保护，进行实质的队列数据搬运。这一段代码在我现在的配置中是不生效的。...

从这个函数的返回值信息来说，如果使用非抢占式的调度后面不会有其他的调度处理了，剩下的就是标准的队列处理套路。这个地方是这个复位接口在我现在工程中的唯一一次调用，也就是在初始化新的队列的时候。这个接口处理的内容其实刚好跟前面的代码分析吻合起来：pcHead肯定是有效的，在这里做了分配。返回值是为了跟之前的版本兼容，从其他接口的情况分析看，这个在之前版本中很可能是用来做任务调度请求的一个标志信息。如果队列不是新创建的，所有的任务都在正常的运行态，只需要把队列链表重新做一个初始化即可。...

其实，看代码下来，我理解在FreeRTOS中后者的使用概率大大降低了，因为队列的取数据是由任务链表来驱动的。从ISR中检查队列是否为空跟不在ISR中的处理差不多，但是由于是ISR已经被调用，中断已经发生了，因此不需要考虑中断对队列的影响。其实，如果想要简化一下，也加一个中断保护的三明治结构，类似在APP的API中调用应该可以实现同样的效果。判断队列是否满了，只需要看队列的元素的数目是否达到了队列允许的最大限制。如果是在中断ISR之外，需要加一个中断保护的三明治结构，这样可以保护队列的数据内容被篡改。...

全部学习汇总： GitHub - GreyZhang/g_FreeRTOS: learning notes about FreeRTOS.前面看了队列的创建函数，今天分析一下队列的发送函数实现。首先，需要知道的是如同前面的创建接口，这个发送接口其实也是一个宏定义包装实现。而包装采用的通用发送接口，这个里面的一个参数是发送到队列的什么位置。从这里看，通用的方式其实就是队列的有序发送，先进先出，因此新发送的信息是发送到队列的末尾。函数的最开始部分，是对一部分条件的判断。首先，队列必须有效，而对等的其实是给队列分

这里也到了函数的最后部分了，可以看得出来，如果创建成功函数返回的句柄其实是指向存储空间的指针，否则返回的是NULL。而收发队列都是借用的这个返回信息，其实是给了相关的动作操作队列空间的方式。这个是reset的操作，队列尾其实是最后的字节位置，写入指定在队列头，读取是在队列尾部的前一个元素的位置。其实，队列跟任务的绑定关系是在发送或者接收的接口调度的时候建立的。另外需要注意的一点是，这个功能是必须开启动态的分配功能的时候才支持的功能。存储的信息主要是两部分，一部分是队列的对象，另一部分是队列容纳的数据信息。.

这是我现在的软件工程的资源消耗的初始状态，这个工程中，目前有3个task，都是通过delay延时做了一个近似的周期性执行。但是，现在的任务执行效果看，1000ms的任务执行频次显然是跟500ms的任务相同了，至少是可以看得出来这个队列的效果是奏效了。队列的核心文件有两个，一个是queue.c另一个则是queue.h，这样，我们很容易可以通过头文件的包含来初步确认一下队列的使用相关模块。但是，这一次修改倒是没有看到RAM的增加，这个多少有点不好理解了，至少我的队列对象是作为变量定义的。...

其实我的代码中，500ms的任务所处理的信息明显不如1000ms的多，但是现在的资源消耗上却没有符合这样的规律。其中，每一个任务都分配了160个字节的空间，从现在的结果看，至少是看得出来现在的1000ms的任务堆栈空间是充足的但是500ms的任务堆栈空间不够。而且，我的修改有时候简单粗暴，因为我用的MCU的资源相当丰富，估计我的项目用下来剩余的资源还是大半的那种。这个是我现在的工程中的具体配置情况，我把最小堆栈大小改成了64，而heap空间改成了2K，开启了堆栈溢出检测，也启用了堆栈水印的提取。...

FreeRTOS中的任务的状态有时候跟队列的操作有一定关系，具体可以体现在队列处理导致的任务阻塞上。对于读取队列的任务来说也是类似的，但是读取的阻塞产生一般是发生在队列为空的时候。当队列为空的时候，任务阻塞。关于这部分的描述其实很容理解，在之前的使用中其实我用的基本都是第一种模式。其他的数据结构的处理其实也容易，因为收发的过程都是自己的软件逻辑，很容易定制灵活的机制来实现数据大小变化、数据类型变化等不同的需求。首先，队列是先进先出的机制，其次，只要空间或者消息存在读写的动作其实是相对独立的操作。...

这是目前的情况，其实注释里面基本上写了现在的配置的情况。前面分析了一些内核的实现，现在结合我自己常见的需求看看如何能够让FreeRTOS的功能减少一些。这么看，从总量上看，尤其是RAM减少了大概600个字节，资源的释放效果还是很明显的。现在的TCB的大小是84个字节。这是目前的一个资源使用使用情况，其实还有一个总体的资源汇总，准确度不知道如何。做这一次的对比之前，我先把之前的测试代码尽量删除一下，再次看一下资源的使用。做了上面的调整之后，系统进入了hardfault，这个又是一个很奇怪的地方。...

但是，从代码的框架看了下，其实CoRoutine的队列实现跟Task支持的队列实现又是两个独立的实现。但是，简单考虑一下也是能够基本清晰的，即使是队列的信息发生了变化，修改改动的还是相应的链表实现。这个处理的方式跟Task的处理方式也有一定的相似之处，其实，很多处理都是少了stack的处理或者调度的请求处理。这个是官方的介绍，从介绍的内容来看，其实这个CoRoutine很大的一个特点就是对资源的需求会少一些。这是一个轻量的、弱化的Task功能。整体的套路其实是差不多的，最重要的一个差异在于少了对战的处理。.

全部学习汇总： GreyZhang/g_FreeRTOS: learning notes about FreeRTOS. (github.com)前面基本把任务调度相关的接口大概看了一下，接下来回归对FreeRTOS整体的认识学习。有了基础的代码分析之后，现在了解了更多的概念，相信接下来的学习可能会更加顺利一些。关于这部分，官方有一个网页可以参考： RTOS task priorities in FreeRTOS for pre-emptive and co-operative real time oper

全部学习汇总： GitHub - GreyZhang/g_FreeRTOS: learning notes about FreeRTOS.关于任务状态的定义，在这个链接有详细的描述：FreeRTOS task states and state transitions described这个是一个状态转换的状态机，可以看得出来各个状态切换的条件。从状态机可以看得出来，跟之前代码分析任务创建的时候看到的信息一致，任务的初始状态默认是ready的状态。只有ready的状态可以切换到running，因此在调度实现的

全部学习汇总： GitHub - GreyZhang/g_FreeRTOS: learning notes about FreeRTOS.前面分析了idle task的设计实现，里面的存储回收中涉及到了TCB信息的释放。这次来看看这个接口的实现。看似复杂的接口，其实涉及到的内容在我现在的配置之中有效的其实不多。上面这些内容，目前看来是全都无效的。最后一个条件是成立的，因此只需要继续往下看。这里分了几种情况来进行处理，处理的根本点是什么呢？那就是：只处理动态分配的存储，只有动态分配的存储才有回收的可能性。那么

全部学习汇总： GitHub - GreyZhang/g_FreeRTOS: learning notes about FreeRTOS.这一次来看一下idle task的实现。在很多RTOS中都有idle task，作用估计也是差不多。操作系统在启动的时候必须要至少有一个任务存在，而为此做保障的就是idle task。而idle task通常也会将自己的保障兵的角色发挥到极致，很多不重要的信息都是通过idle task的钩子函数来实现。这里顺便把这个宏定义的信息一起放在这里了，而这个宏的展开效果其实就是定

全部学习汇总： GreyZhang/g_FreeRTOS: learning notes about FreeRTOS. (github.com)第二部分代码是这里的一个关键的数据结构，其实就是记录了两个基础的信息。而这个接口，则是两个基础信息的更新操作。这个接口跟上面的接口实现差不多，只是抛弃了中断保护。如果任务是无限阻塞，那么就不会出现超时的情况。如果不是无限阻塞，那么就需要查询上面的两个基本信息。如果是溢出的数据增加，那么说明出现了计数器的溢出。xTimeOnEntering本身是记录了一个开始的时间

全部学习汇总： GreyZhang/g_FreeRTOS: learning notes about FreeRTOS. (github.com)今天分析两个事件相关的接口实现，从代码实现以及调用的情况看其实队列也不过是事件的特殊形式罢了。上面的接口实现很简单，关键的操作为：把当前的任务通过事件链表元素绑定插入到事件链表之中，这个过程中涉及到了后续调度时机的排序。接着，通过delayed list实现了当前任务的阻塞状态切换。这个接口实现的功能意图跟上面相似，不相同的地方在于前面的接口是在任务调度器工作的情

全部学习汇总： GreyZhang/g_FreeRTOS: learning notes about FreeRTOS. (github.com)这一次分析几个简单的信息查询类接口的实现，都比较简单，因此把几个相关度不大的接口放在一起做分析。首先是当前tick计数数值的获取，获取的方式不是简单的return而是采用临时变量做了一个备份数值存储。备份存储的时候为了防止数据篡改增加了中断的临时禁用保护措施。这样的设计其实在以后的软件设计中应该参考一下，之前做类似的设计的时候其实没有考虑这么充分。总觉得读取数值可

全部学习汇总： GreyZhang/g_FreeRTOS: learning notes about FreeRTOS. (github.com)这次分析的xTaskResumeAll()接口其实还是小有复杂度的，但是相关的概念清晰了理解起来不难。进行恢复操作的前提是调度器不能够挂起。首先，与挂起的工作做了一个反操作，主要是处理一个标志性计数器。接着查看现在的OS中任务数目，如果任务数目大于0继续往下的处理才有意义。接下来，进行“挂起任务链表的清空”。也就是从中一个个节点取出，从挂起链表以及状态链表中移除，

全部学习汇总： GreyZhang/g_FreeRTOS: learning notes about FreeRTOS. (github.com)今天看一个比较简单的接口实现，vTaskResume()的实现。可能是前面分析的接口已经有一些沉淀了，这次看这个接口实现的时候的确是不难，毕竟里面涉及到的接口实现之前都分析过了。软件中很多接口在我现在的配置中其实是没有奏效的，因此剩余的代码本身就不是很多。接口最开始，断言的方式判断了任务句柄的有效性。其实，有了这个，下面的判断中的一个条件的状态就已经是确认的了，后

全部学习汇总： GreyZhang/g_FreeRTOS: learning notes about FreeRTOS. (github.com)前面刚刚分析完了任务的挂起操作，接下来分析一下任务是否是挂起状态的查询接口实现。一般，这种查询类的接口实现上总是简单一些。接口也是需要配置一个宏定义使能之后才能够生效，这个跟前面的任务挂起接口实现是相似的。接下来，首先得确保传入的任务句柄是有效的。如果任务句柄有效，那么就需要查看任务是否在挂起任务链表之中。如果不在，那么查询就直接得到结果，这个任务并没有挂起。否则

全部学习汇总： GreyZhang/g_FreeRTOS: learning notes about FreeRTOS. (github.com)身体状态除了点小问题，分析暂停了一段时间。好在前阵子多写了2个接口的分析，每天的学习惯性没有停下。今天看一下vTaskSuspend()接口的实现，算是我状态恢复的第一次学习。首先，这个API需要配置生效才会有相关的功能实现。首先，进入临界保护，防止中断的影响。接着获取任务句柄，之后把相应的任务从就绪任务链表中移除。如果移除的时候，相应任务优先级的就绪任务链表空了

全部学习汇总： GreyZhang/g_FreeRTOS: learning notes about FreeRTOS. (github.com)近几次的接口分析分析的可能都是比较简单的项目，分析的时候都比较顺利。当然，也有可能是之前看的信息已经达到一定量了对现在理解这些接口有了一定的帮助。这一次，再分析一个简单的接口vTaskResume()。值得注意的是上面的预处理，其实是跟之前的挂起任务的接口的预处理是同一个条件。两个处理有一点逆向的意思，也很好理解为什么是同时存在。其实，是否同时存在并不是很关键。对

全部学习汇总： GreyZhang/g_FreeRTOS: learning notes about FreeRTOS. (github.com)这一次看一下prvTaskIsTaskSuspended()的接口，这个接口实现的是判断一个task是否是挂起的状态。通常，这种判断类的接口实现简单一些。类似之前获取任务优先级的实现，也是如此。因为本身的功能是查询而不是修改，对OS整体的运行环境没有太大的影响。很多接口的实现中，任务句柄如果为NULL默认就是处理当前的任务。但是在这个接口中这种解释没有意义，因为任

全部学习汇总： GitHub - GreyZhang/g_FreeRTOS: learning notes about FreeRTOS.前面简单分析了优先级的获取，实现上很简单。优先级的获取分为一般的OS API还有一个中断安全的版本。在具体的实现上没有太多的代码实现上难理解的地方，仅仅是一个属性的获取。这一次看看优先级的设置实现，不同于优先级的获取，设置其实只有一个接口。首先保证设置的优先级数值是合理的，进而根据优先级允许的数目来计算实际的优先级。接下来进入临界保护，获取需要修改优先级任务的当前的基础优

全部学习汇总： GreyZhang/g_FreeRTOS: learning notes about FreeRTOS. (github.com)今天来分析一下FreeRTOS中的优先级获取函数的实现，涉及到2个接口，一个是uxTaskPriorityGet()，另一个是它的中断安全版本uxTaskPriorityGetFromISR()。这一个接口的实现还是很简单的，在这个实现中直接是关掉了中断，然后去获取任务的优先级。为什么需要关中断呢，我觉得这里主要的原因是xTask可能是NULL，此时要求的是获取当