FreeRTOS任务调度

就绪链表有多个，构成链表数组，每个优先级对应一个链表，当Tick中断产生，中断函数将开始调度，即查询链表，从最高优先级开始查。

如果高优先级一直不主动放弃cpu，则低优先级将无法执行，不论是否抢占式。

抢占式和非抢占式。抢占式是直接切换任务，非抢占式是等待Running任务主动放弃，Running任务可能会一直不放弃。可以在FreeRTOISConfig.h配置。

当然，如果高优先级想执行，而低优先级正在执行，如果不是抢占式，则只能等低优先级主动放弃，否则，即使等待的任务优先级更高，也无法执行。

优先级的数量，也可以在FreeRTOISConfig.h配置。

阻塞链表（DelayList）和暂停链表(PendingList)只有一个.

当任务执行了xTaskDelay。则对应任务进入阻塞态，调度器将其放入DelayList，每个Tick中断都会到DelayList检查时间到了没，如果没到就不管，如果到了就放入对应优先级的ReadyList。

依次创建任务1，2，3，优先级都为0，开始调度，运行顺序是1-2-3-1......。因为任务调度函数会自动创建一个空闲任务。导致在prvAddNewTaskToReadyList函数里当前任务指向空闲任务，所以从空闲任务开始运行，而空闲任务函数内又有yeiled礼让，所以空闲任务执行一小段时间就马上引发一次调度，然后就是任务1执行。

如果1，2，3任务优先级不为0，比如都为1，则执行顺序是3-1-2-3......。因为当前任务指向任务3，总结就是，同优先级后创建先执行。

在创建任务的函数里，调用了prvAddNewTaskToReadyList函数，如果新任务优先级大于等于当前任务优先级，则将新任务赋给当前任务。这就是导致上面执行顺序的原因。

空闲任务礼让

看下简化的空闲任务代码，当优先级为0的就绪链表长度大于1，即存在优先级为0的非空闲任务，就礼让，即触发一次调度。当第二次轮到空闲任务，则从taskYIELD下面继续运行，第三次轮到就再礼让，第四次轮到又继续运行。portALLOCATE_SECURE_CONTEXT其实是清理自杀任务的内存。

taskYIELD()是portYIELD()的宏定义，portYIELD()是一个函数体的宏定义。如下，这就是触发任务调度

任务开始与结束必须在Tick中断产生时吗

虽然每个tick中断发生都会任务调度，时间片轮转时任务与任务之间都是以Tick为基本单位，但是任务不一定非要执行满一个Tick，比如调用vTaskDelay主动放弃，可以立即放弃然后另一个任务马上运行，而不需要非要等Tick。再比如当中断产生，正在运行的任务将立即停止，不会等到下一个Tick中断，因为即使是最低优先级的中断，也要高于最高优先级任务。

其实vTaskDelay函数里有触发任务调度。所以任务调度也不非得以Tick为基准，或者说任务调度既能在Tick中断触发，也能通过软件调用触发。

当配置为不抢占时，空闲任务是否礼让的宏已经不起作用，Idel即空闲任务必须礼让，同样的，不抢占的话，时间片轮转的宏也不起作用，时间片只支持不轮转。如下，都在task.c文件内。

portTASK_FUNCTION函数

 xTaskIncrementTick函数

所以，当配置为不抢占时，同优先级的任务，如果运行的任务不放弃执行，则后面的任务永远无法执行。如果正在运行的任务主动调用vTaskDelay放弃，其他任务就会开始运行，而延时时间到了后，那个任务想回来继续，必须要等现在的任务放弃。

注意，可以在未到下一个tick就放弃，然后另一个任务开始运行。

如果两个任务修改同一个全局变量，会有个问题，要知道单核cpu一次只能执行一个任务，程序是以机器码保存在flash的，全局变量也一样，当程序开始运行，cpu从flash取指令，当取到全局变量的定义时，cpu会把这个变量放入内存的静态存储区，当有任务想要修改全局变量，就要从静态存储区读出变量值到cpu内部寄存器，然后运算修改，再写入到静态存储区。

如果任务1刚读出变量值，就发生了tick中断，这时候将保存现场并切换到任务2，然后任务2成功修改值并写入内存，当再次到任务1执行，回复现场，再次计算变量值，问题来了，现在的全局变量值已经被任务2修改了，而任务一还在用着之前读出的旧数据。如何让解决呢，最简单的就是互斥访问，不同时访问一个全局变量。

freertos使用队列实现互斥访问，队列是啥，一种数据结构，一头进一头出，对应这里就是一头写临界资源，一头读临界资源。那如果两个任务都想写呢，有一个操作队列的函数QueueSend()，内部实现了关中断开中断，在某个任务操作临界资源时，先关闭中断，包括Tick中断，当操作完再打开中断，这就是最简单粗暴的互斥访问机制。

使用队列的第二个好处，节省cpu资源

裸机程序。如果通过if判断某个条件，要不停地判断，浪费资源，而FreeRTOS使用队列，当B读队列发现无数据，B将进入休眠即阻塞态，直到A写队列，才唤醒B，这就节省了不少cpu资源。

 关中断实现互斥，环形缓冲区保存数据，链表实现唤醒，链表有两个，当任务A读队列发现无数据，任务A将被放入List For Receive，当任务B写入队列发现已经写满了，则将任务B放入List For Send链表。

使用队列之前必须先创建，创建的方法有两种，一种是静态的，另一种是动态的：

xQueueCreateStatic()
xQueueCreate()
这两个函数本质上都是宏，真正完成队列创建的函数是xQueueGenericCreate()和xQueueGenericCreateStatic()。
 

队列有队列头Queue_t（就是QueueDefinition）和环形缓冲区buffer，信号量是特殊的队列，union里的那个xSemaphore就是作为信号量时用的，环形缓冲区，QueueDefinition里的pcWriteTo和QueuePointers里的pcReadFrom分别指向环形缓冲区写和读位置，是int指针类型，

 在xQueueGenericCreate函数里面，就有关于队列创建的详细情况，包括大小的计算。队列大小=队列头+队列长度*元素大小

 队列写流程，大概就是，一个任务往环形缓冲区写数据，如果缓冲区没满，就写入成功，否则就将自己放入WaitongToSend链表，假设写入成功了。

队列读流程。读队列时，首先关中断，再看是否有数据，如果没有的话，就返回错误或休眠，将自己放入WaitingToReceive链表，并将自己从Read链表移动到Delay链表。如果有数据了，就会唤醒这个任务，即从WaitingToReceive移除，并从Delay链表移动到Ready链表。就可以读数据了。

 xQueueReceive（）函数用于从队列中读取数据，同时读取到的数据会被从队列中移除。xQueueSend是写数据。

 

 

看一下 进入临界区的函数，实际上就是关中断

信号量，其实就是特殊的队列,当然，普通队列获取值是xQueueReceive（普通队列专用，底层也是xQueueGenericReceive），而获取信号量和互斥量都是xQueueGenericReceive，这个是通用的

 信号量获取和释放

xSemaphoreTake，xSemaphoreGive

 如下为创建信号量，第一个参数是最大值，第二个是初始值，里面的队列创建函数，第一个参数是最大数，第二个是缓冲区元素大小，第三个是队列类型。

 队列类型的宏定义如下，有基本队列类型，计数信号量，二值信号量，互斥量，循环互斥量。U表示无符号。

 

互斥量，用于对一个资源的互斥访问，互斥量就是有优先级继承机制的二值信号量

仅仅用信号量会有问题，比如优先级反转问题，如下。

优先级反转，假设有3个高中低优先级任务，低优先级任务先执行，获取到信号量，然后就被中优先级抢占了，中优先级又被高优先级抢占，但高优先级获取信号量失败，进入休眠，然后轮到中优先级执行，如果中优先级一直不放弃，就会一直执行，低优先级因为优先级原因无法执行，高优先级又因为获取信号量失败无法执行，这样高优先级就被卡死了，这就是优先级反转。

解决办法，使用互斥量，优先级继承

高优先级获取互斥量失败就会提升当前互斥量所有者的优先级，这样低优先级就能执行并释放互斥量，并唤醒刚刚的高优先级任务。

 互斥量就是特殊的信号量，获取释放互斥量都是直接使用的信号量的代码，获取信号量就是加锁，释放就是开锁，在释放时，会取消优先级继承，也就是恢复原来的优先级。

事件组

事件组不在是使用的队列的源码，可以看到。里面也有个链表，用在WaitBit失败时，如果愿意等待，就会将当前任务放入xTaskWaitingForBits并且从ReadList移到DelayList，当每次有SetBit时，就会判断是否有满足条件的，然后就会唤醒。

 

事件组的等待和设置函数，xEventGroupWaitBits，xEventGroupSetBits

先看xEventGroupWaitBits

里面和队列不同，不是关中断，而是关闭调度器，队列之所以关闭中断，是因为中断函数内也能操作队列，而事件组不同，所以事件组就只需要关闭调度器。当设置事件组时，会判断是否有能被唤醒的任务，如果有就一次唤醒所有满足条件的任务，而队列只会唤醒一个

 

 

 

为什么事件组不关闭中断呢，因为，虽然中断函数内可以SetBits但他其实是唤醒一个守护任务，真正SetBits的是这个守护任务、

事件组用法

  

任务通知是啥呢

任务通知在FreeRTOS中是一个可选的功能，要使用任务通知的话就需要将宏configUSE_TASK_NOTIFICATIONS定义为1。FreeRTOS的每个任务都有一个32位的通知值，任务控制块中的成员变量ulNotifiedValue就是这个通知值。任务通知是一个事件，假如某个任务通知的接收任务因为等待任务通知而阻塞的话，向这个接收任务发送任务通知以后就会解除这个任务的阻塞状态。也可以更新接收任务的任务通知值，任务通知可以通过如下方法更新接收任务的通知值：

不覆盖接收任务的通知值（如果上次发送给接收任务的通知还没被处理）。
覆盖接收任务的通知值。
更新接收任务通知值的一个或多个bit。
增加接收任务的通知值。
合理、灵活的使用上面这些更改任务通知值的方法可以在一些场合中替代队列、二值信号量、计数型信号量和事件标志组。使用任务通知来实现二值信号量功能的时候，解除任务阻塞的时间比直接使用二值信号量要快45%，并且使用的RAM更少！任务通知的发送使用函数xTaskNotify()或者xTaskNotifyGive() (还有此函数的中断版本）来完成，这个通知值会一直被保存着，直到接收任务调用函数xTaskNotifyWait()或者ulTaskNotifyTake()来获取这个通知值。假如接收任务因为等待任务通知而阻塞的话那么在接收到任务通知以后就会解除阻塞态。任务通知虽然可以提高速度，并且减少RAM的使用，但是任务通知也是有使用限制的：

FreeRTOS的任务通知只能有一个接收任务，其实大多数的应用都是这种情况。
接收任务可以因为接收任务通知而进入阻塞态，但是发送任务不会因为任务通知发送失败而阻塞。
 

参考

留小乙的博客