大家好，我是痞子衡，是正經(jīng)搞技術(shù)的痞子。今天痞子衡給大家講的是嵌入式開發(fā)里的image文件(.bin, .hex, .s19)。
今天這節(jié)課是痞子衡《ARM Cortex-M文件那些事》主題系列的最后一節(jié)課（突然有點不舍，要告別的感覺，咳咳，讓痞子衡整理下情緒先）。今天痞子衡主要講的是工程開發(fā)最終的output文件，即image文件。image文件也叫鏡像文件，這個文件主要包含的是只有芯片能夠解釋執(zhí)行的二進制機器碼數(shù)據(jù)，這些數(shù)據(jù)其實在前面介紹的relocatable、list、executable文件中出現(xiàn)過，在那些文件里我們還可以根據(jù)其他輔助信息來分析機器碼數(shù)據(jù)的實際意義，但在image文件里，我們已經(jīng)完全無法看懂這些機器碼了。所以image文件主要是用來做大規(guī)模量產(chǎn)的。既要做大規(guī)模量產(chǎn)，由于各芯片廠家制定的標(biāo)準(zhǔn)不一，所以實際上image文件有很多種格式，今天我們主要講的是其中最具有代表性也應(yīng)用最廣泛的3種image文件格式。
一、通用鏡像文件bin
第一種格式叫binary，以.bin為文件后綴，這種格式是一種通用image格式，其完全是機器碼裸數(shù)據(jù)的集合，沒有其他任何多余信息，這個數(shù)據(jù)可以直接被編程器/下載器下載到芯片內(nèi)部非易失性存儲器里，不需要任何額外的數(shù)據(jù)轉(zhuǎn)換，所見即所得。由于是純二進制編碼的文件，所以普通text編輯器無法正確查看這個文件，需要用專用的十六進制編輯器（比如Hex Editor HxD）才能正常打開。以本系列創(chuàng)建的demo工程的demo.bin文件為例，用HxD打開可見如下數(shù)據(jù)（僅截取前后部分顯示，demo.bin共6780 bytes）。
offset(h)
00000000: 00 20 00 10 41 00 00 00 DB 18 00 00 CB 19 00 00
00000010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00000020: 00 00 00 00 00 00 00 00 00 00 00 00 07 1A 00 00
00000030: 00 00 00 00 00 00 00 00 1D 1A 00 00 1F 1A 00 00
00000040: 72 B6 0E 48 0E 49 88 60 00 22 00 23 00 24 00 25
...
00001A30: 01 23 00 24 13 E0 0A 68 09 1D 1A 42 02 D0 4D 46
00001A40: 6D 1E 52 19 14 60 12 1D 00 1F 04 28 FA D2 15 00
00001A50: 86 07 01 D5 14 80 AD 1C 18 40 00 D0 2C 70 08 68
00001A60: 09 1D 00 28 E7 D1 08 00 70 BC 70 47 C1 FF FF FF
00001A70: 08 02 00 00 14 20 00 10 00 00 00 00 -- -- -- --有細(xì)心的朋友可能會疑問，打開bin文件看數(shù)據(jù)都是按連續(xù)地址排列的，如果在應(yīng)用設(shè)計中，我們在linker文件里給各個段分配的地址不是連續(xù)的，這在bin文件里是怎么處理的？為了解決這個問題，bin文件會在非有效地址區(qū)域插入無效字節(jié)以保證有效地址處都是正確的數(shù)據(jù)，這在IDE里或相關(guān)轉(zhuǎn)換工具里都會有相應(yīng)option，可以讓用戶設(shè)置填充字節(jié)pattern（比如0x00，0xFF等）。
好，現(xiàn)在讓我們嘗試分析一下這個bin文件，我們都知道ARM Cortex-M架構(gòu)里，image bin文件前8個字節(jié)應(yīng)該是初始SP和PC的值，從前面map文件里我們知道SP=0x10002000，PC=0x00000041，來檢查一下bin文件里是不是這樣，前4個字節(jié)分別是 00 20 00 10、看起來好像跟0x10002000數(shù)據(jù)是吻合的，但是這個數(shù)據(jù)排列方式看起來好像有點別扭，怎么回事？嵌入式老司機這時應(yīng)該要莞爾一笑，是的，ARM Coretx-M默認(rèn)采用的Little-Endian（小端）模式，即低位字節(jié)排放在內(nèi)存的低地址端，高位字節(jié)排放在內(nèi)存的高地址端。數(shù)據(jù)查看地址顯示都是從低到高的（從左到右），所以SP的最低字節(jié)應(yīng)該顯示在最左邊（最低地址），而不是像查看0x10002000那樣最低字節(jié)在最右邊，這跟人的閱讀習(xí)慣是有點不吻合。
PS: 既有小端模式，那么與其對應(yīng)的也有大端模式（Big-Endian）-高位字節(jié)排放在內(nèi)存的低地址端，低位字節(jié)排放在內(nèi)存的高地址端。注意大端小端僅是針對以32bit為單元的數(shù)據(jù)排列方式差異，對于n個32bit數(shù)據(jù)，其都是統(tǒng)一的排列。
offset(h)
// 小端
00000000: 00 20 00 10 41 00 00 00
// 大端
00000000: 10 00 20 00 00 00 00 41從上面對bin文件的分析，我們知道bin文件是不含地址信息的，也就是說bin文件數(shù)據(jù)應(yīng)該被放在什么地址處，我們僅從bin文件本身是無法得知的。所以在使用編程器/下載器下載bin文件時，用戶必須指定起始下載地址。由于bin文件的這種局限性，下面兩種帶地址信息的image格式應(yīng)運而生。
二、Intel鏡像文件標(biāo)準(zhǔn)hex
第二種格式叫Intel hex，以.hex為文件后綴，這種格式是Intel公司推行的一種image格式標(biāo)準(zhǔn)，其不僅含有機器碼裸數(shù)據(jù)還含有地址信息等額外信息，與bin文件不同的是，hex文件可以直接通用普通text編輯器打開查看，hex文件采用的ASCII編碼，hex文件內(nèi)的機器碼數(shù)據(jù)不可以直接被下載進芯片內(nèi)部，需要在幀數(shù)據(jù)解析的過程中進行轉(zhuǎn)換。
由于hex文件并不是純機器碼文件，還含有其他額外信息，那么hex文件就需要按某種約定格式進行數(shù)據(jù)組織，數(shù)據(jù)組織方式叫幀格式，hex文件是由n幀數(shù)據(jù)組成的。
2.1 hex幀格式
要想解析hex文件，必須要先了解其幀格式，hex每幀都由下表列出的6部分組成：
編程器/下載器在解析hex文件時，先找到幀前導(dǎo)碼，然后找到幀類型，如果該幀為數(shù)據(jù)幀，再根據(jù)幀機器碼長度，將該幀機器碼數(shù)據(jù)全部讀出放到緩存里，在做完幀和校驗后，如果沒有錯誤，最后根據(jù)幀機器碼存儲地址將幀機器碼數(shù)據(jù)下載到芯片指定存儲器地址處，至此一幀處理結(jié)束，進入下一幀，直到所有幀全部處理完。需要注意的是由于hex文件是ASCII編碼，所以相比bin文件長度至少大2倍以上，demo.hex文件大小有19,106 bytes，后面我們會截取部分hex文件進行分析。
關(guān)于checksum的計算方法，其是將Byte count、Address、Record type、Data四個段內(nèi)所有byte全部相加得到sum，截取sum的LSB（最低字節(jié)），再對該LSB取其補碼（默認(rèn)該LSB為負(fù)數(shù)的低8bit數(shù)據(jù)位(注意8bit中沒有符號位)，其反碼為原碼各bit取反，其補碼為反碼+1）得到checksum。比如LSB是0xA5，其反碼為0x5A，補碼為0x5B，則checksum為0x5B。
2.2 hex幀類型
前面說到一共有6種類型的幀，其中最重要也是數(shù)量最多的幀是數(shù)據(jù)幀，除了數(shù)據(jù)幀之外還有其他5種幀，下面來統(tǒng)一介紹：
2.3 解析hex文件
在了解hex文件幀數(shù)據(jù)格式之后，讓我們開始嘗試解析demo.hex文件(僅截取前后部分，與前面截取的bin文件內(nèi)容對應(yīng)著一起分析)
:100000000020001041000000DB180000CB190000A8
:1000100000000000000000000000000000000000E0
:10002000000000000000000000000000071A0000AF
:1000300000000000000000001D1A00001F1A000050
:1000400072B60E480E498860002200230024002565
....
:101A30000123002413E00A68091D1A4202D04D4612
:101A40006D1E52191460121D001F0428FAD21500D1
:101A5000860701D51480AD1C184000D02C70086892
:101A6000091D0028E7D1080070BC7047C1FFFFFFC7
:0C1A70000802000014200010000000001C
:0400000500000041B6
:00000001FFhex文件前5幀均為數(shù)據(jù)幀，每幀包含16bytes機器碼數(shù)據(jù)，幀數(shù)據(jù)地址分別為0x0000, 0x0010, 0x0020, 0x0030, 0x0040，可見幀數(shù)據(jù)是連續(xù)的，并且5幀機器碼數(shù)據(jù)共80bytes與bin文件前80bytes是一致的。
再來看最后7幀數(shù)據(jù)里的前5個數(shù)據(jù)幀，除最后一幀數(shù)據(jù)只包含12bytes數(shù)據(jù)外，其余數(shù)據(jù)幀均含有16bytes數(shù)據(jù)，5幀數(shù)據(jù)一共76bytes，幀數(shù)據(jù)地址從0x1A30 - 0x1A70。顯然這與bin文件最后76bytes也是吻合的。
倒數(shù)第二幀是起始程序地址幀，其標(biāo)明的程序起始PC是0x00000041，這與bin文件里第二個32bit數(shù)據(jù)（起始PC）是一致的。
倒數(shù)第一幀顯然是標(biāo)準(zhǔn)文件結(jié)尾幀。
三、Motorola鏡像文件標(biāo)準(zhǔn)S-Record
第三種格式叫Motorola S-Record，以.s19或.srec為文件后綴，這種格式是Motorola公司推行的一種image格式標(biāo)準(zhǔn)，其與Intel hex文件比較類似，都是ASCII編碼的文件，可以通過普通text編輯器打開查看，其也由幀數(shù)據(jù)組成，只是幀格式與Intel hex有差別，還是按照介紹Intel hex文件那樣先來看S-Record文件的幀格式。
3.1 S-Record幀格式
S-Record每幀由下表列出的6部分組成：
編程器/下載器在解析S-Record文件時，先找到幀前導(dǎo)碼，然后找到幀類型，如果該幀為數(shù)據(jù)幀，再根據(jù)幀長度，將該幀機器碼數(shù)據(jù)全部讀出放到緩存里，在做完幀和校驗后，如果沒有錯誤，最后根據(jù)幀機器碼存儲地址將幀機器碼數(shù)據(jù)下載到芯片指定存儲器地址處，至此一幀處理結(jié)束，進入下一幀，直到所有幀全部處理完。
關(guān)于checksum的計算方法，其是將Byte count、Address、Data三個段內(nèi)所有byte全部相加得到sum，截取sum的LSB（最低字節(jié)），再對該LSB取其反碼（默認(rèn)該LSB為負(fù)數(shù)的低8bit數(shù)據(jù)位(注意8bit中沒有符號位)，其反碼為原碼各bit取反）得到checksum。比如LSB是0xA5，其反碼為0x5A，則checksum為0x5A。
3.2 S-Record幀類型
前面說到一共有10種類型的幀，其中最重要也是數(shù)量最多的幀是數(shù)據(jù)幀，數(shù)據(jù)幀按地址長度可分為16bit、24bit、32bit地址長度數(shù)據(jù)幀，除了數(shù)據(jù)幀，還有其他種類幀，下面來統(tǒng)一介紹：
3.3 解析S-Record文件
在了解S-Record文件幀數(shù)據(jù)格式之后，讓我們開始嘗試解析demo.s19文件(僅截取前后部分，與前面截取的bin文件內(nèi)容對應(yīng)著一起分析)
S00B000064656D6F2E73313944
S11300000020001041000000DB180000CB190000A4
S113001000000000000000000000000000000000DC
S1130020000000000000000000000000071A0000AB
S113003000000000000000001D1A00001F1A00004C
S113004072B60E480E498860002200230024002561
....
S1131A300123002413E00A68091D1A4202D04D460E
S1131A406D1E52191460121D001F0428FAD21500CD
S1131A50860701D51480AD1C184000D02C7008688E
S1131A60091D0028E7D1080070BC7047C1FFFFFFC3
S10F1A7008020000142000100000000018
S9030041BBS-Record文件第一幀是文件起始幀，幀數(shù)據(jù)64656D6F2E733139對應(yīng)ASCII為demo.s19，即該文件名。
第2-6幀均為16bit地址的數(shù)據(jù)幀，每幀包含16bytes機器碼數(shù)據(jù)，幀數(shù)據(jù)地址分別為0x0000, 0x0010, 0x0020, 0x0030, 0x0040，可見幀數(shù)據(jù)是連續(xù)的，并且5幀機器碼數(shù)據(jù)共80bytes與bin文件前80bytes是一致的。
再來看最后6幀數(shù)據(jù)里的前5個數(shù)據(jù)幀，除最后一幀數(shù)據(jù)只包含12bytes數(shù)據(jù)外，其余數(shù)據(jù)幀均含有16bytes數(shù)據(jù)，5幀數(shù)據(jù)一共76bytes，幀數(shù)據(jù)地址從0x1A30 - 0x1A70。顯然這與bin文件最后76bytes也是吻合的。
倒數(shù)第一幀是起始程序地址幀，其標(biāo)明的程序起始PC是0x0041，這與bin文件里第二個32bit數(shù)據(jù)（起始PC）是一致的。
番外一、一些image文件輔助小工具
SRecordizer：專用S19文件編輯器，可根據(jù)修改自動更新checksum，詳見網(wǎng)頁 https://srecordizer.codeplex.com/
SRecord項目：各種image文件格式互轉(zhuǎn)的小工具合集，詳見網(wǎng)頁 http://srecord.sourceforge.net/
至此，嵌入式開發(fā)里的image文件(.bin, .hex, .s19)文件痞子衡便介紹完畢了，掌聲在哪里~~~