FreeRtos——多任务

官方资料整理测试：

多任务和单任务几乎没有差别。只用多创建一个或多个任务，其他地方和单任务时相同。

static void AppTaskCreate(void)
{
    xTaskCreate(vTaskLed1,           /* 任务函数名 */
                "Task Led1",         /* 任务名，字符串形式，方便调试 */
                 512,                /* 栈大小，单位为字，即4个字节 */
                 (void *)&task_led3,  // task_led1-task_led3可以切换   /* 任务形参 */
                 1,                  /* 优先级，数值越大，优先级越高 */
                 &xHandleTaskLED1);  /* 任务句柄 */
                             
    xTaskCreate(
                             vTaskBeep,
                             "Task Beep",
                             512,
                             NULL,
                             2,
                             &xHandleTaskBeep);
}

这里采用一个任务做LED灯闪烁，一个任务做蜂鸣器，可以看到两个任务展现出似乎同时运行的现象。

但是，其中有一个地方需要测试。

我们知道裸机中，优先级设置一样时，会看硬件编号，小的优先级高。

freertos中，优先级数值越大的，优先级越高，那么，要是设置成优先级相同，那是以什么方式运行的呢？这个等到下一章，讲串口调试时我们来验证。

/*2017.6.22*/在官方手册找到了说明。

任务优先级
xTaskCreate() API 函数的参数 uxPriority 为创建的任务赋予了一个初始优先级。这
个侁先级可以在调度器启动后调用 vTaskPrioritySet() API 函数进行修改。
应 用 程 序 在 文 件 FreeRTOSConfig.h 中 设 定 的 编 译 时 配 置 常 量
configMAX_PRIORITIES 的值，即是最多可具有的优先级数目。 FreeRTOS 本身并没
有限定这个常量的最大值，但这个值越大，则内核花销的内存空间就越多。所以总是建
议将此常量设为能够用到的最小值。
对于如何为任务指定优先级， FreeRTOS 并没有强加任何限制。任意数量的任务可
以共享同一个优先级——以保证最大设计弹性。当然，如果需要的话，你也可以为每个
任务指定唯一的优先级(就如同某些调度算法的要求一样)，但这不是强制要求的。
低优先级号表示任务的优先级低，优先级号 0 表示最低优先级。有效的优先级号范
围从 0 到(configMAX_PRIORITES – 1)。

调度器保证总是在所有可运行的任务中选择具有最高优先级的任务，并使其进入运
行态。如果被选中的优先级上具有不止一个任务，调度器会让这些任务轮流执行。这种
行为方式在之前的例子中可以明显看出来。两个测试任务被创建在同一个优先级上，并
且一直是可运行的。所以每个任务都执行一个”时间片”，任务在时间片起始时刻进入运
行态，在时间片结束时刻又退出运行态。  图 3 中 t1 与 t2 之间的时段就等于一个时间片。

 

要能够选择下一个运行的任务，调度器需要在每个时间片的结束时刻运行自己本
身。一个称为心跳(tick，有些地方被称为时钟滴答， 本文中一律称为时钟心跳)中断的
周期性中断用于此目的。时间片的长度通过心跳中断的频率进行设定，心跳中断频率由
FreeRTOSConfig.h 中的编译时配置常量 configTICK_RATE_HZ 进行配置。比如说，
如果 configTICK_RATE_HZ 设为 100(HZ)，则时间片长度为 10ms。可以将图 3 进行
扩展，将调度器本身的执行时间在整个执行流程中体现出来。请参见图 4。
需要说明的是， FreeRTOS API 函数调用中指定的时间总是以心跳中断为单位（通
常的提法为心跳”ticks”)。常量 portTICK_RATE_MS 用于将以心跳为单位的时间值转化
为以毫秒为单位的时间值。有效精度依赖于系统心跳频率。
心跳计数(tick count)值表示的是从调度器启动开始，心跳中断的总数，并假定心跳

计数器不会溢出。用户程序在指定延迟周期时不必考虑心跳计数溢出问题，因为时间连
贯性在内核中进行管理。

调度器总是在可运行的任务中，选择具有最高优级级的任务，并使其进入运行态。
到目前为止的示例程序中，两个任务都创建在相同的优先级上。所以这两个任务轮番进
入和退出运行态。本例将改变例 2 其中一个任务的优先级，看一下倒底会发生什么。现
在第一个任务创建在优先级 1 上，而另一个任务创建在优先级 2 上。创建这两个任务的
代码参见程序清单 10。这两个任务的实现函数没有任何改动，还是通过空循环产生延
迟来周期性打印输出字符串 。

调度器总是选择具有最高优先级的可运行任务来执行。任务 2 的优先级比任务 1
高，并且总是可运行，因此任务 2 是唯一一个一直处于运行态的任务。而任务 1 不可能
进入运行态，所以不可能输出字符串。这种情况我们称为任务 1 的执行时间被任务 2”
饿死(starved)”了。
任务 2 之所以总是可运行，是因为其不会等待任何事情——它要么在空循环里打
转，要么往终端打印字符串。

 

这里显示了为什么不加freertos的延时函数就无法发生轮转。

注意，在优先级设置相同的情况下，不使用事件驱动（例如freertos的延时函数，即阻塞），多任务也是可以轮转的，此时采用的时间轮转片切换任务。

 

/******END*****/

扩充“非运行态”
到目前为止所有用到的示例中，创建的每个任务都只顾不停地处理自己的事情而没
有其它任何事情需要等待——由于它们不需要等待所以总是能够进入运行态。这种”不
停处理”类型的任务限制了其有用性，因为它们只可能被创建在最低优先级上。如果它
们运行在其它任何优先级上，那么比它们优先级更低的任务将永远没有执行的机会。
为了使我们的任务切实有用，我们需要通过某种方式来进行事件驱动。一个事件驱
动任务只会在事件发生后触发后工作(处理)，而在事件没有发生时是不能进入运行态的。
调度器总是选择所有能够进入运行态的任务中具有最高优先级的任务。一个高优先级但
不能够运行的任务意味着不会被调度器选中，而代之以另一个优先级虽然更低但能够运
行的任务。因此，采用事件驱动任务的意义就在于任务可以被创建在许多不同的优先级
上，并且最高优先级任务不会把所有的低优先级任务饿死。

阻塞状态
如果一个任务正在等待某个事件，则称这个任务处于”阻塞态(blocked)”。阻塞态是
非运行态的一个子状态。
任务可以进入阻塞态以等待以下两种不同类型的事件：
1. 定时(时间相关)事件——这类事件可以是延迟到期或是绝对时间到点。比如
说某个任务可以进入阻塞态以延迟 10ms。
2. 同步事件——源于其它任务或中断的事件。比如说，某个任务可以进入阻塞
态以等待队列中有数据到来。同步事件囊括了所有板级范围内的事件类型。
FreeRTOS 的队列，二值信号量，计数信号量，互斥信号量(recursive semaphore,
递归信号量，本文一律称为互斥信号量， 因为其主要用于实现互斥访问)和互斥量都可
以用来实现同步事件。
任务可以在进入阻塞态以等待同步事件时指定一个等待超时时间，这样可以有效地
实现阻塞状态下同时等待两种类型的事件。比如说，某个任务可以等待队列中有数据到
来，但最多只等 10ms。如果 10ms 内有数据到来，或是 10ms 过去了还没有数据到来，
这两种情况下该任务都将退出阻塞态。
挂起状态
“挂起(suspended)”也是非运行状态的子状态。处于挂起状态的任务对调度器而言
是不可见的。让一个任务进入挂起状态的唯一办法就是调用 vTaskSuspend() API 函数；
而 把 一 个 挂 起 状 态 的 任 务 唤 醒 的 唯 一 途 径 就 是 调 用 vTaskResume() 或
vTaskResumeFromISR() API 函数。大多数应用程序中都不会用到挂起状态。
就绪状态
如果任务处于非运行状态，但既没有阻塞也没有挂起，则这个任务处于就绪(ready，
准备或就绪)状态。处于就绪态的任务能够被运行，但只是”准备(ready)”运行，而当前
尚未运行。

 

通过调用 vTaskDelay() API 函数来代替空循环，对这种”不良行为”
进行纠正。 vTaskDelay()的函数原型见程序清单 11，而新的任务实现见程序清单 12。

 

 

 有了这个函数之后，就可以在优先级不同的任务间切换了。

其中idle是空闲任务，因为首字母大写了，有点误导成小写l。

vTaskDelayUntil() API 函数
vTaskDelayUntil()类似于 vTaskDelay()。和范例中演示的一样，函数 vTaskDelay()
的参数用来指定任务在调用 vTaskDelay()到切出阻塞态整个过程包含多少个心跳周期。
任务保持在阻塞态的时间量由 vTaskDelay()的入口参数指定，但任务离开阻塞态的时刻
实际上是相对于 vTaskDelay()被调用那一刻的。 vTaskDelayUntil()的参数就是用来指定
任务离开阻塞态进入就绪态那一刻的精确心跳计数值。 API 函数 vTaskDelayUntil()可以
用于实现一个固定执行周期的需求(当你需要让你的任务以固定频率周期性执行的时
候)。由于调用此函数的任务解除阻塞的时间是绝对时刻，比起相对于调用时刻的相对
时间更精确(即比调用 vTaskDelay()可以实现更精确的周期性)。
void vTaskDelayUntil( portTickType * pxPreviousWakeTime, portTickType xTimeIncrement );
程序清单 13 vTaskDelayUntil() API 函数原型

 

 上个例子中的两个任务是周期性任务，但是使用 vTaskDelay()无法保证它们具有固定的
执行频率，因为这两个任务退出阻塞态的时刻相对于调用 vTaskDelay()的时刻。通过调
用 vTaskDelayUntil()代替 vTaskDelay()，把这两个任务进行转换，以解决这个潜在的问
题。

 

void vTaskFunction( void *pvParameters )
{
char *pcTaskName;
portTickType xLastWakeTime;
/* The string to print out is passed in via the parameter. Cast this to a
character pointer. */
pcTaskName = ( char * ) pvParameters;
/* 变量xLastWakeTime需要被初始化为当前心跳计数值。说明一下，这是该变量唯一一次被显式赋值。之后，
xLastWakeTime将在函数vTaskDelayUntil()中自动更新。 */
xLastWakeTime = xTaskGetTickCount();
/* As per most tasks, this task is implemented in an infinite loop. */
for( ;; )
{
/* Print out the name of this task. */
vPrintString( pcTaskName );
/* 本任务将精确的以250毫秒为周期执行。同vTaskDelay()函数一样，时间值是以心跳周期为单位的，
可以使用常量portTICK_RATE_MS将毫秒转换为心跳周期。变量xLastWakeTime会在
vTaskDelayUntil()中自动更新，因此不需要应用程序进行显示更新。 */
vTaskDelayUntil( &xLastWakeTime, ( 250 / portTICK_RATE_MS ) );
}
}
程序清单 14 使用 vTaskDelayUntil()实现示例任务