SREC (file format) - Revision history

Darren at 10:58, 26 April 2021

2021-04-26T10:58:19Z

← Older revision		Revision as of 11:58, 26 April 2021
Line 81:		Line 81:
	\| 24-bit<br>Count		\| 24-bit<br>Count
	\| {{Na}}		\| {{Na}}
	\| 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).~~<ref name="SREC-Unix"/>~~		\| 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).
	\|-		\|-
	\| align="center" \| ''S7''		\| align="center" \| ''S7''
Line 102:		Line 102:
	\|}		\|}
	===Record order===		===Record order===
	Although some Unix documentation states "the order of S-records within a file is of no significance and no particular order may be assumed",~~<ref name="SREC-Unix"/>~~ in practice most software has ordered the SREC records. The typical record order starts with a (sometimes optional) S0 header record, continues with a sequence of one or more S1/S2/S3 data records, may have one optional S5/S6 count record, and ends with one appropriate S7/S8/S9 termination record.		Although some Unix documentation states "the order of S-records within a file is of no significance and no particular order may be assumed", in practice most software has ordered the SREC records. The typical record order starts with a (sometimes optional) S0 header record, continues with a sequence of one or more S1/S2/S3 data records, may have one optional S5/S6 count record, and ends with one appropriate S7/S8/S9 termination record.
	; S19-style 16-bit address records		; S19-style 16-bit address records
	# S0		# S0
Line 119:		Line 119:
	# S7		# S7
	===Limitations===		===Limitations===
	''Record length'' - Unix manual page documentation states, "An S-record file consists of a sequence of specially formatted ASCII character strings. An S-record will be less than or equal to 78 bytes in length". The manual page further limits the number of characters in the data field to 64 (or 32 data bytes).~~<ref name="SREC-Unix"/>~~ A record with an 8-hex-character address and 64 data characters would be 78 (2 + 2 + 8 + 64 + 2) characters long (this count ignores possible end-of-line or string termination characters). The file could be printed on an 80-character wide teleprinter. A note at the bottom of the manual page states, "This [manual page] is the only place that a 78-byte limit on total record length or 64-byte limit on data length is documented. These values shouldn't be trusted for the general case".~~<ref name="SREC-Unix"/>~~ If that limitation is ignored, the maximum length of an S-record is 514 characters: 2 for Record Type field + 2 for Byte Count field (whose value would be 0xFF=255) + 2 * 255 for Address, Data, and Checksum fields. Additional buffer space may be required for the line and string terminators. Using long line lengths has problems: "The Motorola S-record format definition permits up to 255 bytes of payload, or lines of 514 characters, plus the line termination. All EPROM programmers should have sufficiently large line buffers to cope with records this big. Few do."~~<ref name="sf"/>~~		''Record length'' - Unix manual page documentation states, "An S-record file consists of a sequence of specially formatted ASCII character strings. An S-record will be less than or equal to 78 bytes in length". The manual page further limits the number of characters in the data field to 64 (or 32 data bytes). A record with an 8-hex-character address and 64 data characters would be 78 (2 + 2 + 8 + 64 + 2) characters long (this count ignores possible end-of-line or string termination characters). The file could be printed on an 80-character wide teleprinter. A note at the bottom of the manual page states, "This [manual page] is the only place that a 78-byte limit on total record length or 64-byte limit on data length is documented. These values shouldn't be trusted for the general case". If that limitation is ignored, the maximum length of an S-record is 514 characters: 2 for Record Type field + 2 for Byte Count field (whose value would be 0xFF=255) + 2 * 255 for Address, Data, and Checksum fields. Additional buffer space may be required for the line and string terminators. Using long line lengths has problems: "The Motorola S-record format definition permits up to 255 bytes of payload, or lines of 514 characters, plus the line termination. All EPROM programmers should have sufficiently large line buffers to cope with records this big. Few do."

	''Data field'' - Some documentation recommends a maximum of 32 bytes of data (64 hex characters) in this field.~~<ref name="SREC-Unix"/>~~ The minimum amount of data for S0/S1/S2/S3 records is zero. The maximum amount of data varies depending on the size of the address field. Since the Byte Count field can't be higher than 255 (0xFF), then the maximum number of bytes of data is calculated by 255 minus (1 byte for checksum field) minus (number of bytes in the address field). S0/S1 records support up to 252 bytes of data. S2 record supports up to 251 bytes of data. S3 record supports up to 250 bytes of data.		''Data field'' - Some documentation recommends a maximum of 32 bytes of data (64 hex characters) in this field. The minimum amount of data for S0/S1/S2/S3 records is zero. The maximum amount of data varies depending on the size of the address field. Since the Byte Count field can't be higher than 255 (0xFF), then the maximum number of bytes of data is calculated by 255 minus (1 byte for checksum field) minus (number of bytes in the address field). S0/S1 records support up to 252 bytes of data. S2 record supports up to 251 bytes of data. S3 record supports up to 250 bytes of data.

	''Comments'' - The SREC file format does not support comments. Some software ignores all text lines that do not start with "S" and ignores all text after the checksum field; that extra text is sometimes used (incompatibly) for comments. For example, the CCS PIC compiler supports placing a ";" comment line at the top or bottom of an [[Intel HEX]] file, and its manuals states "some programmers (MPLAB in particular) do not like comments at the top of the hex file", which is why the compiler has the option of placing the comment at the bottom of the hex file.~~<ref name="CCS_2014"/>~~		''Comments'' - The SREC file format does not support comments. Some software ignores all text lines that do not start with "S" and ignores all text after the checksum field; that extra text is sometimes used (incompatibly) for comments. For example, the CCS PIC compiler supports placing a ";" comment line at the top or bottom of an [[Intel HEX]] file, and its manuals states "some programmers (MPLAB in particular) do not like comments at the top of the hex file", which is why the compiler has the option of placing the comment at the bottom of the hex file.
	==Examples==		==Examples==
	; Color legend		; Color legend

Darren at 10:56, 26 April 2021

2021-04-26T10:56:36Z

← Older revision		Revision as of 11:56, 26 April 2021
Line 51:		Line 51:
	\| 16-bit<br>Address		\| 16-bit<br>Address
	\| {{Ya}}		\| {{Ya}}
	\| This record contains data that starts at the 16-bit address field.~~<ref name="SREC-Unix"/>~~ 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").		\| 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").
	\|-		\|-
	\| align="center" \| ''S2''		\| align="center" \| ''S2''
Line 57:		Line 57:
	\| 24-bit<br>Address		\| 24-bit<br>Address
	\| {{Ya}}		\| {{Ya}}
	\| This record contains data that starts at a 24-bit address.~~<ref name="SREC-Unix"/>~~ 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").		\| 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").
	\|-		\|-
	\| align="center" \| ''S3''		\| align="center" \| ''S3''
Line 63:		Line 63:
	\| 32-bit<br>Address		\| 32-bit<br>Address
	\| {{Ya}}		\| {{Ya}}
	\| This record contains data that starts at a 32-bit address.~~<ref name="SREC-Unix"/>~~ This record is typically used for 32-bit microcontrollers, such as ARM and 680x0. 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").		\| This record contains data that starts at a 32-bit address. This record is typically used for 32-bit microcontrollers, such as ARM and 680x0. 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").
	\|-		\|-
	\| align="center" \| ''S4''		\| align="center" \| ''S4''
Line 75:		Line 75:
	\| 16-bit<br>Count		\| 16-bit<br>Count
	\| {{Na}}		\| {{Na}}
	\| This optional record contains a 16-bit count of S1/S2/S3 records.~~<ref name="SREC-Unix"/>~~ This record is used if the record count is less than or equal to 65,535 (0xFFFF), otherwise S6 record would be used.		\| 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.
	\|-		\|-
	\| align="center" \| ''S6''		\| align="center" \| ''S6''
Line 87:		Line 87:
	\| 32-bit<br>Address		\| 32-bit<br>Address
	\| {{Na}}		\| {{Na}}
	\| This record contains the starting execution location at a 32-bit address.~~<ref name="SREC-Unix"/><ref name="SREC-term"/>~~ 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.		\| 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.
	\|-		\|-
	\| align="center" \| ''S8''		\| align="center" \| ''S8''
Line 93:		Line 93:
	\| 24-bit<br>Address		\| 24-bit<br>Address
	\| {{Na}}		\| {{Na}}
	\| This record contains the starting execution location at a 24-bit address.~~<ref name="SREC-Unix"/><ref name="SREC-term"/>~~ 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.		\| 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.
	\|-		\|-
	\| align="center" \| ''S9''		\| align="center" \| ''S9''
Line 99:		Line 99:
	\| 16-bit<br>Address		\| 16-bit<br>Address
	\| {{Na}}		\| {{Na}}
	\| This record contains the starting execution location at a 16-bit address.~~<ref name="SREC-Unix"/><ref name="SREC-term"/>~~ 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.		\| 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.
	\|}		\|}
	===Record order===		===Record order===

Darren at 10:55, 26 April 2021

2021-04-26T10:55:20Z

← Older revision		Revision as of 11:55, 26 April 2021
Line 21:		Line 21:
	\|}		\|}
	An SREC format file consists of a series of ASCII text records. The records have the following structure from left to right:		An SREC format file consists of a series of ASCII text records. The records have the following structure from left to right:
	# ''Record start'' - each record begins with an uppercase letter "S" character (ASCII 0x53) which stands for "Start-of-Record".<ref>{{cite book \|title=MCM6830L7 MIKBUG / MINIBUG ROM \|author-first1=Mike \|author-last1=Wiles \|author-first2=Andre \|author-last2=Felix \|editor-first=Michael \|editor-last=Holley \|date=2000-10-21 \|orig-year=1975 \|type=Engineering note \|id=Note 100 \|publisher=[[Motorola Semiconductor Products, Inc.]] \|url=http://www.swtpc.com/mholley/MP_A/MikbugEn100.pdf \|access-date=2019-06-16 \|url-status=dead \|archive-url=https://web.archive.org/web/20190616115550/http://www.swtpc.com/mholley/MP_A/MikbugEn100.pdf \|archive-date=2019-06-16}} (23 pages)</ref>		# ''Record start'' - each record begins with an uppercase letter "S" character (ASCII 0x53) which stands for "Start-of-Record".
	# ''Record type'' - single numeric digit "0" to "9", defining the type of record.		# ''Record type'' - single numeric digit "0" to "9", defining the type of record.
	# ''Byte count'' - two hex digits, indicating the number of bytes (hex digit pairs) that follow in the rest of the record (address + data + checksum). This field has a minimum value of 3 for 16-bit address field plus 1 checksum byte, and a maximum value of 255 (0xFF).		# ''Byte count'' - two hex digits, indicating the number of bytes (hex digit pairs) that follow in the rest of the record (address + data + checksum). This field has a minimum value of 3 for 16-bit address field plus 1 checksum byte, and a maximum value of 255 (0xFF).
Line 45:		Line 45:
	\| 16-bit<br>"0000"		\| 16-bit<br>"0000"
	\| {{Na}}		\| {{Na}}
	\| 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. It is common to see: 48 44 52 which is the ASCII H, D, and R - "HDR".~~<ref name="Tareski_2018"/>~~		\| 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. It is common to see: 48 44 52 which is the ASCII H, D, and R - "HDR".
	\|-		\|-
	\| align="center" \| ''S1''		\| align="center" \| ''S1''

Darren: /* External links */

2021-04-26T10:53:19Z

External links

← Older revision		Revision as of 11:53, 26 April 2021
Line 126:		Line 126:
	==Examples==		==Examples==
	; Color legend		; Color legend

	{\| class="wikitable" style="text-align:center"		{\| class="wikitable" style="text-align:center"
	\|-		\|-
	\| style='background: #FFCCCC' \| Record Type \|\| style='background: #CCFFCC' \| Byte Count \|\| style='background: #CCCCFF' \| Address \|\| style='background: #CCFFFF' \| Data \|\| style='background: #CCCCCC' \| Checksum		\| style='background: #FFCCCC' \| Record Type \|\| style='background: #CCFFCC' \| Byte Count \|\| style='background: #CCCCFF' \| Address \|\| style='background: #CCFFFF' \| Data \|\| style='background: #CCCCCC' \| Checksum
	\|}		\|}

	===Checksum calculation===		===Checksum calculation===
	The following example record:		The following example record:

Darren: /* External links */

2021-04-26T10:51:52Z

External links

← Older revision		Revision as of 11:51, 26 April 2021
Line 157:		Line 157:
	* [https://pypi.python.org/pypi/bincopy bincopy] is a Python package for manipulating SREC format files.		* [https://pypi.python.org/pypi/bincopy bincopy] is a Python package for manipulating SREC format files.
	* [https://github.com/arkku/srec kk_srec] is a C library and program for reading the SREC format.		* [https://github.com/arkku/srec kk_srec] is a C library and program for reading the SREC format.
	~~{{DEFAULTSORT:Srec (File Format)}}~~
	~~[[Category:Binary-to-text encoding formats]]~~
	~~[[Category:Embedded systems]]~~
	~~[[Category:Computer file formats]]~~

Darren: /* References */

2021-04-26T10:50:52Z

References

← Older revision		Revision as of 11:50, 26 April 2021
Line 151:		Line 151:
	* [[MOS Technology file format]]		* [[MOS Technology file format]]
	* [[Tektronix hex format]]		* [[Tektronix hex format]]
	~~==References==~~
	~~{{Reflist\|refs=~~
	<ref name="Tareski_2018">{{Cite web \|title=Motorola S-record description \|author-last=Tareski \|author-first=Val \|website=www.amelek.gda.pl \|url=http://www.amelek.gda.pl/avr/uisp/srecord.htm \|access-date=2018-06-26}}</ref>
	~~<ref name="SREC-Unix">{{cite web \|title=Motorola S-records from Unix man pages \|url=http://www.amelek.gda.pl/avr/uisp/srecord.htm \|access-date=2014-06-30}}</ref>~~
	<ref name="SREC-term">{{cite book \|title=M68000 Family Programmer's Reference Manual \|version=Revision 1 \|publisher=[[Motorola]] ([[Freescale]]) \|date=1992 \|pages=C-1–C-5 \|chapter=Appendix C \|isbn=978-0-13723289-5 \|url=http://www.freescale.com/files/archives/doc/ref_manual/M68000PRM.pdf}}</ref>
	~~<ref name="sf">{{cite web \|title=srec_examples \|work=sourceforge.net \|url=http://srecord.sourceforge.net/man/man1/srec_examples.html}}</ref>~~
	<ref name="CCS_2014">{{citation \|title=CCS Compiler Reference Manual PCB/PCM/PCH \|publisher=[[Custom Computer Services, Inc.]] \|date=May 2014 \|page=107 \|url=http://www.ccsinfo.com/downloads/ccs_c_manual.pdf \|access-date=2015-02-08}}</ref>
	<ref name="Xilinx_2010_EXO">{{cite web \|title=AR#476 PROMGen - Description of PROM/EEPROM file formats: MCS, EXO, HEX, and others \|at=Motorola EXORmacs - File Format Code 87 \|date=2010-03-08 \|publisher=[[Xilinx]] \|url=https://www.xilinx.com/support/answers/476.html \|access-date=2020-03-03 \|url-status=live \|archive-url=https://web.archive.org/web/20200303085851/https://www.xilinx.com/support/answers/476.html \|archive-date=2020-03-03}}</ref>
	}}
	== External links ==		== External links ==
	* [http://srecord.sourceforge.net/ SRecord] is a collection of tools for manipulating SREC format files.		* [http://srecord.sourceforge.net/ SRecord] is a collection of tools for manipulating SREC format files.

Darren at 10:36, 26 April 2021

2021-04-26T10:36:21Z

← Older revision		Revision as of 11:36, 26 April 2021
Line 126:		Line 126:
	==Examples==		==Examples==
	; Color legend		; Color legend
	{~~{legend inline~~\| #FFCCCC \|Record ~~type}}~~
	~~{{legend inline~~\| #CCFFCC \|Byte ~~count}}~~		{\| class="wikitable" style="text-align:center"
	~~{{legend inline~~\| #CCCCFF \|Address}}		\|-
	~~{{legend inline~~\| #CCFFFF \|Data}}		\| style='background: #FFCCCC' \| Record Type \|\| style='background: #CCFFCC' \| Byte Count \|\| style='background: #CCCCFF' \| Address \|\| style='background: #CCFFFF' \| Data \|\| style='background: #CCCCCC' \| Checksum
	~~{{legend inline~~\| #CCCCCC \|Checksum}}		\|}

	===Checksum calculation===		===Checksum calculation===
	The following example record:		The following example record:

Darren at 17:01, 23 April 2021

2021-04-23T17:01:40Z

← Older revision		Revision as of 18:01, 23 April 2021
Line 1:		Line 1:
	'''Motorola S-record''' is a file format, created by [[Motorola]], that conveys binary information as [[hexadecimal\|hex]] values in [[ASCII]] text form. This file format may also be known as '''SRECORD''', '''SREC''', '''S19''', '''S28''', '''S37'''. It is commonly used for programming [[flash memory]] in microcontrollers, [[EPROM]]s, [[EEPROM]]s, and other types of programmable logic devices. In a typical application, a compiler or assembler converts a program's source code (such as C or assembly language) to machine code and outputs it into a HEX file. The HEX file is then imported by a programmer to "burn" the machine code into [[non-volatile memory]], or is transferred to the target system for loading and execution.		'''Motorola S-record''' is a file format, created by [[Motorola]], that conveys binary information as [[hexadecimal\|hex]] values in [[ASCII]] text form. This file format may also be known as '''SRECORD''', '''SREC''', '''S19''', '''S28''', '''S37'''. It is commonly used for programming [[flash memory]] in microcontrollers, [[EPROM]]s, [[EEPROM]]s, and other types of programmable logic devices. In a typical application, a compiler or assembler converts a program's source code (such as C or assembly language) to machine code and outputs it into a HEX file. The HEX file is then imported by a programmer to "burn" the machine code into [[non-volatile memory]], or is transferred to the target system for loading and execution.
	~~==Overview==~~
	[[File:Motorola SREC Chart.png\|thumb\|A quick reference chart for the Motorola SREC format. (Note that in the record example image the word "bytes" is alternatively used to specify characters.)		[[File:Motorola SREC Chart.png\|thumb\|A quick reference chart for the Motorola SREC format. (Note that in the record example image the word "bytes" is alternatively used to specify characters.)
	{\| class="wikitable"		{\| class="wikitable"
Line 10:		Line 9:
	\|}		\|}
	]]		]]
			==Overview==
	===History===		===History===
	The S-record format was created in the mid-1970s for the [[Motorola 6800]] processor. [[Programming tool\|Software development tools]] for that and other [[embedded processor]]s would make executable code and data in the S-record format. PROM programmers would then read the S-record format and "burn" the data into the PROMs or EPROMs used in the embedded system.		The S-record format was created in the mid-1970s for the [[Motorola 6800]] processor. [[Programming tool\|Software development tools]] for that and other [[embedded processor]]s would make executable code and data in the S-record format. PROM programmers would then read the S-record format and "burn" the data into the PROMs or EPROMs used in the embedded system.

Darren at 16:59, 23 April 2021

2021-04-23T16:59:09Z

← Older revision		Revision as of 17:59, 23 April 2021
Line 1:		Line 1:
			'''Motorola S-record''' is a file format, created by [[Motorola]], that conveys binary information as [[hexadecimal\|hex]] values in [[ASCII]] text form. This file format may also be known as '''SRECORD''', '''SREC''', '''S19''', '''S28''', '''S37'''. It is commonly used for programming [[flash memory]] in microcontrollers, [[EPROM]]s, [[EEPROM]]s, and other types of programmable logic devices. In a typical application, a compiler or assembler converts a program's source code (such as C or assembly language) to machine code and outputs it into a HEX file. The HEX file is then imported by a programmer to "burn" the machine code into [[non-volatile memory]], or is transferred to the target system for loading and execution.
			==Overview==
	[[File:Motorola SREC Chart.png\|thumb\|A quick reference chart for the Motorola SREC format. (Note that in the record example image the word "bytes" is alternatively used to specify characters.)		[[File:Motorola SREC Chart.png\|thumb\|A quick reference chart for the Motorola SREC format. (Note that in the record example image the word "bytes" is alternatively used to specify characters.)
	{\| class="wikitable"		{\| class="wikitable"
Line 8:		Line 10:
	\|}		\|}
	]]		]]
	'''Motorola S-record''' is a file format, created by [[Motorola]], that conveys binary information as [[hexadecimal\|hex]] values in [[ASCII]] text form. This file format may also be known as '''SRECORD''', '''SREC''', '''S19''', '''S28''', '''S37'''. It is commonly used for programming [[flash memory]] in microcontrollers, [[EPROM]]s, [[EEPROM]]s, and other types of programmable logic devices. In a typical application, a compiler or assembler converts a program's source code (such as C or assembly language) to machine code and outputs it into a HEX file. The HEX file is then imported by a programmer to "burn" the machine code into [[non-volatile memory]], or is transferred to the target system for loading and execution.
	~~==Overview==~~
	===History===		===History===
	The S-record format was created in the mid-1970s for the [[Motorola 6800]] processor. [[Programming tool\|Software development tools]] for that and other [[embedded processor]]s would make executable code and data in the S-record format. PROM programmers would then read the S-record format and "burn" the data into the PROMs or EPROMs used in the embedded system.		The S-record format was created in the mid-1970s for the [[Motorola 6800]] processor. [[Programming tool\|Software development tools]] for that and other [[embedded processor]]s would make executable code and data in the S-record format. PROM programmers would then read the S-record format and "burn" the data into the PROMs or EPROMs used in the embedded system.

Darren at 14:12, 23 April 2021

2021-04-23T14:12:12Z

@@ Line 1: / Line 1: @@
-[[File:Motorola SREC Chart.png|thumb|A quick reference chart for the Motorola SREC format. (Note that in the record example image the word "bytes" is alternatively used to specify characters.)]]
+[[File:Motorola SREC Chart.png|thumb|A quick reference chart for the Motorola SREC format. (Note that in the record example image the word "bytes" is alternatively used to specify characters.)
 '''Motorola S-record''' is a file format, created by [[Motorola]], that conveys binary information as [[hexadecimal|hex]] values in [[ASCII]] text form. This file format may also be known as '''SRECORD''', '''SREC''', '''S19''', '''S28''', '''S37'''. It is commonly used for programming [[flash memory]] in microcontrollers, [[EPROM]]s, [[EEPROM]]s, and other types of programmable logic devices. In a typical application, a compiler or assembler converts a program's source code (such as C or assembly language) to machine code and outputs it into a HEX file. The HEX file is then imported by a programmer to "burn" the machine code into [[non-volatile memory]], or is transferred to the target system for loading and execution.
 ==Overview==