目录
四、机制
4.1任务优先级
4.1.1高优先级抢占低优先级
4.1.2时间片
4.2任务调度器
4.3临界段的保护
4.4空闲任务与阻塞延时
4.5任务延时列表
4.6消息队列
4.6.1消息队列的基本概念
4.6.2消息队列的运作机制
4.7信号量
4.7.1信号量的概念
4.7.2二值信号量的概念
4.7.3计数信号量的概念
4.8互斥量
4.8.1互斥量的基本概念
4.8.2互斥量的优先级继承机制
4.9事件
4.9.1事件的基本概念
4.9.2事件的运作机制
4.10 软件计数器
4.11 任务通知
4.11.1任务通知的基本概念
4.11.2任务通知的运作机制
4.12 内存管理
4.13 中断管理
4.14 CPU使用率统计
FreeRTOS 中提供的任务调度器是基于优先级的全抢占式调度：在系统中除了中断处理函数、调度器上锁部分的代码和禁止中断的代码是不可抢占的之外，系统的其他部分都是可以抢占的。任务优先级高低决定了任务的执行先后。
系统理论上可以支持无数个优先级(0 ～ N，优先级数值越小的任务优先级越低， 0 为最低优先级，分配给空闲任务使用，一般不建议用户来使用这个优先级。假如使能了 configUSE_PORT_OPTIMISED_TASK_SELECTION 这个宏（在 FreeRTOSConfig.h 文件定义）， 一般强制限定最大可用优先级数目为 32。在一些资源比较紧张的系统中， 可以根据实际情况选择只支持 8 个或 32 个优先级的系统配置。
在系统中，当有比当前任务优先级更高的任务就绪时，当前任务将立刻被换出，高优先级任务抢占处理器运行。当高优先级任务执行完之后，再从就绪列表中选择最高优先级任务继续执行，若果就绪列表中最高优先级的任务是之前那个被打断的任务，则改任务会接着之前执行到的地方接着执行。
如果宏configUSE_TIME_SLICING 定义为 1（将时间片功能打开），处于就绪态的多个相同优先级任务将会以时间片切换的方式共享处理器。
任务创建好之后，我们需要把任务添加到就绪列表里面， 表示任务已经就绪，系统随时可以调度。
调度器是操作系统的核心，其主要功能就是实现任务的切换，即从就绪列表里面找到优先级最高的任务，然后去执行该任务。从代码上来看，调度器无非也就是由几个全局变量和一些可以实现任务切换的函数组成，全部都在 task.c 文件中实现。
临界段用一句话概括就是一段在执行的时候不能被中断的代码段。 在 FreeRTOS 里面，这个临界段最常出现的就是对全局变量的操作， 全局变量就好像是一个枪把子，谁都可以对他开枪，但是我开枪的时候，你就不能开枪，否则就不知道是谁命中了靶子。
那么什么情况下临界段会被打断？一个是系统调度，还有一个就是外部中断。在FreeRTOS，系统调度，最终也是产生 PendSV 中断，在 PendSV Handler 里面实现任务的切换，所以还是可以归结为中断。 既然这样， reeRTOS 对临界段的保护最终还是回到对中断的开和关的控制。
为了快速地开关中断， Cortex-M 内核专门设置了一条 CPS 指令，有 4 种用法
PRIMASK 和 FAULTMAST 是 Cortex-M 内核 里面三个中断屏蔽寄存器中的两个，还有一个是 BASEPRI，有关这三个寄存器的详细用法见表格
使用 RTOS 的很大优势就是榨干 CPU 的性能，永远不能让它闲着， 任务如果需要延时也就不能再让 CPU 空等来实现延时的效果。 RTOS 中的延时叫阻塞延时，即任务需要延时的时候， 任务会放弃 CPU 的使用权， CPU 可以去干其它的事情，当任务延时时间到，重新获取 CPU 使用权， 任务继续运行，这样就充分地利用了 CPU 的资源，而不是干等着。
当任务需要延时，进入阻塞状态，那 CPU 又去干什么事情了？如果没有其它任务可以运行， RTOS 都会为 CPU 创建一个空闲任务，这个时候 CPU 就运行空闲任务。 在FreeRTOS 中，空闲任务是系统在【启动调度器】 的时候创建的优先级最低的任务，空闲任务主体主要是做一些系统内存的清理工作。在实际应用中，当系统进入空闲任务的时候， 可在空闲任务中让单片机进入休眠或者低功耗等操作。
在 FreeRTOS 中， 有一个任务延时列表（实际上有两个，为了方便讲解原理，我们假装合并为一个，其实两个的作用是一样的） ，当任务需要延时的时候， 则先将任务挂起，即先将任务从就绪列表删除，然后插入到任务延时列表，同时更新下一个任务的解锁时刻变量： xNextTaskUnblockTime 的值
xNextTaskUnblockTime 的值等于系统时基计数器的值 xTickCount 加上任务需要延时的值 xTicksToDelay。 当系统时基计数器 xTickCount 的值与 xNextTaskUnblockTime 相等时，就表示有任务延时到期了，需要将该任务就绪。 与 RT-Thread 和 μC/OS 在解锁延时任务时要扫描定时器列表这种时间不确定性的方法相比， FreeRTOS 这个 xNextTaskUnblockTime全局变量设计的非常巧妙。
队列又称消息队列，是一种常用于任务间通信的数据结构， 队列可以在任务与任务间、中断和任务间传递信息，实现了任务接收来自其他任务或中断的不固定长度的消息，任务能够从队列里面读取消息，当队列中的消息是空时，读取消息的任务将被阻塞，用户还可以指定阻塞的任务时间 xTicksToWait，在这段时间中，如果队列为空，该任务将保持阻塞状态以等待队列数据有效。 当队列中有新消息时， 被阻塞的任务会被唤醒并处理新消息；当等待的时间超过了指定的阻塞时间，即使队列中尚无有效数据，任务也会自动从阻塞态转为就绪态。 消息队列是一种异步的通信方式。
通过消息队列服务，任务或中断服务例程可以将一条或多条消息放入消息队列中。同样，一个或多个任务可以从消息队列中获得消息。当有多个消息发送到消息队列时，通常是将先进入消息队列的消息先传给任务，也就是说，任务先得到的是最先进入消息队列的消息，即先进先出原则（FIFO），但是也支持后进先出原则（LIFO） 。
FreeRTOS 中使用队列数据结构实现任务异步通信工作，具有如下特性：
1、 消息支持先进先出方式排队，支持异步读写工作方式。
2、读写队列均支持超时机制。
3、 消息支持后进先出方式排队， 往队首发送消息（LIFO） 。
4、可以允许不同长度（不超过队列节点最大值）的任意类型消息。
5、一个任务能够从任意一个消息队列接收和发送消息。
6、多个任务能够从同一个消息队列接收和发送消息。
7、当队列使用结束后，可以通过删除队列函数进行删除
创建消息队列时 FreeRTOS 会先给消息队列分配一块内存空间，这块内存的大小等于消息队列控制块大小加上（单个消息空间大小与消息队列长度的乘积） ，接着再初始化消息队列，此时消息队列为空。 FreeRTOS 的消息队列控制块由多个元素组成，当消息队列被创建时，系统会为控制块分配对应的内存空间，用于保存消息队列的一些信息如消息的存储位置，头指针 pcHead、尾指针 pcTail、消息大小 uxItemSize 以及队列长度 uxLength 等。同时每个消息队列都与消息空间在同一段连续的内存空间中，在创建成功的时候，这些内存就被占用了，只有删除了消息队列的时候，这段内存才会被释放掉，创建成功的时候就已经分配好每个消息空间与消息队列的容量，无法更改，每个消息空间可以存放不大于消息大小 uxItemSize 的任意类型的数据， 所有消息队列中的消息空间总数即是消息队列的长度，这个长度可在消息队列创建时指定。
任务或者中断服务程序都可以给消息队列发送消息， 当发送消息时， 如果队列未满或者允许覆盖入队， FreeRTOS 会将消息拷贝到消息队列队尾，否则，会根据用户指定的阻塞超时时间进行阻塞，在这段时间中，如果队列一直不允许入队，该任务将保持阻塞状态以等待队列允许入队。当其它任务从其等待的队列中读取入了数据（队列未满），该任务将自动由阻塞态转移为就绪态。当等待的时间超过了指定的阻塞时间，即使队列中还不允许
入队，任务也会自动从阻塞态转移为就绪态，此时发送消息的任务或者中断程序会收到一个错误码 errQUEUE_FULL。
发送紧急消息的过程与发送消息几乎一样，唯一的不同是，当发送紧急消息时， 发送的位置是消息队列队头而非队尾，这样，接收者就能够优先接收到紧急消息，从而及时进行消息处理。
当某个任务试图读一个队列时，其可以指定一个阻塞超时时间。在这段时间中，如果队列为空，该任务将保持阻塞状态以等待队列数据有效。当其它任务或中断服务程序往其等待的队列中写入了数据，该任务将自动由阻塞态转移为就绪态。当等待的时间超过了指定的阻塞时间，即使队列中尚无有效数据，任务也会自动从阻塞态转移为就绪态。当消息队列不再被使用时，应该删除它以释放系统资源，一旦操作完成，消息队列将被永久性的删除
信号量（Semaphore）是一种实现任务间通信的机制，可以实现任务之间同步或临界资源的互斥访问， 常用于协助一组相互竞争的任务来访问临界资源。在多任务系统中，各任务之间需要同步或互斥实现临界资源的保护，信号量功能可以为用户提供这方面的支持。
抽象的来讲，信号量是一个非负整数，所有获取它的任务都会将该整数减一（获取它当然是为了使用资源），当该整数值为零时，所有试图获取它的任务都将处于阻塞状态。通常一个信号量的计数值用于对应有效的资源数，表示剩下的可被占用的互斥资源数。
其值的含义分两种情况：
0： 表示没有积累下来的释放信号量操作，且有可能有在此信号量上阻塞的任务。
正值，表示有一个或多个释放信号量操作。
信号量资源被获取了，信号量值就是 0，信号量资源被释放，信号量值就是 1，把这种只有 0 和 1 两种情况的信号量称之为二值信号量。
在多任务系统中，我们经常会使用这个二值信号量，比如，某个任务需要等待一个标记，那么任务可以在轮询中查询这个标记有没有被置位， 但是这样子做，就会很消耗 CPU资源并且妨碍其它任务执行， 更好的做法是任务的大部分时间处于阻塞状态（允许其它任务执行），直到某些事件发生该任务才被唤醒去执行。可以使用二进制信号量实现这种同步， 当任务取信号量时，因为此时尚未发生特定事件，信号量为空，任务会进入阻塞状态；当事件的条件满足后，任务/中断便会释放信号量， 告知任务这个事件发生了， 任务取得信号量便被唤醒去执行对应的操作，任务执行完毕并不需要归还信号量， 这样子的 CPU 的效率可以大大提高， 而且实时响应也是最快。
计数信号量可以用于资源管理，允许多个任务获取信号量访问共享资源，但会限制任务的最大数目。访问的任务数达到可支持的最大数目时，会阻塞其他试图获取该信号量的任务，直到有任务释放了信号量。这就是计数型信号量的运作机制，虽然计数信号量允许多个任务访问同一个资源，但是也有限定，比如某个资源限定只能有 3 个任务访问，那么第 4 个任务访问的时候，会因为获取不到信号量而进入阻塞，等到有任务（比如任务 1）释放掉该资源的时候，第 4 个任务才能获取到信号量从而进行资源的访问，
其运作的机制具体见图
互斥量又称互斥信号量（本质是信号量），是一种特殊的二值信号量，它和信号量不同的是，它支持互斥量所有权、递归访问以及防止优先级翻转的特性，用于实现对临界资源的独占式处理。任意时刻互斥量的状态只有两种，开锁或闭锁。当互斥量被任务持有时，该互斥量处于闭锁状态，这个任务获得互斥量的所有权。当该任务释放这个互斥量时，该互斥量处于开锁状态， 任务失去该互斥量的所有权。当一个任务持有互斥量时，其他任务将不能再对该互斥量进行开锁或持有。 持有该互斥量的任务也能够再次获得这个锁而不被挂起，这就是递归访问，也就是递归互斥量的特性，这个特性与一般的信号量有很大的不同，在信号量中，由于已经不存在可用的信号量， 任务递归获取信号量时会发生主动挂起任务最终形成死锁。
在 FreeRTOS 操作系统中为了降低优先级翻转问题利用了优先级继承算法。优先级继承算法是指，暂时提高某个占有某种资源的低优先级任务的优先级，使之与在所有等待该资源的任务中优先级最高那个任务的优先级相等，而当这个低优先级任务执行完毕释放该资源时，优先级重新回到初始设定值。因此，继承优先级的任务避免了系统资源被任何中间优先级的任务抢占。
互斥量与二值信号量最大的不同是：互斥量具有优先级继承机制，而信号量没有。也就是说，某个临界资源受到一个互斥量保护，如果这个资源正在被一个低优先级任务使用，那么此时的互斥量是闭锁状态，也代表了没有任务能申请到这个互斥量，如果此时一个高优先级任务想要对这个资源进行访问，去申请这个互斥量，那么高优先级任务会因为申请不到互斥量而进入阻塞态，那么系统会将现在持有该互斥量的任务的优先级临时提升到与高优先级任务的优先级相同，这个优先级提升的过程叫做优先级继承。这个优先级继承机制确保高优先级任务进入阻塞状态的时间尽可能短，以及将已经出现的“优先级翻转”危害降低到最小。
事件是一种实现任务间通信的机制，主要用于实现多任务间的同步，但事件通信只能是事件类型的通信，无数据传输。与信号量不同的是，它可以实现一对多，多对多的同步。即一个任务可以等待多个事件的发生：可以是任意一个事件发生时唤醒任务进行事件处理；也可以是几个事件都发生后才唤醒任务进行事件处理。同样，也可以是多个任务同步多个事件。
FreeRTOS 提供的事件具有如下特点：
事件只与任务相关联，事件相互独立，一个 32 位的事件集合（EventBits_t 类型的变量， 实际可用与表示事件的只有 24 位），用于标识该任务发生的事件类型，其中每一位表示一种事件类型（0 表示该事件类型未发生、 1 表示该事件类型已经发生），一共 24 种事件类型。
事件仅用于同步，不提供数据传输功能。
事件无排队性，即多次向任务设置同一事件(如果任务还未来得及读走)， 等效于只设置一次。
允许多个任务对同一事件进行读写操作。
支持事件等待超时机制。
接收事件时，可以根据感兴趣的参事件类型接收事件的单个或者多个事件类型。事件接收成功后，必须使用 xClearOnExit 选项来清除已接收到的事件类型，否则不会清除已接收 到的 事件 ，这样 就需 要用 户显 式清除 事件位。 用户可以自定义通过传入参数xWaitForAllBits 选择读取模式，是等待所有感兴趣的事件还是等待感兴趣的任意一个事件。
设置事件时，对指定事件写入指定的事件类型，设置事件集合的对应事件位为 1，可以一次同时写多个事件类型， 设置事件成功可能会触发任务调度。
清除事件时，根据入参数事件句柄和待清除的事件类型，对事件对应位进行清 0 操作。
事件不与任务相关联，事件相互独立。
定时器，是指从指定的时刻开始，经过一个指定时间，然后触发一个超时事件，用户可以自定义定时器的周期与频率。类似生活中的闹钟，我们可以设置闹钟每天什么时候响，还能设置响的次数，是响一次还是每天都响。
定时器有硬件定时器和软件定时器之分：
硬件定时器是芯片本身提供的定时功能。一般是由外部晶振提供给芯片输入时钟，芯片向软件模块提供一组配置寄存器，接受控制输入，到达设定时间值后芯片中断控制器产生时钟中断。硬件定时器的精度一般很高，可以达到纳秒级别，并且是中断触发方式。
软件定时器，软件定时器是由操作系统提供的一类系统接口，它构建在硬件定时器基础之上，使系统能够提供不受硬件定时器资源限制的定时器服务，它实现的功能与硬件定时器也是类似的。使用硬件定时器时，每次在定时时间到达之后就会自动触发一个中断，用户在中断中处理信息；而使用软件定时器时，需要我们在创建软件定时器时指定时间到达后要调用的函数（也称超时函数/回调函数，为了统一，下文均用回调函数描述），在回调函数中处理信息。
一般系统利用 SysTick 作为软件定时器的基础时钟， 软件定时器的回调函数类似硬件的中断服务函数，所以， 回调函数也要快进快出，而且回调函数中不能有任何阻塞任务运行的情况
FreeRTOS 从 V8.2.0 版本开始提供任务通知这个功能，每个任务都有一个 32 位的通知值，在大多数情况下，任务通知可以替代二值信号量、计数信号量、事件组， 也可以替代长度为 1 的队列（可以保存一个 32 位整数或指针值） 。
相对于以前使用 FreeRTOS 内核通信的资源，必须创建队列、二进制信号量、计数信号量或事件组的情况，使用任务通知显然更灵活。 按照 FreeRTOS 官方的说法，使用任务通知比通过信号量等 ICP 通信方式解除阻塞的任务要快 45%，并且更加省 RAM 内存空间（使用 GCC 编译器， -o2 优化级别） ，任务通知的使用无需创建队列。 想要使用任务通知，必须将 FreeRTOSConfig.h 中的宏定义 configUSE_TASK_NOTIFICATIONS 设置为 1，其实FreeRTOS 默认是为 1 的， 所以任务通知是默认使能的。
FreeRTOS 提供以下几种方式发送通知给任务 ：
发送通知给任务， 如果有通知未读，不覆盖通知值。
发送通知给任务，直接覆盖通知值。
发送通知给任务，设置通知值的一个或者多个位，可以当做事件组来使用。
发送通知给任务，递增通知值，可以当做计数信号量使用。
通过对以上任务通知方式的合理使用，可以在一定场合下替代 FreeRTOS 的信号量，队列、事件组等。
当然， 凡是都有利弊，不然的话 FreeRTOS 还要内核的 IPC 通信机制干嘛，
消息通知虽然处理更快， RAM 开销更小，但也有以下限制 ：
只能有一个任务接收通知消息， 因为必须指定接收通知的任务。。
只有等待通知的任务可以被阻塞， 发送通知的任务，在任何情况下都不会因为发送失败而进入阻塞态。
顾名思义，任务通知是属于任务中附带的资源， 所以在任务被创建的时候，任务通知也被初始化的， 而在分析队列和信号量的章节中，我们知道在使用队列、信号量前，必须先创建队列和信号量，目的是为了创建队列数据结构。比如使用 xQueueCreate()函数创建队列，用 xSemaphoreCreateBinary()函数创建二值信号量等等。再来看任务通知，由于任务通知的数据结构包含在任务控制块中，只要任务存在，任务通知数据结构就已经创建完毕，可以直接使用， 所以使用的时候很是方便。
在计算系统中，变量、中间数据一般存放在系统存储空间中，只有在实际使用时才将它们从存储空间调入到中央处理器内部进行运算。通常存储空间可以分为两种：内部存储空间和外部存储空间。内部存储空间访问速度比较快，能够按照变量地址随机地访问，也就是我们通常所说的 RAM（随机存储器），或电脑的内存；而外部存储空间内所保存的内容相对来说比较固定，即使掉电后数据也不会丢失，可以把它理解为电脑的硬盘。
FreeRTOS 操作系统将内核与内存管理分开实现，操作系统内核仅规定了必要的内存管理函数原型，而不关心这些内存管理函数是如何实现的，所以在 FreeRTOS 中提供了多种内存分配算法（分配策略），但是上层接（API）却是统一的。这样做可以增加系统的灵活性： 用户可以选择对自己更有利的内存管理策略，在不同的应用场合使用不同的内存分配策略。
在嵌入式程序设计中内存分配应该是根据所设计系统的特点来决定选择使用动态内存分配还是静态内存分配算法，一些可靠性要求非常高的系统应选择使用静态的，而普通的业务系统可以使用动态来提高内存使用效率。静态可以保证设备的可靠性但是需要考虑内存上限，内存使用效率低，而动态则是相反。
这里我们一般使用heap_4.c
改方案具有以下特点：
1、可用于重复删除任务、队列、信号量、互斥量等的应用程序
2、 可用于分配和释放随机字节内存的应用程序， 但并不像 heap2.c 那样产生严重的内存碎片。
3、 具有不确定性，但是效率比标准 C 库中的 malloc 函数高得多。
操作系统的中断在某些时候会有适当的中断延迟，因此调用中断屏蔽函数进入临界段的时候，也需快进快出。 当然 FreeRTOS 也能允许一些高优先级的中断不被屏蔽掉，能够及时做出响应，不过这些中断就不受系统管理，
也不允许调用 FreeRTOS 中与中断相关的任何 API 函数接口。
FreeRTOS 的中断管理支持：
开/关中断。
恢复中断。
中断使能。
中断屏蔽。
可选择系统管理的中断优先级。
概念：PU 使用率其实就是系统运行的程序占用的 CPU 资源，表示机器在某段时间程序运行的情况，如果这段时间中，程序一直在占用 CPU 的使用权，那么可以人为 CPU 的利用率是 100%。 CPU 的利用率越高，说明机器在这个时间上运行了很多程序，反之较少。利用率的高低与 CPU 强弱有直接关系，就像一段一模一样的程序，如果使用运算速度很慢的CPU，它可能要运行 1000ms，而使用很运算速度很快的 CPU 可能只需要 10ms，那么在1000ms 这段时间中，前者的 CPU 利用率就是 100%，而后者的 CPU 利用率只有 1%，因为1000ms 内前者都在使用 CPU 做运算，而后者只使用 10ms 的时间做运算，剩下的时间CPU 可以做其他事情。
作用：个系统设计的好坏，可以使用 CPU 使用率来衡量，一个好的系统必然是能完美响应急需的处理，并且系统的资源不会过于浪费（性价比高）。举个例子，假设一个系统的CPU 利用率经常在 90%~100%徘徊，那么系统就很少有空闲的时候，这时候突然有一些事情急需 CPU 的处理，但是此时 CPU 都很可能被其他任务在占用了，那么这个紧急事件就有可能无法被相应，即使能被相应，那么占用 CPU 的任务又处于等待状态，这种系统就是不够完美的，因为资源处理得太过于紧迫；反过来，假如 CPU 的利用率在 1%以下，那么我们就可以认为这种产品的资源过于浪费，搞一个那么好的 CPU 去干着没啥意义的活（大部分时间处于空闲状态），使用，作为产品的设计，既不能让资源过于浪费，也不能让资源过于紧迫，这种设计才是完美的，在需要的时候能及时处理完突发事件，而且资源也不会过剩，性价比更高。
FreeRTOS 是使用一个外部的变量进行统计时间的，并且消耗一个高精度的定时器，其用于定时的精度是系统时钟节拍的 10-20 倍，比如当前系统时钟节拍是 1000HZ，那么定时器的计数节拍就要是 10000-20000HZ。而且 FreeRTOS 进行 CPU 利用率统计的时候，也有一定缺陷，因为它没有对进行 CPU 利用率统计时间的变量做溢出保护， 我们使用的是 32 位变量来系统运行的时间计数值，而按 20000HZ 的中断频率计算，每进入一中断就是 50us，变量加一，最大支持计数时间： 2^32 * 50us / 3600s =59.6 分钟， 运行时间超过了 59.6 分钟后统计的结果将不准确，除此之外整个系统一直响应定时器 50us 一次的中断会比较影响系统的性能
