URL: http://www.eefocus.com/sensorwireless/blog/08-03/144457_c9bd6.html
摘要:FreeRTOS是一个源码公开的免费的嵌入式实时操作系统，通过研究其内核可以更好地理解嵌入式操作系统的实现原理.本文主要阐述FreeRTOS系统中的任务调度机制、时间管理机制、任务管理机制以及内存分配策略的实现原理，并指出FreeRTOS在应用中的优缺点。
FreeRTOS定义就绪任务链表数组为xList pxReady—TasksLists[portMAX_PRIORITIES]。其中portMAX_PRIORITIES为系统定义的最大优先级。若想使优先级为n的任务进入就绪态，需要把此任务对应的TCB中的结点xGenericListltem插入到链表pxReadyTasksLiStS[n]中，还要把xGenericListItem中的pvContainer指向pxReadyTasksLists[n]方可实现。
当进行任务调度时，调度算法首先实现优先级调度。系统按照优先级从高到低的顺序从就绪任务链表数组中寻找usNumberOfItems第一个不为0的优先级，此优先级即为当前最高就绪优先级，据此实现优先级调度。若此优先级下只有一个就绪任务，则此就绪任务进入运行态；若此优先级下有多个就绪任务，则需采用轮换调度算法实现多任务轮流执行。
若在优先级n下执行轮换调度算法，系统先通过执行(pxReadyTasksLists[n])→pxIndex=( pxReadyTasks-Lists[n ]) → pxlndex→pxNext语句得到当前结点所指向的下一个结点，再通过此结点的pvOwner指针得到对应的任务控制块，最后使此任务控制块对应的任务进入运行态。由此可见，在FreeRTOS中，相同优先级任务之间的切换时间为一个时钟节拍周期。
以图1为例，设系统的最大任务数为pottMAX_PRIORITIES，在某一时刻进行任务调度时，得到pxReadyTasksLists[i]．usNumberOfItems=O(i=2...portMAX_PRIORITIES)以及pxReadyTasksLists[1]。usNumberOfItems=3。由此内核可知当前最高就绪优先级为l，且此优先级下已有三个任务已进入就绪态．由于最高就绪优先级下有多个就绪任务，系统需执行轮换调度算法实现任务切换；通过指针pxlndex可知任务l为当前任务，而任务l的pxNext结点指向任务2，因此系统把pxIndex指向任务2并执行任务2来实现任务调度。当下一个时钟节拍到来时，若最高就绪优先级仍为1，由图可见，系统会把pxIndex指向任务3并执行任务3。
图1 任务调度示意
为了加快任务调度的速度，FrecRTOS通过变量ucTopReadyPriotity跟踪当前就绪的最高优先级。当把一个任务加入就绪链表时，如果此任务的优先级高于ucTopReadyPriority，则把这个任务的优先级赋予ucTopReadyPriority。这样当进行优先级调度时，调度算法不是从portMAX_PRIORITIES而是从ucTopReady-Priority开始搜索。这就加快了搜索的速度，同时缩短了内核关断时间。
为了加快任务调度的速度，FrecRTOS通过变量ucTopReadyPriotity跟踪当前就绪的最高优先级。当把一个任务加入就绪链表时，如果此任务的优先级高于ucTopReadyPriority，则把这个任务的优先级赋予ucTopReadyPriority。这样当进行优先级调度时，调度算法不是从portMAX_PRIORITIES而是从ucTopReady-Priority开始搜索。这就加快了搜索的速度，同时缩短了内核关断时间。
2.3 时间管理的实现
FreeRTOS提供的典型时间管理函数是vTaskDelay()，调用此函数可以实现将任务延时一段特定时间的功能。在FreeRT0S中，若一个任务要延时xTicksToDelay个时钟节拍，系统内核会把当前系统已运行的时钟节拍总数(定义为xTickCount，32位长度)加上xTicksToDelay得到任务下次唤醒时的时钟节拍数xTimeToWake。然后，内核把此任务的任务控制块从就绪链表中删除，把xTimeToWake作为结点值赋予任务的xItemValue，再根据xTimeToWake的值把任务控制块按照顺序插入不同的链表。若xTimeToWake > xTickCount，即计算中没有出现溢出，内核把任务控制块插入到pxDelayedTaskList链表；若xTimeToWak e< xTickCount，即在计算过程中出现溢出，内核把任务控制块插入到pxOverflowDelayed-Taskust链表。
每发生一个时钟节拍，内核就会把当前的xTick-Count加1。若xTickCount的结果为0，即发生溢出，内核会把pxOverflowDelayedTaskList作为当前链表；否则，内核把pxDelaycdTaskList作为当前链表。内核依次比较xTickCotlrtt和链表各个结点的xTimcToWake。若xTick-Count等于或大于xTimeToWake，说明延时时间已到，应该把任务从等待链表中删除，加入就绪链表。
由此可见，不同于μC／OS—II，FreeRTOS采用“加”的方式实现时间管理。其优点是时间节拍函数的执行时间与任务数量基本无关，而μC／OS—II的OSTimcTick()的执行时间正比于应用程序中建立的任务数。因此当任务较多时，FreeRTOS采用的时间管理方式能有效加快时钟节拍中断程序的执行速度。
2.4 内存分配策略
每当任务、队列和信号量创建的时候，FreeRTOS要求分配一定的RAM。虽然采用malloc()和free()函数可以实现申请和释放内存的功能，但这两个函数存在以下缺点：并不是在所有的嵌入式系统中都可用，要占用不定的程序空间，可重人性欠缺以及执行时间具有不可确定性。为此，除了可采用malloc()和free()函数外，FreeRTOS还提供了另外两种内存分配的策略，用户可以根据实际需要选择不同的内存分配策略。
第1种方法是，按照需求内存的大小简单地把一大块内存分割为若干小块，每个小块的大小对应于所需求内存的大小。这样做的好处是比较简单，执行时间可严格确定，适用于任务和队列全部创建完毕后再进行内核调度的系统；这样做的缺点是，由于内存不能有效释放，系统运行时应用程序并不能实现删除任务或队列。
第2种方法是，采用链表分配内存，可实现动态的创建、删除任务或队列。系统根据空闲内存块的大小按从小到大的顺序组织空闲内存链表。当应用程序申请一块内存时，系统根据申请内存的大小按顺序搜索空闲内存链表，找到满足申请内存要求的最小空闲内存块。为了提高内存的使用效率，在空闲内存块比申请内存大的情况下，系统会把此空闲内存块一分为二。一块用于满足申请内存的要求，一块作为新的空闲内存块插入到链表中。
2.3 时间管理的实现
FreeRTOS提供的典型时间管理函数是vTaskDelay()，调用此函数可以实现将任务延时一段特定时间的功能。在FreeRT0S中，若一个任务要延时xTicksToDelay个时钟节拍，系统内核会把当前系统已运行的时钟节拍总数(定义为xTickCount，32位长度)加上xTicksToDelay得到任务下次唤醒时的时钟节拍数xTimeToWake。然后，内核把此任务的任务控制块从就绪链表中删除，把xTimeToWake作为结点值赋予任务的xItemValue，再根据xTimeToWake的值把任务控制块按照顺序插入不同的链表。若xTimeToWake > xTickCount，即计算中没有出现溢出，内核把任务控制块插入到pxDelayedTaskList链表；若xTimeToWak e< xTickCount，即在计算过程中出现溢出，内核把任务控制块插入到pxOverflowDelayed-Taskust链表。
每发生一个时钟节拍，内核就会把当前的xTick-Count加1。若xTickCount的结果为0，即发生溢出，内核会把pxOverflowDelayedTaskList作为当前链表；否则，内核把pxDelaycdTaskList作为当前链表。内核依次比较xTickCotlrtt和链表各个结点的xTimcToWake。若xTick-Count等于或大于xTimeToWake，说明延时时间已到，应该把任务从等待链表中删除，加入就绪链表。
由此可见，不同于μC／OS—II，FreeRTOS采用“加”的方式实现时间管理。其优点是时间节拍函数的执行时间与任务数量基本无关，而μC／OS—II的OSTimcTick()的执行时间正比于应用程序中建立的任务数。因此当任务较多时，FreeRTOS采用的时间管理方式能有效加快时钟节拍中断程序的执行速度。
2.4 内存分配策略
每当任务、队列和信号量创建的时候，FreeRTOS要求分配一定的RAM。虽然采用malloc()和free()函数可以实现申请和释放内存的功能，但这两个函数存在以下缺点：并不是在所有的嵌入式系统中都可用，要占用不定的程序空间，可重人性欠缺以及执行时间具有不可确定性。为此，除了可采用malloc()和free()函数外，FreeRTOS还提供了另外两种内存分配的策略，用户可以根据实际需要选择不同的内存分配策略。
第1种方法是，按照需求内存的大小简单地把一大块内存分割为若干小块，每个小块的大小对应于所需求内存的大小。这样做的好处是比较简单，执行时间可严格确定，适用于任务和队列全部创建完毕后再进行内核调度的系统；这样做的缺点是，由于内存不能有效释放，系统运行时应用程序并不能实现删除任务或队列。
第2种方法是，采用链表分配内存，可实现动态的创建、删除任务或队列。系统根据空闲内存块的大小按从小到大的顺序组织空闲内存链表。当应用程序申请一块内存时，系统根据申请内存的大小按顺序搜索空闲内存链表，找到满足申请内存要求的最小空闲内存块。为了提高内存的使用效率，在空闲内存块比申请内存大的情况下，系统会把此空闲内存块一分为二。一块用于满足申请内存的要求，一块作为新的空闲内存块插入到链表中。
下面以图2为例介绍方法2的实现。假定用于动态分配的RAM共有8KB，系统首先初始化空闲内存块链表，把8KB RAM全部作为一个空闲内存块。当应用程序分别申请1KB和2KB内存后，空闲内存块的大小变为5KB3。2KB的内存使用完毕后，系统需要把2KB插入到现有的空闲内存块链表。由于2 KB<5KB，所以把这2 KB插入5KB的内存块之前。若应用程序又需要申请3 KB的内存，而在空闲内存块链表中能满足申请内存要求的最小空闲内存块为5KB，因此把5KB内存拆分为2部分，3KB部分用于满足申请内存的需要，2KB部分作为新的空闲内存块插入链表。随后1KB的内存使用完毕需要释放，系统会按顺序把1KB内存插入到空闲内存链表中。
图2 采用空闲内存块链表进行内存管理
方法2的优点是，能根据任务需要高效率地使用内存，尤其是当不同的任务需要不同大小的内存的时候。方法二的缺点是，不能把应用程序释放的内存和原有的空闲内存混合为一体，因此，若应用程序频繁申请与释放“随机”大小的内存，就可能造成大量的内存碎片。这就要求应用程序申请与释放内存的大小为“有限个”固定的值(如图2中申请与释放内存的大小固定为l KB、2 KB或3 KB)。方法2的另一个缺点是，程序执行时间具有一定的不确定性。
μC／OS—II提供的内存管理机制是把连续的大块内存按分区来管理，每个分区中包含整数个大小相同的内存块。由于每个分区的大小相同，即使频繁地申请和释放内存也不会产生内存碎片问题，但其缺点是内存的利用率相对不高。当申请和释放的内存大小均为一个固定值时(如均为2 KB)，FreeRTOS的方法2内存分配策略就可以实现类似μC／OS—Ⅱ的内存管理效果。
2.5 FreeRTOS的移植
FreeRTOS操作系统可以被方便地移植到不同处理器上工作，现已提供了ARM、MSP430、AVR、PIC、C8051F等多款处理器的移植。FrceRTOS在不同处理器上的移植类似于μC／0S一II，故本文不再详述FreeRTOS的移植。此外，TCP／IP协议栈μIP已被移植到FreeRTOS上，具体代码可见FreeRTOS网站。
2.6 FreeRTOS的不足
相对于常见的μC／OS—II操作系统，FreeRTOS操作系统既有优点也存在不足。其不足之处，一方面体现在系统的服务功能上，如FreeRTOS只提供了消息队列和信号量的实现，无法以后进先出的顺序向消息队列发送消息；另一方面，FreeRTOS只是一个操作系统内核，需外扩第三方的GUI(图形用户界面)、TCP／IP协议栈、FS(文件系统)等才能实现一个较复杂的系统，不像μC／OS-II可以和μC／GUI、μC／FS、μC／TCP-IP等无缝结合。
3、结 论
作为一个源码公开的操作系统，学习FreeRTOS可以更好地掌握嵌入式实时操作系统的实现原理；作为一个免费的操作系统，采用FreeRTOS可在基本满足较小系统需要的情况下降低系统成本、简化开发难度。在实践中，采用FreeRTOS操作系统和MSP430单片机构成的温度控制系统稳定可靠，实现了较好的控制效果。相信随着时间的发展，FreeRTOS会不断完善其功能，以更好地满足人们对嵌入式操作系统实时性、可靠性、易用性的要求。
