reliable rs-232

[Ian Smith]

In freebsd-questions Digest, Vol 305, Issue 13, Message: 2
On Sat, 10 Apr 2010 15:41:33 +0200 Grzegorz Daniluk <lin_g at o2.pl> wrote:
 > Hi everybody,
 > I have a question regarding rs-232 under FreeBSD.
 > I need to write an application for FreeBSD to operate an industrial 
 > controller via rs-232. The trick is that it should have very good long 
 > term stability (reliably operation over years). It should be able to 
 > detect and correct (e.g by reconfiguration of rs-232 port parameters) 
 > when rs-232 hangs or changes its transmission parameters as a result of 
 > electrical interference/disturbances etc. First thought is to simply 
 > close and reopen rs-232 port every given time interval, so even if 
 > something 'strange' happens the failure would be fixed after finite time 
 > period. But maybe there is smarter way of doing that. Maybe some special 
 > fault-tolerant rs-232 kernel drivers ?
 > Any help appreciated, maybe someone has other helpful advieces regarding 
 > reliable rs-232 programming ini general ?

RS-232 is inherently as reliable as the devices you're talking with, the 
protocols you're using for communication and the (lack of) interference 
from noise on cable/s in the environment you're operating in.  Even in 
very adverse (noisy) conditions, I've never found any need to close and 
reopen ports to reinitialise hardware on freeBSD, back to version 2.2.

If a byte of data is corrupted, it's just corrupted; I don't know of any 
conditions (given electrical signals within specification) that could 
cause a tty or uart port to require re-initialisation.  So it comes down 
to detection of any transmission errors, either byte-by-byte using say 
parity bits, or by protocol (eg CRC) if using packet-oriented data 
transmission, and physical prevention of errors by such as shielded 
cables, avoiding earth loops between computer and device/s and so on.

Perhaps you could provide a few more details about how the industrial 
controller is talked to, at what baudrate, cable length, software or 
hardware handshaking (eg CTS/RTS &/or DTR/DSR) and whether byte-by-byte 
or using packet protocols, and such?  Is the communication two-way?

cheers, Ian

(please CC me; I'm subscribed to the -digest which can take a while)