mitron3.02.txt

rtai-3.1-test3的源代码(Real-Time Application Interface )

Computers built around a microprocessor, called microcomputers, are making in-
roads into new computer applications, replacing various control equipment, by
virtue of their being small and inexpensive.  For example, they are
increasingly being used to replace all kinds of control devices, in other
words, it has become possible for a small computer to replace control devices
formerly made up of relays, mechanical parts and analog circuits.
Specifically, many products from telephone switching devices, industrial robots
and NC machine tools, to home appliances such as air conditioners, washers and
televisions use microcomputer control.

The microcomputers used as control devices are not intended to be used inside
of standard computers such as mainframes, personal computers or workstations.
The control computers are characterized by their use as a single part in a
larger system.  For this reason they are called "embedded computer systems",
or "embedded systems" in short.

In general, embedded systems have the ability to detect various external
stimuli or changes in the environment using sensors and then initiate an
operation in response, or to initiate periodic operations so as to affect the
outside environment.  An air conditioner, for example, uses sensors to detect
external temperature and humidity and controls its output level and wind
direction in response.  Embedded system programs must perform their control
by following time-varying changes in the external environment without delay.
It is this point that makes them essentially different from typical data
processing programs.

In order to increase the productivity of embedded system programs and
reduce the manufacturing cycle required, the programs themselves are not
written directly using processor instructions, but rather are written using a
shared management program, or OS.  Application programs written for a given
system are then placed on top of this OS.  The OS itself differs from
operating systems of the type used in a general-purpose computers.  The main
purpose of these operating systems is protection among users and file system
management, whereas embedded operating systems are designed to make it easier
to program applications using concurrent processing and interrupts for
synchronization with external events.

In general, computers, and the programs which run on them, are sequential in
nature.  They cannot do two things at once.  Embedded systems on the other
hand are often required to monitor the outputs from sensors concurrently.
If there are two sensors requiring monitoring, it is intuitive for the
program to be divided into two parts.  These parts can be thought of as
running concurrently, thus making the task of programming simpler.  The
approach that arose from this type of application is the basis of the concept
of multitasking.  All processing is divided into separate tasks each of which
are parallel in flow.  Programs can be produced more quickly and made easier
to understand when divided into tasks in this way.  Of course, a processor
alone is left only with the ability to execute instructions sequentially, so
multitasking is implemented through time-sharing at the OS level.  The OS
having the multitasking capability is called multitasking OS, which is very
useful for embedded systems.

The operating systems used in general-purpose computers are also multitasking
in the sense that they execute multiple jobs (processes, tasks) based on time-
sharing.  In the case of general-purpose computers, however, jobs (processes,
tasks) are highly likely to be unrelated to each other.  In the sense that one
person may be using the computer for document processing, while another is
using it for compiling a program, and yet another is using a text editor, the
computer is in fact multitasking.  But each user is only interested in the job
(program) he or she is executing.  They are not in the least concerned with
what kind of concurrent processing may be going.  In this case, the reason for
using multitasking is mainly for improved cost performance.  In short, even
though it would be ideal for each user to have his or her own computer, it is
necessary for them to share a single computer because there aren't enough to
go around.  The result is multitasking.

In embedded systems, on the other hand, a job having a single purpose is
divided into multiple tasks to make the program easier to write.  Furthermore,
these tasks do not just run in total isolation, but rather have a very
complicated relationship with each other.  In the case of an embedded system,
the operation of any given task and its mutual relationship to other tasks is
controlled by the designer of the overall system, and each of the individual
tasks cooperate to achieve a single goal.  In this sense, the multitasking
used in a general-purpose computer is quite different from that used in an
embedded system.

Another important point about operating systems used in embedded systems is
that they operate in real time.  In abstract terms, real-time operation means
that the computer processing follows changes in external states.  Specifically,
the time required for the output of results is constrained.  In simplest terms,
worst-case response time is predictable.

With conventional computers which use batch or time-sharing processing, the
user waits for the computer.  In this case, the fact that the computer is
computing is a goal in itself, and the computer is unrelated to any other
systems.  Accordingly, no matter how long processing takes, everything will
come out all right in most cases as long as the user waits.  True, the faster
the processing, the better; however, there will be no fatal effects even if it
takes a long time.

In the case of embedded systems, on the other hand, computation itself is not
the goal.  The goal is controlling other equipment based on the results of
computation.  The demand for fast processing is high.  If processing is
delayed, results may be meaningless by the time they are available.  Take the
safety control equipment of a train for example.  If the brakes are not applied
within a set amount of time when something wrong is detected, an accident will
result.  Or, let's say the spark plug timing of an automobile engine is
controlled by an embedded system.  Results must be output before engine
rotation reaches a certain point or the calculation will be useless.  In other
words, it is not only important what happens to the results of processing, when
they are obtained is also important.  Outputting late results is the same as
not outputting any results at all.

In order to meet the strict demands on processing times, the computer must
wait for stimulus from the external environment.  This means the time the
computer is in operation is reduced.  In other words the computer is being
used relatively seldom.  This extravagant use of computers has only become
possible recently, thanks to the popularity of general-purpose computer
helping to reduce prices.  And that is the reason real-time, embedded
computers are a relatively recent application of computer technology.

During programming, one may refer to the algorithm, data structure, or the
efficiency of execution or the amount of calculations, but the absolute
execution time required is rarely discussed.  But in applications intended for
embedded systems, it is often critical to know ahead of time the amount of
execution time required by a program.  And this does not just refer to the CPU
time required by each program (job, process, task).  It is necessary to
estimate the absolute execution time required including the overall load on
the system down to the execution status of other tasks.  This is an extremely
difficult thing to do, and is just plain impossible under a complex OS like
those used in large machines, because unless the OS itself is fairly simple,
it will be impossible to accurately estimate OS overhead.

Operating systems used in embedded systems are greatly different from
operating systems used for typical data processing or those used for software
development.  An OS intended for an embedded system must be capable of both
multitasking and real-time operation.

****************************************************************************
***    1.4 History of ITRON Specification and Planned Future Developments **
****************************************************************************

ITRON (Industrial - The Real-time Operating system Nucleus) is a real-time,
multitasking OS specification intended for use in industrial embedded systems.

Work on the ITRON specification began in 1984 with the start of the TRON
Project, and the first specification was released in 1987.  That specification
is called the ITRON1 specification.  As an OS specification standardized
mainly for 16-bit microprocessors, ITRON1 specification was standardized for
the major 16-bit microprocessors of that time.  Several operating systems
have been implemented based on the ITRON1 specification.  These operating
systems made invaluable contributions to the evaluations of the ITRON
specification.

After this, work was conducted on the uITRON specification (Ver. 2.0), for use
mainly on smaller 8-bit MCUs, and the ITRON2 specification, for use on higher
performance 32-bit microprocessors.  Both specifications were made public in
1989.  uITRON specification is a highly condensed version of ITRON
specification.  System calls are divided into five levels depending on
their importance.  uITRON specification operating systems have been
implemented not only on 8-bit microcontrollers (MCUs), but also on 16 and
32-bit microprocessors.  There have been over 20 implementation examples of
uITRON-based operating systems running on a variety of processors being
reported.  The ITRON2 specification, which is based on ITRON1 specification,
with many high level functions added, has mainly been implemented on TRON-
specification microprocessors.

In parallel with the above work on OS specifications, work has progressed on
the standardization of external I/O used in conjunction with ITRON operating
systems.  The ITRON/FILE specification, a specification for a file management
system under ITRON and uITRON specification kernel, was released in 1992.

uITRON 3.0 specification is a version upgrade of the uITRON specification
based on user feedback and experience in implementing ITRON1, ITRON2 and
uITRON (Ver. 2.0) specification OS.  The ITRON2 and uITRON specifications
have been unified by adding object creation/deletion functions and some of
the extended features of ITRON2 specification to uITRON specification.
Support for distributed systems has also been made available by
adding functions for the loosely-coupled networking of ITRON specification
computers.  Distributed systems supported under uITRON 3.0 specification
have the restriction that node configuration does not change dynamically.

As the future perspective for the ITRON specification, work is progressing on
the ITRON-MP specification for application in tightly-coupled multiprocessor
systems.  There are also plans to develop an IMTRON specification which will
allow operation even in an environment where the node configuration of a
distributed system does change dynamically.

In the rest of this document, "uITRON (Ver. 2.0)" will be written as
"uITRON 2.0".


1st        : 2nd Generation  :   3rd Generation
Generation :                 :
           :                 :                                    ==========
           :                 :                                    |        |
           :                 :    ==============   ============   |        |
           :     ==========  :    |            |   |          |   |        |
           : +-->| ITRON2 |------>|            |-->| ITRON-MP |-->|        |
           : |   |  Spec. |  :    |            |   |   Spec.  |   |        |
========== : |   \--------+  :    |            |   |          |   | IMTRON |
| ITRON1 |---+ Intended for  :    | uITRON 3.0 |   \----------+   |  Spec. |
|  Spec. |---+ 32-bit MPUs   :    |    Spec.   |                  |        |
\--------+ : | such as TRON- :    |            |                  |        |
Intended   : | specification : +->|            |----------------->|        |
for        : | microprocessors |  |            |                  |        |
general-   : |               : |  |            |                  |        |
purpose    : |   ==========  : |  \------------+                  \--------+
16-bit MPUs: +-->| uITRON |----+
           :     |(Ver2.0)|  :
           :     |  Spec. |  :
           :     \--------+  :
           : Intended for    :
           : small scale,    :
           : single-chip     :
           : microcomputer   :
           : based systems   :
           :                 :

               Figure 1 Development of the ITRON Specification

****************************************************************************
***    1.5 Features of ITRON Specification                               ***
****************************************************************************

One of the main features of ITRON specification operating systems is the fact
that although implementation on various types of processors is possible, no
more standardization or virtualization than necessary are made so that higher
processing performance may be achieved.  Another main feature is that although
the operating systems provide many functions, thought has been given to
adaptability such that actual object code can be made very compact.

From the standpoint of software compatibility and ease of learning, it is
desirable to virtualize microprocessor architectures as much as possible and
provide a high level of standardization, but this has the negative impact of
decreasing basic performance.  And although it may be desirable for an OS to
include lots of functions from the standpoint of making programming easier and
raising the performance of certain types of applications, there is again a
negative impact in that object code size grows too large.  In designing an OS,
these two considerations must be kept in balance.  One solution to this