ucosiiucosii任务堆栈的作用是什么呢？

ucosii任务是如何调度的？

UCOS-III的任务调度 任务调度就是CPU终止当前正在运行的任务，转而去执行其他就绪的任务。

UCOS-III 是可剥夺型内核，因此当一个高优先级的任务准备就绪，并且在当前正在执行的任务中发生了任务调度，那么此时这个在任务就绪表中的最高优先级的任务，就会获得CPU的使用权。

UCOS-III的任务调度是有任务调度器来完成的（所谓任务调度器其实就是两个函数），任务调度器函数有2种：分别是 任务级调度器和中断级调度器。

任务级调度器为OSSched()。

中断级调度器为函数OSintExit()，当退出外部中断服务函数的时候使用中断级任务调度。

---------------------

嵌入式ucosii如何学？回答的好加200分！

1. micro os 或 miu os 2.ucosii移植需要汇编，但主要内容是C 3.初学学 ucos的使用 ，深入学 ucos 的内核 4. #include<reg52.h> #define TASK_STK_SIZE 512 //堆栈尺寸 OS_STK led[TASK_STK_SIZE]; //建立任务堆栈 void led(void *pdata); void main() { OSInit(); //OS初始化 OSTaskCreate(led,0,&led[TASK_STK_SIZE-1],4);//创造任务：led，无数据指针，堆栈基址，优先级：4 OSStart(); //任务开始 } void led(void) { while(1) { ……流水灯程序 OSTimeDlyHMSM(0,0,1,0);//延时0时0分1秒0毫秒 } }

关于嵌入式实时操作系统ucos ii的分析

嵌入式实时操作系统ucos ii的分析2010年01月06日 星期三 上午 01:15摘要：近年来，在单片机系统中嵌入操作系统已经成为人们越来越关心的一个话题。

本文通过对一种源码公开的嵌入式实时操作系统ucos ii的分析，以51系列单片机为例，阐述了在单片机中使用该嵌入式操作系统的优缺点，以及在应用中应当注意的一些问题。

关键词：实时操作系统；ucos ii；单片机 引言 早在20世纪60年代，就已经有人开始研究和开发嵌入式操作系统。

但直到最近，它才在国内被越来越多的提及，在通信、电子、自动化等需要实时处理的领域所曰益显现的重要性吸引了人们越来越多的注意力。

但是，人们所谈论的往往是一些著名的商业内核，诸如VxWorks、PSOS等。

这些商业内核性能优越，但价格昂贵，主要用于16位和32位处理器中，针对国内大部分用户使用的51系列8位单片机，可以选择免费的ucos ii。

ucos ii的特点 1．ucos ii是由Labrosse先生编写的一个开放式内核，最主要的特点就是源码公开。

这一点对于用户来说可谓利弊各半，好处在于，一方面它是免费的，另一方面用户可以根据自己的需要对它进行修改。

缺点在于它缺乏必要的支持，没有功能强大的软件包，用户通常需要自己编写驱动程序，特别是如果用户使用的是不太常用的单片机，还必须自己编写移植程序。

2．ucos ii是一个占先式的内核，即已经准备就绪的高优先级任务可以剥夺正在运行的低优先级任务的CPU使用权。

这个特点使得它的实时性比非占先式的内核要好。

通常我们都是在中断服务程序中使高优先级任务进入就绪态（例如发信号），这样退出中断服务程序后，将进行任务切换，高优先级任务将被执行。

拿51单片机为例，比较一下就可以发现这样做的好处。

假如需要用中断方式采集一批数据并进行处理，在传统的编程方法中不能在中断服务程序中进行复杂的数据处理，因为这会使得关中断时间过长。

所以经常采用的方法是置一标志位，然后退出中断。

由于主程序是循环执行的，所以它总有机会检测到这一标志并转到数据处理程序中去。

但是因为无法确定发生中断时程序到底执行到了什么地方，也就无法判断要经过多长时间数据处理程序才会执行，中断响应时间无法确定，系统的实时性不强。

如果使用μC/OS-II的话，只要把数据处理程序的优先级设定得高一些，并在中断服务程序中使它进入就绪态，中断结束后数据处理程序就会被立即执行。

这样可以把中断响应时间限制在一定的范围内。

对于一些对中断响应时间有严格要求的系统，这是必不可少的。

但应该指出的是如果数据处理程序简单，这样做就未必合适。

因为ucos ii要求在中断服务程序末尾使用OSINTEXIT函数以判断是否进行任务切换，这需要花费一定的时间。

3．ucos ii和大家所熟知的Linux等分时操作系统不同，它不支持时间片轮转法。

ucos ii是一个基于优先级的实时操作系统，每个任务的优先级必须不同，分析它的源码会发现，ucos ii把任务的优先级当做任务的标识来使用，如果优先级相同，任务将无法区分。

进入就绪态的优先级最高的任务首先得到CPU的使用权，只有等它交出CPU的使用权后，其他任务才可以被执行。

所以它只能说是多任务，不能说是多进程，至少不是我们所熟悉的那种多进程。

显而易见，如果只考虑实时性，它当然比分时系统好，它可以保证重要任务总是优先占有CPU。

但是在系统中，重要任务毕竟是有限的，这就使得划分其他任务的优先权变成了一个让人费神的问题。

另外，有些任务交替执行反而对用户更有利。

例如，用单片机控制两小块显示屏时，无论是编程者还是使用者肯定希望它们同时工作，而不是显示完一块显示屏的信息以后再显示另一块显示屏的信息。

这时候，要是ucos ii即支持优先级法又支持时间片轮转法就更合适了。

4．ucos ii对共享资源提供了保护机制。

正如上文所提到的，ucos ii是一个支持多任务的操作系统。

一个完整的程序可以划分成几个任务，不同的任务执行不同的功能。

这样，一个任务就相当于模块化设计中的一个子模块。

在任务中添加代码时，只要不是共享资源就不必担心互相之间有影响。

而对于共享资源（比如串口），ucos ii也提供了很好的解决办法。

一般情况下使用的是信号量的方法。

简单地说，先创建一个信号量并对它进行初始化。

当一个任务需要使用一个共享资源时，它必须先申请得到这个信号量，而一旦得到了此信号量，那就只有等使用完了该资源，信号量才会被释放。

在这个过程中即使有优先权更高的任务进入了就绪态，因为无法得到此信号量，也不能使用该资源。

这个特点的好处显而易见，例如当显示屏正在显示信息的时候，外部产生了一个中断，而在中断服务程序中需要显示屏显示其他信息。

这样，退出中断服务程序后，原有的信息就可能被破坏了。

而在μC/OS-II中采用信号量的方法时，只有显示屏把原有信息显示完毕后才可以显示新信息，从而可以避免这个现象。

不过，采用这种方法是以牺牲系统的实时性为代价的。

如果显示原有信息需要耗费大量时间，系统只好等待。

从结果上看，等于延长了中断响应时间，这对于未显示信息是报警信息的情况，无疑是致命的。

发生这种情况，在μC/OS-II中称为优先级反转，就是高优先级任务必须等待低优先级任务的完成。

在上述情况下，在两个任务之间发生优先级反转是无法避免的。

所以在使用ucos ii时，必须对所开发的系统了解清楚，才能决定对于某种共享资源是否使用信号量。

ucos ii在单片机使用中的一些特点 1．在单片机系统中嵌入ucos ii将增强系统的可靠性，并使得调试程序变得简单。

以往传统的单片机开发工作中经常遇到程序跑飞或是陷入死循环。

可以用看门狗解决程序跑飞问题，而对于后一种情况，尤其是其中牵扯到复杂数学计算的话，只有设置断点，耗费大量时间来慢慢分析。

如果在系统中嵌入 ucos ii的话，事情就简单多了。

可以把整个程序分成许多任务，每个任务相对独立，然后在每个任务中设置超时函数，时间用完以后，任务必须交出 CPU的使用权。

即使一个任务发生问题，也不会影响其他任务的运行。

这样既提高了系统的可靠性，同时也使得调试程序变得容易。

2．在单片机系统中嵌入ucos ii将增加系统的开销。

现在所使用的51单片机，一般是指87C51或者89C51，其片内都带有一定的RAM和 ROM。

对于一些简单的程序，如果采用传统的编程方法，已经不需要外扩存储器了。

如果在其中嵌入ucos ii的话，在只需要使用任务调度、任务切换、信号量处理、延时或超时服务的情况下，也不需要外扩ROM了，但是外扩RAM是必须的。

由于ucos ii是可裁减的操作系统，其所需要的RAM大小就取决于操作系统功能的多少。

举例来说，μC/OS-II允许用户定义最大任务数。

由于每建立一个任务，都要产生一个与之相对应的数据结构TCB，该数据结构要占用很大一部分内存空间。

所以在定义最大任务数时，一定要考虑实际情况的需要。

如果定得过大，势必会造成不必要的浪费。

嵌入ucos ii以后，总的RAM需求可以由如下表达式得出： RAM总需求=应用程序的RAM需求+内核数据区的RAM需求+（任务栈需求+最大中断嵌套栈需求）·任务数 所幸的是，μC/OS-II可以对每个任务分别定义堆栈空间的大小，开发人员可根据任务的实际需求来进行栈空间的分配。

但在RAM容量有限的情况下，还是应该注意一下对大型数组、数据结构和函数的使用，别忘了，函数的形参也是要推入堆栈的。

3．ucos ii的移植也是一件需要值得注意的工作。

如果没有现成的移植实例的话，就必须自己来编写移植代码。

虽然只需要改动两个文件，但仍需要对相应的微处理器比较熟悉才行，最好参照已有的移植实例。

另外，即使有移植实例，在编程前最好也要阅读一下，因为里面牵扯到堆栈操作。

在编写中断服务程序时，把寄存器推入堆栈的顺序必须与移植代码中的顺序相对应。

4．和其他一些著名的嵌入式操作系统不同，ucos ii在单片机系统中的启动过程比较简单，不像有些操作系统那样，需要把内核编译成一个映像文件写入ROM中，上电复位后，再从ROM中把文件加载到RAM中去，然后再运行应用程序。

ucos ii的内核是和应用程序放在一起编译成一个文件的，使用者只需要把这个文件转换成HEX格式，写入ROM中就可以了，上电后，会像普通的单片机程序一样运行。

结语 由以上介绍可以看出，ucos ii具有免费、使用简单、可靠性高、实时性好等优点，但也有移植困难、缺乏必要的技术支持等缺点，尤其不像商用嵌入式系统那样得到广泛使用和持续的研究更新。

但开放性又使得开发人员可以自行裁减和添加所需的功能，在许多应用领域发挥着独特的作用。

当然，是否在单片机系统中嵌入ucos ii应视所开发的项目而定，对于一些简单的、低成本的项目来说，就没必要使用嵌入式操作系统了。

ucosii任务堆栈的作用是什么呢？

在uCOS中，每一个任务都有一个独立的任务堆栈。

为了深入理解任务堆栈的作用，不妨分析任务从“出生”到“消亡”的整个过程，具体就是分析任务的建立，运行，挂起几种状态中任务堆栈的变化情况。

现在假设系统运行着一个由用户创建的用以完成打印工作的任务TPrint。

TPrint最初通过OSTaskCreate()函数创建，在该函数中与任务堆栈有关的第一段代码是大家比较熟悉的函数OSTaskStkInit()，这个函数是在uCOS移植过程中必须实现的，其作用是“初始化堆栈”,其实就是预先在RAM中的一块区域中把任务将来运行开始时CPU寄存器应处的状态（正确值）准备好，之后，任务第一次被内核调度器调度运行时，将这些准备好的数据（寄存器的值）推到CPU的寄存器中，如果数据设计的合理，CPU便会按照我们预先设计好的思路运行。

所以，“初始化堆栈”实际上是做了一个“未雨绸缪”的工作。

这个过程中有两点是必须慎重考虑的，一是PC该如何定位，二是CPU的其它寄存器(除PC之外)该怎么处理。

先说第一点，因为任务是第一次运行，而任务从本质上将就是一段代码，所以PC指针应该定位到这段代码的第一行处，即所谓的入口地址(Entry Point)处，这个地址由任务指针保存着，所以把该指针值赋给PC即可。

第二，这段代码还未被执行过，所以代码中的变量与CPU的其它寄存器一点关系也没有，因此R0-R12，R14可随便给值，或者不赋值也可，让这些寄存器保持原来的值，显然后者更为简单。

最后再给CPSR赋值，用户可以根据实际需要使系统运行于系统模式或管理模式。

经过入栈和出栈，此时SP指向任务堆栈的最底端（就是已经定义好的任务堆栈数组的最后一个元素）。

之后任务代码开始正式运行，因为CPU的寄存器是有限的，所以在运行时不可避免地要把一些临时变量暂时保存到堆栈中。

具体应保存到哪个地址呢，不用担心，SP知道（任务第一次运行时，这个地址就是任务堆栈数组的最后一个元素的地址）。

任务堆栈的大小和任务代码中临时变量的数目有关，如果这段代码临变量特别多，堆栈就应设计的大一些。

然后，TPrint任务由于某种原因将要被挂起，所以应把任务的运行现场放到堆栈里保护起来，TPrint任务再次运行时再把这个现场还原，任务就能从上次断点处紧接着运行。

那么，这个现场是什么呢？从本质上讲，TPrint任务的运行过程就是CPU在执行一段特定的代码，所以这个现场就是CPU的现场，也就是寄存器的值。

这些寄存器的值包含了代码执行时的所有信息，包括当前运行到了这段代码的哪个位置处（由PC值指明）。

因此，把CPU的寄存器的值推入堆栈，然后记住栈顶指针的位置（SP由OSTCBCur->OSTCBStkPtr保存），当任务再次将要运行前，从SP指向的地址处依次把先前保存的CPU寄存器的值放到CPU的寄存器中，任务就可以从上次中断的地方准确无误地执行。

这个过程就像突然把任务冻结了，与任务有关的任何东西都不能动了，一段时间之后又把任务解冻，与它有关的东西又变得可用，于是任务又可以活蹦乱跳地跑起来了。

从以上分析可以看出，任务堆栈至始至终伴随着任务，与之生死与共，它的作用可以概括为两点：第一，当任务运行时，它用来保存一些局部变量；第二，当任务挂起时，它负责保存任务的运行现场，也就是CPU寄存器的值。

有些朋友正是忽视了第一点，产生了“任务堆栈大小应是固定值的疑问”。

我感觉，这可能与对函数OSTaskStkInit()的理解有关，我们都称之为堆栈初始化函数，但此处的“初始化”与我们理解的初始化不太一样，平时讲的（变量的）初始化似乎指的是将变量的所有成员都一一初始化。

而此处的堆栈的初始化仅仅是初始化了很大一个堆栈的一小部分，因为当前只有这部分是有用的，而剩余的大部分用不到，所以不用初始化，就像有些变量不用初始化一样（有默认值或随机值）。

而且，任务每次挂起前用来保存当前CPU寄存器这一连续区域在整个任务堆栈空间中是浮动的