14 Nov
2019
14 Nov
'19
3:17 p.m.
I think you may be over thinking this. I suppose a system could send a
bit-stream where the data bits + any parity bits != 8 or the parity bit
isn't in the trailing MSB position. However, for simplification lets
consider only that case. A modem will always set the local line coding
to 8,N,1. Any bytes received in command mode will be AND'd with 0x7f to
strip any parity bits before being interpreted. A modem could
optionally detect and reconstruct the local line parity scheme for the
purpose of stuffing the 8th bit MSB for the command responses (eg 'OK'
etc) on the local line. But it will always transfer the entire 8-bit
word period to the remote end in data mode - unmodified.
I suppose you could have 7,N,x however the MSB of the 8-bit word period
would be a stop bit and would transfer through the modulated
transmission the same way - correctly. The number of stop bits only
affect the transmission side of characters on the local line - in that
it adds extra padding between bytes to mitigate timing mis-alignment.
My rule of thumb for RTL UARTs is transmitters should always idle for
1.5 stop periods while receivers should always begin the start bit
search after .5 bit-periods after the 8th data bit period. I suppose
this could cause problems when a line rate is 100% saturated - but so
could oscillator mismatch over time.
My advise is always set the MCU line coding to 8,N,1 (or preferably
1.5), strip the MSB in command RX, and manually re-add MSB parity
stuffing for command responses only based on some algorithm that makes
the most sense.
-A
On 2019-11-13 19:08, Jim Brain via cctalk wrote:
Jumping back in here:
Initially, tcpser's goal was to emulate enough of the "Hayes" command
set so as to bridge old BBS applications so they could be once again
used without modifying them and trying to make them aware of the
Internet.? Over time, that mandate meant adding in support for S
registers and & commands and such, since apps used those.
However, the actual line functionality of the modem was never
attempted to be emulated, as doing so would defeat the purpose of the
app.
Initially, I assumed everyone would set their BBS to 8N1, so as to
maximize the utility of the connection (8 bit clean, etc.).
But, now, I have a Teletype Model 43 here, and it only does 7 bit
ASCII. Fozztexx's mod helps, but it only cleans up parity while in
command mode, which means I can atdt jammingsignal.com, but then when
I connect, I can't log onto that Telnet BBS (that's the catchall name
for such things) because parity gets in the way.
To be as useful as possible, I think the utility should detect parity
in command mode, but then switch the entire data stream to that
configuration, both command mode and data mode.
The alternative (since a PC can't sniff the serial stream like the
Hayes did), is to allow parameters to set the specific parity and
number of stop bits.? And, I think I'll do both.? Without parity and
stop bits, sniff parity.? With it, lock in the parity and don't
sniff.? That way, if folks want the purist behavior, they do tcpser
-s1200,N,8,1 and sniffing can just do -s 1200
Jim