mitron3.02.txt

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

tradeoff is ITRON specification.  The basic concept of "loose" standardization
which underlies the entire TRON Project can be said to have been concretely
realized in the field of real-time operating systems.

Features of ITRON specification are brought together below.


  - Processor architecture is not virtualized.
        ITRON specification is intended for OS implementation on many
        different processors. However, specific implementation and design is
        carried out independently for each processor.

        The first thing that comes to mind when creating a standard OS is to
        assume the common virtual architecture and then design the ITRON
        specification on that architecture.  With this approach,
        consequently, the gap between the native architecture of the processor
        and the virtualized architecture is directly tied to reduced
        performance.  Architecture which takes full advantage of processor is
        required to maximize performance of the real-time OS.  The
        virtualization in the machine or OS must be kept to a minimum.
        Furthermore, the need for object code compatibility in the case of
        embedded systems is relatively low.  On the other hand, the need for
        compatibility in terms of uniformity of naming of system calls or
        their function is very important from a learning standpoint.  We
        therefore investigated which OS specifications should and should not
        be standardized under ITRON specification.  We clearly isolated
        specifications which were common to all processors and those which
        were processor-dependent. Specifications which were difficult to
        standardize were left alone, so as to prevent loss in performance
        due to excessive standardization and processor virtualization.

  - ITRON specification provides many functions.
        ITRON specification provides many system calls possessing various
        useful functions.  For example, ITRON specification provides almost
        every synchronization mechanism imaginable: eventflags, semaphores,
        and mechanisms accompanying individual tasks (the system calls slp_tsk
        and wup_tsk).  This allows for the selection of the mechanism best
        suited to the application and should lead to better performance and
        greater ease in programming.

  - High-speed response is possible.
        What can really affect response times in a real-time application are
        the part that handles task switching (dispatching) and the part that
        invokes the interrupt handler.  As discussed later in conjunction with
        its adaptability, ITRON specification allows registers to be swapped
        out at dispatch time to be specified to achieve high-speed dispatching.
        Furthermore, it is possible to cause a user-defined interrupt handler
        to run any time an external interrupt occurs, without having to go
        through the OS.  The overhead required here is practically zero.
        However, any registers used by the interrupt handler must be saved by
        the user.

  - ITRON specification has built-in adaptability.
        ITRON specification, an OS architecture, has been designed as a highly
        flexible and adaptable architecture with application in embedded
        systems specifically in mind.  The high level of freedom provided to
        the user through choices such as system call selection, specification
        of registers to be swapped out during dispatching, a low power
        consumption mode when there are no running or ready tasks, and the
        ability to turn off error checking that is done in each system call
        for a highly flexible and adaptable OS.

        For example, let's say there is a parameter which defines a memory
        address.  The overhead in executing a system call is fairly high if
        the software has to check whether a memory-related error such as a
        segmentation error or bus error may occur.  On the other hand, there
        is no reason to expect the parameter to cause an error if the
        parameter specifying the memory address is static and the program has
        been written correctly.

        The best policy under these conditions is to make a thorough error
        checking even with the penalty of some overhead during debugging, and
        then remove all error checking once debugging is complete.  This is
        made possible under the architecture of ITRON specification where
        there is provided a very high degree of freedom in error check on/off.

  - Runs on many hardware platforms.
        There is a series of ITRON specification operating systems operating
        on many hardware platforms from 8-bit MCUs to 32-bit high-performance
        microprocessors.  While it is true that object compatibility of all
        programs is not possible given different CPU sizes and bit widths,
        the fact that a family of ITRON specification operating systems can be
        implemented on various processors is very advantageous in improving
        efficiency by allowing a standardized development process and
        uniformity in learning.

        Furthermore, uITRON 3.0 specification has new functions (connection
        functions) for distributed systems connected with a loosely-coupled
        network.  Even simple serial lines may be used to implement these
        communication functions.  Consideration has been given not just to
        the CPU, but to the entire network and peripheral devices for support
        of hardware of any scale.

        Being able to run on many hardware platforms makes the system highly
        applicable from the standpoint of costs.  On the low-end, the uITRON
        specification may even be used as a very inexpensive control system
        embedded in an electrical appliance.  On the high-end, the ITRON-MP
        specification may be used in a high-performance, tightly-coupled
        multiprocessor system.

  - Serious consideration has been given to ease of learning.
        One aspect of the design concept of ITRON specification is that
        serious consideration has been given to learning process because
        uniformity in its learning is considered one of the important assets
        of a system.

        System call names and functions of ITRON specification are
        systematically defined according to uniform naming conventions which
        make them easy to remember.  All system calls of ITRON specification
        are seven or eight characters long and of the form 'xxx_yyy' or
        'zxxx_yyy' respectively, where 'xxx' represents the method of
        operation, and 'yyy' the object of the operation (Figure 2).  The 'z'
        used in eight-letter system calls represents system calls which are
        derived from the seven-letter system calls excluding 'z'.  Table 1
        shows the specific abbreviations and what they stand for in xxx, yyy
        and z forms.

        Since ITRON specification operating systems run on more than one type
        of processor, learning process in understanding the operating system
        can be made consistent even if more than one type of processor are
        used.  This is a great advantage when it comes to actual program
        development.



         +---------+---------+---------+
         | cre_tsk | del_tsk | sus_tsk | <------ Task
         +---------+---------+---------+
         | cre_sem | del_sem | sig_sem | <------ Semaphore
         +---------+---------+---------+
         | cre_flg | del_flg | set_flg | <------ Eventflag
         +---------+---------+---------+
              ^         ^         ^
              |         |         |
         Creation  Deletion  Other Operations

 Note: System call names of ITRON specification follow the form 'xxx_yyy',
       where 'xxx' is a three-letter abbreviation representing the type of
       operation, and 'yyy' is a three-letter abbreviation representing the
       type of object on which the operation is to be performed.

        Figure 2 System Call Naming Conventions in ITRON Specification


 Table 1  Abbreviations Used in Naming Conventions of ITRON Specification

 +-----------------------------------+--------------------------------+
 |   xxx (operation) Abbreviations   |           Description          |
 +-----------------------------------+--------------------------------+
 |                cre                | Create                         |
 |                del                | Delete                         |
 |                ref                | Refer                          |
 |                def                | Define                         |
 |                ret                | Return                         |
 |                dis                | Disable                        |
 |                ena                | Enable                         |
 |                get                | Get                            |
 |                set                | Set                            |
 |                snd                | Send                           |
 |                rcv                | Receive                        |
 |                can                | Cancel                         |
 |                rel                | Release                        |
 |                wup                | Wakeup (also used in yyy form) |
 |                wai                | Wait (also used in yyy form)   |
 |                chg                | Change                         |
 +-----------------------------------+--------------------------------+


 +-----------------------------------+--------------------------------+
 |    yyy (object) Abbreviations     |           Description          |
 +-----------------------------------+--------------------------------+
 |                tsk                | Task                           |
 |                flg                | Eventflag                      |
 |                sem                | Semaphore                      |
 |                mbx                | Mailbox                        |
 |                mbf                | MessageBuffer                  |
 |                por                | Port                           |
 |                mpl                | MemoryPool                     |
 |                mpf                | Fixed-size MemoryPool          |
 +-----------------------------------+--------------------------------+
 |                int                | Interrupt, Interrupt Handler   |
 |                cyc                | Cyclic Handler                 |
 |                alm                | Alarm Handler                  |
 +-----------------------------------+--------------------------------+
 |                msg                | Message                        |
 |                rdv                | Rendezvous                     |
 |                blk                | Memory Block                   |
 |                blf                | Fixed-size Memory Block        |
 |                tim                | Time                           |
 |                dsp                | Dispatch                       |
 |                cpu                | CPU                            |
 |                dat                | Data                           |
 |                ver                | Version Information            |
 +-----------------------------------+--------------------------------+

 +-----------------------------------+--------------------------------+
 | z (derivation type) Abbreviations |           Description          |
 +-----------------------------------+--------------------------------+
 |                t                  | with Timeout                   |
 |                p                  | Poll                           |
 |                f                  | Force                          |
 |                n                  | Node, coNNection, Network      |
 |                i                  | task Independent, Interrupt    |
 +-----------------------------------+--------------------------------+

****************************************************************************
***    1.6 The Basic ITRON Concept                                       ***
****************************************************************************

***  Tasks *****************************************************************

Under ITRON specification the term "task" refers to a unit of concurrent
processing.  While programs inside a single task are executed sequentially,
programs of different tasks are executed concurrently.  However, this refers
to the way an application programmer (or OS user) looks at things.  At the
physical level, tasks are actually executed under the control of the OS using
time sharing.

The task being executed by the processor is switched by the issue of a
system call or interrupt which causes the task's state to change.  The act of
switching the task being executed by the processor is called "dispatching".
The mechanism in the OS which executes this is called the "dispatcher".

When there is more than one executable task, it is necessary to determine
order of task execution using some sort of algorithm.  The OS act of
controlling the order of task execution is called "task scheduling".  ITRON
specification uses priority-based scheduling based on a priority level
assigned to each task. The smaller the priority value, the higher the priori