1236_FreeRTOS官方演示工程的文件介绍

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

大概看了一下这个页面，其实感觉这个页面看下去的意义不大。但是，从另一个角度讲，了解一下历史也是好的，简单快速地看一下吧。

这里开篇其实就说的清楚了，新的示范工程里面其实Full目录是不用了的。留着的目的也只是为了能够让老的一些例程容易构建出来。新的例程全都在Minimal的目录下，而且相关的说明都在代码文件中。

这个文件中测试了队列以及task的一些特性，涉及到的点：队列的阻塞、队列的深度、任务的阻塞、任务的优先级等功能的验证。相关的功能，我之前是测试过的，但是并不在这个文件。之前测试过的功能可能也比较零散，下面的链接就是其中的一个。

旧笔记的链接： 175_FreeRTOS队列的使用_grey_csdn的博客-CSDN博客_freertos 队列有什么用

测试不同的场景，以确保任务不会过早退出Blocked状态。对测试的描述包含在代码本身中。

创建两个在中断驱动串口上操作的任务。必须使用环回连接器，以便接收所有传输的内容。串口不使用任何流控。在标准的9way“D”连接器上，引脚2和3应该连接在一起。这里提到的9way"D"我不是很熟悉，但是给我的感觉可能是DB9的接口。而流控是串口的一种特殊用法。

第一个任务重复地向队列发送一个字符串，每次发送一个字符。串口中断将清空队列并传输字符。在重新发送字符串之前，任务阻塞伪随机周期。

第二个任务阻塞在等待接收字符的队列上。由串口中断程序接收到的字符被发送到队列上以解除任务阻塞，使其准备执行。如果这是最高优先级的任务，它将立即运行，上下文切换发生在中断服务程序结束时。接收字符的任务执行时优先级高于传输字符的任务。这里，传达出来一个关键的知识点：上下文切换的发生时间在中断的ISR结束的时候发生。

有了回环连接器后，一个任务将传输一个字符串，另一个任务将立即接收它。接收任务知道它期望接收的字符串，因此可以检测错误。我对串口的了解不多，但是感觉这个回环模式应该是串口的一个功能特性。有可能是一个自发自收的链接状态。这也可能是前面2、3脚链接的一个进一步的解释。

第三个任务只是用作检查的功能，没有什么特别的地方。

这里用到了一个向ISR发送或者从ISR发出队列信号的功能，本身是一个比较低效的模式，尽量不要用。其实的软件设计中最好是用DMA来实现这样的功能。

计数信号量的一个简单的演示。

第一个测试创建了三个任务：两个计数器任务(一个连续计数，一个有限计数)和一个控制器。三个任务之间共享一个“count”变量。两个计数器任务永远不应该同时处于“就绪”状态。控制器任务与连续计数任务优先级相同，优先级低于连续计数任务。

一个计数器任务无限循环，在每次迭代中递增共享的count变量。为了确保它具有对变量的独占访问权，它在每次递增之前将其优先级提高到控制器任务的优先级之上，在开始下一次迭代之前再次将其降低到初始优先级。从这一段描述应该关注到一个点：FreeRTOS的任务的优先级是可以在运行的过程中修改的，可能这个特性是有别于其他的操作系统的。

另一个计数器任务在其循环的每次迭代中递增共享count变量，直到计数达到0xff的限制—此时它挂起自己。直到控制器任务通过调用vTaskResume()再次使其“就绪”，它才会启动一个新的循环。第二个计数器任务的优先级高于控制器任务，因此不需要担心计数器变量的互斥问题。

控制器任务分为两部分。第一部分控制和监视连续计数任务。当此部分可操作时，有限计数任务将被挂起。同样，第二部分控制和监视有限计数任务。当此部分可操作时，将挂起连续计数任务。

在第一部分中，控制器任务首先获取共享count变量的一个副本。 为了确保count变量上的互斥性，它暂停连续count任务，在获取副本时再次恢复它。 然后，控制器任务休眠一段固定的时间—在此期间，连续计数任务将执行并增加共享变量。 当控制器任务唤醒时，它通过比较共享变量的副本及其当前值来检查连续计数任务是否已经执行。 这一次，为了确保互斥，RTOS调度程序本身通过调用vTaskSuspendAll()被挂起。 这种方式的效率低，也只是为了演示有这样的功能存在，工程实践中不推荐使用。

在固定的迭代次数之后，控制器任务暂停连续计数任务，开始执行第二部分。

在第二部分开始执行时，共享变量被清除为零。然后调用vTaskResume()将有限计数任务从挂起中唤醒。由于该计数器任务的优先级高于控制器任务，因此控制器任务不应该再次运行，直到共享变量的数量达到导致计数器任务挂起自身的限制值。因此，vTaskResume()之后的下一行是对共享变量的检查，以确保一切都符合预期。

第二个测试由两个非常简单的任务组成，它们在RTOS调度程序挂起时发布到队列中。这个测试被添加到第一个测试中没有执行的RTOS调度器的部分。

这个很简单了，只是一个LED的闪烁控制任务。

创建一系列的任务，其中每个任务循环不断执行浮点计算(模拟或实际，取决于目标MCU或者计算机平台)。

所有任务都以空闲优先级运行，不会阻塞或让出调度。这将导致所有任务与空闲任务一起进行时间切片。以空闲优先级运行意味着，当其他任务准备运行或时间片出现时，这些任务将被抢占。通常情况下，抢占会在计算过程中发生，从而对RTOS调度程序的上下文切换机制进行良好的测试——产生意外结果的计算可能是任务上下文发生故障的征兆。

这个的确是第一次接触，算是得到了一个很好的评估理念：如何来判断一个调度的准确性以及OS的健壮性？这个就是一个很好的方案。看到这里，这一页原本无需看的文档看得意义就很大了！但是最后的说明中说了新的测试例程有了更好的测试手段，现在也非常期待去了解一下了。

这两个例子一个是互锁API的调用，另一个是长整型的测试。

通过更加复杂的任务来模拟伪同时的任务，来对操作系统进行压力测试。

这是两个队列功能的测试，第一个没有什么了解的必要了，因为前面有更好的示例。第二个是一个队列数据提取行为的演示。

这是递归互斥锁的一个演示案例。

第一个任务的优先级最高，而且执行递归调用。每次递归期间还有一定的延时存在。因此，这个任务获得了互斥信号之后，执行不玩不会释放。

第二个任务的优先级低一些，它会持续尝试获得互斥信号。但是只有第一个任务释放互斥信号且挂起的时候，这个任务才会执行。

第三个任务其实与第二个类似，但是互斥信号的获取是非阻塞的。但是这个任务就绪后，会出现优先级翻转，本身的优先级会提升到最高。

创建两组任务，同一组任的任务共享一个变量，对该变量的访问由信号量保护。

每个任务开始时都试图获取信号量。在获取信号量时，任务检查以确保受保护的变量有一个期望值。 然后，它将变量清除到零，然后将其计数回期望值，每次增加1。 在每次递增之后，都会检查变量，以确保它包含刚刚设置的值。 当再次到达起始值时，该任务释放信号量，让集合中的其他任务有机会做完全相同的事情。 起始值设置的足够高，以确保在递增循环期间可能发生滴答。

这个用法，其实可以借鉴来保证软件中信号的一致性。

这样，整个官方演示工程涉及到的文件具体设计目的是什么就有了一个大概的了解了。自然，这期间也了解了一点OS本身的测试手段和方法。