總結(jié)： HEX文件：由一條條具有規(guī)定格式、由16進(jìn)制的數(shù)據(jù)表示特定特定信息的HEX文本記錄組成的可燒寫文件，每條記錄中的數(shù)據(jù)包含有地址與要燒寫的數(shù)據(jù)以及檢驗(yàn)碼等信息。每條燒寫文本記錄中若包含數(shù)據(jù)記錄，那么16進(jìn)制的數(shù)據(jù)與BIN文件【16進(jìn)制表示時(shí)】是一樣的，HEX每條文本記錄多出來的就是地址與檢驗(yàn)信息等.... BIN文件，就是直接可以燒寫到存儲(chǔ)器中的二進(jìn)制文件，程序運(yùn)行后，對(duì)應(yīng)地址的數(shù)據(jù)與BIN是一摸一樣的.我們可以打開KEIL軟件，軟件調(diào)試時(shí)，可以看到，C對(duì)應(yīng)匯編【硬件調(diào)試時(shí)用的是反匯編】，匯編再對(duì)應(yīng)相應(yīng)的機(jī)器碼，最左邊的存儲(chǔ)空間地址，過來就是對(duì)應(yīng)的機(jī)器指令，因?yàn)檫@里的ARM都是Thumb指令所以每一條指令對(duì)應(yīng)的是16位，兩個(gè)字節(jié)，而ARM指令是32位的，4個(gè)字節(jié)，BIN文件就是這些機(jī)器碼的集合，HEX文件中的數(shù)據(jù)記錄也是這些機(jī)器碼得集合，不過HEX文件中除了這些數(shù)據(jù)記錄還有地址信息等

????????Thumb指令可以看做是ARM指令壓縮形式的子集，是針對(duì)代碼密度^【1】的問題而提出的，它具有16為的代碼密度。Thumb不是一個(gè)完整的體系結(jié)構(gòu)，不能指望處理程序只執(zhí)行Thumb指令而不支持ARM指令集。因此，Thumb指令只需要支持通用功能，必要時(shí)，可借助完善的ARM指令集，例如：所有異常自動(dòng)進(jìn)入ARM狀態(tài)。

???????在編寫Thumb指令時(shí)，先要使用偽指令CODE16聲明，而且在ARM指令中要使用BX指令跳轉(zhuǎn)到Thumb指令，以切換處理器狀態(tài)。編寫ARM指令時(shí)，可使用偽指令CODE32聲明。

??????代碼密度：單位存儲(chǔ)空間中包含的指令的個(gè)數(shù)。例如

??????????????ARM指令是32位的，而Thumb指令時(shí)16位的，如果在1K的存儲(chǔ)空間中，可以放32條ARM指令，就可以放64條Thumb指令，因此在存放Thunb指令時(shí)，代碼密度高。

arm存儲(chǔ)格式有小端結(jié)尾（低字節(jié)存儲(chǔ)在低位，即由小到大）、大端結(jié)尾（最高字節(jié)存儲(chǔ)在低位，即由大到小）。arm存儲(chǔ)以字節(jié)為單位，地址空間為2^32個(gè)字節(jié)共4G空間。arm存儲(chǔ)訪問由對(duì)齊訪問和非對(duì)齊訪問。arm指令長度固定為一個(gè)字長，即32位

截圖從反匯編，紅色部分也是BIN文件的內(nèi)容

HEX文件截圖
可以從上面的兩幅圖片上的兩種顏色框的對(duì)應(yīng)關(guān)系看出其中的關(guān)系
Intel HEX文件是記錄文本行的ASCII文本文件，在Intel HEX文件中，每一行是一個(gè)HEX記錄，由十六進(jìn)制數(shù)組成的機(jī)器碼或者數(shù)據(jù)常量。 Intel HEX文件經(jīng)常被用于將程序或數(shù)據(jù)傳輸存儲(chǔ)到ROM、EPROM，大多數(shù)編程器和模擬器使用Intel HEX文件。
???很多編譯器的支持生成HEX格式的燒錄文件，尤其是Keil c。但是編程器能夠下載的往往是BIN格式，因此HEX轉(zhuǎn)BIN是每個(gè)編程器都必須支持的功能。 ??? ???HEX格式文件以行為單位，每行由“：”（0x3a）開始，以回車鍵結(jié)束(0x0d,0x0a)。 ???行內(nèi)的數(shù)據(jù)都是由兩個(gè)字符表示一個(gè)16進(jìn)制字節(jié)，比如”01”就表示數(shù)0x01；”0a”，就表示0x0a。 ???對(duì)于16位的地址，則高位在前低位在后，比如地址0x010a，在HEX格式文件中就表示為字符串”010a”。 ???下面為HEX文件中的一行：:10 0000 00 FF0462FF051EFF0A93FF0572FF0A93FF BC ? ???“：”表示一行的開始。 ? ???“：”后的第1，2個(gè)字符“10”表示本行包含的數(shù)據(jù)的長度，這里就是0x10即16個(gè)。 ??? ???第3，4，5，6個(gè)字符“0000”表示數(shù)據(jù)存儲(chǔ)的起始地址，這里表示從0x0000地址開始存儲(chǔ)16個(gè)數(shù)據(jù)，其中高位地址在前，低位地址在后。 ? ???第7，8個(gè)字符“00”表示數(shù)據(jù)的類型。該類型總共有以下幾種： 00 ----數(shù)據(jù)記錄? 01 ----文件結(jié)束記錄 02 ----擴(kuò)展段地址記錄 04 ----擴(kuò)展線性地址記錄這里就是0x00即為普通數(shù)據(jù)記錄。 自后的32個(gè)字符就是本行包含的數(shù)據(jù)，每兩個(gè)字符表示一個(gè)字節(jié)數(shù)據(jù)，總共有16個(gè)字節(jié)數(shù)據(jù)跟行首的記錄的長度相一致。 最后兩個(gè)字符表示校驗(yàn)碼。 每個(gè)HEX格式的最后一行都是固定為：:00000001FF ???以上的信息其實(shí)就足夠進(jìn)行HEX轉(zhuǎn)BIN格式的程序的編寫。 首先我們只處理數(shù)據(jù)類型為0x00及0x01的情況。0x02表示對(duì)應(yīng)的存儲(chǔ)地址超過了64K，由于我的編程器只針對(duì)64K以下的單片機(jī)， 因此在次不處理，0x04也是如此
什么是Intel HEX格式? 回答: Intel HEX文件是記錄文本行的ASCII文本文件,在Intel HEX文件中,每一行是一個(gè)HEX記錄 由十六進(jìn)制數(shù)組成的機(jī)器碼或者數(shù)據(jù)常量,Intel HEX文件經(jīng)常被用于將程序或數(shù)據(jù)傳輸 存儲(chǔ)到ROM.EPROM,大多數(shù)編程器和模擬器使用Intel HEX文件.
記錄格式 一個(gè)Intel HEX文件可以包含任意多的十六進(jìn)制記錄,每條記錄有五個(gè)域,下面是一個(gè)記錄的格式. :llaaaatt[dd...]cc 每一組字母是獨(dú)立的一域,每一個(gè)字母是一個(gè)十六進(jìn)制數(shù)字,每一域至少由兩個(gè)十六進(jìn)制數(shù)字組成,下面是字節(jié)的描述. :冒號(hào) 是每一條Intel HEX記錄的開始 ll 是這條記錄的長度域,他表示數(shù)據(jù)(dd)的字節(jié)數(shù)目. aaaa 是地址域,他表示數(shù)據(jù)的起始地址<如果是數(shù)據(jù)記錄,這表示將要燒錄的這條記錄中的數(shù)據(jù)在EPROM中的偏移地址, 對(duì)于不支持?jǐn)U展段地址和擴(kuò)展線性地址的,如89C51,這就是此條記錄的起始地址>
tt 這個(gè)域表示這條HEX記錄的類型,他有可能是下面這幾種類型 00 ----數(shù)據(jù)記錄? 01 ----文件結(jié)束記錄 02 ----擴(kuò)展段地址記錄 04 ----擴(kuò)展線性地址記錄
dd 是數(shù)據(jù)域,表示一個(gè)字節(jié)的數(shù)據(jù),一個(gè)記錄可能有多個(gè)數(shù)據(jù)字節(jié),字節(jié)數(shù)目可以 查看ll域的說明
cc 是效驗(yàn)和域,表示記錄的效驗(yàn)和,計(jì)算方法是將本條記錄冒號(hào)開始的所有字母對(duì) <不包括本效驗(yàn)字和冒號(hào)> 所表示的十六進(jìn)制數(shù)字 <一對(duì)字母表示一個(gè)十六進(jìn)制數(shù),這樣的一個(gè)十六進(jìn)制數(shù)為一個(gè)字節(jié)> 都加起來然后模除256得到的余數(shù) 最后求出余數(shù)的補(bǔ)碼即是本效驗(yàn)字節(jié)cc. <例如: :0300000002005E9D cc=0x01+NOT((0x03+0x00+0x00+0x00+0x02+0x00+0x5E)%0x100)=0x01+0x9C=0x9D
C語言描述: UCHAR cc; cc=(UCHAR)~(0x03+0x00+0x00+0x00+0x02+0x00+0x5E); cc++; > 數(shù)據(jù)記錄
Intel HEX文件由若干個(gè)數(shù)據(jù)記錄組成,一個(gè)數(shù)據(jù)記錄以一個(gè)回車和一個(gè)換行結(jié)束 <回車為0x0d換行為0x0a>
比如下面的一條數(shù)據(jù)記錄 :10246200464C5549442050524F46494C4500464C33
10 是此行記錄數(shù)據(jù)的字節(jié)數(shù)目 2462 是數(shù)據(jù)在內(nèi)存<將要燒寫的eprom地址>中的起始地址 00 是記錄類型00(是一個(gè)數(shù)據(jù)記錄) 464C 到 464C 是數(shù)據(jù) 33 是此行記錄的效驗(yàn)和
擴(kuò)展線性地址記錄(HEX386) 擴(kuò)展線性地址記錄也可稱為 32位地址記錄 和 HEX386記錄,這個(gè)紀(jì)錄包含高16(16-31位)位數(shù)據(jù)地址,這種擴(kuò)展的線性記錄總是有兩個(gè)字節(jié)數(shù)據(jù),像下面這樣:
:02000004FFFFFC 02 是記錄的數(shù)據(jù)字節(jié)數(shù)目 0000 是地址域這在擴(kuò)展地址記錄中總是0000 04 是記錄類型04(擴(kuò)展地址記錄) FFFF 是高16位地址 FC 是記錄效驗(yàn)和,計(jì)算方法如下: 01h + NOT(02h + 00h + 00h + 04h + FFh + FFh)
當(dāng)一個(gè)擴(kuò)展線性地址記錄被讀到后,擴(kuò)展線性地址記錄的數(shù)據(jù)區(qū)域?qū)⒈槐４? 并應(yīng)用到后面從Intel HEX文件中讀出的記錄,這個(gè)擴(kuò)展線性記錄一直有效, 直到讀到下一個(gè)擴(kuò)展線性記錄.

絕對(duì)內(nèi)存地址 = 數(shù)據(jù)記錄中的地址 + 移位后的擴(kuò)展線性地址

下面舉例說明這個(gè)過程
從數(shù)據(jù)記錄的地址域得到地址 2462 從擴(kuò)展線性地址記錄的地址域得到地址 FFFF 絕對(duì)內(nèi)存地址 FFFF2462
擴(kuò)展段地址記錄 (HEX86)?
擴(kuò)展段地址記錄也被稱為 HEX86記錄, 包含 4-19位的數(shù)據(jù)地址段, 這個(gè)擴(kuò)展段地址記錄總是有兩字節(jié)數(shù)據(jù),如下:
:020000021200EA 02 是 記錄中的數(shù)據(jù)字節(jié)數(shù)目 0000 是地址域,在擴(kuò)展段地址記錄中,這個(gè)域總是0000 02 是記錄類型02(擴(kuò)展段地址的標(biāo)示) 1200 是該段的地址 EA 是效驗(yàn)和 計(jì)算如下: 01h + NOT(02h + 00h + 00h + 02h + 12h + 00h).
當(dāng)擴(kuò)展段地址記錄被讀后,擴(kuò)展段地址將被存儲(chǔ)并應(yīng)用到以后從Intel HEX文件讀出的記錄,這個(gè)段地址一直有效直到讀到下一個(gè)擴(kuò)展段地址記錄
絕對(duì)內(nèi)存地址 = 數(shù)據(jù)記錄中的地址 + 移位后的擴(kuò)展段地址

數(shù)據(jù)記錄中的地址域 移位后擴(kuò)展段地址記錄中的地址域
下面舉例說明這個(gè)過程
從數(shù)據(jù)記錄的地址域得到地址 2 4 6 2 從擴(kuò)展段地址記錄的地址域得到地址 1 2 0 0 絕對(duì)內(nèi)存地址 0 0 0 1 4 4 6 2
文件結(jié)束記錄(EOF) 一個(gè)Intel HEX文件必須有一個(gè)文件結(jié)束記錄,這個(gè)記錄的類型域必須是01, 一個(gè)EOF記錄總是這樣: :00000001FF 00是記錄中數(shù)據(jù)字節(jié)的數(shù)目 0000這個(gè)地址對(duì)于EOF記錄來說無任何意義 01記錄類型是01(文件結(jié)束記錄標(biāo)示) FF是效驗(yàn)和計(jì)算如下 01h + NOT(00h + 00h + 00h + 01h). ========================
總結(jié)

形如 :BBAAAATTHHHH...HHHHCC
BB: Byte AAAA:數(shù)據(jù)記錄的開始地址,高位在前,地位在后 因?yàn)檫@個(gè)格式只支持8bits,地址被倍乘 所以,為了得到實(shí)際的PIC的地址,需要將 地址除以2 TT: Type 00 數(shù)據(jù)記錄 01 記錄結(jié)束 04 擴(kuò)展地址記錄(表示32位地址的前綴,當(dāng)然這種只能在 INHX32) HHHH:一個(gè)字(Word)的數(shù)據(jù)記錄,高Byte在前,低Byte在后 TT之后,總共有 BB/2 個(gè)字 的數(shù)據(jù) CC: 一個(gè)Byte的CheckSum

因?yàn)镻IC16F873A只有4K的程序空間
所以,不會(huì)有 TT=04的 Linear Address Record

而Bin文件是最純粹的二進(jìn)制機(jī)器代碼,沒有格式,或者說是"順序格式"按assembly code順序翻譯成binary machine code. 由于分析出來Hex文件中的數(shù)據(jù)域ASCII碼表示的十六進(jìn)制與二進(jìn)制一一對(duì)應(yīng),而且我公司DSP又是16位的,以一個(gè)word為最小單位, 所以四個(gè)十六進(jìn)制ASCII碼代表一條機(jī)器指令單位或者地址.借于上面分析,編寫了工具代碼. 大體原理是用fscanf函數(shù)在每行的數(shù)據(jù)域讀入四個(gè) ASCII碼,以短整形(short int 16bit)形式儲(chǔ)存,在把這個(gè)短整形變量順序fwrite到文件流中去即可.?
舉一例說明：? 表1? ORG 0000H? LJMP START? ORG 040H? START：? MOV SP，#5FH ;設(shè)堆棧? LOOP：? NOP? LJMP LOOP ；循環(huán)? END ；結(jié)束? 表2? :03000000020040BB? :0700400075815F000200431F? 表3　　　　　　　　　? 02 00 40 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF? FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF? FF FF FF FF FF FF FF FF FF FF FF FF 75 81 5F 00 02 00 43? 表1為源程序，表2是匯編后得到的HEX文件，表3是由HEX文件轉(zhuǎn)換成的目標(biāo)文件，也就是最終寫入EPROM的文件，它由編程器轉(zhuǎn)換得到， 也可以由 HEXBIN一類的程序轉(zhuǎn)換得到。學(xué)過手工匯編者應(yīng)當(dāng)不難找出表3與表1的一一對(duì)應(yīng)關(guān)系， 值得注意的是從02 00 40后開始的一長串‘FF’，直到75 81，這是由于偽指令：ORG 040H造成的結(jié)果。?
/ copy from:http://tieba.baidu.com/f?kz=271526661?


#include <stdio.h> #include <stdlib.h> #include <string.h>
FILE *fp_read; ??????????????? FILE *fp_write; ????????????? ?????? ?????? unsigned long start_adr; ????? unsigned short cur_base; ????? unsigned short cur_offset; ???
unsigned char read_buf[16]; unsigned char write_buf[48];
void calc_start_adr (char *buf) { ?????unsigned int len; ??? ?????len = strlen(buf); ??? ?????if ((buf[len-1] != 'k') && (buf[len-1] != 'K')) { ?????????printf ("Invalid argument.\n"); ?????????exit (-1); ?????} ??? ?????buf[len-1] = 0; ??? ?????start_adr = atoi (buf); ?????start_adr = start_adr * 1024; ?????cur_base = ???start_adr >> 16;? ?????cur_offset = (unsigned short)start_adr; }
void start_convert (void) { ?????unsigned char cnt; ?????unsigned char read_num; ?????unsigned char cksum, highc, lowc; ??? ???? ?????highc = cur_base >> 8; ?????lowc = (unsigned char)cur_base; ?????cksum = 2 + 4 + highc + lowc; ?????cksum = 0xFF - cksum; ?????cksum = cksum + 1; ?????sprintf (write_buf, ":02000004xx", cur_base, cksum); ?????write_buf[15] = 0x0D; write_buf[16] = 0x0A;? ?????fwrite (write_buf, 1, 17, fp_write); ??? ?????read_num = fread (read_buf, 1, 16, fp_read); ?????while (read_num == 16) { ???????? ?????????highc = cur_offset >> 8; ?????????lowc = (unsigned char)cur_offset; ?????????cksum = 0x10 + highc + lowc; ?????????for (cnt=0; cnt<16; cnt++) { ?????????????cksum += read_buf[cnt]; ?????????} ?????????cksum = 0xFF - cksum; ?????????cksum = cksum + 1; ??????? ?????????sprintf (write_buf, ":10xx00xxxxxxxxxxxxxxxxx",? ?????????????????highc, lowc, ?????????????????read_buf[0], read_buf[1], read_buf[2], read_buf[3],? ?????????????????read_buf[4], read_buf[5], read_buf[6], read_buf[7],? ?????????????????read_buf[8], read_buf[9], read_buf[10], read_buf[11],? ?????????????????read_buf[12], read_buf[13], read_buf[14], read_buf[15],? ?????????????????cksum); ?????????write_buf[43] = 0x0D; write_buf[44] = 0x0A; ?????????fwrite (write_buf, 1, 45, fp_write); ??????? ???????? ?????????if (cur_offset == 65520) { ?????????????cur_offset = 0; ?????????????cur_base ++; ?????????????highc = cur_base >> 8; ?????????????lowc = (unsigned char)cur_base; ?????????????cksum = 2 + 4 + highc + lowc; ?????????????cksum = 0xFF - cksum; ?????????????cksum = cksum + 1; ?????????????sprintf (write_buf, ":02000004xx", cur_base, cksum); ?????????????write_buf[15] = 0x0D; write_buf[16] = 0x0A;? ?????????????fwrite (write_buf, 1, 17, fp_write); ?????????} else { ?????????????cur_offset += 16; ?????????} ??????? ?????????read_num = fread (read_buf,1,16,fp_read); ?????} ??? ???? ?????if (read_num) { ?????????highc = cur_offset >> 8; ?????????lowc = (unsigned char)cur_offset; ?????????cksum = read_num + highc + lowc; ?????????for (cnt=0; cnt<read_num; cnt++) { ?????????????cksum += read_buf[cnt]; ?????????} ?????????cksum = 0xFF - cksum; ?????????cksum = cksum + 1; ??????? ?????????sprintf (write_buf, ":xxx00", read_num, highc, lowc); ?????????for (cnt=0; cnt<read_num; cnt++) { ?????????????sprintf (&write_buf[9 + cnt * 2], "x", read_buf[cnt]); ?????????} ?????????sprintf (&write_buf[9 + cnt * 2], "x", cksum); ?????????write_buf[11 + read_num * 2] = 0x0D; ?????????write_buf[12 + read_num * 2] = 0x0A; ?????????fwrite (write_buf, 1, 13 + read_num * 2, fp_write); ?????} ??? ???? ?????sprintf (write_buf, ":00000001FF"); ?????write_buf[11] = 0x0D; write_buf[12] = 0x0A; ?????fwrite (write_buf, 1, 13, fp_write); }

int main (int argc, char *argv[]) { ??? ?????if (argc != 4) { ?????????printf ("Usage : %s -b address filename.xxx\n", argv[0]); ?????????printf ("-b : indicate the starting address convert to.\n"); ?????????printf ("address : starting address.\n"); ?????????printf ("filename.xxx : file to be converted.\n"); ?????????printf ("output : ???filename.hex\n"); ?????????printf ("example : %s -b 64k rom.bin\n", argv[0]); ?????????return -1; ?????} ??? ?????if (strcmp (argv[1], "-b")) { ?????????printf ("Invalid argument.\n"); ?????????return -1; ?????}; ??? ?????fp_read = fopen (argv[3], "rb"); ?????if (fp_read == NULL) { ?????????printf ("Can't open file %s", argv[3]); ?????????return -1; ?????}
?????fp_write = fopen ("rom.hex", "w"); ?????if (fp_write == NULL) { ?????????printf ("Can't create file rom.hex"); ?????????return -1; ?????} ??? ?????calc_start_adr (argv[2]); ?????start_convert (); ??? ?????fclose (fp_read); ?????fclose (fp_write); ??? ?????printf("Convert Seccessfully!\n"); ??? ?????return 0; }?



簡單介紹一下這2種文件格式的區(qū)別：

1 － HEX文件是包括地址信息的，而BIN文件格式只包括了數(shù)據(jù)本身 ?????????在燒寫或下載HEX文件的時(shí)候，一般都不需要用戶指定地址，因?yàn)镠EX文件內(nèi)部的信息已經(jīng)包括了地址。而燒寫B(tài)IN ?????????文件的時(shí)候，用戶是一定需要指定地址信息的。 ???????? ???????? 3 － BIN文件格式 ?????????對(duì)二進(jìn)制文件而言，其實(shí)沒有”格式”。文件只是包括了純粹的二進(jìn)制數(shù)據(jù)。 ???????? ???????? 4 － HEX文件格式 ?????????HEX文件都是由記錄（RECORD）組成的。在HEX文件里面，每一行代表一個(gè)記錄。記錄的基本格式為： ?????????+---------------------------------------------------------------+ ?????????| ???RECORD ??| RECLEN | ??LOAD ??| RECTYPE | INFO or DATA | CHKSUM | ?????????| ??MARK ':' | ????????| OFFSET | ?????????| ??????????????| ????????| ?????????+---------------------------------------------------------------+ ?????????| ??1-byte ???| 1-byte | 2-byte | 1-byte ??| ????n-byte ????| 1-byte | ?????????+---------------------------------------------------------------+ ???????? ?????????記錄類型包括： ?????????'00' Data Rrecord：用來記錄數(shù)據(jù)，HEX文件的大部分記錄都是數(shù)據(jù)記錄 ?????????'01' End of File Record: 用來標(biāo)識(shí)文件結(jié)束，放在文件的最后，標(biāo)識(shí)HEX文件的結(jié)尾 ?????????'04' Extended Linear Address Record: 用來標(biāo)識(shí)擴(kuò)展線性地址的記錄 ?????????'02' Extended Segment Address Record: 用來標(biāo)識(shí)擴(kuò)展段地址的記錄 ???????? ?????????在上面的后2種記錄，都是用來提供地址信息的。每次碰到這2個(gè)記錄的時(shí)候，都可以根據(jù)記錄計(jì)算出一個(gè)“基”地址。 ?????????對(duì)于后面的數(shù)據(jù)記錄，計(jì)算地址的時(shí)候，都是以這些“基”地址為基礎(chǔ)的。 ???????? ?????????數(shù)據(jù)記錄的具體格式： ?????????+---------------------------------------------------------------+ ?????????| ???RECORD ??| RECLEN | ??LOAD ??| RECTYPE | INFO or DATA | CHKSUM | ?????????| ??MARK ':' | ????????| OFFSET | ??'00' ???| ??????????????| ????????| ?????????+---------------------------------------------------------------+ ?????????| ??1-byte ???| 1-byte | 2-byte | 1-byte ??| ????n-byte ????| 1-byte | ?????????+---------------------------------------------------------------+ ???????? ???????? ?????????看個(gè)例子： ????????:020000040000FA ????????:10000400FF00A0E314209FE5001092E5011092E5A3 ????????:00000001FF ???????? ?????? ????????對(duì)上面的HEX文件進(jìn)行分析： ????????第1條記錄的長度為02，LOAD OFFSET為0000，RECTYPE為04，說明該記錄為擴(kuò)展段地址記錄。數(shù)據(jù)為0000，校驗(yàn)和為 ????????FA。從這個(gè)記錄的長度和數(shù)據(jù)，我們可以計(jì)算出一個(gè)基地址，這個(gè)地址為0X0000。后面的數(shù)據(jù)記錄都以這個(gè)地址為基 ????????地址。 ????????第2條記錄的長度為10（16），LOAD OFFSET為0004，RECTYPE為00，說明該記錄為數(shù)據(jù)記錄。 ????????數(shù)據(jù)為FF00A0E314209FE5001092E5011092E5，共16個(gè)BYTE。這個(gè)記錄的校驗(yàn)和為A3。此時(shí)的基地址為0X0000，加上OFFSET， ????????這個(gè)記錄里的16BYTE的數(shù)據(jù)的起始地址就是0x0000 + 0x0004 = 0x0004. ????????第3條記錄的長度為00，LOAD OFFSET為0000，TYPE ＝ 01，校驗(yàn)和為FF。說明這個(gè)是一個(gè)END OF FILE RECORD，標(biāo)識(shí) ????????文件的結(jié)尾。 ?????? ????????在上面這個(gè)例子里，實(shí)際的數(shù)據(jù)只有16個(gè)BYTE：FF00A0E314209FE5001092E5011092E5，其起始地址為0x4 ??????????
4 － HEX文件和BIN文件大小有區(qū)別 ?????HEX文件是用ASCII來表示二進(jìn)制的數(shù)值。例如一般8-BIT的二進(jìn)制數(shù)值0x3F，用ASCII來表示就需要分別表示字符'3' ?????和字符'F'，每個(gè)字符需要一個(gè)BYTE，所以HEX文件需要 > 2倍的空間。 ?????對(duì)一個(gè)BIN文件而言，你查看文件的大小就可以知道文件包括的數(shù)據(jù)的實(shí)際大小。而對(duì)HEX文件而言，你看到的文件 ?????大小并不是實(shí)際的數(shù)據(jù)的大小。一是因?yàn)镠EX文件是用ASCII來表示數(shù)據(jù)，二是因?yàn)镠EX文件本身還包括別的附加信息。? 本文來自CSDN博客，轉(zhuǎn)載請(qǐng)標(biāo)明出處：http://blog.csdn.net/studyvcmfc/archive/2009/05/30/4225282.aspx

總結(jié)

以上是生活随笔為你收集整理的HEX BIN文件 分析介绍的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。