S-record
S-record
Motorola S-recordは、モトローラによって作成されたファイル形式であり、バイナリ情報をASCII 16進テキスト形式で伝達する。このファイル形式はSRECORD、SREC、S19、S28、S37とも呼ばれる。マイクロコントローラ、EPROM、EEPROM、およびその他の種類のプログラマブルロジックデバイスのフラッシュメモリのプログラミングによく使用される。典型的な適用では、コンパイラやアセンブラはプログラムのソースコード (C言語やアセンブリ言語など) を機械語コードに変換し、16進ファイルに出力する。16進ファイルは、プログラマーによってインポートされ、機械語コードを不揮発性メモリに書き込むか、ロードおよび実行のために対象システムに転送される。
S-recordフォーマットは1970年代中頃にMotorola 6800プロセッサ用として開発された。Motorola 6800や他の組み込みプロセッサ向けのソフトウェア開発ツールを使用することで、S-recordフォーマットの実行可能なコードやデータを作成することができた。PROMプログラマにはS-recordフォーマットを読み込み、組み込みシステム中のPROMやEPROMにデータを書き込む機能があった。
SRECと同様の目的で開発されたASCIIエンコーディング形式が他にも存在する。BPNF、BHLFおよびB10Fは早期に開発されたバイナリフォーマットだったが、データサイズが大きくなりがちで、柔軟性にも欠けていた。16進フォーマットは1キャラクタで1ビットではなく4ビットを表現するため、バイナリフォーマットよりもデータサイズを小さくすることができる。SRECといった16進フォーマットの多くがアドレス情報を含むため、PROMの一部を指定することができるという点で、バイナリフォーマットよりも柔軟な使用が可能である。Intel HEXフォーマットはIntel製プロセッサでしばしば使用された。TekHexは16進フォーマットの一種であり、デバッグ用にシンボルテーブルを含むことができる。
SRECフォーマットのファイルはASCIIテキストレコードの連なりで構成される。レコードは次に示す順番で左から右に並ぶ構造をしている。
レコード開始 - レコードは必ず大文字の"S" (ASCII 0x53) で開始する。これは"Start-of-Record"を意味する。
レコードタイプ - "0"から"9"までの1桁の数字で、レコードのタイプを定義する。
バイト数 - 2桁の16進数であり、残りのレコード (アドレス、データ、チェックサム) のバイト数 (16進数のペアの数) を示す。このフィールドの最小値は3である (16ビットのアドレスフィールドの2バイトとチェックサムの1バイトの和)。最大値は255 (0xFF) である。
アドレス - 4、6または8桁の16進数で示される。桁数はレコードタイプで決定される。ビッグエンディアンフォーマットで記述される。
データ - 2n桁の16進数で表現される (nはデータのバイト数)。S1、S2、S3レコードでは、1レコードにつき32バイトを最大とするのが普通である。これは、80キャラクタ幅の端末のスクリーンにこのバイト数が適するためである。ただし、16バイトの方が特定のアドレスにある各バイトを視覚的に読み解きやすくなる。
チェックサム - 2桁の16進数で示される。バイト数フィールド、アドレスフィールドおよびデータフィールドにある2桁の16進数のペアの和をとったときの、その1の補数の最下位バイトがこのフィールドに入る。チェックサムの例については#例を参照。
SRECレコードは1つ以上のASCIIの行終端キャラクタで区切られる。そのため、各レコードは1行につき1つだけ表示される。視覚的にもレコードを区切ることで読みやすさが向上する。また、コンピュータによるパースの効率を向上させるためのレコード間のパディングとしても機能する。
16進レコードを作成するプログラムでは、普通、オペレーティングシステムの慣例にもとづいた行終端キャラクタが使用される。たとえば、Linuxのプログラムでは、行の終端に単一のLFキャラクタ (ラインフィード、ASCIIコードでは0x0A) が使用される。一方で、Windowsのプログラムでは、LFキャラクタとCRキャラクタ (キャリッジリターン、ASCIIコードでは0x0D) を組み合わせたものが使用される。
次の表では10種類のレコードタイプについて説明する。S4は予約されており、現在は定義されていない。S6は元は予約されていたが、後に再定義された。
あるUNIXのドキュメントには、ファイル中のS-recordの順番に意味は無く、特定の順番は前提とされないだろうとある。しかし、実際には、ほとんどのソフトウェアではSRECレコードに順序を付ける。普通、レコードは、任意の場合もあるが、S0ヘッダレコードから開始される。その後、1つ以上のS1、S2、S3データレコードが並び、任意でS5、S6カウントレコードが1つ配置され、最後に適切なS7、S8、S9終端レコードが1つ配置される。
S1 (1つ以上)
S5 (任意)
S2 (1つ以上)
S5 (任意)
S3 (1つ以上)
S5 (任意)
レコード長 - UNIXのマニュアルには、S-recordファイルは特別なフォーマットのASCII文字列で構成され、1つのSレコードの長さは78バイト以下になるとある。このマニュアルではさらに、データフィールドのキャラクタ数を64 (すなわち32バイト) に制限している。16進キャラクタ8つのアドレスと、64キャラクタのデータのあるレコードのキャラクタ数の合計は78 (2 + 2 + 8 + 64 + 2) になる (この数は改行キャラクタや文字列終端キャラクタの数を含めていない)。このようなファイルは80キャラクタ幅のテレプリンタで印刷できる。マニュアルページの下部の註には、このレコード長の制限は一般的にも適用されると考えるべきではないとある。この制限を無視する場合、S-recordの最大のキャラクタ数は514となる。レコードタイプフィールドで2キャラクタ、バイト数フィールドで2キャラクタ (値は0xFF = 255となる)、アドレスフィールド、データフィールド、チェックサムフィールドで2×255キャラクタが占められる。改行キャラクタや文字列終端キャラクタのためのスペースも必要になる可能性がある。キャラクタ数が多いと問題がある。srec_catというツールのマニュアルによれば、S-recordフォーマットは定義上、ペイロードは255バイト (つまりは514キャラクタ) が上限であり、EPROMプログラマにはこの上限まで扱えるように十分な行バッファがあるべきだが、実際に十分なバッファのあるEPROMプログラマは少数しかないという。
データフィールド - データフィールドの上限を32バイト (64キャラクタ) とすることを推奨するドキュメントがある。S0、S1、S2およびS3レコードのデータ長の下限は0である。データの上限はアドレスフィールドの長さによって変わる。バイト数フィールドは255 (0xFF) を超える値をとらないため、データのバイト数の上限は255バイトからチェックサムフィールドの1バイトを引き、さらにアドレスフィールドのバイト数を引いたものになる。S0およびS1レコードはデータの上限を252バイトとする。S2レコードはデータの上限を251バイトとする。S3レコードはデータの上限を250バイトとする。
コメント - SRECファイルフォーマットはコメントをサポートしない。"S"で始まらない行や、チェックサムフィールドより後ろのテキストすべてを無視するソフトウェアもある。このような無視されるテキストがコメントとして使用される場合もあるが、これには互換性がない。例えば、CCS PICコンパイラには、Intel HEXファイルの最上部または最下部に";"コメント行を配置する機能がある。そのマニュアルによると、一部のプログラマではHEXファイルの最上部にコメントがあると都合が悪いらしく、これを理由にそのコンパイラにはHEXファイルの最下部にコメントを配置するオプションが存在する。
次のレコードを例として、チェックサム値がどのように計算されるか説明する。
モトローラの慣例に則り、ドル記号 ($) を16進数を示す記号として用いる。
加算: 各バイトの和をとると、$13 + $7A + $F0 + $0A + $0A + $0D + $00 + ... + $00 = $019Eとなる。
マスク: この和の最上位バイト ($01) を除外し、最下位バイトの$9Eを残す。
補数: 最下位バイトの1の補数を計算すると、$61となる。普通、この演算はMotorola 6800マイクロプロセッサ上で$FFの値を保持したアキュムレータとの排他的論理和をとることで実行される。