[vox-tech] Driver Question

[Jeff Newmiller]

On Mon, 15 Sep 2003, John Wojnaroski wrote:

> Would not the select() stop the application, forcing it to wait for the
> data?

Yes.  You can also set a zero timeout, though, to get immediate results.

> The application (real time simulation) cannot block or run timeouts or spend
> any time testing to see if data is available.

Perhaps we have different definitions of "real-time"... wouldn't be the
first time those wires got crossed.  Userspace in Linux is NOT what I
think of as real-time.

> The only time it wants to be bothered is when data is available, otherwise
> "leave-me-alone". Since the I/O is async it seems that a push system is more
> advantagous...

It is not clear to me what the primary inputs and outputs for this
simulation are... since you said the driver was autonomously handling most
of the I/O, I assumed the realtime portion of the code was in the driver
(including generation of output signals). In such a case, the userspace
portion would simply be used to provide logging and/or on-the-fly
visibility into the simulation progress, and blocking on such data would
make perfect sense.

Userspace is fine for taking a snapshot of realtime and munging it onto a
a screen or out a network port, but not so good for supplying data to an
A/D card to create the illusion of a physical process signal (voltage
proportional to spring position, for example).

Some simulations use keyboard and screen for their primary I/O... the most
well-known of these simulations are first-person-shoot'em'up games.  Such
simulations can afford to slip a little now and then... that is, not
hitting the specified frame rate simply results in degraded performance
that may or may not be noticeable in the intended application, so
userspace simulation is perfectly acceptable, and poll or select can be an
effective way to obtain input.

However, at some level, your application will be interested in learning
what the status of those inputs are that you are considering signalling.  
It might seem that the quickest way to do that is to simply check an
internal variable that is updated via a signal.  However, you are living a
bit on borrowed time, because when the signal comes along the application
will be stopped for quite a few clock cycles... I would guess easily three
times the clock cycles as the cost of a poll() call would take.  Thus, you
are setting yourself up for fast execution most of the time, with an
occasional hiccup in your simulation speed.  Simply calling poll() every
time with a zero timeout could yield a more predictable simulation loop
execution time.  However, I don't know enough about your application to
say whether average speed or worst-case speed is most important to you.

> Granted signals are more complicated, but they might be necessary in some
> cases. I fiddled with a very non-elegant approach where the driver set a
> flag in the data file and the application read the file (about 64 chars) on
> each pass and tested the flag, if true it accepted the data and reset the
> flag with a write to the file, if false it ignored the data. It works but
> waste CPU resources big time...

You may simply be polling too often.  Also, if there is no change in
input, then there is no need to actually transmit data... the application
can more easily check lack of data than transfer useless data (though
there is that execution time predictability problem again).

> You spend all the effort to design a Ferrari (the interrupt driver and
> board) and then install a VW engine(the fiddle thingy) to make it run ;-)

I don't understand "fiddle thingy".  If you are suggesting that poll() or
signal() are kludgy, then you may not have an appropriate perspective on
userspace programming. Neither of them is intended to provide a real-time
interface to interrupts... that is kernelspace work, or "realtime
task" work as defined by some realtime extension to Linux.  Userspace is
"processing power as available", rather than "processing power on
demand", and blocking on input is ideal for that kind of resource.

---------------------------------------------------------------------------
Jeff Newmiller                        The     .....       .....  Go Live...
DCN:<jdnewmil@dcn.davis.ca.us>        Basics: ##.#.       ##.#.  Live Go...
                                      Live:   OO#.. Dead: OO#..  Playing
Research Engineer (Solar/Batteries            O.O#.       #.O#.  with
/Software/Embedded Controllers)               .OO#.       .OO#.  rocks...2k
---------------------------------------------------------------------------