FreeBSD6.2 What is the easiest Way to Capture RS-232 Serial Data?

[Martin McCormick]

	I wrote a C program several years ago that works and
logs output from a telephone switch to a file and runs in
FreeBSD4.x.

	I just opened /dev/ttyd0 for reading and it has run for
up to 1,000 days at a time, but it also 
has issues as one might expect.

	It can be killed if one of the incoming characters
happens to be an EOF (4) which is quite possible if somebody
umplugs or plugs in the cable and creates garbage on the line.

	The data from the switch is ASCII with carriage
return/linefeed sequences so nothing really harsh goes on, but I
need to make it as bullet-proof as possible.

	In addition, the actual data are 7-bit, odd parity with
1 stop. I basically ignored that fact last time and masked off
the MSB of each character and that's how it has been for 5
years.

	Now, I am writing a similar program to log different
data from that same telephone switch and I want to do better
this time, but not reen vent any wheels I don't have to.

	What is the best way to use as much of the existing UNIX
environment as possible to listen to /dev/ttyd[x] with no
interpretation of incoming data?

	The data will be dumped at the end of each line, stored
in a file, and other action may be taken but normally, the
program will just be in a receive-blocked mode, waiting to hear
something new.

	About the only thing I am doing differently this time is
trying to set the tty such that it doesn't look for any EOF or
other control codes in the data. The data will be treated as raw
and what ever comes across is okay. The program will clean it up
to make it good for the file.

	As I stated, the standard /dev/ttyd device has done
amazingly well in FreeBSD4.7, but some of that has been dumb
luck. We shouldn't have to warn people in the area that they
could kill the logger by unplugging the cable since they
wouldn't be aware that they stopped it until we found out later
when there was nothing in the file.

	Searching archives dealing with serial communications
produced good information about dialup lines and terminals, but
this is actually less complex.

	Many thanks for any good advice about stty or anything
else that will allow one to use standard devices for this
project.

Martin McCormick WB5AGZ  Stillwater, OK 
Systems Engineer
OSU Information Technology Department Network Operations Group