我前面曾经介绍了Intel 32 bit Hex，但并非全部的.hex文件都属于这种格式。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的视角中都存在，因此在几个文件中都有一样的存在，这点要求编程人员注意。 还有，貌似Keil产生的Hex-80文件地址并不连续～天晓得Keil为何不规整一下。