There should also be made a distinction between real time input and real
time output and servo loop. If you are capturing timing events you really
only need to respond to an event and store a time for later processing. I
usually use a microcontroller and write a routine around its interrupts so
that it can respond easily down to microseconds and give good resolution
(this has been mainly for medical projects that are not particularly high
frequency). So you have the interrupts running code real time, and the
normal loop crunching the numbers and providing output.
Real time output can be set up very much like above, where the internal
counter triggers the interrupt which outputs a value. Say you want to
output a particular current at a particular time.
Servo is much harder because it must respond to an input, and process it to
give an output, at a defined frequency response. This is usually
demonstrated with the "balancing hammer" where the servo balances a hammer
on its end. There are systems that achieve this even if the hammer has a
jointed hinge in the middle. I have even heard of it being done where there
are two joints. This is a bit like trying to reverse a 3 bogey semi-trailer
up a country lane at freeway speed.
When you see Windows attempt the hammer demo you can see that every
keyboard press or mouse movement causes instability, and opening a browser
can make the hammer fall over. Often a simple microcontroller can beat even
a really fast powerful computer, mainly because you can use the interrupts
which I have found are almost impossible to "get at" in computers.
> "Real time" simply means "guaranteed to respond to an external event
> within a specified period". What time period is required?
>
> >> But on modern hardware, "other time-critical programs that will carve
> >> out slices of CPU time" are likely a "Who cares?" issue. Commonly
> >> used hardware is orders of magnitude faster than the machines DOS was
> >> made to run on, and there are cases like games where you might
> >> specifically *want* to steal CPU slices, because otherwise your game
> >> runs *too* fast and is unplayable. .
> >>
> > I have had to do this once, when writing an assembly code driver for a
> > digital rotation encoder. The read cycle had to be slowed down by a
> > specified number of NOPs to allow the register to load. The problem is
> > that when a program is monitoring response devices such as the mouse and
> > keyboard and presenting an animated display to the user, even a
> > millisecond lost to some other program is a disaster. As I can often see
> > the system "blink" on modern PCs running Windows and even Linux, I'm
> > reasonably certain that I can't trust them to be accurately recording
> > reaction times. One of my colleagues thought that she had solved the
> > problem by buying an expensive test battery until I showed her the
> > "uncertainty" factor that came with every response recorded.
>
> How accurately do you *need* to be recording reaction times?
>
> For that use case, I'm not sure I'd try to run DOS on top of Linux,
> even with a Linux version modified for RTOS usage.
>
> The best option might be custom monitoring software running directory
> on the RTOS, without DOS in the loop.
>
>
------------------------------------------------------------------------------
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. ON SALE this month only -- learn more at:
http://p.sf.net/sfu/learnmore_122712
_______________________________________________
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user
