SフォーマットとかIntel Hexとか

コンパイラやメモリダンプの出力形式がバイナリデータとも限らず、

Sフォーマット(モトローラ形式とも)だとか、Intel Hexだとか、そういう形式が使われることがある。

16進数のテキストで記載されているのだが、解読にはそれぞれの形式の特徴を知っていなければならない。


SフォーマットはSから始まるテキストでメモリデータを記述している。

S1130110DF107A02000FDF10690369930B800B81F3

こんなのがひたすら並んでいる。

最初のS1がレコードの種類、S1は16ビットアドレスのデータという意味だったはず。

13はレコード長、16進数の13なので、レコード長が19byteであることを表している。

0110が先頭アドレスで、DF……81がデータ、レコード長はアドレス+データの長さを表している。

最後のがチェックサムで、レコード長からチェックサムまで全て足すと0xFFになるように計算されている。


Intel Hex形式はこんなのがひたすら並んでいる。

:100130003F0156702B5E712B722B732146013421C7

10がバイトカウント、この行は16バイトのデータを格納することを表している。

次の0130がアドレス、00がレコードの種類でこのレコードはデータを格納していることを表していて、3F……21がデータ、

最後のC7がチェックサムで、バイトカウントからチェックサムを全て足すと0x00になるように計算されている。


というわけで、この2つのフォーマットの考え方はそう変わらない。

アドレスとデータをそれぞれ16進数で表したものをひたすら並べているということだ。

ただ、あまり直感的とは言いがたく、なんとなく解読できるというものではない。

種別・データ長・アドレス・データ・チェックサムが詰め詰めで書かれてますからね。


ROMライターの書き込みなどで使われるフォーマットだそうだが、職場で作っているシステムではバイナリデータでROMライターに入力している。

以前使っていたコンパイラでは、出力データがSフォーマットだったが、即バイナリデータへの変換を行っていた。

というわけで、現在、主に使っているコンパイラでは最初からバイナリデータで出力しているわけである。

そうやって考えると、やや汎用性の劣るSフォーマットやIntel Hexには何のメリットがあるんだろうとなる。


でも明確なメリットもあるんですよね。

セクション間に空白があるようなデータの場合、バイナリでは空白区間を埋めるデータが必要になる。

ところがSフォーマットやIntel Hexの場合、空白区間は書かなければよいだけである。

例えば0x00000000から64kB、0x20000000から16kBというデータを出力する場合、

バイナリデータの場合、ゼロデータで埋めてしまうから512MBにも及ぶ巨大データが生成されてしまう。

ところが、SフォーマットやIntel Hexの場合、64kBと16kBのデータを記載するだけでよい。

16進数のテキストデータなので、2倍以上のデータ量になるが、200kB程度のデータで済むだろう。


SフォーマットもIntel Hexもテキストデータですから、意味さえ理解できれば加工は容易である。

条件次第だが、中間形式としてはSフォーマットやIntel Hexは有益な気がする。

もちろん、ROMライターなどで最終的に必要なのが、これらの形式ならそれでいいんだけど。