I then tried 7
N 1 (that's how my CT1024 terminal is set up). This time I
got more consistent characters. If I hit reset, there is also a response.
If and when you get consistent characters, no matter how wrong, then it's
time to look at the bit patterns of what you get V what you expect (is
anybody around who knows?)
Since, obviously, if consistent, then it might be right except for one or
more bits stuck on or stuck off.
Yes, it is frustrating.
Am I the only person who rarely, if ever, has RS232 problems?
I don't guess, I don't try things until it works. I make measurements
and figure out how it must work.
In this case, I would guess the serial chip is either a dumb UART (one
of those 40 pin ones) or a 6850. Both have the advantage (here) of
needing an external baud rate clock. So, stick a 'scope, frequency counter,
LogicDart, whatever you use on the Transmit clock pin. Measure the
frequency and remember that almost all serial chips need a 16* baud
clock. So divide what you measure by 16, set that baud rate.
Set 1 stop bit on the terminal. If the system sends 2, it won't matter.
It's asynchronous, it's just an extra bit delay between characters.
Try 8 bits, no parity. Most machines sent 8 bits, the high bit might
be a parity bit. If some characters get through, others are corrupted
into graphics-type things (extended character set) then work out if the
high bit is being set on odd or even parity, and re-set the terminal to
7 data bits and the appropriate parity bit.
If all else fails, stick a logic analyser on the Tx Data pin of the UART,
trigger on the falling edge, and grab the bitstream as it comes out
of the UART. See if you can make sense of it.
-tony
