 上传我的文档
 下载
 收藏
该文档贡献者很忙，什么也没留下。
 下载此文档
正在努力加载中...
uCOS-II-任务管理-1-课件PPT
下载积分：500
内容提示：uCOS-II-任务管理-1-课件PPT
文档格式：PPT|
浏览次数：2|
上传日期： 02:55:56|
文档星级：
该用户还上传了这些文档
uCOS-II-任务管理-1-课件PPT
官方公共微信鲁ICP备号-3您所在位置： &
&nbsp&&nbsp&nbsp&&nbsp
第3章 UCOS-II任务调度.ppt 26页
本文档一共被下载：
次 ,您可全文免费在线阅读后下载本文档。
文档加载中...广告还剩秒
需要金币：100 &&
第3章 UCOS-II任务调度.ppt
你可能关注的文档：
··········
··········
* * * * * * * * * * * * * * * * * * * * * UCOS-II任务调度 uC/OS-II系统移植与开发 课程目标： 本章旨在向学员介绍UCOS-II系统的任务调度机制及任务管理接口，通过本章的学习，学员应掌握以下内容： UCOS-II任务调度及管理 UCOS-II任务初始化及启动 UCOS-II任务接口的使用 uC/OS-II任务结构 前一个任务控制块的指针 后一个任务控制块的指针 指向任务的指针 指向任务堆栈的指针 任务的优先级别 … … void mytask void *pdata … …; … … 任务的代码
任务控制块 … …
任务 任务的组成 从应用程序设计的角度来看，任务就是一个线程。就是一个用来解决用户问题的C语言函数和与之相关联的一些数据结构而构成的一个实体。 从任务存储结构来看，由三部分构成：任务程序代码、任务堆栈和任务控制块。任务控制块用来保存任务属性，任务堆栈用来保存任务工作环境，任务程序代码是任务的执行部分。 任务代码 任务 控制块 任务堆栈
任务1 任务代码 任务 控制块 任务堆栈
任务2 任务代码 任务 控制块 任务堆栈
任务n UCOS-II任务链表 uC/OS-II的任务有两种：用户任务和系统任务。由应用程序设计者编写的任务叫做用户任务，由系统提供的任务叫做系统任务。用户任务是为解决应用问题而编写的，系统任务是为应用程序来提供某种服务的。
为了管理上的方便，uC/OS-II把每一个任务都作为一个节点，然后把它连接成一个任务链表。 目前，uC/OS-II最多可以对64个任务（包括用户任务和系统任务）进行管理。 uC/OS-II任务链表 uC/OS-II任务状态 uC/OS-II任务状态 休眠态：任务只是以代码的形式驻留在程序空间，还没有交给操作系统管理时的情况叫休眠态。简单地说，任务在没有被配备任务控制块或被剥夺了任务控制块时的状态叫作任务的休眠态。
就绪态：如果系统为任务配备了任务控制块且在任务就绪表中进行了就绪登记，则任务就具备了运行的充分条件，这时的任务的状态叫就绪态。
运行态：处于就绪态的任务如果经调度器判断获得了CPU的使用权，则任务就进入运行态。任何时刻只能有一个任务处于运行态，就绪的任务只有当所有优先级高于本任务的任务都转为等待状态时，才能进入运行态。 等待态：正在运行的任务，需要等待一段时间或需要等待一个事件发生再运行时，该任务就会把CPU的使用权让给其他任务而使任务进入等态状态。
中断态：正在运行的任务是可以被中断的，除非该任务将中断关了，或者μC/OS-Ⅱ将中断关了。被中断了的任务就进入了中断服务态（ISR）。响应中断时，正在执行的任务被挂起，中断服务子程序控制了CPU的使用权。中断服务子程序可能会报告一个或多个事件的发生，而使一个或多个任务进入就绪态。在这种情况下，从中断服务子程序返回之前，μC/OS-Ⅱ要判定，被中断的任务是否还是优先级最高的。如果中断服务子程序使一个优先级更高的任务进入了就绪态或唤醒了一个优先级更高的挂起任务，则这个优先级更高的任务将得以运行，否则原来被中断了的任务才能继续运行。 uC/OS-II任务优先级 uC/OS-II分为64个优先级别，每一个级别都用一个数字表示。 数字0的级别最高，数字越大优先级别越低。 通常，一个应用程序的任务数小于64，用户可根据应用程序的需要，在OS_CFG.H中设置OS_LOWEST_PRIO，即定义了可供使用的优先级别共OS_LOWEST_PRIO+1个。 固定地，系统总是把最低优先级别自动赋给空闲任务，如果系统中还有统计任务，则其优先级别为OS_LOWEST_PRIO -1。 uC/OS-II任务代码
void MyTask void *; 可以被中断的任务代码；
OS_ENTER_CRITICAL //进入临阶段（关中断）
不可以被中断的任务代码；
OS_EXIT_CRITICAL //退出临阶段
可以被中断的任务代码； 根据嵌入式系统任务的工作特点，任务的执行代码通常是一个无限循环结构，并且在这个循环中可以响应中断，这种结构也叫超循环结构。 为了有效的对中断进行控制，在任务的代码里可使用UC/OS-II定义的宏OS_ENTER_CRITICAL
和OS_EXIT_CRITICAL
来控制何时响应中断，何时屏蔽中断。在运行这两个宏之间的代码时是不会响应中断的，这种受保护的代码段叫临界段。 uC/OS-II任务控制块 任务控制块结构的主要成员
typedef struct os_tcb OS_STK
*OSTCBStkP //指向任务堆栈栈顶的指针 ?…… st
正在加载中，请稍后...ucosii--任务管理与时间管理
这是第3和第4章的ppt,任务管理和时间管理：
关注微信公众号ucOS-II的线程调度和内存管理
最近学习了ucOS-II，前面对通讯机制进行了一个简单的总结，那么作为操作系统核心的线程调度（这里叫任务调度）和内存管理就不得不深入理解一下了，这里就对这两个操作系统的核心模块进行一个总结，之所以在通讯机制之后再总结任务管理，是我觉得任务管理中一些概念只有在理解了通讯机制之后才能够明白。和前面一样，还是从代码级对这两个方面进行总结。
1. 任务管理
对于ucOS-II的任务管理来说，其相当于windows的线程调度，是操作系统最核心的部分。
1.2 数据结构设计：
对于任务管理来说，用到了两个数据结构：就绪任务表和任务控制块（TCB），其中就绪任务表在前面已经总结过了，这里着重说一下TCB，可以说整个操作系统的运转都是围绕TCB来进行的！下面先说一下TCB中几个不容易理解的变量，其他的变量很容易理解。
OSTCBEventPtr：和该任务相关联的通讯对象ECB的指针（信号量，互斥体，邮箱，队列），当任务在等待上述四种通讯对象的时候，这个指针指向这个ECB。
OSTCBMsg：任务得到的消息，当用到邮箱和队列的时候，如果任务得到了消息，那么得到的消息就放在这里。
OSTCBFlagNode：和该任务相关联的通讯对象OS_FLAG_NODE指针（事件组），当任务在等待一个事件组的时候，这个指针指向相关联的OS_FLAG_NODE，注意，这里并没有给出OS_FLAG_GRP的指针，原因是在OS_FLAG_NODE的变量有反向指到OS_FLAG_GRP的指针。
1.2.4 OSTCBFlagsRdy：任务得到的事件组标识，和事件组一块使用。
1.2.5 OSTCBStat：标识该任务处于什么状态，等待通讯对象中或者主动挂起或者就绪。
OSTCBDly：任务将被延时的时间，当任务调用OSTimeDly函数被挂起的时候，延时的时间将被记录在这个变量里；当任务在等待通讯对象的时候，超时的时间被记录在这个变量里。
OSTCBPrio，OSTCBX，OSTCBY，OSTCBBitX，OSTCBBitY：这五个变量代表了任务的优先级，其中第一个和后四个可以相互推导，后四个是为了处理就绪任务表的时候更快。
1.2.8 OSTCBDelReq：任务将被删除标识，当要删除一个任务的时候，只要将这一位设置。
核心函数：对于任务管理来说，核心函数包括创建任务，删除任务，挂起任务和恢复任务，当然还有最重要的调度函数和时钟节拍处理函数：
OSTaskCreate和OSTaskCreateExt：创建一个任务，其中后者是前者的扩展，功能更加全面：首先在任务优先级标识表中标识该优先级任务被创建；然后初始化堆栈；然后初始化任务TCB；最后判断如果多任务已经开始运行就重新调度。
OSTaskDel：删除一个任务：首先将要删除的任务从就绪任务表中移走；如果该任务正在等待通讯对象，将其从等待任务表或者等待任务节点中移走；最后更新任务TCB，并重新调度。注意，这里个删除任务其实就是使任务进入休眠状态，而并是不是删除任务的代码，呵呵！
OSTaskDelReq：请求删除一个任务：首先判断是不是任务本身请求删除本身，如果是的话就直接返回TCB中OSTCBDelReq的状态；如果是请求删除其他的任务，那么只是将这个任务的TCB的OSTCBDelReq设置。设计这个函数的原因是，如果要删除的任务正在占用一些资源，那么用OSTaskDel将其删除将会使删除任务正在使用的资源得不到释放！
OSTaskSuspend：挂起一个任务：实现很简单，首先将任务从就绪任务表中移走；然后在TCB的OSTCBStat标记此任务为挂起。
OSTaskResume：恢复一个任务：首先判断要恢复的任务是不是处于挂起状态，如果是的话，再接着判断要恢复的任务是不是在等待通讯对象以及是不是在被延时，如果没有没有在等待通讯对象，也没有在被延时的话，就将其加入就绪任务表，最后重新调度！
OS_Sched：调度函数，这是任务管理的核心，但是其实现却相当的简单：首先判断调度是否被允许（不能在中断处理里调度以及调度不能被禁止）；然后通过就绪任务表找到优先级最高的任务；接着判断当前任务是不是优先级最高的任务，如果不是的话就进行任务切换（如果当前任务已经是优先级最高的任务，那么任务切换就不需要做）。任务切换根据平台的不同而不同，作者将其定义成一个宏，移植的时候需要根据实际情况改写这个宏：OS_TASK_SW()。
OSTimeTick：时钟节拍处理函数：遍历所有的任务，将各个任务TCB的OSTCBDly减一，然后判断OSTCBDly是不是等于0，也就是不需要延时，如果是0的话，再判断TCB的OSTCBStat，如果任务是被主动挂起的话，那么将TCB的OSTCBDly设置为1，也就是说，被主动挂起的任务将会被一直延时，直到被主动恢复，呵呵；如果任务是正在等待通讯对象的话，由于延时已经到0，其实就是超时了，那么就将任务加进就绪任务表。
在usOS-II中，会导致重新调度的有：创建任务，删除任务，挂起任务，恢复任务，等待通讯对象的函数，释放通讯对象的函数。
2 内存管理
ucOS-II的内存管理相对来说比较简单，只是提供了建立分区，申请内存，释放内存三个功能，用的时候应用程序必须遵循使用规范，内存主要的目的是不产生内存碎片以及申请释放内存的时间是固定的。
2.1 数据结构的设计：
作者设计了内存分区控制块（MCB）来描述内存分区，系统在初始化的时候会事先建立MCB缓冲区，其大小根据具体的应用来确定。每个MCB管理一个内存分区，它包含五个变量：OSMemAddr（内存分区的起始地址）；OSMemFreeList（分区中空闲内存块的指针）；OSMemBlkSize（分区中内存块的大小）；OSMemNBlks（分区中内存块的数量）；OSMemNFree（分区中空闲内存块的数量）。内存分区由内存块组成，每个内存分区在建立的时候指定内存分区的起始地址，并且指定分区中内存块的大小以及数量。
2.2 核心函数的设计，内存管理中提供三个函数：
OSMemCreate：创建一个内存分区：首先从系统的内存管理块缓冲区申请一个MCB；然后初始化这个MCB，并且初始化这个MCB所描述的内存块——每个内存块的第一个单元放下一个内存块单元的指针。
OSMemGet：申请一个内存块：实现很简单，如果还有空闲内存块的话，就更新MCB然后返回申请到的内存块的指针。
2.2.3 OSMemPut：释放一个内存块：实现很简单，是OSMemGet的反操作，关键的是，应用程序必须保证从哪个分区申请的，要释放到那个分区！
以上网友发言只代表其个人观点，不代表新浪网的观点或立场。