serial line woes -- a bit more

[R. Luoma]

My objective is to have two computers communicate
in an error-free manner over an RS-232 serial line.

Hardware flow control seems to be failing.

At this point, aside from the above objective,
I wish to know two things

1) what exactly is RS-232 hardware flow control
   (down to the level of what UART register gets set when)

2) Why am I getting UART FIFO buffer overrun errors?


I have two PC connected by a full-handshake RS-232 cable
with DB-9 connectors on both ends; a traditional null-modem
cable seems to disable hardware handshaking.  Does this mean
that two PCs cannot use hardware handshaking?

I have used a continuity checker to "buzz-out" the cable;
it is indeed a full handshake cable.

I do have and have used an LED serial line breakout box.
Furthermore, using a basic I/O port program, have used
the appropriate UART register and, using the breakout
box, verified that the UART can change the hardware
flow control lines on the cable.

I have not used a full hardware serial line sniffer
to monitor the control lines as well as the data in real time.

Please note that I am using the functions
tcsetattr, cfsetispeed and cfsetospeed.

I have also used a third computer running "slsnif"
to verify that the receiving system is dropping data.

I have modified the 2.4.31 kernel to show that the buffer
overrun error occurs when the data starts getting dropped.
I have also used printk to make sure that the serial driver
seems to be setting hardware flow control.

At this point, it would be very painful to implement
an error-checking block serial protocol (I have already
received this suggestion many times, thank you),
like the ones used by kermit, xmodem et al.
If I have to do so, I want to make very sure
that serial flowcontrol fails to maintain
error-free communication.

I would greatly appreciate help in this matter.

-- 
R. Luoma

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.