uC/OS-II 应用程序基本结构

推荐程序员们尽量少使用这两个宏调用，因为他们的确会破坏系统的多任务性能。

６） OSTimeDly函数

　　这应该程序员们调用最多的一个函数了，这个函数完成功能很简单，就是先挂起当起当前任务，然后进行任务切换，在指定的时间到来之后，将当前任务恢复为就绪状态，但是并不一定运行，如果恢复后是优先级最高就绪任务的话，那么运行之。简单点说，就是可以任务延时一定时间后再次执行它，或者说，暂时放弃CPU的使用权。一个任务可以不显式的调用这些可以导致放弃CPU使用权的API，但那样多任务性能会大大降低，因为此时仅仅依靠时钟机制在进行任务切换。一个好的任务应该在完成一些操作主动放弃使用权，好东西要大家分享嘛！

（四） uC/OS-II 多任务实现机制分析

　　前面已经说过，uC/OS-II是一种基于优先级的可抢先的多任务内核。那么，它的多任务机制到底如何实现的呢？了解这些原理，可以帮助我们写出更加健壮的代码来。由于我们面向的初级程序员，本文不打算写成又一篇uC/OS-II的源码分析，那样的文章太多了，本文打算从实现原理的角度探讨这个问题。

　　首先我们来看看为什么多任务机制可以实现？其实在单一CPU的情况下，是不存在真正的多任务机制的，存在的只有不同的任务轮流使用CPU，所以本质上还是单任务的。但由于CPU执行速度非常快，加上任务切换十分频繁并且切换的很快，所以我们感觉好像有很多任务同时在运行一样。这就是所谓的多任务机制。

　　由上面的描述，不难发现，要实现多任务机制，那么目标CPU必须具备一种在运行期更改PC的途径，否则无法做到切换。不幸的使，直接设置PC指针，目前还没有哪个CPU支持这样的指令。但是一般CPU都允许通过类似JMP，CALL这样的指令来间接的修改PC。我们的多任务机制的实现也正是基于这个出发点。事实上，我们使用CALL指令或者软中断指令来修改PC，主要是软中断。但在一些CPU上，并不存在软中断这样的概念，所以，我们在那些CPU上，使用几条PUSH指令加上一条CALL指令来模拟一次软中断的发生。

　　回想一下你在微机原理课程上学过的知识，当发生中断的时候，CPU保存当前的PC和状态寄存器的值到堆栈里，然后将PC设置为中断服务程序的入口地址，再下来一个机器周期，就可以去执行中断服务程序了。执行完毕之后，一般都是执行一条RETI指令，这条指令会把当前堆栈里的值弹出恢复到状态寄存器和PC里。这样，系统就会回到中断以前的地方继续执行了。那么设想一下？如果再中断的时候，人为的更改了堆栈里的值，那会发生什么？或者通过更改当前堆栈指针的值，又会发生什么呢？如果更改是随意的，那么结果是无法预料的错误。因为我们无法确定机器下一条会执行些什么指令，但是如果更改是计划好的，按照一定规则的话，那么我们就可以实现多任务机制。事实上，这就是目前几乎所有的OS的核心部分。不过他们的实现不像这样简单罢了。

　　下面，我们来看看uC/OS-II再这方面是怎么处理的。再uC/OS-II里，每个任务都有一个任务控制块(Task Control Block)，这是一个比较复杂的数据结构。在任务控制快的偏移为0的地方，存储着一个指针，它记录了所属任务的专用堆栈地址。事实上，再uC/OS-II内，每个任务都有自己的专用堆栈，彼此之间不能侵犯。这点要求程序员再他们的程序中保证。一般的做法是把他们申明成静态数组。而且要申明成OS_STK类型。当任务有了自己的堆栈，那么就可以将每一个任务堆栈再那里记录到前面谈到的任务控制快偏移为0的地方。以后每当发生任务切换，系统必然会先进入一个中断，这一般是通过软中断或者时钟中断实现。然后系统会先把当前任务的堆栈地址保存起来，仅接着恢复要切换的任务的堆栈地址。由于哪个任务的堆栈里一定也存的是地址（还记得我们前面说过的，每当发生任务切换，系统必然会先进入一个中断，而一旦中断CPU就会把地址压入堆栈），这样，就达到了修改PC为下一个任务的地址的目的。

　　以上就是uC/OS-II的多任务实现机制，我们在这里大费笔墨谈论这个问题，是希望我们的程序员们可以善加利用这个机制，写出更健壮，更富有效率的代码来。