1325_FreeRTOS队列发送函数的实现分析

全部学习汇总： GitHub - GreyZhang/g_FreeRTOS: learning notes about FreeRTOS.

前面看了队列的创建函数，今天分析一下队列的发送函数实现。

首先，需要知道的是如同前面的创建接口，这个发送接口其实也是一个宏定义包装实现。而包装采用的通用发送接口，这个里面的一个参数是发送到队列的什么位置。从这里看，通用的方式其实就是队列的有序发送，先进先出，因此新发送的信息是发送到队列的末尾。

函数的最开始部分，是对一部分条件的判断。首先，队列必须有效，而对等的其实是给队列分配存储空间成功。第二点，如果队列传入的数据对象的大小不是0，那么传入对象的地址就不能够是NULL。第三，只有队列的长度是1的时候，拷贝位置才会是覆写的操作。第四，如果需要控制队列的发送等待有效tick数值，那么必须得保证调度器是正常运行的。而调度器的状态一共就3种：未启动、挂起、正常运行。

数据拷贝其实是一个很简单的动作，主要是从队列元素插入位置（前或者后）、是否覆盖写入等角度进行处理。而 核心的动作就是一个memcpy。关于返回值的应用，在我目前的配置中其实没生效，这个特性主要是用于互斥量。一般的队列应用，不会涉及到 优先级而触发的调度控制。

暂且先按照现在系统的实际设计来分析，那么这一段先跳过。

从这里其实可以看得出来，其实队列触发任务的机制还是很高效的。这个并不会依赖于tick之类的中断信息，而是在发送动作中带着一个可能的任务调度切换请求。如果任务的优先级足够高，那么是可以直接激活的。

关于队列满了的时候的处理，分为直接报错还有等待两种情况。后者的系统容忍能力看似是要强一些。

在队列满了的时候，针对是否时间超时来进行队列的处理。处理其实是分为收发两种状态，而这个过程中需要考虑中断的影响会让队列内容产生变化，这个处理的逻辑层次考虑还是需要很周密的。整个发送过程可能有很多次尝试，最终以成功或者失败作为出口。

这一段的处理有效部分其实不多，主要是处理队列锁定过程中的数据发送。

同样的处理概念，在接收数据上也应该有一个处理的过程。从这里其实是能够对发送接口的死循环设计有一定的理解了，因为这样的数据变化可能是一个动态的模式。这个很有意思，让我想到了一个“动态清零”的说法。

以上，大概就是队列的发送实现，主要还是借用的链表以及延时链表的信息处理，中间增加了数据的搬运。