Motorola S-record adalah format file, dibuat oleh Motorola pada pertengahan 1970-an, yang menyampaikan informasi biner sebagai nilai hex dalam bentuk teks ASCII. Format file ini juga dikenal sebagai SRECORD, SREC, S19, S28, S37. Ini biasanya digunakan untuk memprogram memori flash dalam mikrokontroler, EPROM, EEPROM, dan jenis perangkat logika yang dapat diprogram lainnya. Dalam aplikasi tipikal, kompiler atau assembler mengubah kode sumber program (seperti bahasa C atau bahasa rakitan) menjadi kode mesin dan mengeluarkannya menjadi file HEX. File HEX kemudian diimpor oleh pemrogram untuk “membakar” kode mesin ke dalam memori non-volatile, atau ditransfer ke sistem target untuk dimuat dan dieksekusi.
Ringkasan
Sejarah
Format S-record dibuat pada pertengahan 1970-an untuk prosesor Motorola 6800. Alat pengembangan perangkat lunak untuk itu dan prosesor tertanam lainnya akan membuat kode dan data yang dapat dieksekusi dalam format S-record. Pemrogram PROM kemudian akan membaca format S-record dan “membakar” data ke dalam PROM atau EPROM yang digunakan dalam sistem tersemat.
format hex lainnya
Ada pengkodean ASCII lain dengan tujuan serupa. BPNF, BHLF, dan B10F adalah format biner awal, tetapi tidak kompak dan tidak fleksibel. Format heksadesimal lebih kompak karena mewakili 4 bit daripada 1 bit per karakter. Banyak, seperti S-record, lebih fleksibel karena memasukkan informasi alamat sehingga mereka dapat menentukan hanya sebagian dari PROM. Format Intel HEX sering digunakan dengan prosesor Intel. TekHex adalah format hex lain yang dapat menyertakan tabel simbol untuk debugging.
Format
Struktur rekaman
| S | Type | Byte Count | Address | Data | Checksum |
File format SREC terdiri dari serangkaian rekaman teks ASCII. Catatan memiliki struktur berikut dari kiri ke kanan:
- Mulai rekaman – setiap rekaman dimulai dengan karakter huruf besar “S” (ASCII 0x53) yang merupakan singkatan dari “Start-of-Record”.[2]
- Jenis rekaman – digit numerik tunggal “0” hingga “9”, yang menentukan jenis rekaman.
- Jumlah byte – dua digit hex, menunjukkan jumlah byte (pasangan digit hex) yang mengikuti sisa catatan (alamat + data + checksum). Bidang ini memiliki nilai minimum 3 untuk bidang alamat 16-bit ditambah 1 byte checksum, dan nilai maksimum 255 (0xFF).
- Alamat – empat / enam / delapan digit hex sebagaimana ditentukan oleh jenis catatan. Byte alamat disusun dalam format big-endian.
- Data – urutan 2n digit hex, untuk n byte data. Untuk catatan S1/S2/S3, maksimum 32 byte per catatan adalah tipikal karena akan muat pada layar terminal selebar 80 karakter, meskipun 16 byte akan lebih mudah untuk mendekode secara visual setiap byte pada alamat tertentu.
- Checksum – dua digit heksadesimal, byte terkecil dari komplemen seseorang dari jumlah nilai yang diwakili oleh dua pasangan digit heksadesimal untuk jumlah byte, alamat, dan bidang data. Lihat bagian contoh untuk contoh checksum mendetail.
Terminator baris teks
Catatan SREC dipisahkan oleh satu atau lebih karakter terminasi baris ASCII sehingga setiap catatan muncul sendiri di baris teks. Hal ini meningkatkan keterbacaan dengan membatasi rekaman secara visual dan juga memberikan bantalan di antara rekaman yang dapat digunakan untuk meningkatkan efisiensi penguraian mesin.
Program yang membuat catatan HEX biasanya menggunakan karakter terminasi baris yang sesuai dengan konvensi sistem operasinya. Misalnya, program Linux menggunakan satu karakter LF (line feed, 0x0A sebagai nilai karakter ASCII) untuk mengakhiri baris, sedangkan program Windows menggunakan karakter CR (carriage return, 0x0D sebagai nilai karakter ASCII) diikuti dengan karakter LF.
Jenis rekaman
Tabel berikut menjelaskan 10 kemungkinan S-record. S4 dicadangkan dan saat ini tidak ditentukan. S6 awalnya dicadangkan tetapi kemudian didefinisikan ulang.
| Record field | Record purpose | Address field | Data field | Record description |
|---|---|---|---|---|
| S0 | Header | 16-bit “0000” |  | This record contains vendor specific ASCII text comment represented as a series of hex digit pairs. It is common to see the data for this record in the format of a null-terminated string. The text data can be anything including a mixture of the following information: file/module name, version/revision number, date/time, product name, vendor name, memory designator on PCB, copyright notice, sign on. It is common to see: 48 44 52 which is the ASCII H, D, and R – “HDR”. |
| S1 | Data | 16-bit Address |  | This record contains data that starts at the 16-bit address field.] This record is typically used for 8-bit microcontrollers, such as AVR, PIC, 8051, 68xx, 6502, 80xx, Z80. The number of bytes of data contained in this record is “Byte Count Field” minus 3 (that is, 2 bytes for “16-bit Address Field” and 1 byte for “Checksum Field”). |
| S2 | Data | 24-bit Address | | This record contains data that starts at a 24-bit address. The number of bytes of data contained in this record is “Byte Count Field” minus 4 (that is, 3 bytes for “24-bit Address Field” and 1 byte for “Checksum Field”). |
| S3 | Data | 32-bit Address | | This record contains data that starts at a 32-bit address. This record is typically used for 32-bit microcontrollers, such as ARM and 680×0. The number of bytes of data contained in this record is “Byte Count Field” minus 5 (that is, 4 bytes for “32-bit Address Field” and 1 byte for “Checksum Field”). |
| S4 | Reserved | — | — | This record is reserved. |
| S5 | Count | 16-bit Count | | This optional record contains a 16-bit count of S1/S2/S3 records. This record is used if the record count is less than or equal to 65,535 (0xFFFF), otherwise S6 record would be used. |
| S6 | Count | 24-bit Count | | This optional record contains a 24-bit count of S1/S2/S3 records. This record is used if the record count is less than or equal to 16,777,215 (0xFFFFFF). If less than 65,536 (0x10000), then S5 record would be used. NOTE: This newer record is the most recent change (it may not be official). |
| S7 | Start Address (Termination) | 32-bit Address | | This record contains the starting execution location at a 32-bit address. This is used to terminate a series of S3 records. If a SREC file is only used to program a memory device and the execution location is ignored, then an address of zero could be used. |
| S8 | Start Address (Termination) | 24-bit Address | | This record contains the starting execution location at a 24-bit address. This is used to terminate a series of S2 records. If a SREC file is only used to program a memory device and the execution location is ignored, then an address of zero could be used. |
| S9 | Start Address (Termination) | 16-bit Address | | This record contains the starting execution location at a 16-bit address. This is used to terminate a series of S1 records. If a SREC file is only used to program a memory device and the execution location is ignored, then an address of zero could be used. |
Rekam pesanan
Meskipun beberapa dokumentasi Unix menyatakan “urutan S-record dalam file tidak penting dan tidak ada urutan tertentu yang dapat diasumsikan”, [5] dalam praktiknya sebagian besar perangkat lunak telah memesan catatan SREC. Urutan catatan umum dimulai dengan catatan header S0 (terkadang opsional), berlanjut dengan urutan satu atau beberapa catatan data S1/S2/S3, mungkin memiliki satu catatan hitungan S5/S6 opsional, dan diakhiri dengan satu catatan hitungan S7/S8/ yang sesuai. Catatan penghentian S9.
Catatan alamat 16-bit gaya S19
- S0
- S1 (satu atau lebih catatan)
- S5 (rekaman opsional)
- S9
Catatan alamat 24-bit gaya S28
- S0
- S2 (satu atau lebih catatan)
- S5 (rekaman opsional)
- S8
Catatan alamat 32-bit gaya S37
- S0
- S3 (satu atau lebih catatan)
- S5 (rekaman opsional)
- S7
Keterbatasan
Panjang rekaman – Dokumentasi halaman manual Unix menyatakan, “Sebuah file S-record terdiri dari urutan string karakter ASCII yang diformat secara khusus. Panjang S-record akan kurang dari atau sama dengan 78 byte”. Halaman manual selanjutnya membatasi jumlah karakter dalam bidang data menjadi 64 (atau 32 byte data). Catatan dengan alamat 8-hex-karakter dan 64 karakter data akan memiliki panjang 78 (2 + 2 + 8 + 64 + 2) karakter (hitungan ini mengabaikan kemungkinan karakter akhir baris atau terminasi string). File dapat dicetak pada teleprinter selebar 80 karakter. Catatan di bagian bawah halaman manual menyatakan, “[Halaman manual] ini adalah satu-satunya tempat di mana batas 78-byte pada total panjang rekaman atau batas 64-byte pada panjang data didokumentasikan. Nilai-nilai ini tidak boleh dipercaya untuk kasus umum”. Jika batasan itu diabaikan, panjang maksimum S-record adalah 514 karakter, sehingga dengan asumsi Hitungan Byte 0xFF (255), akan menjadi 2 untuk bidang Jenis Catatan + 2 untuk bidang Hitungan Byte + (2 * 255) untuk Bidang Alamat / Data / Checksum. Ruang buffer tambahan mungkin diperlukan untuk terminator garis dan string. Menggunakan panjang baris memiliki masalah: “Definisi format S-record Motorola mengizinkan hingga 255 byte muatan, atau baris berisi 514 karakter, ditambah penghentian baris. Semua pemrogram EPROM harus memiliki buffer baris yang cukup besar untuk menangani rekaman sebesar ini. Hanya sedikit yang melakukannya.”
Bidang data – Beberapa dokumentasi merekomendasikan maksimum 32 byte data (64 karakter heksadesimal) dalam bidang ini. Jumlah minimum data untuk rekaman S0/S1/S2/S3 adalah nol. Jumlah maksimum data bervariasi tergantung pada ukuran bidang alamat. Karena bidang Penghitungan Byte tidak boleh lebih tinggi dari 255 (0xFF), maka jumlah maksimum byte data dihitung dengan 255 dikurangi (1 byte untuk bidang checksum) dikurangi (jumlah byte di bidang alamat). Catatan S0/S1 mendukung hingga 252 byte data. Catatan S2 mendukung hingga 251 byte data. Catatan S3 mendukung hingga 250 byte data.
Komentar – Format file SREC tidak mendukung komentar. Beberapa perangkat lunak mengabaikan semua baris teks yang tidak dimulai dengan “S” dan mengabaikan semua teks setelah bidang checksum; teks tambahan itu terkadang digunakan (tidak kompatibel) untuk komentar. Misalnya, kompiler CCS PIC mendukung penempatan “;” baris komentar di bagian atas atau bawah file Intel HEX, dan manualnya menyatakan “beberapa pemrogram (khususnya MPLAB) tidak menyukai komentar di bagian atas file hex”, itulah sebabnya kompiler memiliki opsi untuk menempatkan komentar di bagian bawah file hex
