uCOS-II系统应用开发.docVIP

uC/OS-II系统应用开发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的任务优先级分配需要按照不同的系统设计具体分析。比如，对实时性要求越高的任务，则优先级要越高。互斥对象(Mutex)的优先级必须高于一切使用该互斥对象的任务的优先级。 [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必须拥有完备的设备驱动程序，必须提供完备、标准的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后，然后任务B也要使用Sem，于是任务A和任务B都被剥夺CPU控制权，而任务C(假设任务C的优先级比A高，但比B