Projectsauron 的博客

FreeRTOS 本质上就是有很多的 List 组成，所以学习之前最好要对 FreeRTOS 中的链表要有所了解，可以参考：FreeRTOS 列表 List 源码解析源码都在 task.c 中一、基本结构和变量1、TCB_t首先来看一下一个任务的结构：typedef struct tskTaskControlBlock {

heap_1.c所实现的内存管理方法十分简单，其可以使用函数来申请内存，一旦申请成功了，便无法被释放。其实现大致可以用一句话概括，在堆空间剩余时，按需分割出内存，并记录已用的内存大小。heap_1.c使用的内存管理算法虽然简单，但对于许多嵌入式应用场景是适用且有效的。与heap_1.c不同，heap_2.c允许使用函数来释放申请的内存，其算法原理是将空闲堆分为若干个大小不等的内存块，并将其按大小排序，使用单向链表连接起来。申请内存时，便从这些链表中寻找最小可满足申请需求的内存块进行分配。

在一文中，我简单地叙述了FreeRTOS中队列的工作机制和基本使用。这一节我将依据的源码深入地去探究队列是如何实现的。学好队列对我们后续学习信号量等知识的时候有很大的帮助。

FreeRTOS 使用的链表结构是环形的双向链表，而关于链表节点的数据结构都在list.h中定义。

的时刻是 tX，定时器的周期是 n，那么在 tX+n 时刻定时器的回调函数被调用。定时器的回调函数是在守护任务中被调用的，守护任务不是专为某个定时器服务的，它还要处理其他定时器。能否及时处理定时器的命令、能否及时执行定时器的回调函数，严重依赖于守护任务的优先级。定时器的很多 API 函数，都是通过发送"命令"到命令队列，由守护任务来实现。的时刻是 tX，定时器的周期是 n，那么 tX+n 就是重新确定的超时时间。我们可以指定一个超时时间。函数的时间 tX，新的周期是 n，则 tX+n 就是新的超时时间。

按照 FreeRTOS 官方的说法，使用任务通知比通过信号量等 ICP 通信方式解除阻塞的任务要快 45%，并且更加省 RAM 内存空间（使用 GCC 编译器，-o2 优化级别），任务通知的使用无需创建队列。从 V8.2.0 版本开始提供任务通知这个功能，每个任务都有 一个 32 位 的通知值，在大多数情况下，任务通知可以 替代二值信号量、计数信号量、事件组，也可以替代长度为 1 的队列（可以保存一个 32 位整数或指针值）。默认是为 1 的，所以任务通知是默认使能的。的信号量，队列、事件组等。

当期望的时间发生时，这个状态就叫"unblock condition"，非阻塞条件，或称为"非阻塞条件成立"；来等待事件，可以等待某一位、某些位中的任意一个，也可以等待多位；函数不是直接去设置事件组，而是给一个 FreeRTOS 后台任务发送队列数据，由这个任务来设置事件组。事件组用一个整数来表示，其中的高 8 位留给内核使用，只能用其他的位来表示事件。有一个或多个任务在等待事件，如果这些事件符合这些任务的期望，那么任务还会被唤醒。但是设置事件组时，有可能导致多个任务被唤醒，这会带来很大的不确定性。

当该任务释放这个互斥量时，该互斥量处于开锁状态，任务失去该互斥量的所有权。用互斥量处理不同任务对临界资源的同步访问时，任务想要获得互斥量才能进行资源访问，如果一旦有任务成功获得了互斥量，则互斥量立即变为闭锁状态，此时其他任务会因为获取不到互斥量而不能访问这个资源，任务会根据用户自定义的等待时间进行等待，直到互斥量被持有的任务释放后，其他任务才能获取互斥量从而得以访问该临界资源，此时互斥量再次上锁，如此一来就可以确保每个时刻只有一个任务正在访问这个临界资源，保证了临界资源操作的安全性。

信号量（Semaphore）是一种实现任务间通信的机制，可以实现任务之间同步或临界资源的互斥访问，其实信号量主要的功能就是实现任务之间的同步与互斥，实现的方式主要就是依靠队列(信号量是特殊的队列)的任务阻塞机制。

队列通常是一个先入先出（FIFO）的缓冲区，即数据在队列末尾（tail）被写入，在队列前部（head）移出。下图展示了数据被写入和移出作为 FIFO 使用的队列。也可以写入队列的前端，并覆盖已位于队列前端的数据。

要注意的是，函数内部，尽量使用局部变量。因为每个任务都有自己的栈，每个任务运行这个函数时，任务 A 的局部变量放在任务 A 的栈里、任务 B 的局部变量放在任务 B 的栈里。不同任务的局部变量，有自己的副本。函数使用全局变量、静态变量的话，只有一个副本：多个任务使用的是同一个副本。/* 对于不同的任务，局部变量放在任务的栈里，有各自的副本 *//* 任务函数通常实现为一个无限循环 */for(;;/* 任务的代码 *//* 如果程序从循环中退出，一定要使用 vTaskDelete 删除自己。

`FreeRTOS` 提供了几种堆管理方案， 其复杂性和功能各不相同。 你也可以提供自己的堆实现， 甚至同时使用两个堆实现。 同时使用两个堆实现 允许将任务堆栈和其他 `FreeRTOS` 对象放置在 内部 RAM 中，并将应用程序数据放置在较慢的外部 RAM 中。

FreeRTOS 的命名规约非常独特，假若缺乏事先的了解，研读其源代码将使人感到困惑不解。然而，一旦熟悉了其命名规约，阅读就变得十分轻松了。