图 F4.1 内存碎片

μC/OS-Ⅱ支持的处理器的堆栈既可以从上(高地址)往下(低地址)长也可以从下往上长(参看4.02,任务堆栈)。用户在调用OSTaskCreate()或OSTaskCreateExt()的时候必须知道堆栈是怎样长的，因为用户必须得把堆栈的栈顶传递给以上两个函数，当OS_CPU.H文件中的OS_STK_GROWTH置为0时，用户需要将堆栈的最低内存地址传递给任务创建函数，如程序清单4.7所示。

程序清单 L4.7 堆栈从下往上递增

OS_STKTaskStack[TASK_STACK_SIZE];

OSTaskCreate(task,pdata,&TaskStack[0],prio);

当OS_CPU.H文件中的OS_STK_GROWTH置为1时，用户需要将堆栈的最高内存地址传递给任务创建函数，如程序清单4.8所示。

程序清单 L4.8 堆栈从上往下递减

OS_STKTaskStack[TASK_STACK_SIZE];

OSTaskCreate(task,pdata,&TaskStack[TASK_STACK_SIZE-1],prio);

这个问题会影响代码的可移植性。 如果用户想将代码从支持往下递减堆栈的处理器中移植到支持往上递增堆栈的处理器中的话，用户得使代码同时适应以上两种情况。在这种特殊情况下，程序清单L4.7和4.8可重新写成如程序清单L4.9所示的形式。

程序清单 L4.9 对两个方向增长的堆栈都提供支持

OS_STKTaskStack[TASK_STACK_SIZE];

#ifOS_STK_GROWTH==0

OSTaskCreate(task,pdata,&TaskStack[0],prio);

#else

OSTaskCreate(task,pdata,&TaskStack[TASK_STACK_SIZE-1],prio);

#endif

任务所需的堆栈的容量是由应用程序指定的。 用户在指定堆栈大小的时候必须考虑用户的任务所调用的所有函数的嵌套情况，任务所调用的所有函数会分配的局部变量的数目，以及所有可能的中断服务例程嵌套的堆栈需求。另外，用户的堆栈必须能储存所有的CPU寄存器。

4.3 堆栈检验，OSTaskStkChk()

有时候决定任务实际所需的堆栈空间大小是很有必要的。因为这样用户就可以避免为任务分配过多的堆栈空间，从而减少自己的应用程序代码所需的RAM(内存)数量。μC/OS-Ⅱ提供的OSTaskStkChk()函数可以为用户提供这种有价值的信息。

在图4.2中，笔者假定堆栈是从上往下递减的(即OS_STK_GROWTH被置为1)，但以下的讨论也同样适用于从下往上长的堆栈[F4.2(1)]。μC/OS-Ⅱ是通过查看堆栈本身的内容来决定堆栈的方向的。只有内核或是任务发出堆栈检验的命令时，堆栈检验才会被执行，它不会自动地去不断检验任务的堆栈使用情况。在堆栈检验时，μC/OS-Ⅱ要求在任务建立的时候堆栈中存储的必须是0值(即堆栈被清零)[F4.2(2)]。另外，μC/OS-Ⅱ还需要知道堆栈栈底(BOS)的位置和分配给任务的堆栈的大小[F4.2(2)]。在任务建立的时候，BOS的位置及堆栈的这两个值储存在任务的OS_TCB中。

为了使用μC/OS-Ⅱ的堆栈检验功能，用户必须要做以下几件事情：

z 在OS_CFG.H文件中设OS_TASK_CREATE_EXT为1。

z 用OSTaskCreateExt()建立任务，并给予任务比实际需要更多的内存空间。

z 在OSTaskCreateExt()中， 将参数opt设置为OS_TASK_OPT_STK_CHK+OS_TASK_OPT_STK_CLR。注意如果用户的程序启动代码清除了所有的RAM，并且从未删除过已建立了的任务，那么用户就不必设置选项OS_TASK_OPT_STK_CLR了。这样就会减少OSTaskCreateExt()的执行时间。

z 将用户想检验的任务的优先级作为OSTaskStkChk()的参数并调用之。

图 4.2 堆栈检验

OSTaskStkChk()顺着堆栈的栈底开始计算空闲的堆栈空间大小， 具体实现方法是统计储存值为0的连续堆栈入口的数目，直到发现储存值不为0的堆栈入口[F4.2(5)]。注意堆栈入口的储存值在进行检验时使用的是堆栈的数据类型(参看OS_CPU.H中的OS_STK)。换句话说，如果堆栈的入口有32位宽，对0值的比较也是按32位完成的。所用的堆栈的空间大小是指从用户在OSTaskCreateExt()中定义的堆栈大小中减去了储存值为0的连续堆栈入口以后的大小。OSTaskStkChk()实际上把空闲堆栈的字节数和已用堆栈的字节数放置在0S_STK_DATA数据结构中(参看μCOS_Ⅱ.H)。注意在某个给定的时间，被检验的任务的堆栈指针可能会指向最初的堆栈栈顶(TOS)与堆栈最深处之间的任何位置[F4.2(7)]。 每次在调用OSTaskStkChk()的时候， 用户也可能会因为任务还没触及堆栈的最深处而得到不同的堆栈的空闲空间数。

用户应该使自己的应用程序运行足够长的时间，并且经历最坏的堆栈使用情况，这样才能得到正确的数。一旦OSTaskStkChk()提供给用户最坏情况下堆栈的需求，用户就可以重新设置堆栈的最后容量了。为了适应系统以后的升级和扩展，用户应该多分配10%-100%的堆栈空间。在堆栈检验中，用户所得到的只是一个大致的堆栈使用情况，并不能说明堆栈使用的全部实际情况。

OSTaskStkChk()函数的代码如程序清单L4.10所示。0S_STK_DATA(参看μCOS_Ⅱ.H)数据结构用来保存有关任务堆栈的信息。笔者打算用一个数据结构来达到两个目的。第一，把OSTaskStkChk()当作是查询类型的函数，并且使所有的查询函数用同样的方法返回，即返回查询数据到某个数据结构中。第二，在数据结构中传递数据使得笔者可以在不改变OSTaskStkChk()的API(应用程序编程接口)的条件下为该数据结构增加其它域，从而扩展OSTaskStkChk()的功能。现在，0S_STK_DATA只包含两个域：OSFree和OSUsed。从代码中用户可看到，通过指定执行堆栈检验的任务的优先级可以调用OSTaskStkChk()。如果用户指定0S_PRIO_SELF[L4.10(1)]，那么就表明用户想知道当前任务的堆栈信息。当然，前提是任务已经存在[L4.10(2)]。要执行堆栈检验，用户必须已用OSTaskCreateExt()建立了任务并且已经传递了选项OS_TASK_OPT_CHK[L4.10(3)]。如果所有的条件都满足了，OSTaskStkChk()就会象前面描述的那样从堆栈栈底开始统计堆栈的空闲空间[L4.10(4)]。 最后，储存在0S_STK_DATA中的信息就被确定下来了[L4.10(5)]。注意函数所确定的是堆栈的实际空闲字节数和已被占用的字节数，而不是堆栈的总字节数。当然，堆栈的实际大小(用

字节表示)就是该两项之和。

程序清单 L4.10 堆栈检验函数

INT8UOSTaskStkChk(INT8Uprio,OS_STK_DATA*pdata)

{

OS_TCB*ptcb;

OS_STK*pchk;

INT32Ufree;

INT32Usize;

pdata->OSFree=0;

pdata->OSUsed=0;

if(prio>OS_LOWEST_PRIO&&prio!=OS_PRIO_SELF){

return(OS_PRIO_INVALID);

}

OS_ENTER_CRITICAL();

if(prio==OS_PRIO_SELF){(1)

prio=OSTCBCur->OSTCBPrio;

}

ptcb=OSTCBPrioTbl[prio];

if(ptcb==(OS_TCB*)0){(2)

OS_EXIT_CRITICAL();

return(OS_TASK_NOT_EXIST);

}

if((ptcb->OSTCBOpt&OS_TASK_OPT_STK_CHK)==0){(3)

OS_EXIT_CRITICAL();

return(OS_TASK_OPT_ERR);

}

free=0; (4)

size=ptcb->OSTCBStkSize;

pchk=ptcb->OSTCBStkBottom;

OS_EXIT_CRITICAL();

#ifOS_STK_GROWTH==1

while(*pchk++==0){

free++;

}

#else

while(*pchk--==0){

free++;

}

#endif

pdata->OSFree=free*sizeof(OS_STK);(5)

pdata->OSUsed=(size-free)*sizeof(OS_STK);

return(OS_NO_ERR);

}

4.4删除任务，OSTaskDel()

有时候删除任务是很有必要的。删除任务,是说任务将返回并处于休眠状态(参看3.02,任务状态)，并不是说任务的代码被删除了，只是任务的代码不再被μC/OS-Ⅱ调用。通过调用OSTaskDel()就可以完成删除任务的功能(如程序清单L4.11所示)。OSTaskDel()一开始应确保用户所要删除的任务并非是空闲任务，因为删除空闲任务是不允许的[L4.11(1)]。不过，用户可以删除statistic任务[L4.11(2)]。接着，OSTaskDel()还应确保用户不是在ISR例程中去试图删除一个任务，因为这也是不被允许的[L4.11(3)]。调用此函数的任务可以通过指定OS_PRIO_SELF参数来删除自己[L4.11(4)]。接下来OSTaskDel()会保证被删除的任务是确实存在的[L4.11(3)]。如果指定的参数是OS_PRIO_SELF的话，这一判断过程(任务是否存在)自然是可以通过的，但笔者不准备为这种情况单独写一段代码，因为这样只会增加代码并延长程序的执行时间。

程序清单 L4.11 删除任务

INT8UOSTaskDel(INT8Uprio)

{

OS_TCB*ptcb;

OS_EVENT*pevent;

if(prio==OS_IDLE_PRIO){(1)

return(OS_TASK_DEL_IDLE);

}

if(prio>=OS_LOWEST_PRIO&&prio!=OS_PRIO_SELF){(2)

return(OS_PRIO_INVALID);

}

OS_ENTER_CRITICAL();

if(OSIntNesting>0){(3)

OS_EXIT_CRITICAL();

return(OS_TASK_DEL_ISR);

}

if(prio==OS_PRIO_SELF){(4)

Prio=OSTCBCur->OSTCBPrio;

}

if((ptcb=OSTCBPrioTbl[prio])!=(OS_TCB*)0){(5)

if((OSRdyTbl[ptcb->OSTCBY]&=~ptcb->OSTCBBitX)==0){(6)

OSRdyGrp&=~ptcb->OSTCBBitY;

}

if((pevent=ptcb->OSTCBEventPtr)!=(OS_EVENT*)0){(7)

if((pevent->OSEventTbl[ptcb->OSTCBY]&=~ptcb->OSTCBBitX)==0)

{

pevent->OSEventGrp&=~ptcb->OSTCBBitY;

}

}

Ptcb->OSTCBDly=0;(8)

Ptcb->OSTCBStat=OS_STAT_RDY;(9)

OSLockNesting++;(10)

OS_EXIT_CRITICAL();(11)

OSDummy();(12)

OS_ENTER_CRITICAL();

OSLockNesting--;(13)

OSTaskDelHook(ptcb);(14)

OSTaskCtr--;

OSTCBPrioTbl[prio]=(OS_TCB*)0;(15)

if(ptcb->OSTCBPrev==(OS_TCB*)0){(16)

ptcb->OSTCBNext->OSTCBPrev=(OS_TCB*)0;

OSTCBList=ptcb->OSTCBNext;

}else{

ptcb->OSTCBPrev->OSTCBNext=ptcb->OSTCBNext;

ptcb->OSTCBNext->OSTCBPrev=ptcb->OSTCBPrev;

}

ptcb->OSTCBNext=OSTCBFreeList;(17)

OSTCBFreeList=ptcb;

OS_EXIT_CRITICAL();

OSSched();(18)

return(OS_NO_ERR);

}else{

OS_EXIT_CRITICAL();

return(OS_TASK_DEL_ERR);

}

}

一旦所有条件都满足了，OS_TCB就会从所有可能的μC/OS-Ⅱ的数据结构中移除。OSTaskDel()分两步完成该移除任务以减少中断响应时间。首先，如果任务处于就绪表中，它会直接被移除[L4.11(6)]。如果任务处于邮箱、消息队列或信号量的等待表中，它就从自己所处的表中被移除[L4.11(7)]。接着，OSTaskDel()将任务的时钟延迟数清零，以确保自己重新允许中断的时候，ISR例程不会使该任务就绪[L4.11(8)]。最后，OSTaskDel()置任务的.OSTCBStat标志为OS_STAT_RDY。注意，OSTaskDel()并不是试图使任务处于就绪状态，而是阻止其它任务或ISR例程让该任务重新开始执行(即避免其它任务或ISR调用OSTaskResume()[L4.11(9)])。这种情况是有可能发生的，因为OSTaskDel()会重新打开中断，而ISR可以让更高优先级的任务处于就绪状态，这就可能会使用户想删除的任务重新开始执行。如果不想置任务的.OSTCBStat标志为OS_STAT_RDY，就只能清除OS_STAT_SUSPEND位了(这样代码可能显得更清楚，更容易理解一些)，但这样会使得处理时间稍长一些。

要被删除的任务不会被其它的任务或ISR置于就绪状态， 因为该任务已从就绪任务表中删除了，它不是在等待事件的发生，也不是在等待延时期满，不能重新被执行。为了达到删除任务的目的，任务被置于休眠状态。正因为这样，OSTaskDel()必须得阻止任务调度程序[L4.11(10)]在删除过程中切换到其它的任务中去，因为如果当前的任务正在被删除，它不可能被再次调度!接下来，OSTaskDel()重新允许中断以减少中断的响应时间[L4.11(11)]。

这样，OSTaskDel()就能处理中断服务了，但由于它增加了 OSLockNesting，ISR执行完后会返回到被中断任务，从而继续任务的删除工作。注意OSTaskDel()此时还没有完全完成删除任务的工作，因为它还需要从TCB链中解开OS_TCB，并将OS_TCB返回到空闲OS_TCB表中。

另外需要注意的是，笔者在调用OS_EXIT_CRITICAL()函数后，马上调用了OSDummy()[L4.11(12)]，该函数并不会进行任何实质性的工作。这样做只是因为想确保处理器在中断允许的情况下至少执行一个指令。对于许多处理器来说，执行中断允许指令会强制CPU禁止中断直到下个指令结束!Intel80x86和ZilogZ-80处理器就是如此工作的。开中断后马上关中断就等于从来没开过中断，当然这会增加中断的响应时间。因此调用OSDummy()确保在再次禁止中断之前至少执行了一个调用指令和一个返回指令。当然，用户可以用宏定义将OSDummy()定义为一个空操作指令(译者注：例如MC68HC08指令中的NOP指令) ，这样调用OSDummy()就等于执行了一个空操作指令，会使OSTaskDel()的执行时间稍微缩短一点。但笔者认为这种宏定义是没价值的，因为它会增加移植μCOS-Ⅱ的工作量。

现在，OSTaskDel()可以继续执行删除任务的操作了。在OSTaskDel()重新关中断后，它通过锁定嵌套计数器(OSLockNesting)减一以重新允许任务调度[L4.11(13)]。接着，OSTaskDel()调用用户自定义的OSTaskDelHook()函数[L4.11(14)]，用户可以在这里删除或

释放自定义的TCB附加数据域。 然后， OSTaskDel()减少μCOS-Ⅱ的任务计数器。 OSTaskDel()

简单地将指向被删除的任务的OS_TCB的指针指向NULL[L4.11(15)]，从而达到将OS_TCB从优先级表中移除的目的。再接着，OSTaskDel()将被删除的任务的OS_TCB从OS_TCB双向链表中移除[L4.11(16)]。 注意,没有必要检验ptcb->OSTCBNext==0的情况， 因为OSTaskDel()不能删除空闲任务，而空闲任务就处于链表的末端(ptcb->OSTCBNext==0)。接下来，OS_TCB返回到空闲OS_TCB表中，并允许其它任务的建立[L4.11(17)]。最后，调用任务调度程序来查看在OSTaskDel()重新允许中断的时候[L4.11(11)]，中断服务子程序是否曾使更高优先级的任务处于就绪状态[L4.11(18)]。

4.5请求删除任务，OSTaskDelReq()

有时候，如果任务A拥有内存缓冲区或信号量之类的资源，而任务B想删除该任务，这些资源就可能由于没被释放而丢失。在这种情况下，用户可以想法子让拥有这些资源的任务在使用完资源后，先释放资源，再删除自己。用户可以通过OSTaskDelReq()函数来完成该功能。

发出删除任务请求的任务(任务B)和要删除的任务(任务A)都需要调用OSTaskDelReq()函数。任务B的代码如程序清单L4.12所示。任务B需要决定在怎样的情况下请求删除任务[L4.12(1)]。换句话说，用户的应用程序需要决定在什么样的情况下删除任务。如果任务需要被删除，可以通过传递被删除任务的优先级来调用OSTaskDelReq()[L4.12(2)]。如果要被删除的任务不存在(即任务已被删除或是还没被建立)，OSTaskDelReq()返回OS_TASK_NOT_EXIST。如果OSTaskDelReq()的返回值为OS_NO_ERR，则表明请求已被接受但任务还没被删除。用户可能希望任务B等到任务A删除了自己以后才继续进行下面的工作，这时用户可以象笔者一样，通过让任务B延时一定时间来达到这个目的[L4.12(3)]。笔者延时了一个时钟节拍。如果需要，用户可以延时得更长一些。当任务A完全删除自己后，[L4.12(2)]中的返回值成为0S_TASK_NOT_EXIST，此时循环结束[L4.12(4)]。

程序清单 L4.12 请求删除其它任务的任务(任务B)

voidRequestorTask(void*pdata)

{

INT8Uerr;

pdata=pdata;

for(;;){

/* 应用程序代码 */

if('TaskToBeDeleted()' 需要被删除){(1)

while(OSTaskDelReq(TASK_TO_DEL_PRIO)!=OS_TASK_NOT_EXIST){(2)

OSTimeDly(1);(3)

}

}

/*应用程序代码*/(4)

}

}

程序清单 L4.13 需要删除自己的任务(任务A)

voIDTaskToBeDeleted(void*pdata)

{

INT8Uerr;

pdata=pdata;

for(;;){

/*应用程序代码*/

If(OSTaskDelReq(OS_PRIO_SELF)==OS_TASK_DEL_REQ){(1)

释放所有占用的资源;(2)

释放所有动态内存;

OSTaskDel(OS_PRIO_SELF);(3)

}else{

/*应用程序代码*/

}

}

}

需要删除自己的任务(任务A)的代码如程序清单L4.13所示。在OS_TAB中存有一个标志，任务通过查询这个标志的值来确认自己是否需要被删除。这个标志的值是通过调用OSTaskDelReq(OS_PRIO_SELF)而得到的。当OSTaskDelReq()返回给调用者OS_TASK_DEL_REQ[L4.13(1)]时，则表明已经有另外的任务请求该任务被删除了。在这种情况下，被删除的任务会释放它所拥有的所用资源[L4.13(2)]，并且调用OSTaskDel(OS_PRIO_SELF)来删除自己[L4.13(3)]。前面曾提到过，任务的代码没有被真正的删除，而只是μC/OS-Ⅱ不再理会该任务代码，换句话说，就是任务的代码不会再运行了。

但是，用户可以通过调用OSTaskCreate()或OSTaskCreateExt()函数重新建立该任务。OSTaskDelReq()的代码如程序清单L4.14所示。通常OSTaskDelReq()需要检查临界条件。首先，如果正在删除的任务是空闲任务，OSTaskDelReq()会报错并返回[L4.14(1)]。接着，它要保证调用者请求删除的任务的优先级是有效的[L4.14(2)]。如果调用者就是被删除任务本身，存储在OS_TCB中的标志将会作为返回值[L4.14(3)]。如果用户用优先级而不是OS_PRIO_SELF指定任务，并且任务是存在的[L4.14(4)]，OSTaskDelReq()就会设置任务的内部标志[L4.14(5)]。如果任务不存在，OSTaskDelReq()则会返回OS_TASK_NOT_EXIST，表明任务可能已经删除自己了[L4.14(6)]。

程序清单 L4.14 OSTaskDelReq().

INT8UOSTaskDelReq(INT8Uprio)

{

BOOLEANstat;

INT8Uerr;

OS_TCB*ptcb;

if(prio==OS_IDLE_PRIO){(1)

return(OS_TASK_DEL_IDLE);

}

if(prio>=OS_LOWEST_PRIO&&prio!=OS_PRIO_SELF){