Serial Polling - Opinions?
Mark Turner
markt at tse.uucp
Wed Jun 26 00:09:18 AEST 1991
Hi folks. Can anyone out there suggest alternatives to the following
implementation of a RS-232 serial polling program (explained below)? I'm
mainly interested in the types of solutions that others have found for this
problem. I've listed several areas of concern following the explanation.
Currently, I'm working on a small program that reads a data feed from an
RS-232 serial port. The application consists of several processes, the first of
which reads data from the port and throws the raw data into a circular buffer
stored in shared memory (I'll call this the READER process). A second process
reads the data from the buffer (the PROCESSOR process) and constructs messages
to send to a SERVER process that is responsible for broadcasting to the
appropriate clients.
Notes:
(1) The circular buffer *may* fill, in which case the READER executes the time()
system call in the hope that the PROCESSOR will be scheduled and free up
some room in the buffer. This type of contention has not been a problem
to date.
(2) The PROCESSOR is a simple implementation. It simply uses the open() and
read() calls to get at the ASCII transmission.
(3) The priority of these processes have been bumped up so that the READER
process has the highest priority of any user processes; hopefully, this will
prevent data loss when the system is heavily loaded.
Areas of Concern:
(1) This configuration does not guarantee that data won't be lost on the
incoming line. Yech! Should I be thinking about something like SLIP or
PPP? (I really don't know much about these protocols.) Should I build much
of the READER/PROCESSOR functionality into a custom device driver?
(2) Is there any real advantage in splitting the processing between the
READER and the PROCESSOR? Perhaps they should reside in the same program,
where the program itself arbitrates between the two operations.
(3) The main design considerations are performance and accuracy. (Is that all?!)
If you've dealt with similar problem, or have a suggestion, I'd appreciate the
help. I'm hoping to avoid some of the common glitches that others have already
dealt with in the past.
--------------------------------------------------------------------------------
Regards, Mark Turner (markt at tse.UUCP)
More information about the Comp.unix.programmer
mailing list