如何确定嵌入式系统中的最大堆栈使用量？ [英] How to determine maximum stack usage in embedded system?

问题描述

当我给Keil编译器-callgraph选项
时，它静态地计算出我的确切的最大堆栈使用率。

When I give the Keil compiler the "--callgraph" option, it statically calculates the exact "Maximum Stack Usage" for me.

今天它给了我一个最大堆栈使用率= 284字节+未知（无堆栈大小的功能）消息，以及没有堆栈信息的函数列表。

Alas, today it is giving me a "Maximum Stack Usage = 284 bytes + Unknown(Functions without stacksize...)" message, along with a list of "Functions with no stack information".

Nigel Jones表示递归在嵌入式系统中是一个非常糟糕的想法
（计算你的堆栈大小 2009），
所以我一直小心不要在这段代码中做任何相互递归的函数。

Nigel Jones says that recursion is a really bad idea in embedded systems ("Computing your stack size" 2009), so I've been careful not to make any mutually recursive functions in this code.

另外，我确保我的所有中断处理程序都没有重新启用中断，直到最后的中断指令返回，所以我不需要担心重入中断处理程序。

Also, I make sure that none of my interrupt handlers ever re-enable interrupts until their final return-from-interrupt instruction, so I don't need to worry about re-entrant interrupt handlers.

没有递归或重入式中断处理程序，它应该能够静态地确定最大堆栈美国GE。
（所以大部分答案
如何确定最大值堆栈使用？
不适用）。
我的理解是处理--callgraph选项
的软件首先找到每个中断处理程序的最大堆栈深度，当它不被更高优先级的中断中断时，最大堆栈深度main（）函数不中断时。
然后将它们全部添加到最大堆栈深度（最坏情况）中。
当main（）后台任务被最低优先级中断中断时处于最大深度，当中断处于下一个最低优先级中断中断的最大深度时，等等。

Without recursion or re-entrant interrupt handlers, it should able to statically determine the maximum stack usage. (And so most of the answers to How to determine maximum stack usage? do not apply). My understanding is that the software that handles the "--callgraph" option first finds the maximum stack depth for each interrupt handler when it's not interrupted by a higher-priority interrupt, and the maximum stack depth of the main() function when it is not interrupted. Then it adds them all up to find the total (worst-case) maximum stack depth. That occurs when the main() background task is at its maximum depth when it is interrupted by the lowest-priority interrupt, and that interrupt is at its maximum depth when it is interrupted by the next-lowest-priority interrupt, and so on.

我怀疑处理的软件 - 在无堆栈信息的功能列表中，小程序集语言功能变得混乱。
- 电话文档似乎暗示我需要手动计算（或保守估计）他们使用多少堆栈 - 它们非常短，所以应该简单 - 然后使用汇编语言代码中的框架指令来描述代码如何使用栈。
其中一个是在跳转到main（）之前将堆栈重置为零的初始启动代码 - 实际上，这将消耗零堆栈。
另一个是故障中断处理程序，锁定在无限循环中，直到我循环电源 - 可以安全地假定这消耗零堆栈。

I suspect the software that handles --callgraph is getting confused about the small assembly-language functions in the "Functions with no stack information" list. The --callgraph documentation seems to imply that I need to manually calculate (or make a conservative estimate) how much stack they use -- they're very short, so that should be simple -- and then "Use frame directives in assembly language code to describe how your code uses the stack." One of them is the initial startup code that resets the stack to zero before jumping to main() -- so, in effect, this consumes zero stack. Another one is the "Fault" interrupt handler that locks up in an infinite loop until I cycle the power -- it's safe to assume this consumes zero stack.

我正在使用Keil uVision V4.20.03.0编译LM3S1968 ARM Cortex-M3的代码。

I'm using the Keil uVision V4.20.03.0 to compile code for the LM3S1968 ARM Cortex-M3.

那么如何使用框架指令来告诉处理 - 调用这些函数使用多少堆栈的软件？
还是有更好的方法来确定最大堆栈使用率？

So how do I use "frame directives" to tell the software that handles "--callgraph" how much stack these functions use? Or is there some better approach to determine maximum stack usage?

（请参阅的嵌入式系统中最大堆栈使用率如何确定与gcc编译器几乎相同的问题。 ）

(See How to determine maximum stack usage in embedded system with gcc? for almost the same question targeted to the gcc compiler.)

推荐答案

在链接器选项中使用--info = stack。然后，该地图文件将包含具有外部链接的所有功能的堆栈使用。

Use the --info=stack in the linker option. The map file will then include a stack usage for all functions with external linkage.

在单个任务环境中，main（）的堆栈使用将为您提供总需求。如果您使用RTOS（如每个任务具有自己的堆栈）的RTOS，那么您需要查看所有任务入口点的堆栈使用情况，然后在任务上下文中添加一些（在RTX的情况下为64个字节）存储。

In a single tasking environment, the stack usage for main() will give you the total requirement. If you are using an RTOS such as RTX where each task has its own stack, then you need to look at the stack usage for all task entry points, and then add some more (64 bytes in the case of RTX) for the task context storage.

这种和其他适用于Keil的技术和更一般的描述 here

This and other techniques applicable to Keil and more generally are described here

这篇关于如何确定嵌入式系统中的最大堆栈使用量？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！