μC/OS-Ⅱ是怎样处理临界段代码的;
什么是任务,怎样把用户的任务交给μC/OS-Ⅱ;
任务是怎样调度的;
应用程序CPU的利用率是多少,μC/OS-Ⅱ是怎样知道的;
怎样写中断服务子程序;
什么是时钟节拍,μC/OS-Ⅱ是怎样处理时钟节拍的;
μC/OS-Ⅱ是怎样初始化的,以及
怎样启动多任务;
本章还描述以下函数,这些服务于应用程序:
OS_ENTER_CRITICAL() 和 OS_EXIT_CRITICAL(),
OSInit(),
OSSTart(),
OSIntEnter() 和 OSIntExit(),
OSSchedLock() 和 OSSchedUnlock(), 以及
OSVersiON().
3.0 临界段(CriticalSections)
和其它内核一样,μC/OS-Ⅱ为了处理临界段代码需要关中断,处理完毕后再开中断。这使得μC/OS-Ⅱ能够避免同时有其它任务或中断服务进入临界段代码。关中断的时间是实时内核开发商应提供的最重要的指标之一,因为这个指标影响用户系统对实时事件的响应性。μC/OS-Ⅱ努力使关中断时间降至最短,但就使用μC/OS-Ⅱ而言,关中断的时间很大程度上取决于微处理器的架构以及编译器所生成的代码质量。
微处理器一般都有关中断/开中断指令,用户使用的C语言编译器必须有某种机制能够在C中直接实现关中断/开中断地操作。某些C编译器允许在用户的C源代码中插入汇编语言的语句。这使得插入微处理器指令来关中断/开中断很容易实现。而有的编译器把从C语言中关中断/开中断放在语言的扩展部分。μC/OS-Ⅱ定义两个宏(macros)来关中断和开中断,以便避开不同C编译器厂商选择不同的方法来处理关中断和开中断。μC/OS-Ⅱ中的这两个宏调用分别是:OS_ENTER_CRITICAL()和OS_EXIT_CRITICAL()。因为这两个宏的定义取决于所用的微处理器,故在文件OS_CPU.H中可以找到相应宏定义。每种微处理器都有自己的OS_CPU.H文件。
3.1 任务
一个任务通常是一个无限的循环[L3.1(2)],如程序清单3.1所示。一个任务看起来像其它C的函数一样,有函数返回类型,有形式参数变量,但是任务是绝不会返回的。故返回参数必须定义成void[L3.1(1)]。
程序清单L3.1任务是一个无限循环
voidYourTask(void*pdata)(1)
{
for(;;){(2)
/* 用户代码 */
调用uC/OS-II的某种系统服务:
OSMboxPend();
OSQPend();
OSSemPend();
OSTaskDel(OS_PRIO_SELF);
OSTaskSuspend(OS_PRIO_SELF);
OSTimeDly();
OSTimeDlyHMSM();
/* 用户代码 */
}
}
不同的是,当任务完成以后,任务可以自我删除,如清单L3.2所示。注意任务代码并非真的删除了,μC/OS-Ⅱ只是简单地不再理会这个任务了,这个任务的代码也不会再运行,如果任务调用了OSTaskDel(),这个任务绝不会返回什么。
程序清单 L3.2. 任务完成后自我删除
voidYourTask(void*pdata)
{
/* 用户代码 */
OSTaskDel(OS_PRIO_SELF);
}
形式参数变量[L3.1(1)]是由用户代码在第一次执行的时候带入的。请注意,该变量的类型是一个指向void的指针。这是为了允许用户应用程序传递任何类型的数据给任务。这个指针好比一辆万能的车子,如果需要的话,可以运载一个变量的地址,或一个结构,甚至是一个函数的地址。也可以建立许多相同的任务,所有任务都使用同一个函数(或者说是同一个任务代码程序),见第一章的例1。例如,用户可以将四个串行口安排成每个串行口都是一个单独的任务,而每个任务的代码实际上是相同的。并不需要将代码复制四次,用户可以建立一个任务,向这个任务传入一个指向某数据结构的指针变量,这个数据结构定义串行口的参数(波特率、I/O口地址、中断向量号等)。
μC/OS-Ⅱ可以管理多达64个任务,但目前版本的μC/OS-Ⅱ有两个任务已经被系统占用了。作者保留了优先级为0、1、2、3、OS_LOWEST_PRIO-3、OS_LOWEST_PRI0-2,OS_LOWEST_PRI0-1以及OS_LOWEST_PRI0这8个任务以被将来使用。OS_LOWEST_PRI0是作为定义的常数在OS_CFG.H文件中用定义常数语句#defineconstant定义的。因此用户可以有多达56个应用任务。必须给每个任务赋以不同的优先级,优先级可以从0到OS_LOWEST_PR10-2。优先级号越低,任务的优先级越高。μC/OS-Ⅱ总是运行进入就绪态的优先级最高的任务。目前版本的μC/OS-Ⅱ中,任务的优先级号就是任务编号(ID)。优先级号(或任务的ID号)也被一些内核服务函数调用,如改变优先级函数OSTaskChangePrio(),以及任务删除函数OSTaskDel()。
为了使μC/OS-Ⅱ能管理用户任务,用户必须在建立一个任务的时候,将任务的起始地址与其它参数一起传给下面两个函数中的一个:OSTastCreat或OSTaskCreatExt()。
OSTaskCreateExt()是OSTaskCreate()的扩展,扩展了一些附加的功能。,这两个函数的解释见第四章,任务管理。
3.2 任务状态
图3.1是μC/OS-Ⅱ控制下的任务状态转换图。在任一给定的时刻,任务的状态一定是在这五种状态之一。
睡眠态(DORMANT)指任务驻留在程序空间之中,还没有交给μC/OS-Ⅱ管理,(见程序清单L3.1或L3.2)。把任务交给μC/OS-Ⅱ是通过调用下述两个函数之一:
OSTaskCreate()或OSTaskCreateExt()。当任务一旦建立,这个任务就进入就绪态准备运行。任务的建立可以是在多任务运行开始之前,也可以是动态地被一个运行着的任务建立。如果一个任务是被另一个任务建立的,而这个任务的优先级高于建立它的那个任务,则这个刚刚建立的任务将立即得到CPU的控制权。一个任务可以通过调用OSTaskDel()返回到睡眠态,或通过调用该函数让另一个任务进入睡眠态。
调用OSStart()可以启动多任务。OSStart()函数运行进入就绪态的优先级最高的任务。就绪的任务只有当所有优先级高于这个任务的任务转为等待状态,或者是被删除了,才能进入运行态。
图3.1任务的状态
正在运行的任务可以通过调用两个函数之一将自身延迟一段时间,这两个函数是OSTimeDly()或OSTimeDlyHMSM()。这个任务于是进入等待状态,等待这段时间过去,下一个优先级最高的、并进入了就绪态的任务立刻被赋予了CPU的控制权。等待的时间过去以后,系统服务函数OSTimeTick()使延迟了的任务进入就绪态(见3.10节,时钟节拍)。
正在运行的任务期待某一事件的发生时也要等待,手段是调用以下3个函数之一:
OSSemPend(),OSMboxPend(),或OSQPend()。调用后任务进入了等待状态(WAITING)。当任务因等待事件被挂起(Pend),下一个优先级最高的任务立即得到了CPU的控制权。当事件发生了,被挂起的任务进入就绪态。事件发生的报告可能来自另一个任务,也可能来自中断服务子程序。
正在运行的任务是可以被中断的,除非该任务将中断关了,或者μC/OS-Ⅱ将中断关了。被中断了的任务就进入了中断服务态(ISR)。响应中断时,正在执行的任务被挂起,中断服务子程序控制了CPU的使用权。中断服务子程序可能会报告一个或多个事件的发生,而使一个或多个任务进入就绪态。在这种情况下,从中断服务子程序返回之前,μC/OS-Ⅱ要判定,被中断的任务是否还是就绪态任务中优先级最高的。如果中断服务子程序使一个优先级更高的任务进入了就绪态,则新进入就绪态的这个优先级更高的任务将得以运行,否则原来被中断了的任务才能继续运行。当所有的任务都在等待事件发生或等待延迟时间结束,μC/OS-Ⅱ执行空闲任务(idletask),执行OSTaskIdle()函数。
3.3 任务控制块(TaskControlBlocks,OS _TCBs)
一旦任务建立了,任务控制块OS _TCBs将被赋值(程序清单3.3)。任务控制块是一个数据结构,当任务的CPU使用权被剥夺时,μC/OS-Ⅱ用它来保存该任务的状态。当任务重新得到CPU使用权时,任务控制块能确保任务从当时被中断的那一点丝毫不差地继续执行。OS _TCBs全部驻留在RAM中。读者将会注意到笔者在组织这个数据结构时,考虑到了各成员的逻辑分组。任务建立的时候,OS _TCBs就被初始化了(见第四章任务管理)。
程序清单 L3.3μC/OS-II任务控制块.
typedefstructos_tcb{
OS_STK*OSTCBStkPtr;
#ifOS_TASK_CREATE_EXT_EN
void*OSTCBExtPtr;
OS_STK*OSTCBStkBottom;
INT32UOSTCBStkSize;
INT16UOSTCBOpt;
INT16UOSTCBId;
#endif
structos_tcb*OSTCBNext;
structos_tcb*OSTCBPrev;
#if(OS_Q_EN&&(OS_MAX_QS>=2))||OS_MBOX_EN||OS_SEM_EN
OS_EVENT*OSTCBEventPtr;
#endif
#if(OS_Q_EN&&(OS_MAX_QS>=2))||OS_MBOX_EN
void*OSTCBMsg;
#endif
INT16UOSTCBDly;
INT8UOSTCBStat;
INT8UOSTCBPrio;
INT8UOSTCBX;
INT8UOSTCBY;
INT8UOSTCBBitX;
INT8UOSTCBBitY;
#ifOS_TASK_DEL_EN
BOOLEANOSTCBDelReq;
#endif
}OS_TCB;
.OSTCBStkPtr 是指向当前任务栈顶的指针。μC/OS-Ⅱ允许每个任务有自己的栈,尤为重
要的是,每个任务的栈的容量可以是任意的。有些商业内核要求所有任务栈的容量都一
样,除非用户写一个复杂的接口函数来改变之。这种限制浪费了RAM,当各任务需要的栈
空间不同时,也得按任务中预期栈容量需求最多的来分配栈空间。OSTCBStkPtr是OS_TCB
数据结构中唯一的一个能用汇编语言来处置的变量(在任务切换段的代码Context-
switchingcode之中,)把OSTCBStkPtr放在数据结构的最前面,使得从汇编语言中处理
这个变量时较为容易。
.OSTCBExtPtr 指向用户定义的任务控制块扩展。用户可以扩展任务控制块而不必修改μ
C/OS-Ⅱ的源代码。.OSTCBExtPtr只在函数OstaskCreateExt()中使用,故使用时要将
OS_TASK_CREAT_EN设为1,以允许建立任务函数的扩展。例如用户可以建立一个数据结
构,这个数据结构包含每个任务的名字,或跟踪某个任务的执行时间,或者跟踪切换到某
个任务的次数(见例3)。注意,笔者将这个扩展指针变量放在紧跟着堆栈指针的位置,
为的是当用户需要在汇编语言中处理这个变量时,从数据结构的头上算偏移量比较方便。
.OSTCBStkBottom 是指向任务栈底的指针。如果微处理器的栈指针是递减的,即栈存储器
从高地址向低地址方向分配,则OSTCBStkBottom指向任务使用的栈空间的最低地址。类似
地,如果微处理器的栈是从低地址向高地址递增型的,则OSTCBStkBottom指向任务可以使
用的栈空间的最高地址。函数OSTaskStkChk()要用到变量OSTCBStkBottom,在运行中检验
栈空间的使用情况。用户可以用它来确定任务实际需要的栈空间。这个功能只有当用户在
任务建立时允许使用OSTaskCreateExt()函数时才能实现。这就要求用户将
OS_TASK_CREATE_EXT_EN设为1,以便允许该功能。
.OSTCBStkSize 存有栈中可容纳的指针元数目而不是用字节(Byte)表示的栈容量总数。
也就是说,如果栈中可以保存1,000个入口地址,每个地址宽度是32位的,则实际栈容量
是4,000字节。同样是1,000个入口地址,如果每个地址宽度是16位的,则总栈容量只有
2,000字节。在函数OSStakChk()中要调用OSTCBStkSize。同理,若使用该函数的话,要将
OS_TASK_CREAT_EXT_EN设为1。
.OSTCBOpt 把“选择项”传给OSTaskCreateExt(),只有在用户将OS_TASK_CREATE_EXT_EN
设为1时,这个变量才有效。μC/OS-Ⅱ目前只支持3个选择项(见uCOS_II.H):
OS_TASK_OTP_STK_CHK,OS_TASK_OPT_STK_CLR和OS_TASK_OPT_SAVE_FP。
OS_TASK_OTP_STK_CHK用于告知TaskCreateExt(),在任务建立的时候任务栈检验功能得
到了允许。OS_TASK_OPT_STK_CLR表示任务建立的时候任务栈要清零。只有在用户需要有
栈检验功能时,才需要将栈清零。如果不定义OS_TASK_OPT_STK_CLR,而后又建立、删除
了任务,栈检验功能报告的栈使用情况将是错误的。如果任务一旦建立就决不会被删除,
而用户初始化时,已将RAM清过零,则OS_TASK_OPT_STK_CLR不需要再定义,这可以节约程
序执行时间。传递了OS_TASK_OPT_STK_CLR将增加TaskCreateExt()函数的执行时间,因为
要将栈空间清零。栈容量越大,清零花的时间越长。最后一个选择项
OS_TASK_OPT_SAVE_FP通知TaskCreateExt(),任务要做浮点运算。如果微处理器有硬件的
浮点协处理器,则所建立的任务在做任务调度切换时,浮点寄存器的内容要保存。
.OSTCBId用于存储任务的识别码。这个变量现在没有使用,留给将来扩展用。
.OSTCBNext 和.OSTCBPrev 用于任务控制块OS_TCBs的双重链接,该链表在时钟节拍函数
OSTimeTick()中使用,用于刷新各个任务的任务延迟变量.OSTCBDly,每个任务的任务控制
块OS_TCB在任务建立的时候被链接到链表中,在任务删除的时候从链表中被删除。双重连
接的链表使得任一成员都能被快速插入或删除。
.OSTCBEventPtr是指向事件控制块的指针,后面的章节中会有所描述(见第6章任务间通
讯与同步)。
.OSTCBMsg是指向传给任务的消息的指针。用法将在后面的章节中提到(见第6章任务间通
讯与同步)。
.OSTCBDly 当需要把任务延时若干时钟节拍时要用到这个变量,或者需要把任务挂起一段
时间以等待某事件的发生,这种等待是有超时限制的。在这种情况下,这个变量保存的是
任务允许等待事件发生的最多时钟节拍数。如果这个变量为0,表示任务不延时,或者表
示等待事件发生的时间没有限制。
.OSTCBStat是任务的状态字。当.OSTCBStat为0,任务进入就绪态。可以给.OSTCBStat赋
其它的值,在文件uCOS_II.H中有关于这个值的描述。
.OSTCBPrio是任务优先级。高优先级任务的.OSTCBPrio值小。也就是说,这个值越小,任
务的优先级越高。
.OSTCBX,.OSTCBY,.OSTCBBitX和.OSTCBBitY 用于加速任务进入就绪态的过程或进入等
待事件发生状态的过程(避免在运行中去计算这些值)。这些值是在任务建立时算好的,
或者是在改变任务优先级时算出的。这些值的算法见程序清单L3.4。
程序清单 L3.4 任务控制块OS_TCB中几个成员的算法
OSTCBY=priority>>3;
OSTCBBitY=OSMapTbl[priority>>3];
OSTCBX=priority&0x07;
OSTCBBitX=OSMapTbl[priority&0x07];
.OSTCBDelReq是一个布尔量,用于表示该任务是否需要删除,用法将在后面的章节中描述
(见第4章任务管理)
应用程序中可以有的最多任务数(OS_MAX_TASKS)是在文件OS_CFG.H中定义的。这个
最多任务数也是μC/OS-Ⅱ分配给用户程序的最多任务控制块OS_TCBs的数目。将
OS_MAX_TASKS的数目设置为用户应用程序实际需要的任务数可以减小RAM的需求量。所有
的任务控制块OS_TCBs都是放在任务控制块列表数组OSTCBTbl[]中的。请注意,μC/OS-Ⅱ
分配给系统任务OS_N_SYS_TASKS若干个任务控制块,见文件μC/OS-Ⅱ.H,供其内部使
用。目前,一个用于空闲任务,另一个用于任务统计(如果OS_TASK_STAT_EN是设为
1的)。在μC/OS-Ⅱ初始化的时候,如图3.2所示,所有任务控制块OS_TCBs被链接成单
向空任务链表。当任务一旦建立,空任务控制块指针OSTCBFreeList指向的任务控制块便
赋给了该任务,然后OSTCBFreeList的值调整为指向下链表中下一个空的任务控制块。一
旦任务被删除,任务控制块就还给空任务链表。
图3.2空任务列表
3.4 就绪表(ReadyList)
每个任务被赋予不同的优先级等级,从0级到最低优先级OS_LOWEST_PR1O,包括0和S_LOWEST_PR1O在内(见文件OS_CFG.H)。当μC/OS-Ⅱ初始化的时候,最低优先级OS_LOWEST_PR1O总是被赋给空闲任务idletask。注意,最多任务数目OS_MAX_TASKS和最低优先级数是没有关系的。用户应用程序可以只有10个任务,而仍然可以有32个优先级的级别(如果用户将最低优先级数设为31的话)。
每个任务的就绪态标志都放入就绪表中的,就绪表中有两个变量OSRedyGrp和OSRdyTbl[]。在OSRdyGrp中,任务按优先级分组,8个任务为一组。OSRdyGrp中的每一位表示8组任务中每一组中是否有进入就绪态的任务。任务进入就绪态时,就绪表OSRdyTbl[]中的相应元素的相应位也置位。就绪表OSRdyTbl[]数组的大小取决于OS_LOWEST_PR1O(见文件OS_CFG.H)。当用户的应用程序中任务数目比较少时,减少OS_LOWEST_PR1O的值可以降低μC/OS-Ⅱ对RAM(数据空间)的需求量。
为确定下次该哪个优先级的任务运行了,内核调度器总是将OS_LOWEST_PR1O在就绪表中相应字节的相应位置1。OSRdyGrp和OSRdyTbl[]之间的关系见图3.3,是按以下规则给出的:
当OSRdyTbl[0]中的任何一位是1时,OSRdyGrp的第0位置1,
当OSRdyTbl[1]中的任何一位是1时,OSRdyGrp的第1位置1,
当OSRdyTbl[2]中的任何一位是1时,OSRdyGrp的第2位置1,
当OSRdyTbl[3]中的任何一位是1时,OSRdyGrp的第3位置1,
当OSRdyTbl[4]中的任何一位是1时,OSRdyGrp的第4位置1,
当OSRdyTbl[5]中的任何一位是1时,OSRdyGrp的第5位置1,
当OSRdyTbl[6]中的任何一位是1时,OSRdyGrp的第6位置1,
当OSRdyTbl[7]中的任何一位是1时,OSRdyGrp的第7位置1,
程序清单3.5中的代码用于将任务放入就绪表。Prio是任务的优先级。
程序清单L3.5使任务进入就绪态
OSRdyGrp|=OSMapTbl[prio>>3];
OSRdyTbl[prio>>3]|=OSMapTbl[prio&0x07];
表T3.1OSMapTbl[]的值