On Sep 6, 2016, at 7:18 PM, Eric Christopherson
<echristopherson at gmail.com> wrote:
On Tue, Sep 06, 2016, Paul Koning wrote:
[...]
19200? I didn't think the VT100 supported
that.
You've got to be careful with that setting, even on devices that claim
to do it. When it first appeared, it was often a "just barely
possible" setting on the clock generator, with an actual bit rate off
a couple of percent from the correct value. If both ends used the
same clock generators, no problem of course. But if one end uses an
accurate one, you may get framing errors.
Is this why modems went to 14400 instead of 19200?
No, that's a matter of what next step modulation scheme had become feasible.
[...]
On the other hand, flow control issues do not
result in "garbage"
characters. The only way you'd get what looks like garbage is if
escape sequences are corrupted so a portion of that sequence is
mistaken for text. If you see garbage in a full screen editor, that
could be the reason. On the other hand, if you're just sending a
large document to the screen and you're seeing garbage, flow control
is not the cause.
Interesting. I've been trying to get a WiFi device for the Commodore
8-bits working consistently in 9600 bps mode, and have just been
assuming the garbage characters I get when I receive a screenful of text
all at once were due to buffer overruns. The garbage characters there
look like actual garbage, not like partial CSIs like [3;1m or whatever.
It's possible to imagine incompetently designed UARTs that do odd things. But given a
normal UART, the first step it performs is to frame the character and the bits. That
depends on an adequate signal, and a sufficiently accurate clock. After that step, you
have a received character which should be correct. Next, that character has to be
buffered and delivered to the consuming system. That probably involves a FIFO, and either
an interrupt or DMA. If there is no room to buffer the character, it will be discarded,
hopefully with a status in the UART registers to indicate that. But either the character
will be buffered as received, or not at all -- it would not be modified at this point.
Finally, if an XOFF is received, it has to be seen by the element that acts on it (either
something in the serial port hardware, or the driver, or the application software) which
has to stop the output stream. If that takes too long, or the output buffers beyond the
stop point are too large, too many characters may get out after the XOFF was sent. That
would generally cause a buffer overflow, which will drop characters as described above but
will not modify them.
Earlier on
there was some discussion about modern interface devices
with non-compliant "RS232" transceivers. If your RS232 output is
marginal, that could cause garbage. If the clocks are off, ditto. An
oscilloscope could be used to test both those theories.
I wonder if it's a similar sort of timing issue between my device and
the computer. I'll have to try a few computers and see if behavior
varies.
You mean at the USB level? Or in a computer serial port? If the latter, the only timing
issue I can think of would be baud rate clock issues.
BTW, a serial port baud rate generator is a programmable divider. The range of speeds
supported has changed over time; early on it was 110 to 9600 (or sometimes lower, say 110
to 2400). The clock crystal was chosen to deliver "sufficiently accurate"
frequencies, taking into account the way the bit framing was done in the particular UART
design. Some of those generators could do 19200 baud as well but that was often not
supported because there the frequency was off too much. If you used it anyway, and both
ends use the same generator, all would be well. You might be doing 19,900 baud rather
than 19,200, but that's ok so long as the ends agree. But newer serial ports have a
much higher upper limit, which means they have a higher frequency crystal and the
individual error values for the individual speeds will be different. For the ones that
were in spec all along that should not be an issue; for ones that were out of spec, it
probably would be.
paul