On 2014-11-10 18:28, Mouse wrote:
[...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.
True. There are limits. DEC seems to have been fond of using 4800 for
the initial sampling. That worked for anything between 600 and 9600 at
least. Which I'm sure is all a Votrax could handle as well.
(The DEC code does a second sampling at 300 bps if they didn't
successfully detect things at 4800.)
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.
Yes, with high enough samplig, and long enough, you can always figure it
out. Even for odd speeds and so on... :-)
[...] 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.
Ok. Color me stupid. :-)
I really didn't notice you typed a zero, and just read it as 'odd'.
(I need to read text with a better font, that makes zero and o differ
more...)
Johnny