uCOS任务堆栈的深入分析(转)

wstrom

uCOS任务堆栈的深入分析(转) [复制链接]

 

堆栈作用的就是用来保存局部变量，从本质上讲也就是将CPU寄存器的值保存到RAM中。在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寄存器的这一连续的区域肯定在整个堆栈的最上面；当任务重新开始运行时，SP弹出寄存器的值，这段区域变成空白的区域。而且，任务每次挂起前用来保存当前CPU寄存器这一连续区域在整个任务堆栈空间中是浮动的。

 

本文出自：EDN博客精华文章

daicheng

讨论一下，如果堆栈初始化太小了，程序占用超过初始化值时会发生什么 样的情况呢

wstrom

一个不错的话题，我先抛砖引玉吧
堆栈相对于来说每一个任务来说就像是他的一个仓库，而任务运行的关键因素都保存在这个仓库中。每一个任务都有这样一个仓库。每一次任务决定放弃CPU时都会把自己的重要信息先保存到自己的仓库中。以便于下次再次获得CPU使用权时使用。如果堆栈较小，也就是仓库容量不足，就会出现两种可能，一个是自己重要的信息无法全部保存，另外一种情况下占用了别的任务的仓库。第一种情况会造成任务再次运行时得不到全部的资源而无法正常运行。第二种情况会修改别的任务的重要信息而造成别的任务无法正常运行。（在这里解释一下，由于UCOS不想Linux一样使用虚拟地址，UCOS使用的是实地址模式，无法进行地址保护）当任务无法正常运行时就会造成任务之间的相互干扰。最终导致系统的崩溃。所以堆栈的分配就至关重要。这就好比你当老板结果给员工的待遇却很低又想让你的员工好好干活。结果会怎样。轻则员工罢工，重则扰乱军心公司倒闭。呵呵！

daicheng

说的很好，感谢wstrom的回答，在使用系统时，任务本身的程序没有问题而当运行到某一点占用堆栈很大时发生了地址异常，那么可能是你的任务堆栈溢出。

wstrom

任何一点如果进行深入分析皆是学问啊！

yuchen16

学习了，我正在摸索中前进

thinkhunter

也遇到这个问题了，最后只是把堆栈改大了，今天终于学习了。

zw357234798

像这样说，到底任务堆栈定义多大比较合适呢

常见泽1

an ye俺也来学习 落下了不少课啊

hanker510

试想：
  我们在定义任务堆栈空间的时候，总是凭感觉开256字节或者其它，有没有一个合理的工具让我们 来合理的分配堆栈的空间呢？即使出现任务堆栈溢出的情况，我们如何发现并解决问题？
    1、利用OSview 工具是否可以 实时看到任务堆栈的使用情况。
    2、一旦发生堆栈越界 时 是否能 提示出来？通过编译器或者debug信息？
   
   欢迎大家进行讨论

tin0727

如果只是凭感觉把堆栈设的很大，会额外的占用RAM资源，

zzgezi

谢谢楼主，学习了。

college87

那这样一来，当任务很多时，系统对RAM的要求就比较高了！

732460449

请问楼主，任务的临时变量还有嵌套调用的变量是不是安排在该任务的堆栈中？是如何安排的呢？是编译器吗？
怎么确保 该任务的临时变量及嵌套调用产生的变量-就会保存在该堆栈下呢？

andyjian

今天学习了

刘程

相当不错，解决了一个疑问，谢谢、、、