内容介绍
1、介绍uC/OS-II嵌入式操作系统
2、基于uC/OS-II的用电管理终端软件的设计
书籍：《嵌入式实时操作系统uC/OS-II》
作者：JeanLabrosse
uC/OS-IIV2.52通过了美国航空航天管理局（FAA）的安全认证；
安全性、可靠性是得到认证的。
我们为什么会选择uC/OS-II嵌入式操作系统？
1、与终端硬件平台相适应
全部源代码5500行，可裁减定制，生成的可执行代码占15～20k,
可以移植到多种系列单片机上，包括ARM；
2、考虑成本，免费的源代码公开；
3、uC/OS-II代码简单，容易掌握和使用；具有多任务调度的基本功能；
uC/OS-II嵌入式操作系统的缺点：
1、缺少技术支持，相关的支持软件少；
2、和商业软件比，功能较弱（如不支持时间片轮转，最大任务数为64等）；对应用开发的支持不够；
uC/OS内核介绍和基于RTOS的设计介绍
一、概述
l使用嵌入式RTOS的优点
1将复杂的系统分解为多个相对独立的任务，采用“分而治之”的方法降低系统的复杂度。通过将应用程序分割成若干独立的任务，RTOS使得应用程序的设计过程大为简化；
2使得应用程序的设计和扩展变得容易，无需较大的改动就可以增加新的功能；
3用户给系统增加一些低优先级的任务，则用户系统对高优先级的任务的响应时间几乎不受影响；
4实时性能得到提高。使用可剥夺型内核，所有时间要求苛刻的事件都得到了尽可能快捷有效的处理；
5通过有效的服务，如信号量、邮箱、队列、延时及超时等，RTOS使资源得到更好的利用；
l使用嵌入式RTOS的缺点
1使用RTOS增加了系统的内存和CPU等使用开销，例如任务之间的通讯、RTOS的调度程序等；
2需要采用一些新的软件设计方法，对系统设计人员的要求高一些。例如驱动程序的设计要考虑到共享资源的互斥问题；
3系统任务的划分是比较复杂的过程，需要设计人员对业务和RTOS操作系统都很熟悉。
luC/OS操作系统的特点
uC/OS是一个完成的，可移植、可固化、可裁减的抢占式实时多任务操作系统内核。主要用ANSI的C语言编写，少部分代码是汇编语言。uC/OS主要有以下特点：
1、可移植性可以移植到多个CPU上，包括三菱单片机。
2、可固化可以固化到嵌入式系统中
3、可裁减 可以定制uC/OS，使用少量的系统服务
4、可剥夺性uC/OS是完全可剥夺的实时内核，uC/OS总是运行优先级最高的就绪任务。
5、多任务运行uC/OS可以管理最多64个任务。不支持时间片轮转调度法，所以要求每个任务的优先级不一样。
6、可确定性uC/OS的函数调用和系统服务的执行时间可以确定。
7、任务栈每个任务都有自己的单独的栈，而且每个任务栈空间的大小可以不一样。
8、系统服务uC/OS有很多系统服务，如信号量、时间标志、消息邮箱、消息队列、时间管理等等。
二、uC/OS内核介绍
l基本概念
1、前后台系统也称为超循环系统。应用程序是一个无限的循环，循环中实现相应的操作，这部分看成后台行为。用中断服务程序处理异步事件，处理实时性要求很强的操作，这部分可以看成前台行为。
2、共享资源可以被一个以上任务使用的资源叫做共享资源。
3、任务：一个任务是一个线程，一般是一个无限的循环程序。一个任务可以认为CPU资源完全只属于自己。任务可以是以下五种状态之一：休眠态，就绪态，运行态，挂起态和被中断态。uC/OS-II提供的系统服务可以使任务从一种状态变为另一种状态。
4、任务切换：任务切换就是上下文切换，也是CPU寄存器内容切换。当内核决定运行另外的任务时，它保存正在运行任务的当前状态（CPU寄存器的内容）到任务自己的栈区。入栈完成后，就把下一个将要运行的任务状态从该任务的栈中重新装入CPU寄存器，并开始下一个任务的运行，这个过程叫做任务切换。
5、内核多任务系统中内核负责管理和调度各个任务，为每个任务分配CPU时间，并负责任务间的通信。内核总是调度就绪态的优先级最高的任务。内核本身增加了系统的额外负荷，因为内核提供的服务需要一定的执行时间。
6、可剥夺型内核uC/OS－II以及绝大多数商业实时内核都是可剥夺型内核。最高优先级的任务一旦就绪，就抢占运行着的低优先级的任务，得到CPU的使用权。
7、可重入函数：可以被多个任务调用，并且不用担心数据会被破坏的函数。
8、优先级反转优先级反转问题是使用实时内核系统中出现最多的问题。描述如下：假设当前系统有任务3在运行，并且低优先级的任务3占用了共享资源，而高优先级任务1就绪得到CPU使用权后，也要使用任务3占用的共享资源，任务1只能挂起等待任务3使用完共享资源。任务3继续运行时，优先级在任务1和任务3之间的任务2就绪并抢占了任务3的CPU使用权，直到运行完后才把CPU使用权还给任务3。任务3继续运行，在释放了共享资源后任务1才得以运行。这样，任务1实际上降到了任务3优先级的水平。这种情况就是优先级反转问题。uC/OS-II中，可以利用互斥信号量来这个解决。
9、互斥方法使用共享数据结构进行任务间通信时，要求对其进行互斥。保证互斥的方法有：关中断、使用测试变量、禁止任务切换和利用信号量。
10、同步可以利用信号量使任务与任务，任务与ISR之间同步。任务之间没有数据交换。
11、事件标志：当任务要与多个事件同步时，需要使用事件标志(eventflag)。事件标志同步分为独立型同步（逻辑“或”关系）和关联型同步（逻辑“与”关系）。
12、任务间通信：任务间信息的传递有两个途径，通过全局变量或者通过内核发消息给另一个任务。通过内核服务发送的消息包括：消息邮箱、消息队列。任务或者ISR可以把一个指针放到消息邮箱中，让另一个任务接收。消息队列实际上是邮箱阵列。
13、时钟节拍：是特定的周期性的定时器中断。时钟节拍是系统的心脏脉动，提供周期性的信号源，是系统进行任务调度的频率依据和任务延时依据。时钟节拍越快，系统开销就越大。我们移植过程中采用的方法：初始化定时器TA0,周期是20ms,作为操作系统时钟节拍。
luC/OS-II内核结构
1、uC/OS-II是以源代码形式提供的实时操作系统内核，其包含的文件结构如下：
说明：
基于uC/OS-II操作系统进行应用系统时，设计任务的主要任务是将系统合理划分成多个任务，并由RTOS进行调度，任务之间使用uC/OS-II提供的系统服务进行通信，以配合实现应用系统的功能。上图中应用代码部分主要是设计人员设计的业务代码。
与前后台系统一样，基于uC/OS-II的多任务系统也有一个main主函数，main函数由编译器所带的C启动程序调用。在main主函数中主要实现uC/OS-II的初始化OSInit()、任务创建、一些任务通信方法的创建、uC/OS-II的多任务启动OSStart()等常规操作。另外，还有一些应用程序相关的初始化操作，例如：硬件初始化、数据结构初始化等。
在使用uC/OS-II提供的任何功能之前，必须先调用OSInit()函数进行初始化。在main主函数中调用OSStart()启动多任务之前，至少要先建立一个任务。否则应用程序会崩溃。
OSInit()初始化uC/OS-II所有的变量和数据结构，并建立空闲任务OS_TaskIdle()，这个任务总是处于就绪态。
例子：一个典型的应用程序main主函数如下
voidmain(void)
｛
/*-----硬件初始化，等用户代码初始化-----*/
init_mcu();
init_lcd();
init_hdtimer();
OSInit(); /*初始化uC/OS-II*/
…
/*通过调用OSTaskCreate()或OSTaskCreateExt()创建至少一个任务；*/
OSTaskCreate(sample_Task,(void*)0,&sample_TaskStk[TASK_STK_SIZE-1],2);
…
/*通过调用OSSemCreate()创建信号量等任务通信方式；*/
CalcSem =OSSemCreate(0);
…
OSStart(); /*开始多任务调度！OSStart()永远不会返回*/
｝
调用OSStart()后，uC/OS-II就运行main函数所创建任务中优先级最高的一个就绪任务。用户应该在uC/OS-II启动运行后的第1个任务中调用时钟节拍启动函数。在uC/OS-II移植到M16C62的过程中实现了函数init_timer_ta0(),来初始化时钟TA0。本文后面有关部分讨论了时钟节拍的问题。
上例中如果创建了多个（n个）任务，在main函数调用OSStart()后，操作系统就启动了多任务调度，接管了CPU和其他资源的使用权，负责为每个任务分配CPU使用权和使用时间，同时对共享资源进行管理。从宏观上看，整个系统就象有多个执行的程序并行运行，每个程序都是无限循环的main函数。如下图所示：
文件OS_CFG.H是与应用程序有关的配置文件，主要是对操作系统进行设置。包括：
设置系统的最多任务数OS_MAX_TASKS；
最多事件控制块设置OS_MAX_EVENTS；
堆栈方向的设置OS_STK_GROWTH（1为递减、0为递增）；
是否支持堆栈检验OS_TASK_CREATE_EXT；
是否支持任务统计OS_ASK_STAT_EN；
是否支持事件标志组OS_FLG_EN…
等等。
文件INCLUDES.H是主控头文件，包含了整个系统需要的所有头文件。包括操作系统的头文件和用户设计的应用系统的头文件。
OS_CPU.H、OS_CPU_A.ASM等文件是与移植uC/OS-II有关的文件，包含了与处理器类型有关的代码。这几个文件的介绍参见何博士的uC/OS-II移植文档。
2、uC/OS-II内核体系结构图
uC/OS-II内核主要对用户任务进行调度和管理，并为任务间共享资源提供服务。包含的模块有任务管理、任务调度、任务间通信、时间管理、内核初始化等。uC/OS-II内核体系结构如下所示：
3、任务状态及其转换关系
在多任务系统中，任务是设计者实现应用系统的基本形式，也是uC/OS-II系统进行调度的基本单元。任务可以是一个无限的循环，也可以在一次执行后被操作系统删除。任务函数和任何C函数一样，具有一个返回类型和一个参数，但是它决不返回。任务必须是以下2种结构之一：
voidYourTask(voidpdata)
{
for(;;){
/*用户代码*/
}
}
或
voidYourTask(void*pdata)
{
/*用户代码*/
OSTaskDel(OS_PRIO_SELF);
}
在任一给定的时刻，uC/OS-II的任务状态只能是以下5种之一：
l睡眠态：指任务驻留在程序空间（ROM或RAM），还没有交给uC/OS-II来管理。通过创建任务将任务交给uC/OS-II。任务被删除后就进入睡眠态。
l就绪态：任务创建后就进入就绪态。任务的建立可以在多任务运行之前，也可以动态的由一个运行的任务建立。
l运行态：占用CPU资源运行的任务，该任务为进入就绪态的优先级最高的任务。任何时刻只能有一个任务处于运行态。
l等待状态：由于某种原因处于等待状态的任务。例如，任务自身延时一段时间，或者等待某一事件的发生。
l中断服务态：任务运行时被中断打断，进入中断服务态。正在执行的任务被挂起，中断服务子程序控制了CPU的使用权。
uC/OS-II控制下的任务状态转换图如下：
3、任务控制块（OS_TCB）
任务控制块（TCB）是一个数据结构OS_TCB，一旦一个任务创建，就有一个和它关联的TCB被赋值。当任务的CPU使用权被剥夺时，它用来保存该任务的状态。这样，当任务重新获得CPU使用权时，可以从TCB中获取任务切换前的信息，准确的继续运行。
任务控制块包含了许多任务信息，主要有：
.OSTCBStkPtr指向当前任务堆栈栈顶的指针。uC/OS-II允许每个任务有自己的堆栈，每个任务堆栈的大小可以不一样。
.OSTCBNext和.OSTCBPrev指向OS_TCB双向链表的前、后连接。
.OSTCBEventPtr指向事件控制块的指针；
.OSTCBDly保存任务的延时节拍数，或允许等待事件发生的最多节拍数。
.OSTCBPrio任务的优先级；
文件OS_CFG.H中定义的最多任务数OS_MAX_TASKS决定了分配给用户程序的任务控制块的数目。所有的任务控制块都放在任务控制块数组OSTCBTbl[]中。uC/OS-II初始化时，所有OS_TCB都被链接成单向空任务链表。任务一旦建立，就将链表开头的OS_TCB赋给该任务。一旦任务被删除，OS_TCB就还给空任务链表。任务建立时，函数OS_TCBInit()初始化任务控制块。
4、任务调度器
uC/OS-II总是运行进入就绪态的优先级最高的任务。任务调度器的功能是：在就绪表中查找最高优先级的任务，然后进行必要的任务切换，运行该任务。uC/OS-II的任务调度有两种情况：任务级的任务调度由OS_Sched()完成；中断级的任务调度由OSIntExt()完成。这两种任务调度情况调用的任务切换函数不同：任务级的任务调度OS_Sched()调用了任务切换函数OS_TASK_SW()，而中断级的调度OSIntExt()调用了任务切换函数OSIntCtxSw()。
任务级的任务调度是由于有更高优先级的任务进入就绪态，当前的任务的CPU使用权被剥夺，发生了任务到任务的切换；中断级的调度是指当前运行的任务被中断打断，由于ISR运行过程中有更高优先级的任务被激活进入就绪态。而中断返回前ISR调用OSIntExt()函数，该函数查找就绪表发现有必要进行任务切换，从而被中断的任务进入等待状态，运行被激活的高优先级的任务。
任务切换
任务切换有两种：OS_TASK_SW()和OSIntCtxSw()。
任务级的任务切换OS_TASK_SW()是宏调用，通过软中断指令来实现CPU寄存器内容切换。例如：#defineOS_TASK_SW()asm(“int#32”)，具体实现参见移植文档。
任务级的任务切换过程：
1)保存当前运行的任务的CPU寄存器值到该任务的堆栈。如：堆栈指针，程序计数器，状态寄存器等。
2)将要运行的高优先级的任务的寄存器值从堆栈恢复到CPU寄存器。
3)进行TCB的切换，并运行任务。
中断级的任务切换OSIntCtxSw()是在OSIntExt()中调用的，我们一般在用户ISR中调用OSIntExt()以实现中断返回前的任务调度。由于ISR已经将CPU寄存器的值存入被中断的任务的堆栈中，所以OSIntCtxSw()的实现和OS_TASK_SW()不一样，具体参见移植文档。
就绪表
每个就绪的任务都放在就绪表中，就绪表有两个变量：OSRdyGrp和OSRdyTbl[]。OSRdyGrp中，将任务按优先级分组，八个为一组。OSRdyGrp的每一位代表每组任务是否有进入就绪态的任务。
在就绪表中查找优先级最高的任务不需要扫描整个OSRdyTbl[]，只要查优先级判定表OSUnMapTbl[]。OSUnMapTbl[]是常量表，所以查找优先级最高的任务的执行时间为常量，和就绪表的任务数无关。
5、中断服务
在用户的ISR中可以调用OSIntEnter()和OSIntExit()通知uC/OS-II发生了中断，这样可以实现ISR返回前的任务调度。
uC/OS-II中的中断服务子程序示例：
用户中断服务子程序：
保存CPU寄存器；
调用OSIntEnter()；
if(OSIntNesting==1){
OSTCBCur->OSTCBStkPtr=SP;
}
清中断源；
重新开中断；
执行用户ISR代码；
调用OSIntExit()；
恢复CPU寄存器；
执行中断返回指令；
6、时钟节拍
uC/OS-II要求用户提供一个周期性的时钟源，来实现时间的延迟和超时功能，时钟节拍应该每秒发生10~100次/秒。时钟节拍率越高，系统的额外负荷就越重。
应该在多任务系统启动后，也就是调用OSStart()后再开启时钟节拍器。系统设计者可以在第1个开始运行的任务中调用时钟节拍启动函数。假设用定时器TA0作为时钟中断源，那么，在移植过程中实现了函数init_timer_ta0()，此函数用来初始化定时器TA0，并将其打开。
uC/OS-II中的时钟节拍服务是在ISR中调用OSTimeTick()实现的。OSTimeTick()跟踪所有任务的定时器以及超时时限。
7、uC/OS-II的初始化和启动
调用uC/OS-II的服务之前要先调用系统初始化函数OSInit()。OSInit()初始化uC/OS-II所有的变量和数据结构，并建立空闲任务。uC/OS-II初始化任务控制块、事件控制块、消息队列缓冲、标志控制块等数据结构的空缓冲区。
多任务的启动是通过调用OSStart()实现的。启动之前要至少创建一个任务。OSStart()调用就绪任务启动函数OSStartHighRdy()，其功能是将任务栈的值恢复到CPU寄存器，并执行中断返回指令，强制执行该任务代码。
l任务管理
uC/OS-II可以管理最多64个任务。任务管理包括创建任务、删除任务、改变任务的优先级及挂起和恢复任务等。
1、建立任务，OSTaskCreate()、OSTaskCreateExt()
OSTaskCreate()需要四个参数：void(*task)(void*pd),void*pdata,OS_STK*ptos,INT8Uprio。task是指向任务函数的指针；
pdata是任务开始执行时，传递给任务的参数指针；
ptos是分配给任务的堆栈的栈顶指针；
prio是分配给任务的优先级。
OSTaskCreateExt()是OSTaskCreate()的扩展，需要的参数比OSTaskCreate()更多，共九个，前4个和OSTaskCreate()的参数一样。其余的参数是为了系统进行堆栈检验和任务统计等扩展服务功能提供的参数。
2、任务堆栈
每个任务都有自己的堆栈空间，为OS_STK类型，并且由连续的内存空间组成。可以静态分配堆栈空间，也可以动态分配。
uC/OS-II支持的处理器的堆栈既可以是递减的，也可以是递增的。在创建任务时必须知道堆栈是递减还是递增的，因为必须把堆栈的栈顶传递给OSTaskCreate()和OSTaskCreateExt()。可以在文件OS_CPU.H中的OS_STK_GROWTH进行堆栈方向的设置。
3、删除任务，OSTaskDel()
删除任务是指任务处于休眠状态，不再被RTOS调用。
4、请求删除任务，OSTaskDelReq()
为了避免删除任务时，任务占用的资源因为没有被释放而丢失，可以调用OSTaskDelReq()，让拥有这些资源的任务使用完资源后，先释放资源，再删除自己。
5、改变任务优先级，OSTaskChangePrio()
调用OSTaskChangePrio(INT8Uoldprio,INT8Unewprio)可以动态改变任务的优先级。
6、挂起任务，OSTaskSuspend()
调用OSTaskSuspend(INT8Uprio)可以挂起一个任务，被挂起的任务只有通过调用OSTaskResume()函数来恢复。
7、恢复任务，OSTaskResume()
恢复因为调用OSTaskSuspend(INT8Uprio)挂起的任务。
三、uC/OS-II任务间通信方式
1、信号量
信号量由两部分组成：一部分是16位的无符号整型信号量的计数值；另一部分是由等待该信号量的任务组成的等待任务表；
信号量用于对共享资源的访问，用钥匙符号，符号旁数字代表可用资源数，对于二值信号量该值为1；
信号量还可用于表示某事件的发生，用旗帜符号表示，符号旁数字代表事件已经发生的次数；
提供服务：
OSSemCreate()，建立一个信号量，对信号量赋予初始计数值。
如信号量是用于表示一个或多个事件的发生的，其初始值通常为0；
如信号量用于对共享资源的访问，则该值赋为1；
如信号量用于表示允许任务访问n个相同的资源，则该值赋为n，并把该信号量作为一个可计数的信号量使用；
OSSemDel()，删除一个信号量，在删除信号量前必须首先删除操作该信号量的所有任务；
OSSemPend()，等待一个信号量；
OSSemPost()，发出一个信号量；
OSSemAccept()，无等待地请求一个信号量；
OSSemQuery()，查询一个信号量的当前状态；
不推荐任务和中断服务子程序共享信号量，因为信号量一般用于任务级。
如果确实要在任务和中断服务子程序中传递信号量，则中断服务子程序只能发送信号量；
OSSemDel()和OSSemPend()服务不能被中断服务子程序调用；
2、互斥型信号量（mutex）
互斥型信号量用于处理共享资源；
由于终端硬件平台的某些实现特性，例如单片机管脚的复用，多个任务需要对硬件资源进行独占式访问。所谓独占式访问，指在任意时刻只能有一个任务访问和控制某个资源，而且必须等到该任务访问完成后释放该资源，其他任务才能对此资源进行访问。
操作系统进行任务切换时，可能被切换的低优先级任务正在对某个共享资源进行独占式访问，而任务切换后运行的高优先级任务需要使用此共享资源，此时会出现优先级反转的问题。即，高优先级的任务需要等待低优先级的任务继续运行直到释放该共享资源，高优先级的任务才可以获得共享资源继续运行。
可以在应用程序中利用互斥型信号量（mutex）解决优先级反转问题。互斥型信号量是二值信号量。由于uC/OS-II不支持多任务处于同一优先级，可以把占有mutex的低优先级任务的优先级提高到略高于等待mutex的高优先级任务的优先级。等到低优先级任务使用完共享资源后，调用OSMutexPost()，将低优先级任务的优先级恢复到原来的水平。
互斥型信号量（mutex）的操作：
建立一个互斥型信号量 OSMutexCreate(INT8Uprio,INT8U*err)
等待一个互斥型信号量（挂起）
OSMutexPend(OS_EVENT*pevent,INT16Utimeout,INT8U*err)
释放一个互斥型信号量OSMutexPost(OS_EVENT*pevent)
优先级反转问题。
优先级反转问题发生于高优先级的任务需要使用某共享资源，而该资源已被一个低优先级的任务占用的情况。
为了降解优先级反转，内核可以将低优先级任务的优先级提升到高于高优先级任务的优先级，直到低优先级的任务使用完占用的共享资源。
优先级继承优先级PIP，略高于最高优先级任务的优先级；
例：OSMutexCreate(9,&err)；建立互斥型信号量，9为PIP；
其它服务：
OSMutexDel（），删除互斥型信号量，在删除信号量之前应先删除可能用到该信号量的所有任务；
OSMutexPend（），等待一个互斥型信号量（挂起），定义超时值为0时则无限期等待；
OSMutexPost（），释放一个互斥型信号量；
OSMutexAccept（），无等待地获取互斥型信号量（不挂起）；
OSMutexQuery（），获取互斥型信号量的当前状态；
所有服务只能用于任务与任务之间，不能用于任务与中断服务子程序之间；
3、事件标志组(eventflag)
事件标志组由2部分组成：一是保存各事件状态的标志位；二是等待这些标志位置位或清除的任务列表。可以用8位、16位或32位的序列表示事件标志组，每一位表示一个事件的发生。
要使系统支持事件标志组功能，需要在OS_CFG.H文件中打开OS_FLAG_EN选项。
应用场合：如果一个任务需要等待多个事件的同时发生或者多个事件的中的某个事件发生才能转为就绪态，就可以考虑事件标志组进行任务的同步通信。
操作集合：
OSFlagCreate()，建立一个事件标志组；
事件标志组数据结构包括：指针类型，等待事件标志组的任务列表，以及表明当前事件标志状态的位；
OSFlagDel()，删除一个事件标志组，在删除事件标志组前必须首先删除操作该事件标志组的所有任务；
OSFlagPend()，等待事件标志组的事件标志位；
OSFlagPost()，置位或清0事件标志组中的事件标志；
OSFlagAccept()，无等待地获得事件标志组中的事件标志，可以被ISR调用；
OSFlagQuery()，查询事件标志组的状态；
其中OSFlagCreate()、OSFlagDel()、OSFlagPend()只能被任务调用，不能被中断调用；其它服务任务和中断都可调用；
4、消息邮箱
一种通信机制，可以使一个任务或者中断服务子程序向另一个任务发送一个指针型的变量，通常该指针指向一个包含了消息的特定数据结构。
提供的服务：
OS_EVENT*OSMboxCreate(void*msg)，建立一个邮箱，并对邮箱须定义指针的初始值。
一般情况下该值为NULL，但也可以初始化一个邮箱，使其在最开始就包含一条消息。
如使用邮箱的目的是通知一个事件的发生（发送一个消息），则初始化该邮箱为空，即null，因为在开始时很有可能事件没有发生；
如用邮箱共享某些资源，则要初始化该邮箱为一个非空的值，此时邮箱被当做一个二值信号量使用；
OSMboxDel()，删除一个邮箱，在删除邮箱前必须首先删除操作该邮箱的所有任务；
OSMboxPend()，等待邮箱中的消息；
OSMboxPost()，向邮箱发送一则消息；
OSMboxPostOpt()，向邮箱发送一则消息，增强功能，可以广播；
OSMboxAccept()，无等待地从邮箱得到一则消息；
OSMboxQuery()，查询一个邮箱的状态；
其中：OSMboxDel()、OSMboxPend()、OSMboxQuery()只有任务可以调用，中断不能调用；其它服务两者均可调用；
邮箱的使用：
可使用的最大邮箱数由配置文件决定；
用邮箱作为二值信号量，可在其与信号量之间选择其一；
用邮箱实现延时，可取代OSTimeDly（）服务；
5、消息队列
另一种通信机制，允许一个任务或者中断服务子程序向另一个任务发送以指针方式定义的变量或其它任务，因具体应用不同，每个指针指向的包含了消息的数据结构的变量类型也有所不同。
提供服务：
OSQCreate()，建立一个消息队列，并给它赋给两个参数：指向消息数组的指针和数组的大小。
OSQDel()，删除一个消息队列，在删除一个消息队列前必须首先删除所有可能用到这个消息队列的任务；
OSQPend()，等待消息队列中的消息，返回消息指针；
OSQPost()，向消息队列发送一则消息（基于FIFO，先进先出）；
OSQPostFront()，向消息队列发送一则消息（基于LIFO，后进先出）；
OSQPostOpt()，向消息队列发送一则消息（FIFO或LIFO）；
OSQAccept()，无等待地从消息队列获得消息；
OSQFlush()，清空消息队列，清空队列中的所有消息以重新使用；
OSQQuery()，查询消息队列的状态；
其中：OSQDel()、OSQPend()、OSQQuery()只有任务可以调用，中断不能调用；其它服务两者均可调用；
消息队列的使用：
使用消息队列读取模拟量的值；
消息队列用作计数型信号量；
使用消息队列的方式消耗的是消息队列指针指向的数据类型的变量，原来可以用信号量来管理的每个共享资源都需要占用一个队列控制块，因此消息队列与信号量相比，节省了代码空间，而牺牲了RAM空间；
此外，当用计数型信号量管理的共享资源很多时，消息队列的方式效率非常低；
四、多任务系统中驱动程序的实现方法
系统在运行多任务时，由于任务切换的存在，驱动程序库的实现与以前基于前后台系统的实现方法有区别。因为一个硬件驱动在对硬件接口进行操作时可能会发生任务切换，正在执行的硬件接口操作会被打断，而任务切换后运行的任务可能对同一个硬件接口进行操作，从而破坏任务切换前的接口操作状态。为了防止出现这种情况，驱动程序必须考虑到对硬件操作的原子性，即一个底层的操作序列完成前不能被另一个操作打断。
例如，由于xRam读写和LCD显示数据线的复用，向LCD显示一个字节数据的操作（lcd_draw_byte）不能被xRam读写操作wr_abyte和rd_abyte打断。同样，在向外部RAM读写一个字节数据时也不能被LCD显示操作打断。另外，两个调用xRam读写操作的任务在进行xRam读写字节操作时也不能相互打断。
在uC/OS-II中，保护一个原子操作的手段有：关闭中断、禁止任务切换和利用互斥信号量。例如，在函数voidlcd_draw_byte(intix,intiy,chardata)中使用互斥信号量保证此函数执行完成才能进行任务切换。
例：在xRam读写函数中使用互斥信号量
/**************************************************************************
功能:向外部RAM写一个字节，
入口参数:addr外部RAM地址，data写入的字节
**************************************************************************/
voidwr_abyte(UBYTEdata,addr_taddr)
｛
INT8Uerr；
OSMutexPend（xRamMutex，0,&err）；//等待一个互斥信号量
写W24100xram过程…
OSMutexPost（xRamMutex，）； //释放一个互斥信号量
｝
多任务系统中，不仅硬件复用的驱动程序之间需要互斥信号量保证操作的正确，而且相同的驱动被不同的任务调用时也会出现独占访问的问题。除了LCD显示和xRam，系统中其他需要互斥信号量保护的驱动程序，包括EEPROM读写子程序（模拟IIC总线）、dataflash读写操作驱动（模拟spi总线）。
对于uart通讯驱动和rtc4553时钟芯片读写驱动可以考虑在一个任务中调用，因此不存在互斥访问的问题。
无论是不同驱动程序之间的硬件资源共享问题，还是同一个驱动被不同任务调用时的共享问题，都可以采用隐含的信号量才实现，即将信号量放在驱动内部。任务在与某一资源打交道的时候并不知道相应的驱动内有一个互斥信号量。任务在调用一个驱动函数时，实际在申请得到一个信号量。如下图所示：
五、键盘驱动和LCD显示的实现
LCD显示驱动作为功能子程序实现。LCD显示驱动程序必须考虑显示驱动对硬件资源进行操作时有可能进行任务切换，进行xRam读写而出现硬件访问错误。可以考虑利用互斥信号量将LCD显示驱动和xRam驱动程序实现为可重入函数。
键盘处理程序作为任务来实现，任务通常是一个无限的循环，相当于一个线程，当一个任务运行时，该任务单独占用CPU资源，直到被其他高优先级的任务剥夺运行权利而转为就绪态任务。
键盘用两个任务来实现，一个是键盘扫描任务KeyboardScanTask，定时对按键状态进行扫描，并将健值放到缓冲中；另一个是键盘处理任务KeyboardProcTask，定期从键盘缓冲获取健值，并进行相应处理。键盘处理任的执行周期比扫描任务长，但是比扫描任务优先级高。
键盘扫描任务是定时任务。以前的前后台系统实现时是将键盘扫描驱动keyProcess放到20ms定时器中断服务队列中。20ms定时器中断发生时，进行键盘处理keyProcess。KeyProcess调用scanfkey函数，scanfkey函数实现键盘按键状态的扫描，并返回当前按键值。KeyProcess同时处理键盘抖动的因素，采取的方法是连续两次20ms定时器任务时判断按键的值是否一样，如果是，则说明操作员在进行按键操作。所以设置定时器的间隔时间不能太长，否则键盘需要按下很长时间才能对其响应，键盘的响应就会很慢。将键盘keyProcess加入20ms定时器中断任务队列中的方法如下：
voidinit_keyboard(void)
{
insert_task(keyProcess);
}
现在，在多任务调度系统中为了提高系统的实时性，应该尽量减少中断服务子程序的操作内容，借鉴以前系统将键盘驱动加入20ms定时器中断任务队列的实现，我们可以采取两种方法来实现键盘扫描任务。一个是采用操作系统的任务延迟，一个是利用定时中断服务子程序发送信号量。
第一种方法的实现比较简单，也比较节省内存资源。但是由于操作系统的调度等原因，延迟时间不够精确。
第二种方法实现一个20ms的定时中断服务子程序，在中断服务子程序中发出一个信号量（post）给键盘扫描任务。如果键盘扫描任务处于就绪状态，在得到信号量时，键盘驱动就继续运行，运行结束后挂起，继续等待下一次信号量。这种方法延时比较精确，但实现复杂些，消耗内存多些。
键盘处理任务的实现相对简单，就是定时的从键盘缓冲读取按键值。如果有按键值，就根据相应的值进行逻辑处理。键盘处理任务比键盘扫描任务的优先级高。
原系统中的20ms定时任务有：
1、键盘任务insert_task(keyProcess);
2、LED显示insert_task(lmp_proc);
3、延时和计数任务unsignedcharinsert_timer(int*cnt)
系统中的5ms定时任务有：
1.电表通讯任务insert_ctask(cch_mt_ctask);
2.电台通信通讯任务insert_ctask(cch_rd_ctask);
六、交流采集中断和计算任务的通信
交流采样模块采用中断驱动模式，分别用定时器TA2作为采样定时器，定时器TB0、TB1、TB2为三相测频定时器，定时器TA2工作于定时方式（用于采样），定时器TB0、TB1、TB2工作于脉冲周期测量方式（用于A、B、C三相工频测频）。
采样周期是每16个电网频率周期，采集一个周期的数据，即隔15个周期采一个周期。采集频率是一个周期内采64个点。由于电网频率是在一定范围内波动的，所以采样模块对每个工频进行频率测量，第16个周期（采样周期）的工频是根据前16个周期的工频进行的估算，以便确定出将要进行采样的时间间隔。估算公式如下：
number_next=(nub_acc/16+number)/2;
number： 表示当前工频周期f8计数器的计数值。
nub_acc： 表示前16个工频周期的f8计数器累计值。
number_next：估算的将要进行采样的工频周期的频率。
交采表的精度也是整个测试项目主要考虑的问题。为了满足表计精度要求，交采表部分的交流采样要求实时性强，响应快，所以应该用中断服务子程序（ISR）来实现，并且将中断优先级设置为最高（7级）。交采表计算部分作为一个任务来实现，优先级主要实现电流电压和电网频率的信号采集，然后根据三相电表的计算公式进行有效电流、电压、功率等数据相的计算。
整个系统中，除了交流采样的实时性要求最高外，为了能够达到1级电能表的要求，交采表的电表数据计算任务的优先级高于系统其他任务的优先级。因此设置交采计算任务的优先级为0级（最高级）。这样可以满足15个工频周期内将交流采样的64个电流、电压值计算完成。
交流采样中断服务子程序（ISR）与电表数据计算任务之间的同步
采用信号量的通信方法，交流采样ISR完成以后发出一个信号给等待的数据计算任务，计算任务完成以后挂起，等待下一个交流采集信号量。
七、多任务系统中任务划分原则和任务优先级设定
l任务划分的原则
1、I/O依赖性：
如果变换依赖于I/O，那么它运行的速度常常受限于与它互操作的I/O设备的速度，这种情况下变换应成为一个独立的任务；
在系统中创建多个与I/O设备相当数目的I/O任务；
I/O任务只实现与设备相关的代码；
I/O任务的执行只受限于I/O设备的速度，而不是处理器；
在任务中分离设备相关性；
如键盘显示任务、数据存储任务等；
2、时间关键性的功能：
将有时间关键性（deadline）的功能分离出来，组成独立运行的任务；
赋予这些任务高的优先级，以满足对时间的需要；
如交采任务；
3、计算功能；
计算功能占用CPU的时间多；
捆绑计算功能成任务，赋予它们较低优先级运行，能被高优先级的任务抢占，消耗CPU的剩余时间；
保持高优先级的任务是轻量级的（负荷较轻）；
如统计计算任务；
4、功能内聚：
各紧密相关的功能，不能分别对应不同的任务；
将这些紧密相关的功能组，组成一个任务，使各功能共享资源或相同事件的驱动；
组成一个任务会减小通信的开销，而且不仅保证了模块级的功能内聚，也保证了任务级的功能内聚；
如通信任务，将通信驱动和通信规约在一个任务中实现；
5、时间内聚：
将在同一时间内完成的各功能，即使这些功能是不相关的，组成功能组，形成一个任务；
功能组的各功能是由相同的外部时间驱动的（如时钟等），这样每次任务接收到一个事件，它们都可以同时执行；
组成一个任务，减小了系统的开销；
时间内聚在结构化设计中并不被认为是一个好的模块分解原则，但在任务级是可以接受的；每个功能都作为一个独立的模块来实现，从而达到了模块级的功能内聚，这些模块组合在一起，又达到了任务级的时间内聚；
6、周期执行的功能：
将在相同周期内执行的各功能组成一个任务；
频率高的赋予高优先级；
l优先级设定的约定
uc/OS-II中最高优先级为0级，数字越大优先级越低。考虑到采用互斥信号量时优先级继承优先级的问题，便于系统灵活扩展，我们使用偶数作为任务优先级，如：0，2，4……。需要时，采用奇数作为优先级继承优先级。
八、uC/OS内核程序错误修改记录
相关文件名：OS_MUTEX.C
函数名：OS_EVENT*OSMutexCreate(INT8Uprio,INT8U*err)
改动原因：
内核在创建互斥信号量的函数OSMutexCreate中，由于数据类型不匹配产生了PIP参数不能保存的错误。
在函数OSMutexCreate创建一个互斥信号量时，调用函数传递一个PIP作为函数实参（PIP是优先级继承优先级，其作用是利用互斥信号量解决多任务系统中可能出现的优先级反转问题。即把占用共享资源的低优先级任务的优先级暂时提高到PIP，等其释放共享资源后再恢复到原来的优先级）。函数OSMutexCreate将实参prio保存到.OSEventCnt的高八位。由于prio是INT8U数据类型的变量，其长度是八位，prio左移八位后就等于0。所以应该将prio强制转换为16位类型的数据，再左移8位，然后与0xFF相“或”并保存到.OSEventCnt。
下图表示OSMutexCreate返回的事件控制块ECB的数据结构。
OS_EVENT_TYPE_MUTEX
prio
0xFF
(void*)0
0x00
7
6
5
4
3
2
1
0
31
改动前后的程序对比：
改动前：
OS_EVENT*OSMutexCreate(INT8Uprio,INT8U*err)
{
….
pevent->OSEventCnt=(prio<<8)|OS_MUTEX_AVAILABLE;
//由于prio是八位，左移八位后就等于0
pevent->OSEventPtr=(void*)0;
…
｝
改动后：
OS_EVENT*OSMutexCreate(INT8Uprio,INT8U*err)
{
INT16Upip=(INT16U)prio; //强制类型转换
….
pevent->OSEventCnt=(pip<<8)|OS_MUTEX_AVAILABLE;
//将pip的低八位左移到高八位并保存到OSEventCnt
pevent->OSEventPtr=(void*)0;
….
｝
内核错误发现的经过和背景：
我们在做可行性系统测试时，利用互斥信号量来保证驱动程序对资源的独占访问（参见“四、多任务系统中驱动程序实现的问题和方法”）。测试系统在main函数中成功创建了一个MUTEX，并传递了PIP为3的参数值。同时测试系统创建了一个优先级为0级的任务，这个任务运行一次后就调用OSTaskDel(OS_PRIO_SELF)将自己删除。任务将自己删除以后操作系统应该永远不会再调度该任务（参见uC/OS－II书籍），可是测试发现这个优先级为0的任务继续运行。通过调试跟踪发现，调用OSMutexCreate函数创建MUTEX时，传递的PIP参数值（值为3）没有被函数保存到ECB结构中，而是将0保存到ECB中，从而使操作系统认为创建MUTEX时传递了PIP为0的参数。这样，在后面调用OSMutexPend的函数中将优先级为0的任务又改变成就绪状态并得以继续运行，使uC/OS－II操作系统出现了调度错误。
这个错误在uC/OS－II后续的版本中做了修改。例如V2.88就没有这个问题。