Talk:SREC (file format)
|WikiProject Computing||(Rated Start-class, Low-importance)|
Need to add more
- 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."
- E.g. for the real time operating system QNX, boot images can be built in the SREC format. —Preceding unsigned comment added by 188.8.131.52 (talk) 19:28, 14 December 2010 (UTC)
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
- 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)
- 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 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)