1322_FreeRTOS中的队列使用的信息梳理以及初步队列的使用

1322_FreeRTOS中的队列使用的信息梳理以及初步队列的使用

全部学习汇总： ​​https://github.com/GreyZhang/g_FreeRTOS​​

预感到这个队列的使用可能并不是简单看看就能够结束的，如果无法一次性搞定，那么这个学习笔记可能会拆分成多个部分。队列的核心文件有两个，一个是queue.c另一个则是queue.h，这样，我们很容易可以通过头文件的包含来初步确认一下队列的使用相关模块。

从引用的角度来看，从上面至少还可以看到信号量以及计时器的功能与之有一定的引用关系。而上面的三个文件的引用，基本上都是接口封装暂且应该可以不去做过多的关注。

那么接下来如何去认识队列的设计以及使用呢？首先得尝试构建一个简单的队列的使用例子，之后追着这个例子的实现看看队列如何发挥作用的。这样，初步的尝试至少应该先搭建一个队列的使用例子出来。

这部分信息来自于FreeRTOS的官方教程里面的，之前其实在Windows的模拟环境下我曾经把这些功能简单测试了一下。这一次，我将把主要的注意力集中于FreeRTOS在嵌入式方面的实现上。这部分内容中，我想再次深化一下这部分内容的理解，那就是队列支持的信息交互方式：任务到任务、任务到中断、中断到任务。其实，之前自己尝试使用FreeRTOS的时候，任务到任务以及中断到任务的使用方式已经被我用了很多了。

关于队列行为的实现有两种，通过拷贝或者引用。其实，很多地方把这两种方式都叫做拷贝，只不过一个叫做深度拷贝而另一个叫做浅拷贝。

在实现上，FreeRTOS采用的是拷贝的方式而不是引用的方式。这在实现上其实是简单的，也让很多使用的场景得到了简化。这里也提到了，这种方式可以让队列传输的对象更容易被直接加工，而且发送的buffer可以很好的重用。不过，通过我自己的使用经验来看，其实存储的重用在理论上行得通，在实际上来说可行性不大。尤其是针对我接触的这种行业中常用的工程构建方式来说，尤其难实施。因此，这方面的处理可能让我感觉到RAM的消耗非常厉害。但是，在简化软件设计上的确是有很好的体验。

接下来，我会先尝试做一个简单的测试。从一个task给另一个task发送队列信息，收到之后，接收任务执行。在此过程中，我也会对比一下这个队列简单的功能会带来多大的存储开销。

这是我现在的软件工程的资源消耗的初始状态，这个工程中，目前有3个task，都是通过delay延时做了一个近似的周期性执行。分别是1000ms、500ms、10ms，其中1000ms的优先级低，而后两者目前的优先级相同。接下来，我会尝试通过500ms给1000ms发送队列信号以让1000ms执行。其中，队列只有一个元素深度，元素大小用最小的uint8_t。

看上去，之前的队列代码可能被链接器给优化掉了，因此这里简单的功能增加导致了2284字节的flash的增加。但是，这一次修改倒是没有看到RAM的增加，这个多少有点不好理解了，至少我的队列对象是作为变量定义的。

从map文件看，相应的变量也的确是分配了存储的。编译器优化的确是开到了最高，不过这样的资源使用效果也的确是让我觉得有点莫名其妙了。

重新运行之后，可以看出来运行效果依然是没问题的。可能这里的存储消耗，是因为我的软件中有一个delay被删除了导致的。接下来，重新增加做一个测试。

测试之后发现，存储依然不变。但是，现在的任务执行效果看，1000ms的任务执行频次显然是跟500ms的任务相同了，至少是可以看得出来这个队列的效果是奏效了。如果增加相应的延时，由于队列发送的时候出现了阻塞，其实这个运行效果只会编程一个执行频次上有变化而不会出现2倍关系。

重新把队列的深度扩展为了2，依然没有看出实际的变化。

但是，从S19文件上可以看得出来还是有内容的变化产生的。进一步，我测试了队列长队为10的时候，依然是这样的现象。这样其实就可以给我们一定的猜测空间了，或许队列深度等存储的消耗都在heap之中，体现不到用户RAM的空间消耗上。在后面的设计实现的代码分析中，我将会针对这部分做更深入的分析。

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。