Talk:SREC (file format)

Need to add more

Need to add more to the SREC file format description here anyone have any comments? JBadger169 (talk) 14:23, 29 November 2007 (UTC)

I added some more content, axed the duplicate S19 page, and rewrote some stuff. Also, I removed the link to Altera. This article could have a list of embedded software packages that offer S-record support, but it would be a long list. I think this is turning into a nice little article on an arcane subject. There are some remaining issues with this article that I haven't addressed yet. Both the record description and the example are copied directly from the man page. I think those need to be replaced with original content, but I am not an expert on licensing. -Wronkiew (talk) 06:45, 18 December 2007 (UTC)

‘banked’ S-Record format.

There should be notes on the new banked s-record format. This is where A S2 record the upper 8 bits has the PPAGE address and the lower 16 bits has the word address.--JBadger169 (talk) 14:04, 24 March 2008 (UTC)

Please list which companies support it and point to a specification or documentation. • Sbmeirow • Talk • 12:05, 30 June 2014 (UTC)

Usage of SREC?

"[SREC] is used by software development tools to encode binary data, especially executable code, for embedded processors."

Exactly where in the development process is SREC used? The embedded systems I came in contact with yet work on "true" binary files. --Abdull (talk) 19:44, 9 March 2010 (UTC)

E.g. for the real time operating system QNX, boot images can be built in the SREC format. —Preceding unsigned comment added by 71.246.14.17 (talk) 19:28, 14 December 2010 (UTC)

In my present job (automotive industry), we're also using Intel Hex and Motorola SREC files for all kinds of controllers. --Antred (talk) 10:54, 30 November 2016 (UTC)

Record sequence

This article quotes a misnomer that was (as noted) published in the UNIX world some years ago, specifically that records may be expected to appear in any order in the data stream. That is incorrect. The final record must always be S7, S8 or S9 (depending on addressing). More than a few S-record loaders are dependent on that requirement. Bigdumbdinosaur (talk) 22:23, 8 July 2015 (UTC)

I wouldn't doubt that some software is written in a manor that requires records to appear in a specific order. It would make the most sense that records appear in the order "S0 then (S1|S2|S3) then (S5|S6) then (S7|S8|S9)", but then again I didn't write the spec. Still, your text changes need to be tweaked to sound more encyclopedic-like than opinion/blog-like. • Sbmeirow • Talk • 07:37, 9 July 2015 (UTC)

I'll second Sbmeirow.

The Unix man comment may have intended to say the data in the (S1|S2|S3) need not be in address order but may appear in any order. Assemblers and compilers might spit stuff out in blocks whose addresses jump around.

The early Mot specs said that there would usually be 1 S0 but there could be arbitrarily many of them. I get the impression they could be interspersed as long as they don't break a data block. The early spec also implies that there could be many data blocks (S1|S2|S3) records as long as each block was monotheistic and terminated by its corresponding termination record. That tends to support another reading of the Unix man's any order statement: a file might be S0 S1 S1 S7 S0 S2 S2 S8.

The early spec also allowed line numbers and other cruft before the S.

WP should be neither prescriptive nor judgmental. Most software will be optional S0 (S1|S2|S3) followed by appropriate (S7|S8|S9).

Glrx (talk) 17:01, 10 July 2015 (UTC)

I disagree with both of you and have the documentation here to support my edit (see appendix C of the MOTOROLA M68000 FAMILY Programmer's Reference Manual).  Please locate and review a copy of that manual (it can be found on-line) and then advise. Bigdumbdinosaur (talk) 01:06, 15 August 2015 (UTC)

You mean the MOTOROLA M68000 FAMILY Programmer's Reference Manual that is already cited as reference 2 in the article? The one that has a URL link? The one that describes and "S-record format module" as something containing a sequence of S-records? The one that states S0 is the "header record for each block [not module] of S-records", then says "Each block [not module] of S-records uses only one termination record", and goes on to say "Normally, there is only one header record, although it is possible for multiple header records to occur." The same ref I used when I said "The early Mot specs said that there would usually be 1 S0 but there could be arbitrarily many of them." Gee, maybe a "module" could have multiple S-record blocks. The spec is not clear. Glrx (talk) 18:15, 17 August 2015 (UTC)

Small error in the explanatory graphic

The picture titled "Motorola SREC Chart.png" seems to have an error. The graphics claims that the checksum is 2 bytes when in fact it's only 1 byte. --Antred (talk) 16:57, 29 November 2016 (UTC)

The graphic is correct, but the author of that graphic should have described it differently. The checksum is one binary byte, which requires 2 ASCII characters to represent it, each ASCII character is 1 byte, thus 2 bytes is correct. • Sbmeirow • Talk • 02:58, 30 November 2016 (UTC)

I see. You're right; I hadn't realized that he basically meant the characters needed to represent the checksum byte. --Antred (talk) 10:14, 30 November 2016 (UTC)

Early reference to this format in a 1975 Motorola 6800 manual

I've found a very early reference to this format, perhaps among the earliest, in Motorola's M6800 Microprocessor Applications Manual, published in early 1975, on page 5-57 and following, in a description of an example of a teletype-based communications link for a Motorola 6800 system. The paper-tape-based format there is not called "SREC", but its description matches the SREC format. (Incidentally, this description also mentions a length limit of 70 characters—paper tape frames—for each record.) Just noting this as a possible historical reference. --Colin Douglas Howell (talk) 07:20, 27 March 2022 (UTC)