进行最坏情况堆栈分析的3种方法

弄清楚如何为嵌入式应用程序确定堆栈的大小以及其中的任务可能是具有挑战性的。在许多情况下,开发人员会选择他们认为应该足够的值。这些估算有时会短一些,大多数情况下是总估算,很少出现。尽管我一直鼓励开发人员在整个开发周期中监视其堆栈使用情况,但有时开发人员应该执行最坏情况的堆栈分析,例如:

  • 它们的RAM严重不足
  • 需要提交新的代码版本
  • 他们正在完成固件的生产

In this post, I will discuss three different ways that a develop can perform a 最坏的-case stack analysis.

技术#1 –手工计算

在过去,嵌入式软件开发人员过去不得不手工计算堆栈使用量,这可能是一项棘手的业务。为了手动计算堆栈使用量,开发人员需要知道:

  • 他们要去多少个函数调用
  • 每个函数中将存储在堆栈中的局部变量
  • 将存储在堆栈中的返回地址的大小
  • 将存储在堆栈中的局部变量的大小
  • 如果在执行过程中发生中断,中断帧将有多大
  • 可能发生的嵌套中断数

您可以想象,找到所有这些值并在进行更改后继续跟踪它们会非常耗时且容易出错。这就是为什么不再建议使用此方法的原因,但尝试一次以更深入地了解其他技术的作用仍然很有用。

技术2 –使用静态代码分析器

许多静态代码分析器可用于估计最坏情况下的堆栈使用情况。在代码分析过程中,该工具将确定功能深度以及我们之前列出的许多项目。使用静态分析器的好处在于,它不仅可以执行堆栈分析,还可以检查代码中的潜在问题。它只需几秒钟即可运行,从而使开发人员无需手工计算堆栈使用量。

使用静态代码分析器获取最坏情况下的堆栈使用率是一个不错的方法,但开发人员需要注意一些潜在的问题。这些包括:

  • 取消引用函数指针不算作函数调用
  • 不考虑中断帧

了解您的工具如何处理这些项目很重要。为了获得准确的结果,在静态代码分析过程中,通常必须使用宏或编译器符号有条件地将函数指针编译为函数调用。然后,您还必须添加您认为中断堆栈使用量的内容。次要问题,但在任何分析中均应理解。

技术#3 –测试与测量

对于最坏情况的堆栈分析,我最常提倡的技术是测试和测量系统。现在,许多开发环境都具有执行操作系统感知调试的工具,该工具将密切监视RTOS性能,包括在应用程序运行时最大堆栈使用率。在下面的图像中,可以从使用ThreadX的Renesas Synergy平台的e2 Studio中看到一个很好的例子。

如您所见,列出了每个线程(任务)以及内存位置,堆栈指针和最大堆栈使用率。我们甚至可以看到为堆栈分配了多少内存。这不仅为开发人员提供了一种监控堆栈使用情况的好方法,而且还可以确定最大堆栈使用情况。

开发人员确实需要谨慎对待提供给他们的最大价值。请务必在系统承受最大压力时进行读数。对于基于RTOS的应用程序,中断帧通常存储在系统堆栈中,因此我们无需考虑每个线程的大小以具有足够的内存来应对中断风暴。

结论

无论您使用哪种技术来确定堆栈的使用情况,仍然都应适当增加堆栈的大小。在测试过程中,有可能从未达到最坏的情况,当系统在现场时,可能会将系统设置为堆栈溢出。

在本文中,我们研究了几种可用于计算最坏情况的堆栈使用情况的技术。我们仅涉及了几个重点。开发人员还可以使用其他几种方法,例如使用诸如Percepio Tracealyzer或uC Probe之类的工具直接监视堆栈内存。甚至有些方法依赖于由编译器和链接器执行的计算。今天,这些已经超出了我们的范围,但是如果您对这些方法感兴趣,我建议 阅读这篇文章。如我们所见,在整个开发周期中,使用现代工具来监视堆栈使用非常容易。强烈建议开发人员在编写软件时,相应地监视和调整堆栈大小,以实现尽可能高效的系统。

3 thoughts 上 “进行最坏情况堆栈分析的3种方法”

  1. 不错的文章,但是有点离题。
    由于复杂性,无法进行手动计算,此外您还需要检查由编译器/优化器生成的汇编代码以查看实际的堆栈使用情况。
    Measuring the stack usage in general does not provide the 最坏的-case stack usage, it just provides the stack usage for the 最坏的情况下 that was tested, which may be far away from the absolute maximum. The latter, howevr, is likely to happen during a product’的生命周期,但不太可能被测试用例击中。
    因此,真正确定最坏情况的唯一方法是基于工具的方法。但是,如果您使用的是复杂的软件系统,则由于您使用了所有注释,因此这种分析可能很容易需要一周以上的时间’必须要做的。如果您使用大量的函数指针,则需要进行大量工作。某些工具不是在源代码上运行,而是在二进制文件上运行,实际上这是首选,因为只有这样,您才能对实物进行分析(工具并不总是正确地解释#ifdefs),但是随后您还需要查看注释函数指针时反汇编。因此,工作量可能会非常大,过程仍然容易出错,并且只有当您做得很好时,您才能获得可靠的最坏情况数字。
    因此,随着项目规模的增加,两种方法提供了估计值,而第三种方法提供了准确的数字的可能性降低了。

    1. 感谢您的评论。确实可以进行手动计算。一世’做到了,有一些客户也取得了良好的效果。仅仅因为某件事很复杂并不意味着它就不可能完成。 15年前,当我第一次进入该领域时,执行最坏情况堆栈分析的唯一方法实际上是手动执行。当时很少有工具可以给出答案。

      对于您的其余评论,我相信本文中会涉及这些内容。堆栈分析的最坏情况总是“worst case”。即使使用最先进的工具也无法保证您将获得准确的结果。这就是为什么您要查看结果,方法并为生产单元提供一些缓冲的原因。

      您还可以使用MPU和其他几种方法来测试您的“worst”以确保适用于该应用程序。

发表评论

您的电子邮件地址不会被公开。 必需的地方已做标记 *

该网站使用Akismet减少垃圾邮件。 了解如何处理您的评论数据.