HEX-80文件格式

转载地址：Hex-80文件格式研究

这段时间在研究Keil，不是很明白代码是怎么加载到CodeRAM里的，所以着重看了一下Keil的默认生成文件格式，先转一下从网上看到的资料：

Keil输出的hex文件则是另外一个类似的格式Hex-80。与前者类似，纪录的格式为:
：LLAAAARRDDDD………DDDDCC
LL:    Length field-长度段：数据段(D)的字节数
AAAA:  Address field-地址段：数据段第一个字节的地址
RR:    Record type-纪录类型,00代表数据,01代表纪录结束
DD..:  Data field-数据段
CC:    CheckSum field-校验和：计算方法是将本条记录冒号开始的所有对字母<不包括本效验字和冒号>所表示的十六进制数字<一对字母表示一个十六进制数,这样的一个十六进制数为一个字节>都加起来然后模除256得到的余数最后求出余数的补码即是本效验字节cc.

例子：:011B50002272
LL = 0x01
AAAA = 0x1B50
RR=0x00
DD=0x22
CHECK SUM = ~((0x01+0x1B+0x50+0x22)&0xFF)+1 = 0x72

与Intel 32不同，由于Hex-80用于64K地址范围以内的系统，所以没有基址设定的指令。如果在Keil－51中，用跨BANK的方式超过了64K，编译器会产生多个HXX文件来标识BANK。如：
test.h00
test.h01
test.h02
分别在每个bank的视角来产生64K代码空间。对于Common Bank由于其在每个Bank的视角中都存在，所以在几个文件中都有同样的存在，这点要求编程人员注意。

于是马上生成一个HEX-80文件格式，并用HEX2BIN.exe转成二进制文件进行比较（实践是检验真理的标准嘛，毛主席教导我们的）：

对了，HEX2BIN不支持长于8个字符的文件名，真是个历史遗留问题...

HEX文件：
:0300000002001EDD
:0C001E00787FE4F6D8FD758109020065CA
:0E00D2000108550109AA4100005A410001A58C
:1000AA00E58954F04401F589758C27758A10D2A91F
:1000BA00D28CE589540F4410F589758DFF758BFF35
:0800CA00D2ABD28ED2AF80FE52
:03000B00020003ED
:03000300050832BB
:03001B00020006DA
:03000600050832B8
:10002A000200AAE493A3F8E493A34003F68001F242
:10003A0008DFF48029E493A3F85407240CC8C333D7
:10004A00C4540F4420C8834004F456800146F6DFA6
:10005A00E4800B01020408102040809000D2E47E64
:10006A00019360BCA3FF543F30E509541FFEE4939B
:10007A00A360010ECF54C025E060A840B8E493A362
:10008A00FAE493A3F8E493A3C8C582C8CAC583CA8D
:10009A00F0A3C8C582C8CAC583CADFE9DEE780BE45
:0100E000001F
:00000001FF


二进制文件：

00h: 02 00 1E 05 08 32 05 08 32 00 00 02 00 0300 00

10h: 00 00 00 00 00 00 00 00 00 00 00  02 00 06 78 7F

20h: E4 F6 D8 FD 75 81 09 02 00 65 02 00 AA E4 93 A3

...

d0h: 80 FE 01 08 55 01 09 AA 41 00 00 5A 41 00 01 A5

e0h: 00

UltraEdit不能复制二进制，自己也懒的转，就写一些好了，关键是结论，HEX2BIN会根据Hex-80文件中的地址信息把各个段放在指定的地方，对于空的地址写0（其实写什么都可以，PC跑不到），如图中的红色。


因此，如果在编程时通过CREG AT ADDRESS指定了一个很高的地址，而本身代码量很小的话，生成的HEX文件会很小，而通过HEX2BIN转出来的bin文件就会大了去了，哈哈哈哈。。。


这样看来，代码是不需要在程序里搬移的，?C_START只需要负责初始化全局变量就可以了，所以Keil的ROM文件的效率还是很低啊。。。