Tony Sivori wrote:
> Roy Schestowitz wrote:
> > NASA robots run Linux too. You can't just remotely reboot some land
> > vehicle that BSoD'ed on Mars...
>
> The rovers currently on Mars do not run Linux. They run VxWorks. I believe
> that at least some the support software back on Earth runs on Linux.
This is correct. VxWorks is a real-time UNIX based on BSD with some
VRTX style technology built in. Many of the same principles are also
used in embedded Linux, however it is different technology.
The fundamental differences between traditional Linux/UNIX and
Real-time Linux/Unix is that there are priorities and queues dedicated
to providing nearly instant response to specific events. The classic
scenario is something like a car engine. In the engine, the timing is
critical. Fuel must be let in at exactly the right time, mixed with
just the right amount of air, and then the spark plug must be fired at
the best possible moment, and then the exhaust has to be released at
exactly the right moment. If you wanted to replace the cam shaft, and
distributor coil and put all of these components under
computer/solenoid control, you would have to make sure that the timing
was almost exact.
The key element is not the speed of the computer or OS, but the ability
to respond to an external event within a predictable period of time.
For example, if you have a sensor that detects the timing point on the
flywheel, you know at exactly what points the spark needs to be fired
based on temperature, air pressure, current speed, and desired speed.
Based on this combination of inputs, the computer can determine the
best time to inject fuel, the best time to fire the spark, and the best
setting for the exhaust and PCV system.
All of these calculations could be done in a few microseconds, so the
computer is fast enough. The problem is that this all needs to be
translated into the exact correct actions being triggered at exactly
the right time. The computer chip can set timers, or use other sensors
(such as the timing rotor on the distributor cap), but the timing has
to be predictable, relative to the event.
In a general purpose Linux or Unix system, the design is to make sure
that every process gets some execution time, because there might be too
many processes running, or too many processes that are not
relinquishing control. Too many high priority processes can cause the
other proceses to become "starved".
In a Real-Time system, the event is recorded as quickly as possible,
queued into a separate mail-box or queue, and control is given to the
thread or process at the head of the queue. The key is that these "top
priority" processes are usually very quick, and usually only need to
fire an event or command and will reqinquish control almost immediatly.
As a result, there is a very small and predictable range of delay
between the incoming event and the outgoing event. Worst case, their
might be 3-4 items in this high priority queue, and each one might only
take less than a hundred nanoseconds, or a microsecond. The key is
that it's a predictable delay. Relative to the possible range of
response times, the minimum and maximum response time are known and
predictable based on predictable events.
Going back to our computerized car engine, we know how many cylinders
are in the car, the minimum and maximum RPM of the engine, and, based
on this, the maximum number of input events which will need to be
"pending", and how long each message handler takes to respond.
By combining finite state machines with alarm clocks and event
monitors, you have a predictable "what happens next" and "when"
regardless of what else the computer might be doing. Lower priority
tasks such as displays on the dashboard, directions, or navigational
aids, would be secondary tasks that are not time critical.
http://en.wikipedia.org/wiki/VxWorks
http://www.windriver.com/vxworks/
Keep in mind that there are real-time Linux systems as well, several of
the embedded Linux systems have a real-time option. When the option is
set, anything run with "nice -20" the priority is always immediate.
The main reason this is an option is to make sure that someone doesn't
run a compute intensive process with nice -20 and lock up the entire
system.
This is information about a number of real-time operating systems.
http://www.onesmartclick.com/rtos/rtos.html
> --
> Tony Sivori
|
|
