发布时间 : 星期五 文章UCOS-II操作系统详解更新完毕开始阅读
的，沿用的是以前前后台设计的思路。
对于这样的设计方式，时钟节拍的处理方式必须和一般的中断处理方式是一样的。一般来说，MSP430使用WATCHDOG时钟中断作为时钟节拍的产生源。从本质上来说，时钟节拍本身也是中断处理过程，所以对于时钟节拍的处理应该和其它的中断处理过程相同。实际上，在时钟节拍的处理过程中也可能会存在中断嵌套的问题。
中断堆栈和任务堆栈分离设计的程序流程如图6所示。
8相关建议编辑
① 编写中断程序的时候，有条件尽量使用汇编语言。因为这样可以避免一些编译器自己进行的操作，减少指针调整的次数。
② 在用C编写中断服务的时候，因为有些功能必须调用汇编的函数才能实现。调用函数时，有些时候压栈的PC会破坏堆栈的结构。这个时候需要把堆栈进行适当的调整，保证堆栈格式的正确。
③中断处理过程中调用OSIntExit()的时候，由于 μC/OS-II的原始设计中SP指针有时是不调整的，所以在OSIntExit()返回了以后，还要判断一下是否中断嵌套。因为有的时候是需要切换任务的。
(综合电子论坛)
9优先级编辑
运行机制
在嵌入式系统的应用中，实时性是一个重要的指标，而优先级翻转是影响系统实时性的重要问题。本文着重分析优先级翻转问题的产生和影响，以及在uC/OS-II中的解决方案。[2]
uC/OS-II采用基于固定优先级的占先式调度方式，是一个实时、多任务的操作系统。系统中的每个任务具有一个任务控制快OS_TCB，任务控制块记录任务执行的环境，包括任务的优先级，任务的堆栈指针，任务的相关事件控制块指针等。内核将系统中处于就绪态的任务在就绪表(ready list)进行标注，通过就绪表中的两个变量OSRdyGrp和OSRdyTbl[]可快速查找系统中就绪的任务。在uC/OS-II中每个任务有唯一的优先级，因此任务的优先级也是任务的唯一编号(ID)，可以作为任务的唯一标识。内核可用控制块优先级表OSTCBPrioTbl[]由任务的优先级查
到任务控制块的地址。uC/OS-II主要就是利用任务控制快OS_TCB、就绪表(ready list)和控制块优先级表OSTCBPrioTbl[]来进行任务调度的。任务调度程序OSSched()首先由就绪表(ready list)中找到当前系统中处于就绪态的优先级最高的任务，然后根据其优先级由控制块优先级表OSTCBPrioTbl[]取得相应任务控制块的地址，由OS_TASK_SW()程序进行运行环境的切换。将当前运行环境切换成该任务的运行环境，则该任务由就绪态转为运行态。当这个任务运行完毕或因其它原因挂起时，任务调度程序OSSched()再次到就绪表(ready list)中寻找当前系统中处于就绪态中优先级最高的任务，转而执行该任务，如此完成任务调度。若在任务运行时发生中断，则转向执行中断程序，执行完毕后不是简单的返回中断调用处，而是由OSIntExit()程序进行任务调度，执行当前系统中优先级最高的就绪态任务。当系统中所有任务都执行完毕时，任务调度程序OSSched()就不断执行优先级最低的空闲任务OSTaskIdle()，等待用户程序的运行。[2]
优先翻转
在uC/OS-II中，多个任务按照优先级高低由内核调度执行，而且任务调度所花的时间是常数，与应用程序中建立的任务数无关。对于占先式内核，任务的响应时间是确定的，而且是最优化的，占先式内核保证最高优先级的任务最先执行。[2]
任务的响应时间=寻找最高优先级任务的时间+任务切换时间
在uC/OS-II中寻找进入就绪态的最高优先级任务是通过查就绪表实现的，这减少了所需时间。
y=OSUnMapTbl[OSRdyGrp]; x= OSUnMapTbl [OSRdyTbl[y]]; prio=(y<<3)+x;
任务切换是通过调用汇编函数OS_TASK_SW()来实现的，主要完成两个任务运行环境的保存和恢复。因此用户可以通过安排任务的优先级，保证系统的实时性。当涉及到共享资源的互斥访问时，多任务实时操作系统常常会出现优先级翻转问题(priority inversion)，不能保证高优先级任务的响应时间，影响系统的实时性，uC/OS-II中也存在同样问题。所谓优先级翻转问题(priority inversion)即当一个高优先级任务通过信号量机制访问共享资源时，该信号量已被一低优先级任务占有，而这个低优先级任务在访问共享资源时可能又被其它一些中等优先级的任务抢先，因此造成高优先级任务被许多具有较低优先级的任务阻塞，实时性难以得到保证。例如：有优先级为A、B和C的三个任务，优先级A>B>C，任务A，B处于挂起状态，等待某一事件的发生，任务C正在运行，此时任务C开始使用某一共享资源S。在使用中，任务A等待的事件到来，任务A转为就绪态，因为它比任务C优先级高，所以立即执行。当任务A要使用共享资源S时，由于其正在被任务C使用，因此任务A被挂起，任务C开始运行。如果此时任务B等待的事件
到来，则任务B转为就绪态。由于任务B的优先级比任务C高，因此任务B开始运行，直到其运行完毕，任务C才开始运行。直到任务C释放共享资源S后，任务A才得以执行。在这种情况下，优先级发生了翻转，任务B先于任务A运行。这样便不能保证高优先级任务的响应时间，解决优先级翻转问题有优先级天花板(priority ceiling)和优先级继承(priority inheritance)两种办法。[2]
优先级天花板是当任务申请某资源时，把该任务的优先级提升到可访问这个资源的所有任务中的最高优先级，这个优先级称为该资源的优先级天花板。这种方法简单易行，不必进行复杂的判断，不管任务是否阻塞了高优先级任务的运行，只要任务访问共享资源都会提升任务的优先级。在uC/OS-II中，可以通过OSTaskChangePrio()改变任务的优先级，但是改变任务的优先级是很花时间的。如果不发生优先级翻转而提升了任务的优先级，释放资源后又改回原优先级，则无形中浪费了许多CPU时间，也影响了系统的实时性。
优先级继承是当任务A申请共享资源S时，如果S正在被任务C使用，通过比较任务C与自身的优先级，如发现任务C的优先级小于自身的优先级，则将任务C的优先级提升到自身的优先级，任务C释放资源S后，再恢复任务C的原优先级。这种方法只在占有资源的低优先级任务阻塞了高优先级任务时才动态的改变任务的优先级，如果过程较复杂，则需要进行判断。uC/OS-II不支持优先级继承，而且其以任务的优先级作为任务标识，每个优先级只能有一个任务，因此，不适宜在应用程序中使用优先级继承。[2]
翻转解决
在uC/OS-II中，为解决优先级翻转影响任务实时性的问题，可以借鉴优先级继承的方法对优先级天花板方法进行改进。对uC/OS-II的使用，共享资源任务的优先级不是全部提升，而是先判断再决定是否提升。即当有任务A申请共享资源S时，首先判断是否有别的的任务正在占用资源S，若无，则任务A继续执行，若有，假设为任务B正在使用该资源，则判断任务B的优先级是否低于任务A，若高于任务A，则任务A挂起，等待任务B释放该资源，如果任务B的优先级低于任务A，则提升任务B的优先级到该资源的优先级天花板，当任务B释放资源后，再恢复到原优先级。在uC/OS-II中，每个共享资源都可看作一个事件，每个事件都有相应的事件控制块ECB。在ECB中包含一个等待本事件的等待任务列表，该列表包括OSEventTbl[]和OSEventGrp两个域，通过对等待任务列表的判断可以很容易的确定是否有多个任务在等待该资源，同时也可判断任务的优先级与当前任务优先级的高低，从而决定是否需要用OSTaskChangePio()来改变任务的优先级。这样，仅在优先级有可能发生翻转的情况下才改变任务的优先级，而且利用事件的等待任务列表进行判断，比用OSTaskChangePio()来改变任务的优先级速度快，并占用较少的CPU时间，有利于系统实时性的提高。[2]
总之，优先级翻转问题是多任务实时操作系统普遍存在的问题，这个问题也存在于uC/OS-II中。通过在应用程序中进行简单的判断，在可能出现优先级翻转的情况下动态的改变任务的优先级，可以有效地避免任务的优先级翻转，保证高优先级任务的执行，提高了系统的实时性。[2]
10开发笔记编辑
uC/OS-II是一个简洁、易用的基于优先级的嵌入式抢占式多任务实时内核。尽管它非常简单，但是它的确在很大程度上解放了我的嵌入式开发工作。既然是一个操作系统内核，那么一旦使用它，就会涉及到如何基于操作系统设计应用软件的问题。
任务框架
void task_xxx(void *pArg) {
/* 该任务的初始化工作 */ ……
/* 进入该任务的死循环 */ while(1) { …… } }
每个用户的任务都必须符合事件驱动的编程模型，即uC/OS-II的应用程序都必须是“事件驱动的编程模型”。一个任务首先等待一个事件的发生，事件可以是系统中断发出的，也可以是其它任务发出的，又可以是任务自身等待的时间片。当一个事件发生了，任务再作相应处理，处理结束后又开始等待下一个事件的发生。如此周而复始的任务处理模型就是“事件驱动的编程模型”。事件驱动模型也涵盖了中断驱动模型，uC/OS-II事件归根结底来自三个方面： (1)中断服务函数发送的事件 (2)系统延时时间到所引起的 (3)其它任务发送的事件。
其中“中断服务函数发送的事件”就是指每当有硬件中断发生，那么中断服务程序就会以事件的形式告诉任务，而等待该事件的最高优先级任务就会马上得以运行；“系统延时时间到所引起的”事件其实也是硬件中断导致的，那就是系统定时器中断。而“其它任务发送的事件”则是由任务代码自身决定的，这是完全的“软事件”。不管“软事件”还是“硬事件”，反正引起uC/OS-II任务切换的原因就是“事件”，所以用户编写应用代码的时候一定要体现出“事件驱动的编程模型”。
任务分配