UC-OS II多任务机制
Ucos多任务演示实验
uCOS多任务演示实验一、实验目的（1）、理解任务，任务调度的概念（2）、理解任务通信的几种方式（管道、共享内存、消息、队列、邮箱、套接字等）（3）、理解任务同步的几种方式（信号量、互斥、忙等待、事件、临界区等）（4）、掌握LPC2200(for MagicARM2200)专用工程模板的使用；（5）、能够在MagicARM2200-S 上运行基于μC/OS-II 操作系统的程序；（6）、掌握基于μC/OS-II 操作系统的用户程序的编写格式。
二、实验内容及要求建立三个或三个以上的μC/OS-II 的任务，一个任务用于检测KEY1 按键输入，称之为按键检测任务，另一个任务用于控制蜂鸣器，就称之为蜂鸣器控制任务。
还有LED灯任务和电机任务。
要求各个任务之间不是独立的，而是有相互关联的，达到多任务间的数据通信和同步的实验要求。
三、实验设备及软件硬件：PC 机一台MagicARM2200-S 教学实验开发平台一套软件：Windows98/XP/2000 系统，ADS 1.2 集成开发环境μC/OS-II 操作系统(V2.52)四、设计方案（一）方案原理 1、信号量与邮箱（1）要完成两个任务之间的单向同步，需要通过邮箱或者信号量来实现。
用信号量进行单向同步，以一个事情触发两个以上任务时，按键任务划分原则可以将他们合并为一个任务。
如果这些任务因为其他原因不能合并（不同的功能部件），则可以采用有消息分发功能的通信机制——邮箱，以减少通信工具的个数。
（2）且用信号量进行行为同步时，只能提供同步的时刻信息，不能提供内容信息，当控制方在对被控制方进行控制，且还需要向被控制方提供内容信息（数据或字符串）时，消息邮箱是一种有效的方案。
（3）当两个任务是系统“信息链条”中的相邻两个环节时，前一个任务的输出信息就是后一个任务的输入信息，消息邮箱就是连接这两个任务的桥梁。
在消息邮箱看来，提供消息的任务（或ISR）是生产者，读取消息的任务是消费者，正常情况下，消息的消费时间比生产时间短，消费者总是在等待消息的到来，这时，生产者每向“消息邮箱”发送一次“消息”，就立即被消费者取走，两者达到理想的同步效果。
μC／OS-Ⅱ的多任务系统实时性分析与优先级分配
１
ｊ ＾Ｌ盖 入 ｊ 毒 刍厢 —毒 ：
… … … … ｒ Ａ 些喜田、
维普资讯
专 题 论 述
动 条 和状 态 标 志 块 ， Ｌ Ｄ界 面 上 获 得 明确 的 操 作 指 示 ， 在 Ｃ ② Ｆａｈ除 了用 作 程 序 存 储 器 外 ， 下 的部 分 作 为 非 ｌｓ 剩 易 失性 数 据 存储 器 。每个 Ｆｌ ｈ块 为 １Ｋ 故 需要 １ＫＢ的 ａ ｓ Ｂ，
显 示 状 态 标志 ｌ
Ｉ会 大 大 加 重 系 统 负 担 ， 应 用 程 序 的 运 行 受 到 影 响 ， Ｉ 使 特 别 在 快 速 Ａ／ 转 换 等 实 时 性 较 强 的场 合 ， 法 得 到 及 时 Ｄ 无
的响 应 ， 是才 有 了更 轻 量 级 的 Ｓ ｌ ＲＴＯＳ等 操 作 系统 于 ｍａｌ
的 出现 。
显 示 状 态 标志２
但 目前更 强 劲 的 ５ １内 核 版 本 微 处 理 器 的 大 量 出 现 ， 从 根 本 上 改 变 了 这种 情 况 。４ Ｏ ＭＨｚ以 上 的主 频 ， 周 期 单 指 令 的微 处 理器 ， 上 ６ 加 ４ＫＢ的程 序 空 间 和 ８ＫＢ 以 上 的
确 保 每个 通 道 的正 确 操作 。 要求 在 通 道启 动 后 ， 精 确 地 每 隔 ０ １Ｓ 成 一 次 采 能 ． 完
样 并处 理 数据 ， 以每个 通 道 的最 长处 理 时 间 不 能 超 过 ２ 所 ５
Ｒ ＡＭ 作 为 Ｆａｈ的读写 缓 冲 区 ； １ ｓ
③ ＧＵＩ自身 约 占去 了 １ＫＢ内存 ；
维普资讯
／／ ￣ ＯＳ—Ｉ的多任务 系统 Ｃ ｌ 实 时性分 析与优先 级分 配 ＊
■ 武汉 工 程 大 学 冉 全 钟 时 明 钱 环 环
uCOS-II的任务切换机理及中断调度优化
uCOS-II的任务切换机理及中断调度优化uC/OS-II的任务切换机理及中断调度优化摘要：μC/OS-II是一种适用于嵌入式系统的抢占式实时多任务操作系统，开放源代码，便于学习和使用。
介绍μC/OS-II在任务级和中断级的任务切换原理，以及这一操作系统基于嵌入式系统的对于中断的处理；相对于内存资源较少的单片机，着重讨论一种优化的实用堆栈格式和切换形式，以提高资源的利用率；结合MSP430单片机，做具体的分析。
关键词：实时多任务操作系统μC/OS MSP430 中断堆栈引言在嵌入式操作系统领域，由Jean J. Labrosse开发的μC/OS，由于开放源代码和强大而稳定的功能，曾经一度在嵌入式系统领域引起强烈反响。
而其本人也早已成为了嵌入式系统会议（美国）的顾问委员会的成员。
不管是对于初学者，还是有经验的工程师，μC/OS开放源代码的方式使其不但知其然，还知其所以然。
通过对于系统内部结构的深入了解，能更加方便地进行开发和调试；并且在这种条件下，完全可以按照设计要求进行合理的裁减、扩充、配置和移植。
通常，购买RTOS 往往需要一大笔资金，使得一般的学习者望而却步；而μC/OS对于学校研究完全免费，只有在应用于盈利项目时才需要支付少量的版权费，特别适合一般使用者的学习、研究和开发。
自1992第1版问世以来，已有成千上万的开发者把它成功地应用于各种系统，安全性和稳定性已经得到认证，现已经通过美国FAA认证。
1 μC/OS-II的几大组成部分μC/OS-II可以大致分成核心、任务处理、时间处理、任务同步与通信，CPU的移植等5个部分。
核心部分(OSCore.c) 是操作系统的处理核心，包括操作系统初始化、操作系统运行、中断进出的前导、时钟节拍、任务调度、事件处理等多部分。
能够维持系统基本工作的部分都在这里。
任务处理部分(OSTask.c) 任务处理部分中的内容都是与任务的操作密切相关的。
包括任务的建立、删除、挂起、恢复等等。
uCOS-II任务及其结构
uCOS-II任务及其结构
正如前⾯所介绍，在uC/OS-II中，任务包括任务控制块、任务堆栈以及任务代码组成，
其中任务控制块包括程序控制块+链表（前⼀篇内容）：指向前⼀个任务控制块的指针，后⼀⼽任务控制块的指针，指向任务指针，指向任务堆栈的指针以及任务的优先级等等，
任务堆栈是⽤来保存任务的环境，
任务代码即为需要执⾏的任务内容，
介绍下线程与进程的定义：
线程，不占有私有空间的任务
进程，占有私有任务的任务
在uC/OS-II中，任务可分为⽤户任务和系统任务，系统中，最多可以含有64个任务（包括系统任务和⽤户任务），其中⼀个具体的时刻只可以存在⼀个任务占⽤CPU（运⾏状态），⽽其他任务只可以出于其他状态，系统任务的状态主要有：
睡眠状态：没有配备任务控制块或被剥夺了任务控制块
就绪状态：配备了任务控制块且在任务就绪表中登记
运⾏状态：处于就绪状态且获得了CPU的使⽤权，
等待状态：正在运⾏的任务，需要等待⼀段时间或者需要等待⼀个事件的触发再运⾏，此时CPU的使⽤权将让给其他的任务：使该任务进⼊等待状态，
中断服务状态：⼀个正在运⾏的任务⼀旦响应中断申请就会中⽌运⾏，转⽽执⾏中断服务程序（需要保存断点）
任务代码是⼀个⽆限循环结构，并且在循环中可以响应中断，这种结构是超循环结构，⽤户任务是需要调度才会被执⾏的，操作系统在管理⽤户任务的同时会处理⼀些内部事务(系统任务),为了使CPU在没有⽤户任务可执⾏时，有事可做，uC/OS-II提供了⼀个空闲任务（OSTaskIdle（））的系统任务（简单说就是任务运⾏次数计数器），还包含统计任务（CPU使⽤率），即每秒计算⼀次CPU在单位时间内被使⽤的时间，并把计算结果以百分⽐形式存放在OSCPUsage中。
uCOSII工作核心原理
uC/OS-II是一种基于优先级的可抢先的硬实时内核。
要实现多任务机制,那么目标CPU必须具备一种在运行期更改PC的途径,否则无法做到切换。
不幸的使,直接设置PC指针,目前还没有哪个CPU支持这样的指令。
但是一般CPU都允许通过类似JMP,CALL这样的指令来间接的修改PC。
我们的多任务机制的实现也正是基于这个出发点。
事实上,我们使用CALL指令或者软中断指令来修改PC,主要是软中断。
但在一些CPU上,并不存在软中断这样的概念,所以,我们在那些CPU上,使用几条PUSH指令加上一条CALL指令来模拟一次软中断的发生。
再uC/OS-II里,每个任务都有一个任务控制块(Task Control Block),这是一个比较复杂的数据结构。
在任务控制快的偏移为0的地方,存储着一个指针,它记录了所属任务的专用堆栈地址。
事实上,再uC/OS-II内,每个任务都有自己的专用堆栈,彼此之间不能侵犯。
这点要求程序员再他们的程序中保证。
一般的做法是把他们申明成静态数组。
而且要申明成OS_STK类型。
当任务有了自己的堆栈,那么就可以将每一个任务堆栈再那里记录到前面谈到的任务控制快偏移为0的地方。
以后每当发生任务切换,系统必然会先进入一个中断,这一般是通过软中断或者时钟中断实现。
然后系统会先把当前任务的堆栈地址保存起来,仅接着恢复要切换的任务的堆栈地址。
由于哪个任务的堆栈里一定也存的是地址（还记得我们前面说过的,每当发生任务切换,系统必然会先进入一个中断,而一旦中断CPU 就会把地址压入堆栈）,这样,就达到了修改PC为下一个任务的地址的目的。
uC/OS-II内核工作原理uC/OS-II是一个源码公开应用于嵌入式的小型的RTOS(实时),由于其内核精简,可理解性和可移植性强,因此广泛应用于小型的嵌入式系统中.内核工作原理:实时嵌入式操作系统mC/OS-II内核的工作原理如图1所示。
首先，在主程序中对操作系统进行初始化，完成uC/OS-II所有变量和数据结构的初始化，包括任务控制块(TCB)初始化，TCB优先级表初始化，TCB链表初始化，事件控制块(ECB)链表初始化以及空闲任务的创建等。
UCOSII多任务
1VC下时钟的获得《嵌入式实时操作系统uC/OS-II》这本书已经安排了大量篇幅来专门讲解uC/OS-II的移植：第13章移植uC/OS-II，第14章uC/OS-II在80x86上的移植，第15章uC/OS-II在带有硬件浮点运算单元的80x86上的移植。
所以本文只是重点讲解移植到VC下和其他处理器上的不同地方，更详细的介绍读者可以参考《嵌入式实时操作系统uC/OS-II》这本书。
和所有其他的移植一样，本文所做的移植也只需要修改uC/OS-II处理器相关代码，一共包括3个文件：OS_CPU.H，OS_CPU_A.ASM，OS_CPU_C.C。
考虑到VC可以嵌入汇编代码，并不需要专门的汇编代码文件，所以OS_CPU_A.ASM是多余的，最终只有OS_CPU.H和OS_CPU_C.C两个文件。
所以这两个文件成了移植的关键，首先要解决的问题就是时钟“滴答”的获得。
移植到BC下的uC/OS-II是通过修改DOS下的硬件时钟中断来得到时钟滴答的，VC下时钟滴答从哪里来呢？这是移植uC/OS-II到VC下第一个要考虑的问题。
在windows的保护模式下不能像DOS下面那么容易，直接通过一个函数调用就能够修改中断。
windows下要修改中断涉及到驱动程序，这样就加大了移植的困难度与复杂度，但好处是只有真正硬件时钟的“滴答”才能够保证uC/OS-II的实时性。
另外一种解决方法是采用windows下的软件定时器，通过定时器来产生模拟时钟“滴答”。
考虑到本移植只是为了教学和学习，并没有应用到对实时性要求高的产品，所以最终决定采用软件定时器来模拟时钟中断。
Windows下软件定时器种类很多，下面分别简要介绍一下这些定时器：1.SetTimer()函数有windows下编程经验的最先想到的应该是SetTimer这个API函数，但本文采用的移植程序是基于控制台的，也就是说最开始建立VC工程的时候选择的是创建win32 console application，控制台下的程序是没有消息循环的，所以要使用SetTimer函数则必须再创建一个线程来专门处理消息循环，这样一来事情就复杂了，而且这个函数定时精度非常不高。
ucos-ii及其任务
• 中断管理
1、uc/os-ii的概述 2、 uc/os-ii的任务 3、任务控制块 4、任务创建 5、uc/os-ii的初始化及任务启动
• uc/os-ii中的任务是一个线程，其代码通常是一个无 限循环结构/超循环结构，看起来像其它C 函数一样。 void mytask(void *pdata) //示意代码 { for (;;) { do something; waiting; do something; } }
uc/os-ii概述—性能特点
• 可剥夺性（Preemptive）与可确定性
内核可剥夺、函数调用或系统服务的执行时间具有 可确定性，是硬实时操作系统。
• 支持多任务
• 任务栈
uc/os-ii可以管理64个任务 每个任务有自己单独的栈，uc/os-ii允许每个任允 许每个任务有不同的栈空间，以便压低应用程序对 RAM的需求。
删除任 务
等待
等 待 时 间 到 创建任务 任务调度
挂 起
中断 运行 任务被占先 中断结束 中断任务
uc/os-ii的任务—优先级
uc/os-ii支持64个任务，每个任务有一个特定 的优先级。 任务的优先级别用数字表示，0表示的任务的 优先级最高，数字越大表示的优先级越低。 通过常数OS__LOWEST__PRIO（在 OS_CFG.H中）定义系统的最低优先级别，同 时限定系统能容纳的最多任务数量。 OS_LOWEST_PRIO给空闲任务， OS_LOWEST_PRIO-1给统计任务。
1、uc/os-ii的概述 2、 uc/os-ii的任务 3、任务控制块 4、任务的创建 5、uc/os-ii的初始化及任务启动
任务控制块—结构
任务控制块 （Task Control Blocks, OS_TCBs）是 ucos-ii用来存储任务堆栈指针、当前状态、优先级及 任务链表指针等属性的一个数据结构。 任务控制块是任务的身份证，每个任务都有一个属于 自已的任务控制块，当任务的CPU使用权被剥夺时， 任务的属性被保存在任务控制块中，而当任务重新得 到CPU使用权时任务控制块能确保任务从当时被中断 的那一点丝毫不差地继续执行。 OS_TCBs全部驻留在RAM中。 OS_TCBs 在任务建立的时候被初始化。
uC-OS-II的运行机制
uC/OS-II的运行机制在嵌入式系统的应用中，实时性是一个重要的指标，而优先级翻转是影响系统实时性的重要问题。
本文着重分析优先级翻转问题的产生和影响，以及在uC/OS-II 中的解决方案。
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()程序进行任务调度，执行当前系统中优先级最高的就绪态任务。
当系统中所有任务都执行完毕时，。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
UC/OS II 多任务机制
前面已经说过，uC/OS-II是一种基于优先级的可抢先的多任务内核。
那么，它的多任务机制到底如何实现的呢?了解这些原理，可以帮助我们写出更加健
壮的代码来。
首先我们来看看为什么多任务机制可以实现?其实在单一CPU的情况下，是不存在真正的多任务机制的，存在的只有不同的任务轮流使用CPU，所以本质上还是单任务的。
但由于CPU执行速度非常快，加上任务切换十分频繁并且
切换的很快，所以我们感觉好像有很多任务同时在运行一样。
这就是所谓的多
任务机制。
由上面的描述，不难发现，要实现多任务机制，那么目标CPU必须具备一
种在运行期更改PC的途径，否则无法做到切换。
不幸的使，直接设置PC指针，目前还没有哪个CPU支持这样的指令。
但是一般CPU都允许通过类似JMP，CALL这样的指令来间接的修改PC。
我们的多任务机制的实现也正是基于这个出发点。
事实上，我们使用CALL指令或者软中断指令来修改PC，主
要是软中断。
回想一下你在微机原理课程上学过的知识，当发生中断的时候，CPU保存当前的PC和状态寄存器的值到堆栈里，然后将PC设置为中断服务程序的入口
地址，再下来一个机器周期，就可以去执行中断服务程序了。
执行完毕之后，
一般都是执行一条RETI指令，这条指令会把当前堆栈里的值弹出恢复到状态
寄存器和PC里。
这样，系统就会回到中断以前的地方继续执行了。
那么设想
一下?如果再中断的时候，人为的更改了堆栈里的值，那会发生什么?或者通过更改当前堆栈指针的值，又会发生什么呢?如果更改是随意的，那么结果是无
法预料的错误。
因为我们无法确定机器下一条会执行些什么指令，但是如果更。