前面我们所有的实验都是跑的裸机程序（裸奔），从本章开始，我们开始介绍UCOSII（实时多任务操作系统内核）。
UCOSII的前身是UCOS，最早出自于1992年美国嵌入式系统专家Jean J.Labrosse在《嵌入式系统编程》杂志的5月和6月刊上刊登的文章连载，并把UCOS的源码发布在该杂志的BBS上。目前最新的版本：UCOSIII已经出来，但是现在使用最为广泛的还是UCOSII，本章主要针对UCOSII进行介绍。
UCOSII是一个可以基于ROM运行的、可裁剪的、抢占式、实时多任务内核，具有高度可移植性，特别适合于微处理器和控制器，是和很多商业操作系统性能相当的实时操作系统（RTOS）。为了提供最好的移植性能，UCOSII最大程度上使用ANSI C语言进行开发，并且已经移植到近40多种处理器体系上，涵盖了从8位到64位各种CPU（包括DSP）。
UCOSII是专门为计算机的嵌入式应用设计的，绝大部分代码是用C语言编写的。CPU硬件相关部分是用汇编语言编写的，总量约200行的汇编语言部分被压缩到最低限度，为的是便于移植到任何一种其他的CPU上。用户只要有标准的ANSI的C交叉编译器，有汇编器、连接器等软件工具，就可以将UCOSII嵌入到开发的产品中。UCOSII具有执行效率高、占用空间小、实时性能优良和可扩展性强等优点，最小内核可编译至2KB。UCOSII已经移植到了几乎所有知名的CPU上。
UCOSII构思巧妙。结构简洁精炼，可读性强，同时又具备了实时操作系统的全部功能，虽然它只是一个内核，但非常适合初次接触嵌入式实时操作系统的朋友，可以说是麻雀虽小，五脏俱全。UCOSII（V2.91版本）体系结构如图所示：
V2.91版本比早期的V2.52多了很多功能（比如多了软件定时器，支持任务数最大达到255个等），而且修正了很多已知BUG。不过，有两个文件：os_dbg_r.c和os_dbg.c，我们没有在上图列出，也不将其加入到我们的工程中，这两个主要用于对UCOS内核进行调试支持，比较少用到。
从上图可以看出，UCOSII的移植，我们只需要修改：os_cpu.h、os_cpu_a.asm和os_cpu.c等三个文件即可，其中：
os_cpu.h，进行数据类型的定义，以及处理器相关代码和几个函数原型；
os_cpu_a.asm，是移植过程中需要汇编完成的一些函数，主要就是任务切换函数；
os_cpu.c，定义一些用户HOOK函数。
图中定时器的作用是为UCOSII提供系统时钟节拍，实现任务切换和任务延时等功能。这个，时钟节拍由OS_TICKS_PER_SEC（在os_cfg.h中定义）设置，一般我们设置UCOSII的系统时钟节拍为1ms-100ms，具体根据你所用处理器和使用需要来设置。本章，我们利用STM32的SYSTICK定时器来提供UCOSII时钟节拍。
UCOSII早期版本只支持64个任务，但是从2.80版本开始，支持任务数提高255个，不过对我们来说一般64个任务都是足够多了，一般很难用到这么多个任务。UCOSII保留了最高4个优先级和最低4个优先级的总共8个任务，用于拓展使用，但实际上，UCOSII一般只占用了最低2个优先级，分别用于空闲任务（倒数第一）和统计任务（倒数第二），所以剩下给我们使用的任务最多可达255-2=253个（V2.91版本）。
UCOS是怎么实现多任务并发工作的呢？外部中断相信大家都比较熟悉了。CPU在执行一段用户代码的时候，如果此时发生了外部中断，那么先进行现场保护，之后转向中断服务程序执行，执行完成后恢复现场，从中断处开始执行原来的用户代码。UCOS的原理本质上也是这样的，当一个任务A正在执行的时候，如果它释放了CPU控制权，先对任务A进行现场保护，然后从任务就绪表中查找其他就绪任务去执行，等到任务A的等待时间到了，它可能重新获得CPU控制权，这个时候恢复任务A的现场，从而继续执行任务A。这样看起来就好像2个任务同时执行了。实际上，任何时候，只有一个任务可以获得CPU控制权。这个过程很复杂，场景也多样这里只是举个简单的例子说明。
所谓的任务，其实就是一个死循环函数，该函数实现一定的功能，一个工程可以有很多这样的任务（最多255个），UCOSII对这些任务进行调度管理，让这些任务可以并发工作（注意不是同时工作！！并发只是各个任务轮流占用CPU，而不是同时占用，任何时候还是只有1个任务能够占用CPU），这就是UCOSII最基本的功能。
UCOS任务的一般格式为：
假如我们新建了2个任务mytask和yourtask，这里我们先忽略任务优先级的概念，2个任务死循环中延时时间为1s。如果某个时刻，任务mytask在执行中，当它执行到延时函数OSTimeDlyHMSM的时候，它释放CPU控制器，这个时候，任务yourtask获得CPU控制器开始执行，任务yourtask执行过程中，也会调用延时函数1s释放CPU控制器，这个过程中任务A延时1s到达，重新获得CPU控制权，重新开始执行死循环中的任务实体代码。如此循环，现象就是2个任务交替运行，就好像CPU在同时做两件事情一样。
疑问来了，如果有很多任务都在等待，那么先执行哪个任务呢？如果任务在执行过程中，想停止之后去执行其他任务是否可行呢？这里就涉及到任务优先级以及任务状态任务控制的一些知识，我们在后面会有所提到。如果要详细的学习，，建议看任哲老师的《UCOSII实时操作系统》一书。
前面我们学习的所有实验，都是一个大任务（死循环），这样，有些事情就比较不好处理，比如：MP3实验，在MP3播放的时候，我们还希望显示歌词，如果是一个死循环（一个任务），那么很可能在显示歌词的时候，MP3声音出现停顿（尤其是高码率的时候），这主要是歌词显示占用太长时间，导致VS1053由于不能及时得到数据而停顿。而如果用UCOSII来处理，那么我们可以分2个任务，MP3播放一个任务（优先级高），歌词显示一个任务（优先级低）。这样，由于MP3任务的优先级高于歌词显示任务，MP3任务可以打断歌词显示 任务，从而及时给VS1053提供数据，保证音频不断，而显示歌词又能顺利进行。这就是UCOSII带来的好处。
这里有几个UCOSII相关的概念需要了解一下。任务优先级，任务堆栈，任务控制块，任务就绪表，任务调度器。
任务优先级，这个概念比较好理解，UCOS中，每个任务都有唯一的一个优先级。优先级是任务的唯一标识。在UCOSII中，使用CPU的时候，优先级高（数值小）的任务比优先级低的任务具有优先使用权，即任务就绪表中总是优先级最高的任务获得CPU使用权，只有高优先级的任务让出CPU使用权（比如延时）时，低优先级的任务才能获得CPU使用权。UCOSII不支持多个任务优先级相同，也就是每个任务的优先级必须不一样。
任务堆栈，就是存储器中的连续存储空间。为了满足任务切换和响应中断时保存CPU寄存器中的内容以及任务调用其他函数时的需要，每个任务都有自己的堆栈。在创建任务的时候，任务堆栈是任务创建的一个重要入口参数。
任务控制块OS_TCB，用来记录任务堆栈指针、任务当前状态以及任务优先级等任务属性。UCOSII的任何任务都是通过任务控制块（TCB）的东西来控制的，一旦任务创建了，任务控制块OS_TCB就会被赋值。每个任务管理块有3个最重要的参数：
1、任务函数指针
2、任务堆栈指针
3、任务优先级
任务控制块就是任务在系统里面的身份证（UCOSII通过优先级识别任务）。
任务就绪表，简而言之就是用来记录系统中所有处于就绪状态的任务。它是一个位图，系统中每个任务都在这个位图中占据一个进制位，该位置的状态（1或者0）就表示任务是否处于就绪状态。
任务调度的作用一是在任务就绪表中查找优先级最高的就绪任务，二是实现任务的切换。比如说，当一个任务释放CPU控制权后，进行一次任务调度，这个时候任务调度器首先要去任务就绪表查询优先级最高的就绪任务，查到之后，进行一次任务切换，转而去执行下一个任务。
UCOSII的每个任务都是一个死循环。每个任务都处在以下5种状态之一的一种状态下，这5种状态是：睡眠状态、就绪状态、运行状态、等待状态（等待某一事件发生）、中断服务状态。
睡眠状态，任务在没有被配备任务控制块或被剥夺了任务控制块时的状态。
就绪状态，系统为任务配备了任务控制块且在任务就绪表中进行了就绪登记，任务已经准备好了，但由于该任务的优先级比正在运行的任务的优先级低，还暂时不能运行，这时任务的状态叫做就绪状态。
运行状态，该任务获得CPU使用权，并正在运行中，此时的任务状态叫做运行状态。
等待状态，正在运行的任务，需要等待一段时间或需要等待一个事件发生再运行时，该任务就会把CPU的使用权让给别的任务而使任务进入等待状态。
中断服务状态，一个正在运行的任务一旦响应中断申请就会终止运行而去执行中断服务程序，这时任务的状态叫做中断服务状态。
UCOSII任务的5个状态转换关系如图所示：
