S-record

S-record
Motorola S-Record形式のクイックリファレンスチャート (注意: レコードの例の画像では、単語「バイト」は文字を指定するために代わりに使用されている)。
拡張子.s19, .s28, .s37, .s, .s1, .s2, .s3, .sx, .srec, .mot, .mxt

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にデータを書き込む機能があった。

その他の16進フォーマット

[編集]

SRECと同様の目的で開発されたASCIIエンコーディング形式が他にも存在する。BPNF、BHLFおよびB10Fは早期に開発されたバイナリフォーマットだったが、データサイズが大きくなりがちで、柔軟性にも欠けていた。16進フォーマットは1キャラクタで1ビットではなく4ビットを表現するため、バイナリフォーマットよりもデータサイズを小さくすることができる。SRECといった16進フォーマットの多くがアドレス情報を含むため、PROMの一部を指定することができるという点で、バイナリフォーマットよりも柔軟な使用が可能である。Intel HEXフォーマットはIntel製プロセッサでしばしば使用された。TekHexは16進フォーマットの一種であり、デバッグ用にシンボルテーブルを含むことができる。

フォーマット

[編集]

レコード構造

[編集]
S タイプ バイト数 アドレス データ チェックサム

SRECフォーマットのファイルはASCIIテキストレコードの連なりで構成される。レコードは次に示す順番で左から右に並ぶ構造をしている。

  1. レコード開始 - レコードは必ず大文字の"S" (ASCII 0x53) で開始する。これは"Start-of-Record"[1]を意味する。
  2. レコードタイプ - "0"から"9"までの1桁の数字で、レコードのタイプを定義する。
  3. バイト数 - 2桁の16進数であり、残りのレコード (アドレス、データ、チェックサム) のバイト数 (16進数のペアの数) を示す。このフィールドの最小値は3である (16ビットのアドレスフィールドの2バイトとチェックサムの1バイトの和)。最大値は255 (0xFF) である。
  4. アドレス - 4、6または8桁の16進数で示される。桁数はレコードタイプで決定される。ビッグエンディアンフォーマットで記述される。
  5. データ - 2n桁の16進数で表現される (nはデータのバイト数)。S1、S2、S3レコードでは、1レコードにつき32バイトを最大とするのが普通である。これは、80キャラクタ幅の端末のスクリーンにこのバイト数が適するためである。ただし、16バイトの方が特定のアドレスにある各バイトを視覚的に読み解きやすくなる。
  6. チェックサム - 2桁の16進数で示される。バイト数フィールド、アドレスフィールドおよびデータフィールドにある2桁の16進数のペアの和をとったときの、その1の補数の最下位バイトがこのフィールドに入る。チェックサムの例については#例を参照。

テキスト行終端記号

[編集]

SRECレコードは1つ以上のASCIIの行終端キャラクタで区切られる。そのため、各レコードは1行につき1つだけ表示される。視覚的にもレコードを区切ることで読みやすさが向上する。また、コンピュータによるパースの効率を向上させるためのレコード間のパディングとしても機能する。

16進レコードを作成するプログラムでは、普通、オペレーティングシステムの慣例にもとづいた行終端キャラクタが使用される。たとえば、Linuxのプログラムでは、行の終端に単一のLFキャラクタ (ラインフィード、ASCIIコードでは0x0A) が使用される。一方で、Windowsのプログラムでは、LFキャラクタとCRキャラクタ (キャリッジリターン、ASCIIコードでは0x0D) を組み合わせたものが使用される。

レコードタイプ

[編集]

次の表では10種類のレコードタイプについて説明する。S4は予約されており、現在は定義されていない。S6は元は予約されていたが、後に再定義された。

レコード
フィールド 		レコードの
目的 		アドレス
フィールド 		データ
フィールド 		レコードの
説明
S0 ヘッダ 16ビット
"0000" 		No S0はベンダー固有のASCIIテキストのコメントから成り、16進数のペアの連なりで表現される。S0のデータはヌル終端文字列のフォーマットと見なすのが一般的である。ファイル/モジュール名、バージョン/リビジョン番号、日付/時刻、製品名、ベンダー名、PCBのメモリデジグネータ、著作権表示といった情報を組み合わせて含むことができる。
S1 データ 16ビット
アドレス 		Yes S1は16ビットのアドレスフィールドで開始されるデータから成る[2]。普通、AVR、PIC、8051、68xx、6502、80xx、Z80などの8ビットのマイクロコントローラで使用される。データのバイト数はバイト数フィールドの値から3引いた値になる (2バイトは16ビットのアドレスフィールドに、1バイトはチェックサムフィールドに使用される)。
S2 データ 24ビット
アドレス 		Yes S2は24ビットのアドレスフィールドで開始されるデータから成る[2]。データのバイト数はバイト数フィールドの値から4引いた値になる (3バイトは24ビットのアドレスフィールドに、1バイトはチェックサムフィールドに使用される)。
S3 データ 32ビット
アドレス 		Yes S3は32ビットのアドレスフィールドで開始されるデータから成る[2]。普通、ARMや680x0などの32ビットのマイクロコントローラで使用される。データのバイト数はバイト数フィールドの値から5引いた値になる (4バイトは32ビットのアドレスフィールドに、1バイトはチェックサムフィールドに使用される)。
S4 予約 N/A N/A S4は予約されている。
S5 カウント 16ビット
カウント 		No S5は任意のレコードであり、S1、S2、S3レコードの数を16ビットで示す[2]。レコード数が65,535 (0xFFFF) 以下であるときに使用される。65,535を超過する場合はS6レコードが使用される。
S6 カウント 24ビット
カウント 		No S6は任意のレコードであり、S1、S2、S3レコードの数を24ビットで示す。レコード数が16,777,215 (0xFFFFFF) 以下の場合に使用される。65,536 (0x10000) 以下の場合はS5レコードが使用される。S6は最新の変更で追加されたものであり、公式扱いされないことがある[2]。
S7 開始アドレス
(終端) 		32ビット
アドレス 		No S7は32ビットアドレスで開始実行位置を示す[2][3]。S3レコードの連なりの終端として使用される。SRECファイルがメモリデバイスのプログラミングにのみ使用され、実行位置が無視される場合、アドレスとして0を指定できる。
S8 開始アドレス
(終端) 		24ビット
アドレス 		No S8は24ビットアドレスで開始実行位置を示す[2][3]。S2レコードの連なりの終端として使用される。SRECファイルがメモリデバイスのプログラミングにのみ使用され、実行位置が無視される場合、アドレスとして0を指定できる。
S9 開始アドレス
(終端) 		16ビット
アドレス 		No S9は16ビットアドレスで開始実行位置を示す[2][3]。S1レコードの連なりの終端として使用される。SRECファイルがメモリデバイスのプログラミングにのみ使用され、実行位置が無視される場合、アドレスとして0を指定できる。

レコード順

[編集]

あるUNIXのドキュメントには、ファイル中のS-recordの順番に意味は無く、特定の順番は前提とされないだろうとある[2]。しかし、実際には、ほとんどのソフトウェアではSRECレコードに順序を付ける。普通、レコードは、任意の場合もあるが、S0ヘッダレコードから開始される。その後、1つ以上のS1、S2、S3データレコードが並び、任意でS5、S6カウントレコードが1つ配置され、最後に適切なS7、S8、S9終端レコードが1つ配置される。

S19スタイル16ビットアドレスレコード
  1. S0
  2. S1 (1つ以上)
  3. S5 (任意)
  4. S9
S28スタイル24ビットアドレスレコード
  1. S0
  2. S2 (1つ以上)
  3. S5 (任意)
  4. S8
S37スタイル32ビットアドレスレコード
  1. S0
  2. S3 (1つ以上)
  3. S5 (任意)
  4. S7

制限事項

[編集]

レコード長 - UNIXのマニュアルには、S-recordファイルは特別なフォーマットのASCII文字列で構成され、1つのSレコードの長さは78バイト以下になるとある。このマニュアルではさらに、データフィールドのキャラクタ数を64 (すなわち32バイト) に制限している[2]。16進キャラクタ8つのアドレスと、64キャラクタのデータのあるレコードのキャラクタ数の合計は78 (2 + 2 + 8 + 64 + 2) になる (この数は改行キャラクタや文字列終端キャラクタの数を含めていない)。このようなファイルは80キャラクタ幅のテレプリンタで印刷できる。マニュアルページの下部の註には、このレコード長の制限は一般的にも適用されると考えるべきではないとある[2]。この制限を無視する場合、S-recordの最大のキャラクタ数は514となる。レコードタイプフィールドで2キャラクタ、バイト数フィールドで2キャラクタ (値は0xFF = 255となる)、アドレスフィールド、データフィールド、チェックサムフィールドで2×255キャラクタが占められる。改行キャラクタや文字列終端キャラクタのためのスペースも必要になる可能性がある。キャラクタ数が多いと問題がある。srec_catというツールのマニュアルによれば、S-recordフォーマットは定義上、ペイロードは255バイト (つまりは514キャラクタ) が上限であり、EPROMプログラマにはこの上限まで扱えるように十分な行バッファがあるべきだが、実際に十分なバッファのあるEPROMプログラマは少数しかないという[4]。

データフィールド - データフィールドの上限を32バイト (64キャラクタ) とすることを推奨するドキュメントがある[2]。S0、S1、S2およびS3レコードのデータ長の下限は0である。データの上限はアドレスフィールドの長さによって変わる。バイト数フィールドは255 (0xFF) を超える値をとらないため、データのバイト数の上限は255バイトからチェックサムフィールドの1バイトを引き、さらにアドレスフィールドのバイト数を引いたものになる。S0およびS1レコードはデータの上限を252バイトとする。S2レコードはデータの上限を251バイトとする。S3レコードはデータの上限を250バイトとする。

コメント - SRECファイルフォーマットはコメントをサポートしない。"S"で始まらない行や、チェックサムフィールドより後ろのテキストすべてを無視するソフトウェアもある。このような無視されるテキストがコメントとして使用される場合もあるが、これには互換性がない。例えば、CCS PICコンパイラには、Intel HEXファイルの最上部または最下部に";"コメント行を配置する機能がある。そのマニュアルによると、一部のプログラマではHEXファイルの最上部にコメントがあると都合が悪いらしく、これを理由にそのコンパイラにはHEXファイルの最下部にコメントを配置するオプションが存在する[5]。

例

[編集]
色凡例

  レコードタイプ   バイト数   アドレス   データ   チェックサム

チェックサム計算

[編集]

次のレコードを例として、チェックサム値がどのように計算されるか説明する。 

S1137AF00A0A0D0000000000000000000000000061

モトローラの慣例に則り、ドル記号 ($) を16進数を示す記号として用いる。

  1. 加算: 各バイトの和をとると、$13 + $7A + $F0 + $0A + $0A + $0D + $00 + ... + $00 = $019Eとなる。
  2. マスク: この和の最上位バイト ($01) を除外し、最下位バイトの$9Eを残す。
  3. 補数: 最下位バイトの1の補数を計算すると、$61となる。普通、この演算はMotorola 6800マイクロプロセッサ上で$FFの値を保持したアキュムレータとの排他的論理和をとることで実行される。

16-bit メモリアドレス

[編集]
S00F000068656C6C6F202020202000003C
S11F00007C0802A6900100049421FFF07C6C1B787C8C23783C6000003863000026
S11F001C4BFFFFE5398000007D83637880010014382100107C0803A64E800020E9
S111003848656C6C6F20776F726C642E0A0042
S5030003F9
S9030000FC

関連項目

[編集]

出典

[編集]
  1. ^ Wiles, Mike; Felix, Andre (2000-10-21). Holley, Michael. ed. MCM6830L7 MIKBUG / MINIBUG ROM (Engineering note). Motorola Semiconductor Products, Inc.. Note 100. オリジナルの2019-06-16時点におけるアーカイブ。. https://web.archive.org/web/20190616115550/http://www.swtpc.com/mholley/MP_A/MikbugEn100.pdf 2019年6月16日閲覧。  (23 pages)
  2. ^ a b c d e f g h i j k l “Motorola S-records from Unix man pages”. 2014年6月30日閲覧。
  3. ^ a b c “Appendix C”. M68000 Family Programmer's Reference Manual (Revision 1 ed.). Motorola (Freescale). (1992). pp. C-1–C-5. ISBN 978-0-13723289-5. http://www.freescale.com/files/archives/doc/ref_manual/M68000PRM.pdf 
  4. ^ “srec_examples”. sourceforge.net. 2021年9月2日閲覧。
  5. ^ CCS Compiler Reference Manual PCB/PCM/PCH, Custom Computer Services, Inc., (May 2014), p. 107, http://www.ccsinfo.com/downloads/ccs_c_manual.pdf 2015年2月8日閲覧。 

参考文献

[編集]

外部リンク

[編集]
  • RFC 4194 - The S Hexdump Format - IETF
  • SRecord - SRECフォーマットのファイルを操作するためのツール群
  • BIN2MOT - バイナリファイルをSRECファイルに変換するためのユーティリティ
  • SRecordizer - S19フォーマットのファイルを閲覧、編集、エラーチェックするためのツール
  • bincopy - SRECフォーマットのファイルを操作するためのPythonのパッケージ
  • kk_srec - SRECフォーマットを読み込むためのC言語のライブラリ