今天主要講的是工程開發最終的output檔案，即image檔案。image檔案也叫鏡像檔案，這個檔案主要包含的是隻有晶片能夠解釋執行的二進制機器碼資料。
大家好，我是痞子衡，是正經搞技術的痞子。今天痞子衡給大家講的是嵌入式開發裡的image檔案(.bin, .hex, .s19)。
今天這節課是痞子衡《ARM Cortex-M檔案那些事》主題系列的最後一節課（突然有點不舍，要告别的感覺，咳咳，讓痞子衡整理下情緒先）。今天痞子衡主要講的是工程開發最終的output檔案，即image檔案。image檔案也叫鏡像檔案，這個檔案主要包含的是隻有晶片能夠解釋執行的二進制機器碼資料，這些資料其實在前面介紹的relocatable、list、executable檔案中出現過，在那些檔案裡我們還可以根據其他輔助資訊來分析機器碼資料的實際意義，但在image檔案裡，我們已經完全無法看懂這些機器碼了。是以image檔案主要是用來做大規模量産的。既要做大規模量産，由于各晶片廠家制定的标準不一，是以實際上image檔案有很多種格式，今天我們主要講的是其中最具有代表性也應用最廣泛的3種image檔案格式。
第一種格式叫binary，以.bin為檔案字尾，這種格式是一種通用image格式，其完全是機器碼裸資料的集合，沒有其他任何多餘資訊，這個資料可以直接被程式設計器/下載下傳器下載下傳到晶片内部非易失性存儲器裡，不需要任何額外的資料轉換，所見即所得。由于是純二進制編碼的檔案，是以普通text編輯器無法正确檢視這個檔案，需要用專用的十六進制編輯器（比如Hex Editor HxD）才能正常打開。以本系列建立的demo工程的demo.bin檔案為例，用HxD打開可見如下資料（僅截取前後部分顯示，demo.bin共6780 bytes）。
有細心的朋友可能會疑問，打開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資料，其都是統一的排列。
從上面對bin檔案的分析，我們知道bin檔案是不含位址資訊的，也就是說bin檔案資料應該被放在什麼位址處，我們僅從bin檔案本身是無法得知的。是以在使用程式設計器/下載下傳器下載下傳bin檔案時，使用者必須指定起始下載下傳位址。由于bin檔案的這種局限性，下面兩種帶位址資訊的image格式應運而生。
第二種格式叫Intel hex，以.hex為檔案字尾，這種格式是Intel公司推行的一種image格式标準，其不僅含有機器碼裸資料還含有位址資訊等額外資訊，與bin檔案不同的是，hex檔案可以直接通用普通text編輯器打開檢視，hex檔案采用的ASCII編碼，hex檔案内的機器碼資料不可以直接被下載下傳進晶片内部，需要在幀資料解析的過程中進行轉換。
由于hex檔案并不是純機器碼檔案，還含有其他額外資訊，那麼hex檔案就需要按某種約定格式進行資料組織，資料組織方式叫幀格式，hex檔案是由n幀資料組成的。
要想解析hex檔案，必須要先了解其幀格式，hex每幀都由下表列出的6部分組成：
幀段名
Start code
Byte count
Address
Record type
Data
Checksum
幀段内容
固定前導碼':'，十六進制0x3A
機器碼資料長度
機器碼資料存儲位址
幀類型"00"-"05"，有6種幀
機器碼資料
校驗和
幀段長度(bytes)
1
1*2
2*2
(0-255)*2
程式設計器/下載下傳器在解析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。
前面說到一共有6種類型的幀，其中最重要也是數量最多的幀是資料幀，除了資料幀之外還有其他5種幀，下面來統一介紹：
幀類型碼
幀類型
幀描述
幀舉例
"00"
資料幀
以16bit位址描述開始的最大255個位元組有效機器碼的資料幀
含11bytes機器碼從0x0010位址處開始的資料幀:0B0010006164647265737320676170A7
"01"
檔案結尾幀
用于表明hex檔案的結尾
統一的檔案結尾幀:00000001FF
"02"
拓展段位址幀
多用于80x86架構晶片，ARM Cortex-M架構不用
:020000021200EA
"03"
起始段位址幀
:0400000300003800C1
"04"
拓展線性位址幀
用于32bit位址存儲空間晶片，與資料幀配合使用，指引程式設計器将資料下載下傳到正确位址
标明拓展位址為0xFFFF的幀:02000004FFFFFC
"05"
起始程式位址（PC）幀
訓示調試器，程式初始PC位址，友善線上調試
标明起始PC為0x000000CD的幀:04000005000000CD2A
在了解hex檔案幀資料格式之後，讓我們開始嘗試解析demo.hex檔案(僅截取前後部分，與前面截取的bin檔案内容對應着一起分析)
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，以.s19或.srec為檔案字尾，這種格式是Motorola公司推行的一種image格式标準，其與Intel hex檔案比較類似，都是ASCII編碼的檔案，可以通過普通text編輯器打開檢視，其也由幀資料組成，隻是幀格式與Intel hex有差别，還是按照介紹Intel hex檔案那樣先來看S-Record檔案的幀格式。
S-Record每幀由下表列出的6部分組成：
固定前導碼'S'，十六進制0x53
幀類型'0'-'9'，有10種幀
幀資料長度（包含後續段位址、資料、校驗和）
(2-4)*2
程式設計器/下載下傳器在解析S-Record檔案時，先找到幀前導碼，然後找到幀類型，如果該幀為資料幀，再根據幀長度，将該幀機器碼資料全部讀出放到緩存裡，在做完幀和校驗後，如果沒有錯誤，最後根據幀機器碼存儲位址将幀機器碼資料下載下傳到晶片指定存儲器位址處，至此一幀處理結束，進入下一幀，直到所有幀全部處理完。
關于checksum的計算方法，其是将Byte count、Address、Data三個段内所有byte全部相加得到sum，截取sum的LSB（最低位元組），再對該LSB取其反碼（預設該LSB為負數的低8bit資料位(注意8bit中沒有符号位)，其反碼為原碼各bit取反）得到checksum。比如LSB是0xA5，其反碼為0x5A，則checksum為0x5A。
前面說到一共有10種類型的幀，其中最重要也是數量最多的幀是資料幀，資料幀按位址長度可分為16bit、24bit、32bit位址長度資料幀，除了資料幀，還有其他種類幀，下面來統一介紹：
'0'
檔案起始幀
用于表明S-Record檔案的開始
标明檔案名為HDR的檔案起始幀S00600004844521B
'1'
資料幀x16位址
含14bytes機器碼從0x0038位址處開始的資料幀S111003848656C6C6F20776F726C642E0A0042
'2'
資料幀x24位址
以24bit位址描述開始的最大255個位元組有效機器碼的資料幀
含4bytes機器碼從0x100000位址處開始的資料幀S2081000000400FA05E5
'3'
資料幀x32位址
以32bit位址描述開始的最大255個位元組有效機器碼的資料幀
含4bytes機器碼從0x13000160位址處開始的資料幀S309130001600400FA057F
'4'
N/A
未定義
'5'
資料幀總數幀x16
用16bit count記錄資料幀總幀數的總數幀
标明總資料幀為4幀的總數幀S5030004F8
'6'
資料幀總數幀x24
用24bit count記錄資料幀總幀數的總數幀
标明總資料幀為80000幀的總數幀S604080000F3
'7'
起始程式位址（PC）幀x32
含32bit起始PC的幀
标明起始PC為0x10000000的幀S70510000000EA
'8'
起始程式位址（PC）幀x24
含24bit起始PC的幀
标明起始PC為0x100000的幀S804100000EB
'9'
起始程式位址（PC）幀x16
含16bit起始PC的幀
标明起始PC為0x0000的幀S9030000FC
在了解S-Record檔案幀資料格式之後，讓我們開始嘗試解析demo.s19檔案(僅截取前後部分，與前面截取的bin檔案内容對應着一起分析)
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）是一緻的。
SRecordizer：專用S19檔案編輯器，可根據修改自動更新checksum，詳見網頁 https://srecordizer.codeplex.com/ SRecord項目：各種image檔案格式互轉的小工具合集，詳見網頁 http://srecord.sourceforge.net/
至此，嵌入式開發裡的image檔案(.bin, .hex, .s19)檔案痞子衡便介紹完畢了，掌聲在哪裡~~~
文章會同時釋出到我的 部落格園首頁、CSDN首頁、微信公衆号 平台上。
微信搜尋"痞子衡嵌入式"或者掃描下面二維碼，就可以在手機上第一時間看了哦。
最後歡迎關注痞子衡個人微信公衆号【痞子衡嵌入式】，一個專注嵌入式技術的公衆号，跟着痞子衡一起玩轉嵌入式。
衡傑(痞子衡)，目前就職于恩智浦MCU系統部門，擔任嵌入式系統應用工程師。
專欄内所有文章的轉載請注明出處：http://www.cnblogs.com/henjay724/
與痞子衡進一步交流或咨詢業務合作請發郵件至 [email protected]
可以關注痞子衡的Github首頁 https://github.com/JayHeng，有很多好玩的嵌入式項目。
關于專欄文章有任何疑問請直接在部落格下面留言，痞子衡會及時回複免費(劃重點)答疑。
痞子衡郵箱已被私信擠爆，技術問題不推薦私信，堅持私信請先掃碼付款(5元起步)再發。