[...CR for autobaud...]
If it's bit-banged,
I find it plausible; taking a highly oversampled
CR character and deducing the effective divisor from it is
relatively easy.
Meh. Auto baud detection has been around a long time. Easy to
with
uarts as well. I think all DEC OSes can do it. You basically just
set a fairly high speed on the port and read. You get a character
and have a lookup table for the different speeds.
As described, this can't work if the sender's speed is slower than 1/10
of the receiver's speed, because then the receiver's entire character
time falls within the sender's start bit. (Of course, that's enough to
span a factor of 8, which is enough to be somewhat useful; it allows
autobauding from 9600 down as low as 1200, for example: 0x0d=N,
0xe6=N/2, 0x78 with a framing error = N/4, 0x80=N/8, 0x00 with a
framing error = N/10 or slower.)
Handling faster speeds is more difficult, and may vary based on details
such as whether the sender's speed is slightly more or slightly less
than (say) double the receiver's speed.
But, if it's bit-banged, then simply greatly oversampling the autobaud
input can allow autobauding even to unusual speeds like 4000 baud,
provided they're within range.
[...] ASCII,
in which case 8N and 70 are equivalent.
8N1 would actually be the same as 7S1, but
depending on the software
many variants could work. 7O will set the high bit for some
characters.
I said 701, not 7O1. I initially wrote 7Z1, but its converse is
ambiguous (because "one" and "odd" both begin with o). I didn't
think
of M and S; I wish I had, because the set M S E O is less likely to
display ambiguously than 0 1 E O.
/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTML mouse at
rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
