Re: [vox-tech] Driver Question
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [vox-tech] Driver Question
Ooops, the fiddle thingy was referring to the hack that I threw together,
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
Thanks for the clear thinking
----- Original Message -----
From: "Jeff Newmiller" <firstname.lastname@example.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
> > 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,
> > "leave-me-alone". Since the I/O is async it seems that a push system is
> > 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
> > 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)
> > each pass and tested the flag, if true it accepted the data and reset
> > flag with a write to the file, if false it ignored the data. It works
> > 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
> DCN:<email@example.com> Basics: ##.#. ##.#. Live
> Live: OO#.. Dead: OO#.. Playing
> Research Engineer (Solar/Batteries O.O#. #.O#. with
> /Software/Embedded Controllers) .OO#. .OO#.
> vox-tech mailing list
vox-tech mailing list