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" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> 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:<[EMAIL PROTECTED]> 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 > [EMAIL PROTECTED] > http://lists.lugod.org/mailman/listinfo/vox-tech _______________________________________________ vox-tech mailing list [EMAIL PROTECTED] http://lists.lugod.org/mailman/listinfo/vox-tech
