如何在运行时检查堆栈和堆使用情况

好吧，我确实从80年代开始在这里旅行，所以并不奇怪。你倾向于足智多谋，因为ICE的成本与汽车一样多，虽然现在跟踪/配置文件盒的价格便宜很多，但很多人没有它们，或者用于支持它们的标头连接。
有些工具提供了对调用树和堆栈深度的静态分析，但是中断和嵌套往往是一个更大的未知因素。
我构建的大多数东西都有一个命令行监视器，允许现场调试/分析，这些通常包括从控制台感知到的堆栈深度报告，以及运行测试/诊断例程之后的报告。还尝试在硬故障的情况下提供寄存器转储，因此我们可以尝试确定LED的闪烁模式或静默死亡。热插拔系统并不总是实用或可靠。



以下为原文




Well I did travel here from the 80's so not exactly surprising. You tended to be resourceful because an ICE would cost as much as a car, and while trace/profile pods are now much cheaper a lot of people don't have them, or header connections to support them.
Some tools provide for static analysis of call trees and stack depth, but interrupts and nesting there tends to be a bigger unknown factor.
Most things I build have a command line monitor to permit field debug/analysis, these typically include a reporting of stack depth as perceived from the console, and after running test/diagnostic routines. Also try to provide a register dump in case of hard failure, so we have something to work from than trying to determine the flashing pattern of an LED, or silent death. Hot-plugging a system isn't always practical or reliable.

我以为我疯狂地从构建基于串口的控制台和简单的CLI解析器开始每个项目;）
我的疯狂来自于我对Cisco路由器的长期经验以及它们具有内置良好调试功能的能力（包括发生崩溃时的内存和堆栈跟踪）。我还为我的项目添加了一些脚本功能，因为我喜欢脚本语言。
我喜欢的另一个奇怪的事情是从SRAM运行代码（如果可能的话，由于SRAM大小）。许多人说这是愚蠢的，因为闪光灯可以在很多次重编程中存活下来。我曾经使用TI MCU，其中1000个周期被杀死;）我注意到你也使用这个功能。



以下为原文




I was thinking I am mad starting every project from building serial-based console and simple CLI parser;)
My madness come from my long experience with Cisco routers and their ability to have built-in decent debugging capabilities (including memory and stack traces when a crash occurs). I also add some scripting capabilities to my projects as I like scripting languages.
Another weird thing I like is running code from SRAM (if possible due to SRAM size).  Many people say it's stupid as the flash can survive many cycles of reprogramming. I used to use a TI MCU where the 1000 cycles were killing;) I noticed that you also use this feature.