This is a little off topic, but I don't know where else I can find a
stronger knowledge pool. :-)
I am working on some code that needs to read and write from a serial port
and has to write vast quantities of data ... to the point that the line is
fully saturated or close to it as I can get. I have to read *and* write to
the port. I don't care so much if I drop some data once in a while.
I have been trying to avoid threads in this code to keep things simple and
linear, so I have been using non-blocking IO. However, as I read through
the available serial programming documentation, it is becoming more and more
clear that non-blocking serial IO seems to refer primarily to the read()
operation and the write() operation has different semantics.
What I am finding with my actual code is that the write() operation can
sometimes take a long time, even on a file descriptor that is configured for
non-blocking IO. My main loop runs at 50hz (0.02 seconds per iteration) but
I am seeing some serial port writes that can take 0.2 or 0.3 seconds and
every once in a while the whole thing gets stopped up and my whole write
blocks (including the entire application) until the other end stuffs at
least another character up the pipeline in my direction. This situation is
starting to become unacceptable.
The quick answer I know would be to spawn off a pthread and handling the
serial IO in a separate thread. But I am trying to avoid adding threads to
this code like a person might try to avoid knee replacement surgery.
I know I can use select() to check if the file descriptor is ready for a
write(), but that would still not be a way to determine if the file
descriptor is ready for the size of my particular write() and ensure that my
write() will return in a timely fashion ... it seems like it would still
leave me open for potential trouble or potential unwanted time delays.
Does anyone have any thoughts or suggestions. The programming environment
is linux, the code is actually being developed primarily to run on a gumstix
embedded processor, but of course the more portable, the better.
Thanks,
Curt.
--
Curtis Olson: http://baron.flightgear.org/~curt/
------------------------------------------------------------------------------
Sell apps to millions through the Intel(R) Atom(Tm) Developer Program
Be part of this innovative community and reach millions of netbook users
worldwide. Take advantage of special opportunities to increase revenue and
speed time-to-market. Join now, and jumpstart your future.
http://p.sf.net/sfu/intel-atom-d2d
_______________________________________________
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
