uCOS-II
在uCOS-II实时内核下，对外设的访问接口没有统一完善，有很多工作需要用户自己去完成。串口通信是单片机测控系统的重要组成部分，异步串行口是一个比较简单又很具代表性的中断驱动外设。本文以单片机中的串口为例，介绍uCOS—II下编写中断服务程序以及外设驱动程序的一般思路。
1、uCOS-II的中断处理及51系列单片机中断系统分析
uCOS-II中断服务程序(ISR)一般用汇编语言编写。以下是中断服务程序的步骤。
保存全部CPU寄存器；调用OSIntEnter()或OSIntNesting(全局变量)直接加1； 执行用户代码做中断服务； 调用OSIntExit()； 恢复所有CPU寄存器； 执行中断返回指令。
uCOS-II提供两个ISR与内核接口函数；OSIntEnter（）和OSIntExit（）。OSIntEnter（）通知uCOS-II核，中断服务程序开始了。事实上，此函数做的工作是把一个全局变量OSIntNesting加1，此中断嵌套计数器可以确保所有中断处理完成后再做任务调度。另一个接口函数OSIntExit（）则通知内核，中断服务已结束。根据相应情况，退回被中断点（可能是一个任务或者是被嵌套的中断服务程序）或由内核作任务调度。
用户编写的ISR必须被安装到某一位置，以便中断发生后，CPU根据相应的中断号运行准确的服务程序。许多实时操作系统都提供了安装和卸载中断服务程序的 API接口函数，但uCOS-II内核没有提供类似的接口函数，需要用户在对CPU的移植中自己实现。这些接口函数与具体的硬件环境有关，接下来以51单片机下的中断处理对此详细说明。
51单片机的中断基本过程如下：CPU在每个机器周期的S5P2时刻采样中断标志，而在下一指令周期将对采样的中断进行查询。如果有中断请求，则按照优先级高低的原则进行处理。响应中断时，先置相应的优先级激活触发器于相应位，封锁同级或低级中断，然后根据中断源类别，在硬件控制下，将中断地址压入堆栈，并转向相应的中断向量入口单元。通常在入口单元处放一跳转指令，转向执行中断服务程序．当执行中断返回指令RETI时，把响应中断时所置位的优先级激活触发器清零后，从堆栈中弹出被保护的断点地址，装入程序计数器PC，CPU返回原来被中断处继续执行程序。
在移植的过程中，采用Keil C51作为编译环境。Keil C5l集成C编译和汇编器。中断子程序用汇编语言编写，放到移植uCOS-II后的OS_CPU_A.ASM汇编文件中。下面是以串行口中断为例的移植中断服务子程序代码。
CSEGAT0023H ；串口中断响应入口地址
LJMPSerialISR；转移到串口中断子程序入口地址
RSEG？PR?SeriallSR？OS_CPU_A
SerialISR：
USINGO
CLR EA ；先关中断，以防中断嵌套
PUSHALL ；已定义的压栈宏，用于将CPU寄存器的值压入堆栈
LCALL_?OSIntEnter ；监视中断嵌套
LCALL_?Serial ；串口中断服务程序
LCALL_?OSintExlt
SETBEA
POPALL；已定义的出栈宏，将CPU寄存器的值出栈
RETI
2、串口驱动程序
笔者已在5l单片机上成功移植了uCOS-II内核，移植过程在此不再讨论。这里重点分析uC0S—II内核下串口驱动程序编写。
由于串行设备存在外设处理速度和CPU速度不匹配的问题，所以需要一个缓冲区．向串口发送数据时，只要把数据写到缓冲区中，然后由串口逐个取出往外发。从串口接收数据时，往往等收到若干个字节后才需要CPU进行处理，所以这些预收的数据可以先存于缓冲区中。实际上，单片机的异步串口中只有两个相互独立、地址相同的接收、发送缓冲寄存器SBUF。在实际应用中，需要从内存中开辟两个缓冲区，分别为接收缓冲区和发送缓冲区。这里把缓冲区定义为环形队列的数据结构。
uCOS-II内核提供了信号量作为通信和同步的机制，引入数据接收信号量、数据发送信号量分别对缓冲区两端的操作进行同步。串口的操作模式如下：用户任务想写，但缓冲区满时，在信号量上睡眠，让CPU运行别的任务，待ISR从缓冲区读走数据后唤醒此睡眠的任务；同样，用户任务想读，但缓冲区空时，也可以在信号量上睡眠，待外部设备有数据来了再唤醒。由于uCOS-II的信号量提供了超时等待机制，串口当然也具有超时读写能力。
图1是带缓冲区和信号量的串口接收示意图。数据接收信号量初始化为0，表示在环形缓冲区中无数据。
接收中断到来后，ISR从UART的接收缓冲器SBUF中读入接收的字节(②)，放入接收缓冲区(③)，然后通过接收信号量唤醒用户任务端的读操作(④、 ①)。在整个过程中，可以查询记录缓冲区中当前字节数的变量值，此变量表明接收缓冲区是否已满。UART收到数据并触发了接收中断，但如果此时缓冲区是满的，那么放弃收到的字符。缓冲区的大小应合理设置，降低数据丢失的可能性，又要避免存储空间的浪费。
图2为带环形缓冲区和超时信号量的串口发送示意图。发送信号量初始值设为发送缓冲区的大小，表示缓冲区已空，并且关闭发送中断。发送数据时，用户任务在信号量上等待(①)。如果发送缓冲区未满，用户任务向发送缓冲区中写入数据(②)。如果写入的是发送缓冲区中的第一个字节，则允许发送中断(②)。然后，发送ISR从发送缓冲区中取出最早写入的字节输出至UART(④)，这个操作又触发了下一次的发送中断，如此循环直到发送缓冲区中最后一个字节被取走，重新关闭发送中断。在ISR向UART输出的同时，给信号量发信号(⑤)，发送任务据此信号量计数值来了解发送缓冲区中是否有空间。
3、串口通信模块的设计
每个串行端口有两个环状队列缓冲区，同时有两个信号量：一个用来指示接收字节，另一个用来指示发送字节。每个环状缓冲区有以下四个要素：
存储数据(INT8U数组)； 包含环状缓冲区字节数的计数器； 环状缓冲区中指向将被放置的下一字节的指针； 环状缓冲区中指向被取出的下一字节的指针。
图3是接收数据软件模块的流程图。SerialGetehar（）用来获取接收到的数据，如果缓冲区已空时将任务挂起，接收到字节时，任务将被唤醒，同时从串行口接收字节。SerialPutRxChar()用来将接收的字节放到缓冲区中，如果接收缓冲区已满，则该字节被丢弃。当字节插入到缓冲区中，SerialPutRxChar()通知数据接收信号量，使之将数据己到的消息传达给所有等待的任务。为防止挂起应用任务，可以通过调用 SceiallsEmPty()去发现环状队列中是否有字节。
图4是发送数据模块的流程图。当需要发送数据给串行端口时，SerialPurChar()等待信号量在初始化发送信号量时应该初始为缓冲区的大小。因此，当缓冲区中没有更多空间时，SerialPutChar()就挂起任务，只要UART再次发送字节，挂起任务就将恢复。 SerialGctChar()被中断服务程序调用，如果发送缓冲区至少还有一个字节，Seri-a1GetChar()就返回一个从缓冲区发送的字节。如果缓冲区己空，则SerialGetChar()返回Null，这将使调用停止进一步的发送中断，一直到有数据发送为止。
4、异步串行通信的接口函数
应用任务可以通过如下的几个函数来控制和访问UART：SerialCfgPort()、SerialGetChar()、SerialInit()、SerialIsEmpty()、SerialIsFull()和SerialPutChar()。
SerialCfgPort()用于建立串行端口的特征，在为指定端口调用其他服务前，必须先调用该函数，包括确定波特率、比特数、奇偶校验和停止位等。
SerialGetChar()使应用程序从接收数据的环状缓冲区中取出数据。
SerialInit()用于初始化整个串口软件模块，且必须在该模块提供的其他任何服务前调用。SeriallInit()将环状缓冲区计数器的字节数清零，并初始化每个环状缓冲区的IN和OUT指针，指向数据存储区的开始处。数据接收信号量初始化为0，表示在环状缓冲区无数据。用传送缓冲区大小初始化数据传送信号量，表示缓冲区已空。
SerialIsEmpty()允许应用程序确定是否有字节从串口接收进来。本函数允许在无数据时避免将任务挂起。
SerialIsFull()允许应用程序确定传送环状缓冲区的状态，本函数可以在缓冲区已满时避免将任务挂起。
SerialPutChar()允许应用程序向一个串行端口发送数据。
5、结语
该串口通信模块充分利用了实时内核的任务调度功能和信号量机制，系统软件模块化，可读性增强，便于修改和移植，其设计思路和方法可以很好的应用在多种情况下的测控系统中，系统的扩展方便，具有一定的借鉴作用。该串口通信模块已作为某铁路供水远程控制终端的一部分，运行稳定，提高了整个系统的运行效率和实时性。
转自：畅学电子网
ucos ii是由Labrosse先生编写的一个开放式内核，最主要的特点就是源码公开。这一点对于用户来说可谓利弊各半，好处在于，一方面它是免费的，另一方面用户可以根据自己的需要对它进行修改。缺点在于它缺乏必要的支持，没有功能强大的软件包，用户通常需要自己编写驱动程序，特别是如果用户使用的是不太常用的单片机，还必须自己编写移植程序。
ucos ii是一个占先式的内核，即已经准备就绪的高优先级任务可以剥夺正在运行的低优先级任务的CPU使用权。这个特点使得它的实时性比非占先式的内核要好。通常我们都是在中断服务程序中使高优先级任务进入就绪态（例如发信号），这样退出中断服务程序后，将进行任务切换，高优先级任务将被执行。拿51单片机为例，比较一下就可以发现这样做的好处。假如需要用中断方式采集一批数据并进行处理，在传统的编程方法中不能在中断服务程序中进行复杂的数据处理，因为这会使得关中断时间过长。所以经常采用的方法是置一标志位，然后退出中断。由于主程序是循环执行的，所以它总有机会检测到这一标志并转到数据处理程序中去。但是因为无法确定发生中断时程序到底执行到了什么地方，也就无法判断要经过多长时间数据处理程序才会执行，中断响应时间无法确定，系统的实时性不强。如果使用μC/OS-II的话，只要把数据处理程序的优先级设定得高一些，并在中断服务程序中使它进入就绪态，中断结束后数据处理程序就会被立即执行。这样可以把中断响应时间限制在一定的范围内。对于一些对中断响应时间有严格要求的系统，这是必不可少的。但应该指出的是如果数据处理程序简单，这样做就未必合适。因为ucos ii要求在中断服务程序末尾使用OSINTEXIT函数以判断是否进行任务切换，这需要花费一定的时间。
ucos ii和大家所熟知的Linux等分时操作系统不同，它不支持时间片轮转法。ucos ii是一个基于优先级的实时操作系统，每个任务的优先级必须不同，分析它的源码会发现，ucos ii把任务的优先级当做任务的标识来使用，如果优先级相同，任务将无法区分。进入就绪态的优先级最高的任务首先得到CPU的使用权，只有等它交出CPU的使用权后，其他任务才可以被执行。所以它只能说是多任务，不能说是多进程，至少不是我们所熟悉的那种多进程。显而易见，如果只考虑实时性，它当然比分时系统好，它可以保证重要任务总是优显患有CPU。但是在系统中，重要任务毕竟是有限的，这就使得划分其他任务的优先权变成了一个让人费神的问题。另外，有些任务交替执行反而对用户更有利。例如，用单片机控制两小块显示屏时，无论是编程者还是使用者肯定希望它们同时工作，而不是显示完一块显示屏的信息以后再显示另一块显示屏的信息。这时候，要是ucos ii即支持优先级法又支持时间片轮转法就更合适了。
ucos ii对共享资源提供了保护机制。正如上文所提到的，ucos ii是一个支持多任务的操作系统。一个完整的程序可以划分成几个任务，不同的任务执行不同的功能。这样，一个任务就相当于模块化设计中的一个子模块。在任务中添加代码时，只要不是共享资源就不必担心互相之间有影响。而对于共享资源（比如串口），ucos ii也提供了很好的解决办法。一般情况下使用的是信号量的方法。简单地说，先创建一个信号量并对它进行初始化。当一个任务需要使用一个共享资源时，它必须先申请得到这个信号量，而一旦得到了此信号量，那就只有等使用完了该资源，信号量才会被释放。在这个过程中即使有优先权更高的任务进入了就绪态，因为无法得到此信号量，也不能使用该资源。这个特点的好处显而易见，例如当显示屏正在显示信息的时候，外部产生了一个中断，而在中断服务程序中需要显示屏显示其他信息。这样，退出中断服务程序后，原有的信息就可能被破坏了。而在μC/OS-II中采用信号量的方法时，只有显示屏把原有信息显示完毕后才可以显示新信息，从而可以避免这个现象。不过，采用这种方法是以牺牲系统的实时性为代价的。如果显示原有信息需要耗费大量时间，系统只好等待。从结果上看，等于延长了中断响应时间，这对于未显示信息是报警信息的情况，无疑是致命的。发生这种情况，在μC/OS-II中称为优先级反转，就是高优先级任务必须等待低优先级任务的完成。在上述情况下，在两个任务之间发生优先级反转是无法避免的。所以在使用ucos ii时，必须对所开发的系统了解清楚，才能决定对于某种共享资源是否使用信号量。
ucos ii在单片机使用中的一些特点
1．在单片机系统中嵌入ucos ii将增强系统的可靠性，并使得调试程序变得简单。以往传统的单片机开发工作中经常遇到程序跑飞或是陷入死循环。可以用看门狗解决程序跑飞问题，而对于后一种情况，尤其是其中牵扯到复杂数学计算的话，只有设置断点，耗费大量时间来慢慢分析。如果在系统中嵌入 ucos ii的话，事情就简单多了。可以把整个程序分成许多任务，每个任务相对独立，然后在每个任务中设置超时函数，时间用完以后，任务必须交出 CPU的使用权。即使一个任务发生问题，也不会影响其他任务的运行。这样既提高了系统的可靠性，同时也使得调试程序变得容易。
2．在单片机系统中嵌入ucos ii将增加系统的开销。现在所使用的51单片机，一般是指87C51或者89C51，其片内都带有一定的RAM和 ROM。对于一些简单的程序，如果采用传统的编程方法，已经不需要外扩存储器了。如果在其中嵌入ucos ii的话，在只需要使用任务调度、任务切换、信号量处理、延时或超时服务的情况下，也不需要外扩ROM了，但是外扩RAM是必须的。由于ucos ii是可裁减的操作系统，其所需要的RAM大小就取决于操作系统功能的多少。举例来说，μC/OS-II允许用户定义最大任务数。由于每建立一个任务，都要产生一个与之相对应的数据结构TCB，该数据结构要占用很大一部分内存空间。所以在定义最大任务数时，一定要考虑实际情况的需要。如果定得过大，势必会造成不必要的浪费。嵌入ucos ii以后，总的RAM需求可以由如下表达式得出：
RAM总需求=应用程序的RAM需求+内核数据区的RAM需求+（任务栈需求+最大中断嵌套栈需求）·任务数
所幸的是，μC/OS-II可以对每个任务分别定义堆栈空间的大小，开发人员可根据任务的实际需求来进行栈空间的分配。但在RAM容量有限的情况下，还是应该注意一下对大型数组、数据结构和函数的使用，别忘了，函数的形参也是要推入堆栈的。
3．ucos ii的移植也是一件需要值得注意的工作。如果没有现成的移植实例的话，就必须自己来编写移植代码。虽然只需要改动两个文件，但仍需要对相应的微处理器比较熟悉才行，最好参照已有的移植实例。
另外，即使有移植实例，在编程前最好也要阅读一下，因为里面牵扯到堆栈操作。在编写中断服务程序时，把寄存器推入堆栈的顺序必须与移植代码中的顺序相对应。
转自： ChunJian-YANG
