uC/OS-II系统开发笔记

uC/OS-II是一个简洁、易用的基于优先级的嵌入式抢占式多任务实时内核。尽管它非常简单，但是它的确在很大程度上解放了我的嵌入式开发工作。既然是一个操作系统内核，那么一旦使用它，就会涉及到如何基于操作系统设计应用软件的问题。

1、uC/OS-II的任务框架

void  task_xxx(void *pArg)
{
    /* 该任务的初始化工作 */

……    

    /* 进入该任务的死循环 */
    while(1)
    {
……
}
}

   每个用户的任务都必须符合事件驱动的编程模型，即uC/OS-II的应用程序都必须是“事件驱动的编程模型”。一个任务首先等待一个事件的发生，事件可以是系统中断发出的，也可以是其它任务发出的，又可以是任务自身等待的时间片。当一个事件发生了，任务再作相应处理，处理结束后又开始等待下一个事件的发生。如此周而复始的任务处理模型就是“事件驱动的编程模型”。事件驱动模型也涵盖了中断驱动模型，uC/OS-II事件归根结底来自三个方面：
(1)中断服务函数发送的事件
(2)系统延时时间到所引起的
(3)其它任务发送的事件。
   其中“中断服务函数发送的事件”就是指每当有硬件中断发生，那么中断服务程序就会以事件的形式告诉任务，而等待该事件的最高优先级任务就会马上得以运行；“系统延时时间到所引起的”事件其实也是硬件中断导致的，那就是系统定时器中断。而“其它任务发送的事件”则是由任务代码自身决定的，这是完全的“软事件”。不管“软事件”还是“硬事件”，反正引起uC/OS-II任务切换的原因就是“事件”，所以用户编写应用代码的时候一定要体现出“事件驱动的编程模型”。

2、uC/OS-II的任务优先级分配
   uC/OS-II的任务优先级分配需要按照不同的系统设计具体分析。比如，对实时性要求越高的任务，则优先级要越高。

3、uC/OS-II的软件层次
   uC/OS-II会直接操纵硬件，比如：任务切换代码必然要保存和恢复CPU及协处理器的寄存器；uC/OS-II的内核时基时钟就需要硬件定时器的中断。

   BSP就是“板极支持包”，它包括基于uC/OS-II而开发的事件驱动模型、支持多任务的驱动程序，这些驱动程序直接控制各个硬件模块并利用uC/OS-II的系统函数来实现多任务功能，它们应该尽量避免应用程序直接操纵硬件和uC/OS-II内核。BSP还应该为应用程序提供标准、统一的API，以达到软件层次分明、应用软件代码可复用的目的。

   应用程序就是用户为具体应用需要而开发的软件，它必须符合uC/OS-II的编程模型，即“事件驱动的编程模型”。应用程序还应该尽量避免直接控制硬件和直接调用uC/OS-II系统函数、变量，一个完善的uC/OS-II系统是不需要应用程序来针对具体硬件而设计的。也就是说，uC/OS-II必须拥有完备的设备驱动程序，而驱动程序和BSP共同提供完备、标准的API。

4、uC/OS-II中使用互斥信号对象应该注意
   互斥信号对象(Mutual Exclusion Semaphore)简称Mutex，是uC/OS-II的内核对象之一，用于管理那些需要独占访问的资源，并使其适应多任务环境。

   创建每一个Mutex，都需要指定一个空闲的优先级号，这个优先级号的优先级必须比所有可能使用此Mutex的任务的优先级都高！

   uC/OS-II的Mutex实现原理大致如下：
   当一个低优先级的任务A申请并得到了Mutex，于是它获得资源访问权。如果此后有一个高优先级的任务B开始运行(此时任务A已经被剥夺)，而且也要求得到Mutex，系统就会把任务A的优先级提高到Mutex所指定的优先级。由于此优先级高于任何可能使用此Mutex的任务的优先级，所以任务A会马上获得CPU控制权。一直到任务A释放Mutex，任务A才回到它原有的优先级，这时任务B就可以拥有该Mutex了。

   应该注意的是：当任务A得到Mutex后，就不要再等待其它内核对象(诸如：信号量、邮箱、队列、事件标志等等)了，而应该尽量快速的完成工作，释放Mutex。否则，这样的Mutex就失去了作用，而且效果比直接使用信号量(Sem)更糟糕！

   虽然普通的信号量(Sem)也可以用于互斥访问某独占资源，但是它可能引起“优先级反转”的问题。假设上面的例子使用的是Sem，当任务A得到Sem后，那么任务C(假设任务C的优先级比A高，但比B低)就绪的话将获得CPU控制权，于是任务A和任务B都被剥夺CPU控制权。任务C的优先级比B低，却优先得到了CPU！而如果任务A是优先级最低的任务，那么它就要等到所有比它优先级高的任务都挂起之后才会拥有CPU，那么任务B(优先级最高的任务)跟着它一起倒霉！这就是优先级反转问题，这是违背“基于优先级的抢占式多任务实时操作系统”原则的！

   综上所述，uC/OS-II中多个任务访问独占资源时，最好使用Mutex，但是Mutex是比较消耗CPU时间和内存的。如果某高优先级的任务要使用独占资源，但是不在乎久等的情况下，就可以使用Sem，因为Sem是最高效最省内存的内核对象。

5、uC/OS-II应用程序调用OSSchedLock()和OSSchedUnlock()函数应注意
uC/OS-II的OSSchedLock()和OSSchedUnlock()函数允许应用程序锁定当前任务不被其它任务抢占。使用时应当注意的是：当你调用了OSSchedLock()之后，而在调用OSSchedUnlock()之前，千万不要再调用诸如OSFlagPend()、OSMboxPend()、OSMutexPend()、OSQPend()、OSSemPend()之类的事件等待函数！而且应当确保OSSchedLock()和OSSchedUnlock()函数成对出现，特别是在有些分支条件语句中，要考虑各种分支情况，不要有遗漏！

   需要一并提醒用户的是：当您调用开关中断函数OS_ENTER_CRITICAL()和OS_EXIT_CRITICAL()时也要确保成对出现，否则系统将可能崩溃！不过，在OS_ENTER_CRITICAL()和OS_EXIT_CRITICAL()函数之间调用OSFlagPend()、OSMboxPend()、OSMutexPend()、OSQPend()、OSSemPend()之类的事件等待函数是允许的。

6、uC/OS-II驱动程序编写规范，特别推荐
首先应该阐明的是，我们这里讨论的是“驱动程序”，而不是“中断服务程序”，这两个词语往往被用户混淆。
(1)中断服务程序指那种硬件中断一旦发生，就会立即被硬件中断控制器调用的一小段程序，它的操作追求简单明了，越快速越精简就越好。
(2)驱动程序是指封装了某种硬件操作细节的函数集，它提供给应用程序的是统一、标准、清晰、易用的API。

   对于中断服务程序的编写，往往与驱动程序的设计相关联。比如驱动程序提供异步操作的功能，那么就需要中断服务程序为它准备缓冲区和一个结构体，并且中断服务程序会依照这个结构体的成员参数自动完成所要求的操作。又如，串口(UART)中断服务程序的设计有两种：基于数据包传输和基于单字节传输，前者适用于以数据包为单位的通信程序，而后者适用于如超级终端这样的应用程序。

   如果在一个系统中，要求使用同一个硬件设备完成几种不同的操作方式，就需要设计一个通用的驱动程序，而该驱动程序可以根据需要安装各种针对性很强的中断服务程序。

   在设计驱动程序时，特别需要注意的是，某些外设的操作往往以一个连续而严格的时序作为原子操作，比如用I/O端口来访问DS1302、24C01、LM75A等等。在这类设备的操作过程中，不允许有其它任务来控制对应的I/O端口，否则会引起数据错误甚至器件损坏。所以，这种设备的驱动程序都应该仔细设计“原子操作”，把必须连贯操作的时序控制代码用互斥对象封装成一个“原子操作”，以适应多任务环境。其实，大部分设备都是这样，需要确定“原子操作”，如LCD、RTL8019AS、Flash等等也是如此。

   关于驱动程序的设计，还有很多很多的文章可作，需要具体问题具体分析。在这里我就不列出个条条目目了，希望有兴趣的朋友多多讨论。