标签：style blog http color os 使用 strong ar 文件
一般在stm32工程使用keil编译之后，keil的build output栏目下面会出现如图所示的输出信息，其中会显示code 大小 RO-data、RW-data 、ZI-data的大小。一般别人不怎么会在意这个的大小。
出于好奇我百度了下网上关于这些段的介绍，援引自http://mcuos.com/thread-2843-1-1.html，上面的介绍是这样说的：
ARM程序的组成
此处所说的“ARM程序”是指在ARM系统中正在执行的程序，而非保存在ROM中的bin映像（image）文件，这一点清注意区别。
一个ARM程序包含3部分：RO，RW和ZI。RO是程序中的指令和常量；RW是程序中的已初始化变量;ZI是程序中的未初始化的变量.
由以上3点说明可以理解为：RO就是readonly，RW就是read/write，ZI就是zero
ARM映像文件的组成
所谓ARM映像文件就是指烧录到ROM中的bin文件，也称为image文件。以下用Image文件来称呼它。
Image文件包含了RO和RW数据。之所以Image文件不包含ZI数据，是因为ZI数据都是0，没必要包含，只要程序运行之前将ZI数据所在的区域一律清零即可。包含进去反而浪费存储空间。
Q：为什么Image中必须包含RO和RW？
A：因为RO中的指令和常量以及RW中初始化过的变量是不能像ZI那样“无中生有”的。
ARM程序的执行过程
从以上两点可以知道，烧录到ROM中的image文件与实际运行时的ARM程序之间并不是完全一样的。因此就有必要了解ARM程序是如何从ROM中的image到达实际运行状态的。
实际上，RO中的指令至少应该有这样的功能：
1. 将RW从ROM中搬到RAM中，因为RW是变量，变量不能存在ROM中。
2. 将ZI所在的RAM区域全部清零，因为ZI区域并不在Image中，所以需要程序根据编译器给出的ZI地址及大小来将相应得RAM区域清零。ZI中也是变量，同理：变量不能存在ROM中
在程序运行的最初阶段，RO中的指令完成了这两项工作后C程序才能正常访问变量。否则只能运行不含变量的代码。
按照上面的我标红色的部分的解释，这样的话RO-data、RW-data和code的大小加起来就是最终的烧入程序的大小，但是好像事情不是这么简单的。看截图：
从我截图的hex程序来看程序的大小是1.5K和我们编译出来的RO-data+RW-data+code的大小是304+252=556字节，557字节和1.5K相差了很多，这又是怎么回事呢？
这时候我想起了hex和bin这两种文件的格式，我在想是不是因为格式的原因在到鬼呢？
这是百度文库里面一篇关于单片机编译生成的各种文件的格式的介绍，从介绍中我们很明显的hex文件的大小并不等于最终烧入到单片机的程序大小，因为hex里面有很多的ASSII码的信息，最终的程序大小是可以从bin文件中看出来的。怎么样子把hex文件转化为bin文件呢？
在keil的安装目录下面有一个小工具：C:\Keil_v5\ARM\ARMCC\bin目录下面有一个fromelf.exe的小工具，是可以将axf文件转换成bin文件的一个小工具。我在命令行下面进行了这个操作。
上面是运行的过程，然后我们可以看生成的bin文件大小。
从上面的图上看出，生成的bin文件和我们之前计算的一样了。其实如果是有特殊的需要的话，可以在keil里面设置调用fromelf就可以了。具体的自己百度。
标签：style blog http color os 使用 strong ar 文件
原文地址：http://www.cnblogs.com/51mcu/p/3940376.html
