如何改善FreeRTOS的运行速度和RAM的大小

　    写在前面 几乎所有RTOS操作系统都提供了队列和信号量的功能，对于大部分新手来说，使用队列和信号量是必备技能。

　　但是，在大多数情况下，他们都是使用“中介对象”进行通信，而并非“直接任务消息”通信。

　　通过“中介对象”进行通信，每一组队列或信号量都会分配一段内存（消息缓冲区和流缓冲区）。就存在一个问题，如果队列或信号量比较多，势必造成更大的内存开支。

　　但是，如果通过本文说的“直接消息”通信，会节约很多内存。

　　什么是直接任务通知？ 大多数任务间通信方法都通过 中介对象 ，例如队列，信号量或事件组。 发送任务写入通信对象，接收任务从通信对象读取。

　　比如FreeRTOS的队列通信，首先创建队列之前要定义一个队列：

　　QueueHandle_t xQueue； xQueue = xQueueCreate（10， sizeof（ /* 长度 */ ） ）; 而这个队列包含了很多中介对象：

　　大家可以算一下这个“中介对象”会占用多少RAM空间？

　　通过一个代码示意图理解中介对象通信：

　　直接任务通知： 当使用直接任务通知时，顾名思义，发送任务将通知直接发送给接收任务，而无需中介对象。

　　通过一个代码示意图理解：

　　从FreeRTOS V10.4.0开始，每个任务都有一系列通知。每个通知都包含一个32位值和一个布尔状态，它们一起仅消耗5个字节的RAM。

　　就像任务可以阻止二进制信号量等待该信号量变为“可用”一样，任务可以阻止通知以等待该通知的状态变为“待处理”。同样，就像任务可以阻止计数信号量以等待该信号量的计数变为非零一样，任务可以阻止通知以等待该通知的值变为非零。下面的第一个示例演示了这种情况。

　　通知不仅可以传达事件，还可以通过多种方式传达数据。

　　3

　　进一步分析直接任务通知 通过对比 FreeRTOS V10.4.0 和之前版本，你会发现 V10.4.0 多了一些API，比如ulTaskNotifyTake / ulTaskNotifyTakeIndexed：

　　在官网也有针对这些API的详细介绍和说明，以及应用代码例子：

　　4

　　使用直接任务通知性能优势和使用限制 任务通知的灵活性使它们可以在需要创建单独的队列、 二进制信号量、 数信号量或事件组的情况下使用。

　　与使用中介对象（例如信号量）来取消阻止任务相比，使用直接通知取消阻止RTOS任务的速度快了45％ （来自官方数据） ，并且使用的RAM更少。

　　当然，有这些性能优势，也肯定一些限制：

　　仅当只有一个任务可以作为事件的接收者时，才可以使用RTOS任务通知。但是，在大多数实际使用情况下都可以满足此条件，例如中断使执行任务处理的任务中断时，该任务将处理该中断接收的数据。

　　仅在使用RTOS任务通知代替队列的情况下：接收任务可以在“阻塞”状态下等待通知（因此不占用任何CPU时间），而发送任务不能在“阻塞”状态下等待消息。如果发送无法立即完成，则发送完成。

　　5

　　使用方法 使用方法其实很简单，只要你会使用RTOS的队列、信号量，基本看一眼官方例子就能使用。

　　我这里也拿官方例子说明一下：

　　/* main（） 创建的两个任务的原型 */static void prvTask1（ void *pvParameters ）;static void prvTask2（ void

二进制信号量中介队列

免责声明：本网信息来自于互联网，目的在于传递更多信息，并不代表本网赞同其观点。其原创性以及文中陈述文字和内容未经本站证实，对本文以及其中全部或者部分内容、文字的真实性、完整性、及时性本站不作任何保证或承诺，并请自行核实相关内容。本站不承担此类作品侵权行为的直接责任及连带责任。如若本网有任何内容侵犯您的权益，请及时联系我们，本站将会在24小时内处理完毕。