在为资源受限的系统开发软件时，强烈建议嵌入式开发人员使用跟踪代码、数据和RAM使用情况的指标。该信息总是可以在编译器生成的映射文件中找到，但它并不总是最终的和总的值。许多编译器会计算这些值，并在编译过程中将它们打印到控制台窗口。尽管显示的信息并不总是清晰的。

　　例如，在为ARM Cortex-M处理器编译程序时，打印到控制台的输出将采用类似如下的形式:

　　文本数据 bss dec 十六进制文件名

　　0x100 0x22 0x56 377 0x178 experiment1.elf

　　乍一看，这可能看起来相对令人生畏，尽管并不完全如此。脑海中浮现的问题是，这些不同的空间到底是什么意思?实际使用了多少RAM和多少闪存?要理解这一点，关键是要知道这些细分市场到底是什么，以及它们对这些总数的贡献如何。

　　文本段告诉嵌入式开发人员有多少闪存空间被分配给程序的代码和常量。这可以被认为是任何使用常量类型限定符的变量、函数和作为程序的一部分生成的可执行代码。例如，下面的语句将向文本段添加四个字节。

　　const uint32 _ t Data = 0x14

　　数据段包含初始化变量在闪存中占用的空间量。这一部分非常重要，因为变量的初始值存储在flash中，但在系统初始化期间会复制到RAM中。这种复制过程通常被称为C向下复制。下面是一个初始化变量的例子:

　　uint32 _ t Data _ Init = 0x14

　　bss段包含用于任何未初始化数据的空间。这是将被赋予初始值0的数据。这些变量将再次存储在RAM中。未初始化数据的一个简单示例如下:

　　uint32 _ t Data _ NoInit

　　编译器输出中的其余值只是以十进制或十六进制表示法表示文本、数据和bss段的总数。不幸的是，这个结果实际上只告诉了应用程序将使用多少闪存空间。要获得正在使用的RAM量，需要将数据段和bss段相加。一旦完成，嵌入式开发人员就可以了解器件使用了多少闪存和RAM空间。