3.0          临界段(Critical Sections) 1

3.1          任务... 1

3.2          任务状态... 3

3.3          任务控制块（Task Control Blocks, OS_TCBs）... 3

3.4          就绪表（Ready List）... 6

3.5          任务调度（Task Scheduling）... 8

3.6          给调度器上锁和开锁(Locking and UnLocking the Scheduler) 9

3.7          空闲任务(Idle Task) 11

3.8          统计任务... 11

3.9          μC/OS中的中断处理... 14

3.10        时钟节拍... 17

3.11        μC/OS-Ⅱ初始化... 20

3.12        μC/OS-Ⅱ的启动... 20

3.13        获取当前μC/OS-Ⅱ的版本号... 21

3.14        OSEvent???()函数... 22

 

第3章           内核结构
本章给出μC/OS-Ⅱ的主要结构概貌。读者将学习以下一些内容；

l         μC/OS-Ⅱ是怎样处理临界段代码的;

l         什么是任务，怎样把用户的任务交给μC/OS-Ⅱ;

l         任务是怎样调度的;

l         应用程序CPU的利用率是多少，μC/OS-Ⅱ是怎样知道的;

l         怎样写中断服务子程序;

l         什么是时钟节拍，μC/OS-Ⅱ是怎样处理时钟节拍的;

l         μC/OS-Ⅱ是怎样初始化的，以及

l         怎样启动多任务;

本章还描述以下函数,这些服务于应用程序：

l         OS_ENTER_CRITICAL() 和 OS_EXIT_CRITICAL(),

l         OSInit(),

l         OSStart(),

l         OSIntEnter() 和 OSIntExit(),

l         OSSchedLock() 和 OSSchedUnlock(), 以及

l         OSVersion().

 

3.0          临界段(Critical Sections)
    和其它内核一样，μ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 任务是一个无限循环
 
    void YourTask (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()，这个任务绝不会返回什么。

 

 

程序清单 L 3.2     . 任务完成后自我删除
 
    void YourTask (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文件中用定义常数语句#define constant定义的。因此用户可以有多达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-Ⅱ执行空闲任务（idle task），执行OSTaskIdle()函数。

3.3          任务控制块（Task Control Blocks, OS­­_TCBs）
    一旦任务建立了，任务控制块OS­­_TCBs将被赋值（程序清单3.3）。任务控制块是一个数据结构，当任务的CPU使用权被剥夺时，μC/OS-Ⅱ用它来保存该任务的状态。当任务重新得到CPU使用权时，任务控制块能确保任务从当时被中断的那一点丝毫不差地继续执行。OS­­_TCBs全部驻留在RAM中。读者将会注意到笔者在组织这个数据结构时，考虑到了各成员的逻辑分组。任务建立的时候，OS­­_TCBs就被初始化了（见第四章 任务管理）。

 

程序清单 L 3.3     µC/OS-II任务控制块.
 
typedef struct os_tcb {
 
    OS_STK        *OSTCBStkPtr;
 
 
 
#if OS_TASK_CREATE_EXT_EN
 
    void          *OSTCBExtPtr;
 
    OS_STK        *OSTCBStkBottom;
 
    INT32U         OSTCBStkSize;
 
    INT16U         OSTCBOpt;
 
    INT16U         OSTCBId;
 
#endif
 
 
 
    struct os_tcb *OSTCBNext;
 
    struct os_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
 
 
 
    INT16U         OSTCBDly;
 
    INT8U          OSTCBStat;
 
    INT8U          OSTCBPrio;
 
 
 
    INT8U          OSTCBX;
 
    INT8U          OSTCBY;
 
    INT8U          OSTCBBitX;
 
    INT8U          OSTCBBitY;
 
 
 
#if OS_TASK_DEL_EN
 
    BOOLEAN        OSTCBDelReq;
 
#endif
 
} OS_TCB;
 

 

.OSTCBStkPtr是指向当前任务栈顶的指针。μC/OS-Ⅱ允许每个任务有自己的栈，尤为重要的是，每个任务的栈的容量可以是任意的。有些商业内核要求所有任务栈的容量都一样，除非用户写一个复杂的接口函数来改变之。这种限制浪费了RAM，当各任务需要的栈空间不同时，也得按任务中预期栈容量需求最多的来分配栈空间。OSTCBStkPtr是OS_TCB数据结构中唯一的一个能用汇编语言来处置的变量（在任务切换段的代码Context-switching code之中，）把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。

 

程序清单 L 3.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           Ready List）
    每个任务被赋予不同的优先级等级，从0级到最低优先级OS_LOWEST_PR1O，包括0和OS_LOWEST_PR1O在内（见文件OS_CFG.H）。当μC/OS-Ⅱ初始化的时候，最低优先级OS_LOWEST_PR1O总是被赋给空闲任务idle task。注意，最多任务数目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.1 OSMapTbl[]的值

 
 
Index
 Bit Mask (Binary)
 
0
 00000001
 
1
 00000010
 
2
 00000100
 
3
 00001000
 
4
 00010000
 
5
 00100000
 
6
 01000000
 
7
 10000000
 

 

 

    读者可以看出，任务优先级的低三位用于确定任务在总就绪表OSRdyTbl[]中的所在位。接下去的三位用于确定是在OSRdyTbl[]数组的第几个元素。OSMapTbl[]是在ROM中的（见文件OS_CORE.C）屏蔽字，用于限制OSRdyTbl[]数组的元素下标在0到7之间，见表3.1

图3.3μC/OS-Ⅱ就绪表

 

    如果一个任务被删除了，则用程序清单3.6中的代码做求反处理。

 

程序清单 L3.6 从就绪表中删除一个任务
 
if ((OSRdyTbl[prio >> 3] &= ~OSMapTbl[prio & 0x07]) == 0)
 
    OSRdyGrp &= ~OSMapTbl[prio >> 3];
 

 

    以上代码将就绪任务表数组OSRdyTbl[]中相应元素的相应位清零，而对于OSRdyGrp，只有当被删除任务所在任务组中全组任务一个都没有进入就绪态时，才将相应位清零。也就是说OSRdyTbl[prio>>3]所有的位都是零时，OSRdyGrp的相应位才清零。为了找到那个进入就绪态的优先级最高的任务，并不需要从OSRdyTbl[0]开始扫描整个就绪任务表，只需要查另外一张表，即优先级判定表OSUnMapTbl([256])(见文件OS_CORE.C)。OSRdyTbl[]中每个字节的8位代表这一组的8个任务哪些进入就绪态了，低位的优先级高于高位。利用这个字节为下标来查OSUnMapTbl这张表，返回的字节就是该组任务中就绪态任务中优先级最高的那个任务所在的位置。这个返回值在0到7之间。确定进入就绪态的优先级最高的任务是用以下代码完成的，如程序清单L3.7所示。

程序清单 L3.7 找出进入就绪态的优先级最高的任务
 
y    = OSUnMapTbl[OSRdyGrp];
 
x    = OSUnMapTbl[OSRdyTbl[y]];
 
prio = (y << 3) + x;
 

 

    例如，如果OSRdyGrp的值为二进制01101000，查OSUnMapTbl[OSRdyGrp]得到的值是3，它相应于OSRdyGrp中的第3位bit3，这里假设最右边的一位是第0位bit0。类似地，如果OSRdyTbl[3]的值是二进制11100100,则OSUnMapTbl[OSRdyTbc[3]]的值是2，即第2位。于是任务的优先级Prio就等于26（3*8+2）。利用这个优先级的值。查任务控制块优先级表OSTCBPrioTbl[]，得到指向相应任务的任务控制块OS_TCB的工作就完成了。

3.5          任务调度（Task Scheduling）
    μC/OS-Ⅱ总是运行进入就绪态任务中优先级最高的那一个。确定哪个任务优先级最高，下面该哪个任务运行了的工作是由调度器（Scheduler）完成的。任务级的调度是由函数OSSched()完成的。中断级的调度是由另一个函数OSIntExt()完成的，这个函数将在以后描述。OSSched()的代码如程序清单L3.8所示。

 

 程序清单 L3.8 任务调度器（the Task Scheduler）
 
void OSSched (void)
 
{
 
    INT8U y;
 
 
 
 
 
    OS_ENTER_CRITICAL();
 
    if ((OSLockNesting | OSIntNesting) == 0) {                          (1)
 
        y             = OSUnMapTbl[OSRdyGrp];                             (2)
 
        OSPrioHighRdy = (INT8U)((y << 3) + OSUnMapTbl[OSRdyTbl[y]]);    (2)
 
        if (OSPrioHighRdy != OSPrioCur) {                               (3)
 
            OSTCBHighRdy = OSTCBPrioTbl[OSPrioHighRdy];                  (4)
 
            OSCtxSwCtr++;                                                      (5)
 
            OS_TASK_SW();                                                      (6)
 
        }
 
    }
 
    OS_EXIT_CRITICAL();
 
}
 

 

    μC/OS-Ⅱ任务调度所花的时间是常数，与应用程序中建立的任务数无关。如程序清单中[L3.8(1)]条件语句的条件不满足，任务调度函数OSSched()将退出，不做任务调度。这个条件是：如果在中断服务子程序中调用OSSched()，此时中断嵌套层数OSIntNesting>0，或者由于用户至少调用了一次给任务调度上锁函数OSSchedLock()，使OSLockNesting>0。如果不是在中断服务子程序调用OSSched()，并且任务调度是允许的，即没有上锁，则任务调度函数将找出那个进入就绪态且优先级最高的任务[L3.8(2)]，进入就绪态的任务在就绪任务表中有相应的位置位。一旦找到那个优先级最高的任务，OSSched()检验这个优先级最高的任务是不是当前正在运行的任务，以此来避免不必要的任务调度[L3.8(3)]。注意，在μC/OS中曾经是先得到OSTCBHighRdy然后和OSTCBCur做比较。因为这个比较是两个指针型变量的比较，在8位和一些16位微处理器中这种比较相对较慢。而在μC/OS-Ⅱ中是两个整数的比较。并且，除非用户实际需要做任务切换，在查任务控制块优先级表OSTCBPrioTbl[]时，不需要用指针变量来查OSTCBHighRdy。综合这两项改进，即用整数比较代替指针的比较和当需要任务切换时再查表，使得μC/OS-Ⅱ比μC/OS在8位和一些16位微处理器上要更快一些。

    为实现任务切换，OSTCBHighRdy必须指向优先级最高的那个任务控制块OS_TCB，这是通过将以OSPrioHighRdy为下标的OSTCBPrioTbl[]数组中的那个元素赋给OSTCBHighRdy来实现的[L3.8(4)]。接着，统计计数器OSCtxSwCtr加1，以跟踪任务切换次数[L3.8(5)]。最后宏调用OS_TASK_SW()来完成实际上的任务切换[L3.8(6)]。

    任务切换很简单，由以下两步完成，将被挂起任务的微处理器寄存器推入堆栈，然后将较高优先级的任务的寄存器值从栈中恢复到寄存器中。在μC/OS-Ⅱ中，就绪任务的栈结构总是看起来跟刚刚发生过中断一样，所有微处理器的寄存器都保存在栈中。换句话说，μC/OS-Ⅱ运行就绪态的任务所要做的一切，只是恢复所有的CPU寄存器并运行中断返回指令。为了做任务切换，运行OS_TASK_SW(),人为模仿了一次中断。多数微处理器有软中断指令或者陷阱指令TRAP来实现上述操作。中断服务子程序或陷阱处理（Trap hardler），也称作事故处理（exception handler），必须提供中断向量给汇编语言函数OSCtxSw()。OSCtxSw()除了需要OS_TCBHighRdy指向即将被挂起的任务，还需要让当前任务控制块OSTCBCur指向即将被挂起的任务，参见第8章，移植μC/OS-Ⅱ，有关于OSCtxSw()的更详尽的解释。

    OSSched()的所有代码都属临界段代码。在寻找进入就绪态的优先级最高的任务过程中，为防止中断服务子程序把一个或几个任务的就绪位置位，中断是被关掉的。为缩短切换时间，OSSched()全部代码都可以用汇编语言写。为增加可读性，可移植性和将汇编语言代码最少化，OSSched()是用C写的。

3.6          给调度器上锁和开锁(Locking and UnLocking the Scheduler)
    给调度器上锁函数OSSchedlock()（程序清单L3.9）用于禁止任务调度，直到任务完成后调用给调度器开锁函数OSSchedUnlock()为止，（程序清单L3.10）。调用OSSchedlock()的任务保持对CPU的控制权，尽管有个优先级更高的任务进入了就绪态。然而，此时中断是可以被识别的，中断服务也能得到（假设中断是开着的）。OSSchedlock()和OSSchedUnlock()必须成对使用。变量OSLockNesting跟踪OSSchedLock()函数被调用的次数，以允许嵌套的函数包含临界段代码，这段代码其它任务不得干预。μC/OS-Ⅱ允许嵌套深度达255层。当OSLockNesting等于零时，调度重新得到允许。函数OSSchedLock()和OSSchedUnlock()的使用要非常谨慎，因为它们影响μC/OS-Ⅱ对任务的正常管理。

    当OSLockNesting减到零的时候，OSSchedUnlock()调用OSSched[L3.10(2)]。OSSchedUnlock()是被某任务调用的，在调度器上锁的期间，可能有什么事件发生了并使一个更高优先级的任务进入就绪态。

    调用OSSchedLock()以后，用户的应用程序不得使用任何能将现行任务挂起的系统调用。也就是说，用户程序不得调用OSMboxPend()、OSQPend()、OSSemPend()、OSTaskSuspend(OS_PR1O_SELF)、OSTimeDly()或OSTimeDlyHMSM(),直到OSLockNesting回零为止。因为调度器上了锁，用户就锁住了系统，任何其它任务都不能运行。

    当低优先级的任务要发消息给多任务的邮箱、消息队列、信号量时(见第6章任务间通讯和同步)，用户不希望高优先级的任务在邮箱、队列和信号量没有得到消息之前就取得了CPU的控制权，此时，用户可以使用禁止调度器函数。

 

程序清单 L3.9 给调度器上锁
 
void OSSchedLock (void)
 
{
 
    if (OSRunning == TRUE) {
 
        OS_ENTER_CRITICAL();
 
        OSLockNesting++;
 
        OS_EXIT_CRITICAL();
 
    }
 
}
 

 

 

程序清单 L3.10 给调度器开锁.
 
void OSSchedUnlock (void)
 
{
 
    if (OSRunning == TRUE) {
 
        OS_ENTER_CRITICAL();
 
        if (OSLockNesting > 0) {
 
            OSLockNesting--;
 
            if ((OSLockNesting | OSIntNesting) == 0) {                    (1)
 
                OS_EXIT_CRITICAL();
 
                OSSched();                                                     (2)
 
            } else {
 
                OS_EXIT_CRITICAL();
 
            }
 
        } else {
 
            OS_EXIT_CRITICAL();
 
        }
 
    }
 
}
 

 

 

3.7          空闲任务(Idle Task)
    μC/OS-Ⅱ总是建立一个空闲任务，这个任务在没有其它任务进入就绪态时投入运行。这个空闲任务[OSTaskIdle()]永远设为最低优先级，即OS_LOWEST_PRI0。空闲任务OSTaskIdle()什么也不做，只是在不停地给一个32位的名叫OSIdleCtr的计数器加1，统计任务（见3.08节，统计任务）使用这个计数器以确定现行应用软件实际消耗的CPU时间。程序清单L3.11是空闲任务的代码。在计数器加1前后，中断是先关掉再开启的，因为8位以及大多数16位微处理器的32位加1需要多条指令，要防止高优先级的任务或中断服务子程序从中打入。空闲任务不可能被应用软件删除。

 

程序清单 L3.11 μC/OS-Ⅱ的空闲任务.
 
void OSTaskIdle (void *pdata)
 
{
 
    pdata = pdata;
 
    for (;;) {
 
        OS_ENTER_CRITICAL();
 
        OSIdleCtr++;
 
        OS_EXIT_CRITICAL();
 
    }
 
}
 

 

3.8          统计任务
    μC/OS-Ⅱ有一个提供运行时间统计的任务。这个任务叫做OSTaskStat(),如果用户将系统定义常数OS_TASK_STAT_EN（见文件OS_CFG.H）设为1，这个任务就会建立。一旦得到了允许，OSTaskStat()每秒钟运行一次（见文件OS_CORE.C），计算当前的CPU利用率。换句话说，OSTaskStat()告诉用户应用程序使用了多少CPU时间，用百分比表示，这个值放在一个有符号8位整数OSCPUsage中，精读度是1个百分点。

    如果用户应用程序打算使用统计任务，用户必须在初始化时建立一个唯一的任务，在这个任务中调用OSStatInit()（见文件OS_CORE.C）。换句话说，在调用系统启动函数OSStart()之前，用户初始代码必须先建立一个任务，在这个任务中调用系统统计初始化函数OSStatInit()，然后再建立应用程序中的其它任务。程序清单L3.12是统计任务的示意性代码。

 

程序清单 L3.12 初始化统计任务.
 
void main (void)
 
{
 
    OSInit();                 /* 初始化uC/OS-II                          (1)*/
 
    /* 安装uC/OS-II的任务切换向量                                          */
 
    /* 创建用户起始任务(为了方便讨论，这里以TaskStart()作为起始任务)         (2)*/
 
    OSStart();                /* 开始多任务调度                           (3)*/
 
}
 
 
 
 
 
 
 
void TaskStart (void *pdata)
 
{
 
    /* 安装并启动uC/OS-II的时钟节拍                                      (4)*/
 
    OSStatInit();             /* 初始化统计任务                           (5)*/
 
    /* 创建用户应用程序任务                                                 */
 
    for (;;) {
 
        /* 这里是TaskStart()的代码!                                        */
 
    }
 
}
 

 

    因为用户的应用程序必须先建立一个起始任务[TaskStart（）]，当主程序main()调用系统启动函数OSStcnt()的时候，μC/OS-Ⅱ只有3个要管理的任务：TaskStart()、OSTaskIdle()和OSTaskStat()。请注意，任务TaskStart()的名称是无所谓的，叫什么名字都可以。因为μC/OS-Ⅱ已经将空闲任务的优先级设为最低，即OS_LOWEST_PR10，统计任务的优先级设为次低，OS_LOWEST_PR10-1。启动任务TaskStart()总是优先级最高的任务。

    图F3.4解释初始化统计任务时的流程。用户必须首先调用的是μC/OS-Ⅱ中的系统初始化函数OSInit()，该函数初始化μC/OS-Ⅱ[图F3.4(2)]。有的处理器（例如Motorola的MC68HC11）,不需要“设置”中断向量，中断向量已经在ROM中有了。用户必须调用OSTaskCreat()或者OSTaskCreatExt()以建立TaskStart()[图F3.4(3)]。进入多任务的条件准备好了以后，调用系统启动函数OSStart()。这个函数将使TaskStart()开始执行，因为TaskStart()是优先级最高的任务[图F3.4(4)]]。

图F3.4统计任务的初始化

 

TaskStart()负责初始化和启动时钟节拍[图F3.4(5)]。在这里启动时钟节拍是必要的，因为用户不会希望在多任务还没有开始时就接收到时钟节拍中断。接下去TaskStart()调用统计初始化函数OSStatInit()[图F3.4（6）]。统计初始化函数OSStatInit()决定在没有其它应用任务运行时，空闲计数器（OSIdleCtr）的计数有多快。奔腾II微处理器以333MHz运行时，加1操作可以使该计数器的值达到每秒15,000,000次。OSIdleCtr的值离32位计数器的溢出极限值4,294,967,296还差得远。微处理器越来越快，用户要注意这里可能会是将来的一个潜在问题。

    系统统计初始化任务函数OSStatInit()调用延迟函数OSTimeDly()将自身延时2个时钟节拍以停止自身的运行[图F3.4(7)]。这是为了使OSStatInit()与时钟节拍同步。μC/OS-Ⅱ然后选下一个优先级最高的进入就绪态的任务运行，这恰好是统计任务OSTaskStat()。读者会在后面读到OSTaskStat()的代码，但粗看一下，OSTaskStat()所要做的第一件事就是查看统计任务就绪标志是否为“假”，如果是的话，也要延时两个时钟节拍[图F3.4(8)]。一定会是这样，因为标志OSStatRdy已被OSInit()函数初始化为“假”，所以实际上DSTaskStat也将自己推入休眠态（Sleep）两个时钟节拍[图F3.4(9)]。于是任务切换到空