On Wed, May 17, 2000 at 07:28:32AM -0700, Tom Glass wrote:
> What kind of time resolution are you needing? I have an application
> that monitors one serial port for incoming messages in an infinite
> loop. For some of the messages I initiate a child process that
> communicates with a robot, voltmeter, and other hardware on two other
> serial ports. The parent process is then free to continue monitoring
> the first port and is able to terminate the child process, if needed.
> My time resolution (including reading in and testing messages that can
> be hundreds of bytes long) is about 1/2 to 1 second. Probably I could
> do better, but this meets my need nicely.
The serial ports I control need to look like DCE equipment i.e. like
a modem. The device attached to the port drops DTR for 50ms or so to
initiate a reset. I need to be able to spot that. The net result is
that I sit in a pretty tight loop which does
while (1) {
select with very small timeout on fd's that interest me
ioctl to see if control lines have changed
}
and that chomps lots of cpu on the box (which is dedicated to this task
but will have at least about 10 serial ports on which this needs to
happen) hence my requirement for something prettier.
The reason why it's not a total train smash if I miss the event is that
the device connected to me will bounce the lines again if it fails to
see a reset response from me i.e. no RT linux necessary.
There isn't going to be any serious disk i/o or anything else happening
on the box so to a large degree I expect things will work with a polling
model.
> Personally, I think the fork solution is a pretty elegant way to handle
> my problem and having had some experience with threads in windows makes
> me very grateful to be working with processes in Linux.
The fork isn't too bad but if I could have monitored the serial fd for
exceptional events say and had that return when the control lines
toggled it would have been pretty cool ...
Cheers,
--Craig
-
To unsubscribe from this list: send the line "unsubscribe linux-serial" in
the body of a message to [EMAIL PROTECTED]
