[U-Boot-Users] RE: Why S-Records?

[Wells, Charles]

Rupesh,

I always view the choice of S-records (or Intel hex or whatever) vs. binary
records as being a matter of line bandwidth.  The problem is, of course,
that the ASCII hex characters take a bit more than twice as long to send.
Note that even in the ancient minicomputer days (say 1969), the DEC paper
tape loader was a binary loader.  The problem here was that the terminal of
choice was an ASR33 and loaded programs at 10 bytes per second.  Even short
programs took a very long time to load.  A PDP11 might have 16k bytes of
memory, so a 6k program was not unreasonable.  This would take over 10
minutes to load.

ASCII-based download formats became popular with the advent of
microprocessors which originally had very limited memory but faster serial
ports.  The micro may have only 1k of program RAM and the serial port would
run at 960 characters per second.  So, the entire RAM could be loaded in
just over 1 second.  The problem was that the serial port used to download a
program was also used as the console device and therefore had an ASCII
terminal monitoring the line as well.  If you sent binary over the line, it
was echoed you would get unsightly garbage printed on the console.  You also
had to put up with the irritating noise of the bell.  Worse yet, the binary
characters would put VT100-style consoles into strange modes that you
couldn't recover from.  So, if you split one binary character into two ASCII
hex characters, you never had to deal with a messy or noisy display.  You
could also just look at it and read it.  Some of us got quiet good at this.

Error detection and control is a totally different matter.  If you're
downloading a program, you always need to know that it got down there
correctly, so you always need error detection (and possibly control). My
preference is to add the extra error detection characters in the definition
of the loader records, regardless of whether these loader records are ASCII
or binary.  This way you can move between physical transport methods (e.g.,
raw serial ports or TCP/IP/Ethernet) and simply not worry about whether the
line discipline has error checking or not.  With the speed of modern
communications lines, the few percent of overhead for the checksums just
doesn't matter.

Just my $0.02.

Regards,
Charlie