大家好，我是痞子衡，是正經搞技術的痞子。今天痞子衡給大家講的是嵌入式開發里的image文件(.bin, .hex, .s19)。

今天這節課是痞子衡《ARM Cortex-M文件那些事》主題系列的最后一節課（突然有點不舍，要告別的感覺，咳咳，讓痞子衡整理下情緒先）。今天痞子衡主要講的是工程開發最終的output文件，即image文件。image文件也叫鏡像文件，這個文件主要包含的是只有芯片能夠解釋執行的二進制機器碼數據，這些數據其實在前面介紹的relocatable、list、executable文件中出現過，在那些文件里我們還可以根據其他輔助信息來分析機器碼數據的實際意義，但在image文件里，我們已經完全無法看懂這些機器碼了。所以image文件主要是用來做大規模量產的。既要做大規模量產，由于各芯片廠家制定的標準不一，所以實際上image文件有很多種格式，今天我們主要講的是其中最具有代表性也應用最廣泛的3種image文件格式。

一、通用鏡像文件bin

第一種格式叫binary，以.bin為文件后綴，這種格式是一種通用image格式，其完全是機器碼裸數據的集合，沒有其他任何多余信息，這個數據可以直接被編程器/下載器下載到芯片內部非易失性存儲器里，不需要任何額外的數據轉換，所見即所得。由于是純二進制編碼的文件，所以普通text編輯器無法正確查看這個文件，需要用專用的十六進制編輯器（比如Hex Editor HxD）才能正常打開。以本系列創建的demo工程的demo.bin文件為例，用HxD打開可見如下數據（僅截取前后部分顯示，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 -- -- -- --

有細心的朋友可能會疑問，打開bin文件看數據都是按連續地址排列的，如果在應用設計中，我們在linker文件里給各個段分配的地址不是連續的，這在bin文件里是怎么處理的？為了解決這個問題，bin文件會在非有效地址區域插入無效字節以保證有效地址處都是正確的數據，這在IDE里或相關轉換工具里都會有相應option，可以讓用戶設置填充字節pattern（比如0x00，0xFF等）。

好，現在讓我們嘗試分析一下這個bin文件，我們都知道ARM Cortex-M架構里，image bin文件前8個字節應該是初始SP和PC的值，從前面map文件里我們知道SP=0x10002000，PC=0x00000041，來檢查一下bin文件里是不是這樣，前4個字節分別是 00 20 00 10、看起來好像跟0x10002000數據是吻合的，但是這個數據排列方式看起來好像有點別扭，怎么回事？嵌入式老司機這時應該要莞爾一笑，是的，ARM Coretx-M默認采用的Little-Endian（小端）模式，即低位字節排放在內存的低地址端，高位字節排放在內存的高地址端。數據查看地址顯示都是從低到高的（從左到右），所以SP的最低字節應該顯示在最左邊（最低地址），而不是像查看0x10002000那樣最低字節在最右邊，這跟人的閱讀習慣是有點不吻合。

PS: 既有小端模式，那么與其對應的也有大端模式（Big-Endian）-高位字節排放在內存的低地址端，低位字節排放在內存的高地址端。注意大端小端僅是針對以32bit為單元的數據排列方式差異，對于n個32bit數據，其都是統一的排列。

offset(h)
// 小端
00000000: 00 20 00 10 41 00 00 00
// 大端
00000000: 10 00 20 00 00 00 00 41

從上面對bin文件的分析，我們知道bin文件是不含地址信息的，也就是說bin文件數據應該被放在什么地址處，我們僅從bin文件本身是無法得知的。所以在使用編程器/下載器下載bin文件時，用戶必須指定起始下載地址。由于bin文件的這種局限性，下面兩種帶地址信息的image格式應運而生。

二、Intel鏡像文件標準hex

第二種格式叫Intel hex，以.hex為文件后綴，這種格式是Intel公司推行的一種image格式標準，其不僅含有機器碼裸數據還含有地址信息等額外信息，與bin文件不同的是，hex文件可以直接通用普通text編輯器打開查看，hex文件采用的ASCII編碼，hex文件內的機器碼數據不可以直接被下載進芯片內部，需要在幀數據解析的過程中進行轉換。

由于hex文件并不是純機器碼文件，還含有其他額外信息，那么hex文件就需要按某種約定格式進行數據組織，數據組織方式叫幀格式，hex文件是由n幀數據組成的。

2.1 hex幀格式

要想解析hex文件，必須要先了解其幀格式，hex每幀都由下表列出的6部分組成：

編程器/下載器在解析hex文件時，先找到幀前導碼，然后找到幀類型，如果該幀為數據幀，再根據幀機器碼長度，將該幀機器碼數據全部讀出放到緩存里，在做完幀和校驗后，如果沒有錯誤，最后根據幀機器碼存儲地址將幀機器碼數據下載到芯片指定存儲器地址處，至此一幀處理結束，進入下一幀，直到所有幀全部處理完。需要注意的是由于hex文件是ASCII編碼，所以相比bin文件長度至少大2倍以上，demo.hex文件大小有19,106 bytes，后面我們會截取部分hex文件進行分析。

關于checksum的計算方法，其是將Byte count、Address、Record type、Data四個段內所有byte全部相加得到sum，截取sum的LSB（最低字節），再對該LSB取其補碼（默認該LSB為負數的低8bit數據位(注意8bit中沒有符號位)，其反碼為原碼各bit取反，其補碼為反碼+1）得到checksum。比如LSB是0xA5，其反碼為0x5A，補碼為0x5B，則checksum為0x5B。

2.2 hex幀類型

前面說到一共有6種類型的幀，其中最重要也是數量最多的幀是數據幀，除了數據幀之外還有其他5種幀，下面來統一介紹：

2.3 解析hex文件

在了解hex文件幀數據格式之后，讓我們開始嘗試解析demo.hex文件(僅截取前后部分，與前面截取的bin文件內容對應著一起分析)

:100000000020001041000000DB180000CB190000A8
:1000100000000000000000000000000000000000E0
:10002000000000000000000000000000071A0000AF
:1000300000000000000000001D1A00001F1A000050
:1000400072B60E480E498860002200230024002565
....
:101A30000123002413E00A68091D1A4202D04D4612
:101A40006D1E52191460121D001F0428FAD21500D1
:101A5000860701D51480AD1C184000D02C70086892
:101A6000091D0028E7D1080070BC7047C1FFFFFFC7
:0C1A70000802000014200010000000001C
:0400000500000041B6
:00000001FF

hex文件前5幀均為數據幀，每幀包含16bytes機器碼數據，幀數據地址分別為0x0000, 0x0010, 0x0020, 0x0030, 0x0040，可見幀數據是連續的，并且5幀機器碼數據共80bytes與bin文件前80bytes是一致的。

再來看最后7幀數據里的前5個數據幀，除最后一幀數據只包含12bytes數據外，其余數據幀均含有16bytes數據，5幀數據一共76bytes，幀數據地址從0x1A30 - 0x1A70。顯然這與bin文件最后76bytes也是吻合的。

倒數第二幀是起始程序地址幀，其標明的程序起始PC是0x00000041，這與bin文件里第二個32bit數據（起始PC）是一致的。

倒數第一幀顯然是標準文件結尾幀。

三、Motorola鏡像文件標準S-Record

第三種格式叫Motorola S-Record，以.s19或.srec為文件后綴，這種格式是Motorola公司推行的一種image格式標準，其與Intel hex文件比較類似，都是ASCII編碼的文件，可以通過普通text編輯器打開查看，其也由幀數據組成，只是幀格式與Intel hex有差別，還是按照介紹Intel hex文件那樣先來看S-Record文件的幀格式。

3.1 S-Record幀格式

S-Record每幀由下表列出的6部分組成：

編程器/下載器在解析S-Record文件時，先找到幀前導碼，然后找到幀類型，如果該幀為數據幀，再根據幀長度，將該幀機器碼數據全部讀出放到緩存里，在做完幀和校驗后，如果沒有錯誤，最后根據幀機器碼存儲地址將幀機器碼數據下載到芯片指定存儲器地址處，至此一幀處理結束，進入下一幀，直到所有幀全部處理完。

關于checksum的計算方法，其是將Byte count、Address、Data三個段內所有byte全部相加得到sum，截取sum的LSB（最低字節），再對該LSB取其反碼（默認該LSB為負數的低8bit數據位(注意8bit中沒有符號位)，其反碼為原碼各bit取反）得到checksum。比如LSB是0xA5，其反碼為0x5A，則checksum為0x5A。

3.2 S-Record幀類型

前面說到一共有10種類型的幀，其中最重要也是數量最多的幀是數據幀，數據幀按地址長度可分為16bit、24bit、32bit地址長度數據幀，除了數據幀，還有其他種類幀，下面來統一介紹：

3.3 解析S-Record文件

在了解S-Record文件幀數據格式之后，讓我們開始嘗試解析demo.s19文件(僅截取前后部分，與前面截取的bin文件內容對應著一起分析)

S00B000064656D6F2E73313944
S11300000020001041000000DB180000CB190000A4
S113001000000000000000000000000000000000DC
S1130020000000000000000000000000071A0000AB
S113003000000000000000001D1A00001F1A00004C
S113004072B60E480E498860002200230024002561
....
S1131A300123002413E00A68091D1A4202D04D460E
S1131A406D1E52191460121D001F0428FAD21500CD
S1131A50860701D51480AD1C184000D02C7008688E
S1131A60091D0028E7D1080070BC7047C1FFFFFFC3
S10F1A7008020000142000100000000018
S9030041BB

S-Record文件第一幀是文件起始幀，幀數據64656D6F2E733139對應ASCII為demo.s19，即該文件名。

第2-6幀均為16bit地址的數據幀，每幀包含16bytes機器碼數據，幀數據地址分別為0x0000, 0x0010, 0x0020, 0x0030, 0x0040，可見幀數據是連續的，并且5幀機器碼數據共80bytes與bin文件前80bytes是一致的。

再來看最后6幀數據里的前5個數據幀，除最后一幀數據只包含12bytes數據外，其余數據幀均含有16bytes數據，5幀數據一共76bytes，幀數據地址從0x1A30 - 0x1A70。顯然這與bin文件最后76bytes也是吻合的。

倒數第一幀是起始程序地址幀，其標明的程序起始PC是0x0041，這與bin文件里第二個32bit數據（起始PC）是一致的。

番外一、一些image文件輔助小工具

SRecordizer：專用S19文件編輯器，可根據修改自動更新checksum，詳見網頁 https://srecordizer.codeplex.com/

SRecord項目：各種image文件格式互轉的小工具合集，詳見網頁 http://srecord.sourceforge.net/

至此，嵌入式開發里的image文件(.bin, .hex, .s19)文件痞子衡便介紹完畢了，掌聲在哪里~~~