[vox-tech] Driver Question

Mon, 15 Sep 2003 20:42:12 -0700

Ooops, the fiddle thingy was referring to the  hack that I threw together,
nothing else.

Right, define the terms, in this case a game simulation (FlightGear) so ,
yes, you can afford some slippage in that FG calculates the slip and adjusts
the delta time(s) so that the EOMs remain valid.

The more I consider your points the simpler the solution becomes. The update
of numeric readouts occurs between the driver and the hardware. Its only
when the operator depresses a switch that a one of four variables is sent to
the simulation. ONce again, falling into that trap of over-designing
something simple.....

Thanks for the clear thinking
John W

----- Original Message -----
From: "Jeff Newmiller" <jdnewmil@dcn.davis.ca.us>
To: <vox-tech@lists.lugod.org>
Sent: Monday, September 15, 2003 3:05 PM
Subject: Re: [vox-tech] Driver Question

> 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
> --------------------------------------------------------------------------
-
>
> _______________________________________________
> vox-tech mailing list
> vox-tech@lists.lugod.org
> http://lists.lugod.org/mailman/listinfo/vox-tech