******************************************************************************

*
ITRON Specification
*
*
microITRON
*
*
Ver. 2.01.00.00
*
*
*
*
Designed by Ken Sakamura
*
*
*
*
Document number: I-01-02E-Ver.2.01.00 (File#1)
*
*
*
*
TRON ASSOCIATION
*
*
5th Floor, Katsuta Bldg., 1-3-39, Mita, Minato-ku, Tokyo 108, JAPAN
*
*
Tel +81-3-3454-3191
*
******************************************************************************
******************************************************************************
*
Copyright (c) 1990,1992 by TRON Association
*
*
*
*
The copyright of this document is reserved by TRON ASSOCIATION.
*
******************************************************************************
******************************************************************************
*
LICENSE AGREEMENT
*
*
*
* Permission to receive, use, and/or reproduce the SPECIFICATIONS which
*
* follow is granted only under the following terms and conditions.
*
* Acceptance of receipt of the SPECIFICATIONS constitutes your agreement *
* with such terms and conditions. If you do not agree with such terms
*
* and conditions, do not retrieve the SPECIFICATIONS.
*
*
*
* SECTION #1 COPYRIGHT AND OTHER PROPRIETARY RIGHTS
*
* 1.1 All copyright and other proprietary rights relating to or in
*
*
connection with the SPECIFICATIONS belong to solely the TRON
*
*
ASSOCIATION.
*
*
*
* SECTION #2 LIMITATION OF REPRODUCTION
*
* 2.1 The SPECIFICATIONS may be reproduced in their entity but any
*
*
reproduction in part is strictly prohibited.
*
*
*
* SECTION #3 COPYRIGHT NOTICES
*
* 3.1 In no event may the copyright notices or the terms and conditions *
*
of this LICENSE AGREEMENT and "Fundamental Concepts Governing the *
*
TRON Project" described on the SPECIFICATIONS be deleted.
*
* 3.2 When you reproduce the SPECIFICATION, in no event may the
*
*
copyright notices or the terms and conditions of this LICENSE
*
*
AGREEMENT and "Fundamental Concepts Governing the TRON Project"
*
*
on any copy of the SPECIFICATIONS be deleted.
*
*
*
* SECTION #4 RESTRICTION OF MODIFICATIONS
*
* 4.1 Any modification of the SPECIFICATIONS is strictly prohibited.
*
*
*
* SECTION #5 RESTRICTION OF REDISTRIBUTION
*
* 5.1 Redistributing the SPECIFICATIONS upon receipt of payment of
*
*
consideration therefor without written consent from the TRON
*
*
ASSOCIATION prior to such distribution is strictly prohibited.
*
*
*
* SECTION #6 NO WARRANTIES
*
*
*
* 6.1 The TRON ASSOCIATION disclaims all warranties with regards to the *
*
SPECIFICATIONS, including all implied warranties of
*
*
merchantability and fitness.
*

* 6.2 In no event shall the TRON ASSOCIATION be liable for any special, *
*
indirect or consequential damage or any damages or disputes
*
*
whatsoever arising out of or in connection with the use of the
*
*
SPECIFICATIONS.
*
******************************************************************************
******************************************************************************
*
Fundamental Concepts Governing the TRON Project
*
*
*
* 1. The computer architecture TRON originated by Dr.Ken Sakamura is an
*
*
open computer architecture. The TRON Specifications are made publicly *
*
available to anyone in the world.
*
*
*
* 2. Copyrights to the TRON Specifications belong to the TRON Association. *
*
Anyone is entitled to utilize the TRON Specifications in developing
*
*
and merchandizing products conforming to the TRON Specifications.
*
*
*
* 3. The TRON Association has been established as the core organization
*
*
for the purpose of preparing the TRON Specification, conducting
*
*
conformance testing, and otherwise promoting the TRON Project.
*
*
Membership in the TRON Association is open to anyone in the world who *
*
shares in the objectives of the TRON Project and agrees to observe
*
*
the TRON Association's rules.
*
*
*
*
The TRON ASSOCIATION
*
******************************************************************************
The contents of this document may be revised without prior notice.
Although the contents in this document have been carefully reviewed and is
believed to be reliable, TRON ASSOCIATION is not assuring its contents nor
assuming any liability of problems caused by this document.
TRON
BTRON
CTRON
ITRON
MTRON

is
is
is
is
is

an
an
an
an
an

abbreviation
abbreviation
abbreviation
abbreviation
abbreviation

of
of
of
of
of

The Real-time Operating system Nucleus.

Business TRON.
Communication and Central TRON.
Industrial TRON.
Macro TRON.

****************************
* Structure of This Manual *
****************************
This manual explains uITRON specification which is the revised version of the
ITRON specification realtime operating system for microprocessors.
This manual is structured as follows:
1. Realtime Operating System and ITRON Specification overviews the necessity
for a realtime operating system and ITRON specification, and describes
ITRON1 specification, uITRON specification, and ITRON2 specification, and
their relationships.
2. uITRON Specification explains the concept of uITRON specification design,
the relationship between ITRON1 specification and uITRON specification,
and the syntax of system call specifications in later chapters.
3. System Call explains the uITRON specification system calls.
4. Programming Interface explains the system call interfaces recommended for
the uITRON specification, specifically, the function codes, error codes,

and C language interfaces.

Note: uITRON means microITRON.
************
* Contents *
************
-----File#1
-----Chapter 1 Realtime Operating System and ITRON Specification
1.1 TRON Project and ITRON Specification
1.2 Basic Philosophy of ITRON Specification
1.2.1 Multitasking and realtime operating systems
1.2.2 Advantages of ITRON specification
1.2.3 ITRON specification series
1.3 Functions
1.3.1 Basic concepts
1.3.1.1 Tasks
1.3.1.2 Resources
1.3.1.3 Task states and operation
1.3.1.4 Task scheduling
1.3.1.5 System status during non-task portion execution
1.3.1.6 Task-independent portion and quasi-task portion
1.3.1.7 ID (identification) numbers and access keys
1.3.1.8 Standardization policies and compatibility
in ITRON specification
1.3.2 System call interfaces
1.3.2.1 Interfaces with assembly language
1.3.2.2 Interfaces with C language
1.4 uITRON and ITRON2 Specifications
1.4.1 Overview of uITRON specification
1.4.1.1 Basic philosophy of uITRON specification
1.4.1.2 uITRON specification design
1.4.1.3 uITRON specification OS requirements
1.4.2 Overview of ITRON2 specification
1.4.2.1 Basic philosophy of ITRON2 specification
1.4.2.2 ITRON2 specification design
Chapter 2 uITRON Specification
2.1 Design Concept
2.2 uITRON Specification Design
2.2.1 Task states
2.2.2 Functions that form subsets
2.2.3 System call interfaces
2.3 Standardization Philosophy in uITRON Specification
2.4 Scope of uITRON Specification
2.5 Functions Added to uITRON Specification
2.6 System Call Specification Syntax
-----File#2
-----Chapter 3 System Call
3.1 Task Management Functions
3.2 Task-Dependent Synchronization Functions
3.3 Synchronization and Communications Functions

3.4
3.5
3.6
3.7
3.8
3.9

Interrupt Management Functions

Exception Management Functions
Memory Pool Management Functions
Time Management and Timer Handler Functions
System Management Function
uITRON Specification System Call List

Chapter 4 Programming Interface

4.1 Assembler Interfaces
4.1.1 Flag changes after system call execution
4.1.2 Function codes
4.2 C Language Interfaces and Mnemonics
4.2.1 Common principles in assigning mnemonics
4.2.2 Data types and syntax
4.2.3 Common principles of C language interfaces
4.2.4 C language interface standard specifications
4.2.5 Constants and packet format
4.3 Error Codes
4.3.1 Error code format
4.3.2 Exception classes
4.3.3 Standard error code specifications
4.3.4 Implementation-dependent error codes
******************************************
* uITRON Specification System Call Index *
******************************************
This index lists all uITRON specification system calls arranged in
alphabetical order.
act_cyc
[4]
alh_sts
[4]
can_wup
[3]
chg_iXX
[2B]
chg_pri
[3]
clr_flg
[3A]
clr_flg
[3B]
cpol_flg [3B]
cwai_flg [3B]
cyh_sts
[4]
def_alm
[#4]
def_cyc
[#4]
def_int
[#1]
def_rst
[#5]
dis_int
[2A]
ena_int
[2A]
ext_tsk
[2]
flg_sts
[4A]
flg_sts
[4B]
frsm_tsk
[4]
get_blk
[4]
get_tid
[3]
get_tim
[2]
get_ver
[1]
ichg_pri [#3]
irel_wai [#5]
irot_rdq [#3]
irsm_tsk [#3]
iset_flg [#3A]
iset_flg [#3B]

Activate cyclic handler

Get alarm handler status
Cancel wakeup task
Change interrupt XXXX
Change task priority
Clear event flag (word)
Clear event flag (bit)
Poll and clear event flag (bit)
Wait and clear event flag (bit)
Get cyclic handler status
Define alarm handler
Define cyclic handler
Define interrupt handler
Define task restart address
Disable interrupt
Enable interrupt
Exit task
Get event flag status (word)
Get event flag status (bit)
Force resume task
Get memory block
Get task ID number
Get time
Get version number
Change task priority (for task-independent portion)
Release wait (for task-independent portion)
Rotate ready queue (for task-independent portion)
Resume task (for task-independent portion)
Set event flag (word) (for task-independent portion)
Set event flag (bit) (for task-independent portion)

isig_sem
isnd_msg
isnd_tmb
isus_tsk
iwup_tsk
iXX_sts
mbx_sts
mpl_sts
pget_blk
pol_flg
pol_flg
prcv_msg
prcv_tmb
preq_sem
rcv_msg
rcv_tmb
rel_blk
rel_wai
ret_int
ret_rst
ret_tmr
ret_wup
rot_rdq
rsm_tsk
sem_sts
set_flg
set_flg
set_tim
sig_sem
slp_tsk
snd_msg
snd_tmb
sta_tsk
sus_tsk
ter_tsk
tmb_sts
tsk_sts
wai_flg
wai_flg
wai_sem
wai_tsk
wup_tsk

[#1]
[#2]
[#5]
[#3]
[#1]
[3B]
[4]
[4]
[3]
[3A]
[3B]
[2]
[5]
[1]
[2]
[5]
[3]
[5]
[#1]
[5]
[#4]
[3]
[3]
[3]
[4]
[3A]
[3B]
[2]
[1]
[1]
[2]
[5]
[2]
[3]
[3]
[5]
[3]
[3A]
[3B]
[1]
[3]
[1]

Signal semaphore (for task-independent portion)

Send message to mailbox (for task-independent portion)
Send message to task mailbox (for task-independent portion)
Suspend task (for task-independent portion)
Wake up task (for task-independent portion)
Get interrupt XXXX status
Get mailbox status
Get memory pool status
Poll and get memory block
Poll event flag (word)
Poll event flag (bit)
Poll and receive message from mailbox
Poll and receive message from task mailbox
Poll and request semaphore
Receive message from mailbox
Receive message from task mailbox
Release memory block
Release wait
Return from interrupt handler
Return and restart task
Return from timer handler
Return and wakeup task
Rotate ready queue
Resume task
Get semaphore status
Set event flag (word)
Set event flag (bit)
Set time
Signal semaphore
Sleep task
Send message to mailbox
Send message to task mailbox
Start task
Suspend task
Terminate task
Get task mailbox status
Get task status
Wait event flag (word)
Wait event flag (bit)
Wait on semaphore
Wait for wakeup task
Wake up task

******************************************************************************
* Chapter 1
*
* Realtime Operating System and ITRON Specification
*
******************************************************************************
This chapter reviews the necessity for a realtime operating system and the
summary of ITRON specification, and explains ITRON1 specification, uITRON
specification, ITRON2 specification, and their relationships.
****************************************
* 1.1
*
* TRON Project and ITRON Specification *
****************************************
Since microprocessors evolved at the beginning of the 1970s, the accompanying
technology has progressed rapidly and the scope of applications is still
expanding. Microprocessors are being used everywhere and are already

necessities in our daily lives. Their communication capabilities and

distributed processing power will bring us more comfortable lives. It is
predicted that million-gate VLSI chips will appear in the 1990s. With such
state-of-the-art semiconductors, microprocessors will have enough power to
satisfy most every demand.
Existing microprocessors are not yet powerful enough to meet future demands.
They still use out-of-date architectures which have covered up many of the
hardware constraints brought about by the technology in 1970s. These
constraints have distorted many aspects of the current architectures. If
semiconductor technology continues to develop at its present rate, the
increasing gap between hardware and architecture will reveal that only a small
part of potential hardware power is available because of obsolete
architectures. Although requests for wider coverage coming from application
fields and improved semiconductor technology will force improvements in the
current architectures, no architecture will be able to satisfy the demands
completely if innovation is not implemented in the current architecture.
To respond to the predicted VLSI technology and the spreading desires for
more sophisticated applications, the TRON project is providing a new
microprocessor architecture which can cover the wide range of needs that will
be required in the 1990s.
The TRON project was started in June 1984 to provide a new architecture to
cover wide areas of computer-related technologies, ranging from microprocessor
hardware to application programs. The goal of the project is to meet future
demands for microprocessor applications based on the predictions and
perspectives of VLSI technology in the 1990s, getting free from the
limitations of old architectures. The new architecture is realtime-, VLSI-,
and distributed processing-oriented in order to be a standard architecture of
the 1990s.
The following paragraphs summarize the philosophy of the TRON project:
- The architecture design must meet the technology levels in the 1990s.
Current microprocessor architecture is still restrained by compatibility
with 8-bit microprocessor architecture, sacrificing the benefits of
advanced VLSI technology. Ad-hoc architectures distorted to meet the VLSI
technology waste the potential performance of VLSI microprocessors.
The TRON project sets the goal at a VLSI-based design, freed from current
limitations.
- Realtime processing is essential.
As can be seen in batch or TSS processing, the way of using conventional
computers was for humans to wait for computers. In the future, however,
many computers will be used to control and interface with the external
environment, including natural phenomena, and to make life more
comfortable. This means that computers will wait for humans (or for
stimuli from the external environment). This environment must be treated
as realtime processing by nature. Realtime response is essential in
distributed processing and communications applications. For realtime
processing to obtain the same processing power as other processing,
however, higher performance computers are necessary because the computer
use ratio significantly drops in realtime processing. The TRON project
considers realtime capability essential and requests all designs to take
this into account.
- The goal is to produce the ultimate von Neumann computer.

The TRON project research is limited to general-purpose von Neumann

computers although much research is also being done on non-von Neumann
computers. Some researchers doubt the limited potential of von Neumann
computers. Because of the wide range of their coverage on applications
and the completeness of their computer technology, von Neumann computers
will certainly be the core of data processing in the 1990s. The TRON
project intends to propose a model of an ultimate von Neumann computer that
makes full use of VLSI features.
- The TRON total architecture covers all layers of computer hierarchy.
The TRON project covers all levels of computer hierarchy, from microprocessors
to networks. Consequently, demands or requests from one design are fed back
to a wide range of designs. For example, a problem in the operating system
can be solved by reinforced processor instructions, and system calls necessary
to build networks can be built into the operating system. Thus, application
execution speed, which can be considered as the actual computer speed, is
greatly increased, because tuning between layers is possible in the design
stage.
Five subprojects proceed in parallel in the TRON project. The kernel of the
project is the TRON-architecture microprocessor that will make full use of the
semiconductor technology of the 1990s. The TRON-architecture microprocessor
will be the optimum one for applications and operating system execution in the
1990s. The operating system layer consists of three operating system
specifications: the industrial TRON (ITRON) specification for realtime
microcontroller operating systems, the business TRON (BTRON) specification for
workstation operating systems, and the communication and central TRON (CTRON)
specification for operating systems implemented on data center machines that
perform large-volume data processing. The CTRON specification is intended for
mainframes rather than microcomputers. These three specifications each cover
process control, workstations, and center mainframes because a single
operating system cannot cover all of these. The macro-TRON (MTRON)
specification integrates the ITRON, BTRON, and CTRON specifications through
networks to achieve the overall goals of the TRON project.
The TRON project separates the design criteria (the architecture) from the
means of realization (the implementation). First, let us define the term
architecture. The TRON project extended the meaning defined by G.M. Amdahl.
In addition to the instruction set for programmers, an architecture specifies
all attributes of a system, including operating systems and man-machine
interfaces. Specifically, the TRON architecture contains all interface
specifications, from the TRON-architecture based microprocessor specification
instruction set to the ITRON- and BTRON-architecture system calls and the
BTRON-architecture man-machine interfaces. Separating architecture and
implementation gives the advantage that higher layers are not affected even
if a lower layer implementation is completely changed. In other words,
compatibility is maintained for each layer. Another important concept in the
TRON project is that architecture is specified, but performance is not.
Consequently, there is free competition between implementors. From the
user's viewpoint, many different products having the same functions and
different performance levels are offered by different manufacturers at
different times. The TRON project provides not only schemes for
standardization but also an arena for fair technological competition.
*******************************************
* 1.2
*
* Basic Philosophy of ITRON Specification *
*******************************************

------------------------------------------------1.2.1 Multitasking and realtime operating systems

------------------------------------------------Microcomputers have pioneered a new computer application field, the
replacement of control devices. This is due to their compact size, and low
price.
Specifically, microcomputer control is now used for telephone switching
systems,industrial robots, numerically controlled machine tools, and home
appliances such as air conditioners, washing machines, and televisions.
These microcomputers are used as a single component within a larger system.
For this reason, they are called embedded computer systems or embedded
systems.
Embedded computer systems usually contain sensors and must be able to cause
external devices to take proper actions periodically and be able to respond to
external stimuli or changes. In an air conditioner, for example, sensors
sense external temperature and humidity, and the sense information is used to
control the air conditioner output and wind direction. Programs in embedded
systems differ from those in usual data processing. They must control the
external environment with minimal delay by responding within milliseconds.
To improve program productivity and shorten the development period of those
realtime programs, an operating system (OS) should be used in application
programming. The operating system to be used is different from that used for
a general-purpose computer, which protects user spaces and manages files.
Its main purpose is to simplify programming, such as parallel processing and
synchronization with external events by interrupts.
Computers execute their instructions or programs sequentially; they cannot do
two things at a time. Realtime systems, however, often have multiple sensors
and have to monitor several things in parallel. If there are two things to be
monitored, it is natural to cause two separate programs to run in parallel for
simpler programming. The concept of multitasking was invented because of this
problem. In multitasking, each program to be executed in parallel is called a
task. Programming each task improves understandability and productivity of
the program. Of course, a single processor can only execute one instruction
at a time, so multitasking is implemented by time-sharing under the operating
system control. Multitasking operating systems are required for embedded
systems.
General-purpose computer operating systems are capable of multitasking and,
their jobs (processes or tasks) are executed in parallel. Their jobs however,
are mutually independent. For example, one computer is used for word
processing, compilation, and text editing, each job being submitted by
separate users. In this case, multitasking is used by that computer, but
there is no relationship between jobs. Multitasking is used to increase cost
effectiveness,that is, to share one computer for mutually independent jobs.
In embedded systems, the entire work to be conducted is split into several
tasks to make programming easier. Tasks are thus closely related with each
other, and the relationship between tasks is extremely complex. The chief
system designer must know the operations of each task and coordinate those
tasks to complete the assigned work. The nature of multitasking is thus quite
different for general-purpose computers and embedded systems.
Another important point is their realtime response. Realtime response is the
ability of computers to follow changes in the external environment. The time
taken to produce a processing result is limited. More simply, it means that

the response must always be quick enough, or that the worst response time must
be predictable.
In conventional batch or TSS processing, users are waiting for available
computer time. The computer performs calculations, and there is no
relationship with other systems. Consequently, delayed processing causes
delayed results, but does not lead to catastrophe.
In realtime systems, however, calculation is not the final objective; the real
objective of the system is to control other equipment using the calculation
results. There are thus strict requirements for processing time, and if
processing is too slow, results are useless even if they are correct.
Processing delay in safety equipment control on the high-speed trains, for
example, may cause a serious accident because brakes may not operate in time.
In another system that controls the ignition timing in car engines, the
calculated timing must be given to the engine before its rotation reaches the
ignition point.
The response time is thus as important as the processing results are, and late
results mean no results.
To satisfy the strict requirements of response time, the computer must be able
to process results quickly whenever external stimuli are received. The CPU
use ratio thus drops very low. This type of computer uses never happened
until computers have become popular and their prices have dropped.
Application fields in realtime processing and embedded systems are still new.
In ordinary programming, algorithms, data structure, overall performance, and
calculation volume are usually estimated. However, the absolute program
execution time is not accurately estimated. Applications for realtime systems
require accurate estimation of execution time. They require the estimation of
response time, considering the execution status of other tasks and the load on
the entire system. Estimating the CPU time of individual programs is not
required. This estimation is extremely difficult and is impossible on the
complex operating system used on mainframes. The operating system must be
compact and simple; otherwise the overhead time cannot be estimated.
Operating systems used in embedded systems are quite different from those used
in development systems or in general data processing systems. They must have
multitasking capability and realtime characteristics.
--------------------------------------1.2.2 Advantages of ITRON specification
--------------------------------------Industrial TRON (ITRON) specification is for a realtime-multitasking operating
system to be implemented in embedded industrial systems. The standardization
or hardware virtualization is kept to a minimum to improve the processing
performance. Another important feature is that it produces compact object
code by system tuning, even though it has many functions.
Standardization and hardware virtualization are desirable from the viewpoints
of software compatibility and user training, but may cause performance
degradation. Having many functions makes programming easier and improves
performance, but the object code becomes larger. In designing an operating
system, it is necessary to balance these trade-offs, and the ITRON
specification is a good example of this. The concept of weak standardization,
which is common to the entire TRON project, has been adopted by realtime
operating systems.

The following paragraphs summarize the advantages of the ITRON specification.

- Availability on various processors
The ITRON specification is to be implemented on many processors.
However, the implementation can be made processor-specific if so desired.
When designing a standard operating system, the first step is to design a
virtual-processor architecture common to all processors, and to implement
the ITRON specification on it. However, there is an obvious gap between the
virtual-processor architecture and the native architecture of each
processor. This degrades performance. To obtain maximum performance as a
realtime operating system, the architecture must use the full potential of
the processor, and extreme virtualization of hardware and operating system
functions must be avoided. Object compatibility is not as important for the
application fields. Training compatibility, such as consistent system call
names and functions is important instead.
In conclusion, the ITRON specification provides processor-independent
specifications separated from processor-dependent specifications. To avoid
performance degradation, ITRON specifications are left as is where
standardization or virtualization was difficult.
- Many functions
The ITRON specification has many system calls. For example, it offers
almost all conceivable synchronization mechanisms: event flags, semaphores,
and task-dependent functions (such as the slp_tsk and wup_tsk system calls).
Performance and program productivity can be improved by selecting the best
mechanism for the application.
- High-speed response
Task switching (dispatching) and interrupt-handler activation are most
sensitive to the response time in realtime applications. Related to system
tuning as explained later, the ITRON specification allows high-speed
dispatching by limiting general-purpose registers to save.
It also allows user-defined interrupt handlers to be activated without
operating system intervention when external interrupts occur. No overhead
results except that the user must save the registers used by interrupt
handlers.
- Adaptability
The ITRON specification is flexible and adaptable, considering
embedded-system applications. Selection of system calls, specification of
the registers used during dispatching, use of low-power modes when there are
no running (or ready) tasks, and whether to perform error checking during
system call execution are all left for the implementor or user to decide.
For example, checking memory-address parameters by software for whether to
cause memory-related errors, such as segmentation and bus errors, generates
high overhead for system call execution. If the parameters are fixed, and
the user program is correct, the parameters do not cause errors. Therefore,
complete error checking can be performed during debugging and the error
checking routine is removed after debugging. The ITRON architecture thus
has a large degree of freedom regarding error checking.
- Ease of training

The ITRON specification design philosophy places an emphasis on training, so

considerations on programmer training are thought of as important functions.
ITRON specification system call names and functions are determined
systematically, based on several criteria, to make them easy to understand.
For example, ITRON specification system call names consist of seven
characters, xxx_yyy, or eight characters, zxxx_yyy. xxx represents the
operation and yyy the object (Figure 1.1). Table 1.1 lists the meanings of
xxx and yyy. Eight-character system calls prefixed by z are compound system
calls having multiple functions or those derived from seven-character system
calls without the z.
The ITRON specification is generally independent of processor models, so
knowledge about the operating system is common to all models. This is a
major advantage for program development.
+---------+---------+---------+
| cre_tsk | del_tsk | sus_tsk | <------ Task
+---------+---------+---------+
| cre_flg | del_flg | set_flg | <------ Event flag
+---------+---------+---------+
| cre_sem | del_sem | sig_sem | <------ Semaphore
+---------+---------+---------+
^
^
^
|
|
|
Creation Deletion Operation
The ITRON specification system call names use seven characters, xxx_yyy, where
xxx gives the operation and yyy gives the object.
Figure 1.1 ITRON specification system call naming convention
Table 1.1 ITRON specification convention
for abbreviated names
+------------------+---------------+
| Abbreviated name |
Meaning
|
+------------------+---------------+
|
tsk
| Task
|
|
flg
| Event flag |
|
sem
| Semaphore
|
|
mbx
| Mailbox
|
|
mpl
| Memory pool |
+------------------+---------------+
|
msg
| Message
|
|
int
| Interrupt
|
|
exc
| Exception
|
|
blk
| Block
|
|
tim
| Time
|
+------------------+---------------+
|
cre
| Create
|
|
del
| Delete
|
|
def
| Define
|
|
can
| Cancel
|
|
wup
| Wakeup
|
|
wai
| Wait
|
|
ret
| Return
|
+------------------+---------------+

-------------------------------1.2.3 ITRON specification series

-------------------------------The ITRON specification is standard one for the realtime operating systems, but
its implementation is designed independently for each processor. As those
processors increase, the standard specification needs to be expanded to
several specifications. Currently, three specifications are available: the
ITRON1, ITRON2, and uITRON specifications.
The ITRON1 specification is for processors such as the Intel iAPX86, Motorola
MC68000, National Semiconductor NS32000, and NEC V series. The ITRON2
specification is for new high-performance processors, for example, those based
on the TRON architecture. Compared to the ITRON1 specification, the ITRON2
specification has additional functions and improved compatibility. Unlike the
ITRON2 specification, the uITRON specification is for inexpensive processors
such as single-chip processors.
Generally, there are trade-offs between compatibility with a standard
operating system and performance improvement by tuning. This means that there
must be balanced trade-offs between the two. The ITRON1 specification is for
existing 16-bit processors, the ITRON2 specification is for new 32-bit
processors, and the uITRON specification is for single-chip processors.
In other words, the ITRON2 specification is an improved version of the ITRON1
specification, with higher standardization levels and extended specifications.
The uITRON specification is an improved version of the ITRON1 specification,
with higher tuning capabilities and simplified specifications.
************
* 1.3
*
* Function *
************
-------------------1.3.1 Basic concepts
--------------------------------1.3.1.1 Tasks
-------------In the ITRON specification, a task is defined as a unit of parallel processing
of programs. Whereas a program in one task is executed sequentially, programs
in different tasks are executed in parallel. However, parallel execution is
only a conceptual operation as viewed by the applications programmer
(operating system user). Physically, each task is processed by the operating
system on a time-sharing basis.
The task being executed by the processor is switched to another task when a
system call that changes the task state is issued or when an interrupt which
causes state transition occurs. Switching between tasks is called
dispatching, and the mechanism in the operating system that executes this is
called the dispatcher.
When there is more than one task that can be executed, the order of execution
is determined by an algorithm. This control of the task execution order is
called task scheduling. The ITRON specification adopts a scheduling algorithm
based on the priority assigned to each task. Smaller numbers have higher
priority. In the ITRON specification, higher priority tasks are always
executed first. Lower priority tasks are never executed until higher priority

tasks have been executed.

In the ITRON specification, numbers are used to identify tasks. These numbers
are called task ID numbers. The maximum number of tasks that can be created
depends on the implementation, the target system hardware configuration, and
the content of the configuration table. In the uITRON specification, tasks
are created statically when the system is started, while in the ITRON1 and
ITRON2 specifications, tasks are created dynamically using task ID numbers.
After creation, tasks are identified using the task ID numbers or the task
access keys assigned when the tasks were created (in ITRON1 specification
only).
The ITRON specification OS must collect task management information to control
the execution of many tasks and to carry out multitasking. This collected
information is called the task control block (TCB). In principle, the content
of the TCB cannot be viewed by the user; the ITRON specification OS sets and
changes internal TCB values. In the ITRON specification, the TCB usually
holds information such as the following (details depend on the
implementation):
Task ID number
Task priority
Entry pointer (Task start address)
Initial user stack pointer
Exception handler address
Save area for registers used by the task
Flags indicating the task status
-----------------1.3.1.2 Resources
-----------------The elements necessary for task execution are called resources. Resources
include hardware, such as processors, memories, and I/O units, and software,
such as programs. Since the majority of resources cannot be used by more than
one task at a time, the operating system must coordinate limited resources so
that they are assigned exclusively among multiple tasks operating in parallel.
The ITRON specification has synchronization and communications functions to
assign resources exclusively.
---------------------------------1.3.1.3 Task states and operation
---------------------------------Figure 1.2 shows the task states and the system calls that cause state
transition. There are five task states:
(1) Run state
In the run state, a task is being executed.
(2) Ready state
In the ready state, a task is ready for execution, but cannot be executed
because a higher priority (or equal-priority) task is being executed. In this
state, a ready task can be executed as soon as the processor becomes
available. If there are two or more ready tasks, they form a queue, waiting
for the processor to become free. This is called the ready queue.
(3) Wait state

In the wait state, the task cannot be executed because an execution condition
has not been satisfied. In the wait state, the task is waiting for the
condition to be satisfied.
The wait state can be further classified as the wait state, the suspend state,
or the wait-suspend state. A task enters the wait state when the task issues
a system call to itself, while waiting for an event to occur. A task enters
the suspend state when the task is suspended by another task. A task enters
the wait-suspend state when the task already in the wait state is forced to
enter the event wait state. In the ITRON specification, there is a distinct
difference between the wait and suspend states. A task cannot enter the
suspend state by itself. Resumption from the wait state begins at the point
at which the task was suspended, and environmental data such as the program
counter, registers, or other program execution status (called context) is
restored to previous value. In the wait state, the task keeps possession of
semaphores and resources other than the processor.
(4) Dormant state
In the dormant state, the task has not yet been started or has already
terminated. A task enters this state when it is created.
In this state, unlike the wait state, all the resources are released, the
context, such as the registers or program counter, is initialized at start,
and operations (wup_tsk, ter_tsk, sus_tsk, chg_pri, and other system calls)
issued to the task are treated as errors.
(5) Nonexistent state
The nonexistent state is a hypothetical state where a task is not registered
in the system; it has not been created or it has already been deleted.
The uITRON specification does not support the nonexistent state. Depending on
the implementation, it also might not support the suspend state, wait-suspend
state, or dormant state. All of states (1) to (5) are necessary in the ITRON1
and ITRON2 specifications.
One of the features of the ITRON specification is that system calls addressed
to the caller and those addressed to another task (Table 1.2) are separated to
show clearly the state transition of a task and to make the operations of
system calls easy to understand. In other words system calls for transitions
from the run state are distinguished from those for transitions from other
states.
+---------+ -------------------- Dispatch -------------------> +-------+
| READY | <------------------- Preempt -------------------- | RUN |
+---------+ <--------+ Release
Wait +------------ +-------+
| ^ ^ |
|
|
| |
| | | |
|
+----------+
|
| |
| | | |
+------- | WAIT | <-----+
| |
| | | |
|
| Terminate
| |
| | | |
+----------+ ---------------+
| |
| | | |
| ^
(ter_tsk)
|
| |
| | | |
| |
|
| |
| | | |
Suspend | | Resume
|
| |
| | | |
(sus_tsk) v | (rsm_tsk,frsm_tsk) |
| |
| | | |
+----------+
|
| |
| | | |
+---> | WAIT- | Terminate
|
| |
| | | |
|
| SUSPEND | ---------------+
| |

| | | |
+---| | | |
| | | |
| | | |
| | | | Suspend
| | | | (sus_tsk)
| | | +------------------->
| | +--------------------->
| | Resume
| | (rsm_tsk,frsm_tsk)
| |
| |
| |
| | Start (sta_tsk)
| +-----------------------+------------------------->
Terminate (ter_tsk)

+----------+ (ter_tsk)
|
| |
|
|
| |
| Release
|
| |
|
|
| |
v
|
| |
+----------+
|
| |
| SUSPEND | Terminate
|
| |
|
| ---------------+
| |
+----------+ (ter_tsk)
|
| |
|
^
|
| |
|
|
|
| |
+------+
|
| |
|
| |
+----------+
|
| |
| DORMANT | <--------------+
| |
|
| <-----------------------+ |
+----------+ Exit,abort
|
^
| (ext_tsk,abo_tsk)
|
|
|
|
Create |
| Delete
|
(cre_tsk) |
v (del_tsk)
|
+----------+
|
| NON- | Exit and delete
|
| EXISTENT | <-------------------------+
+----------+ (exd_tsk)
^
|
Initial state

* The uITRON specification does not support the nonexistent state.

Depending on the implementation, it also might not support the suspend
state, wait-suspend state, or dormant state.
Figure 1.2 Task state transitions (ITRON specification)
Table 1.2 Distinction between the caller task and other, tasks,
and state transition diagrams
+---------------------+---------------------------+-------------------------+
|
|Operation on the caller
|Operation on another task|
|
|(Transition from run state)|(Transition from state |
|
|
|other than run state)
|
+---------------------+---------------------------+-------------------------+
| Placing a task in |
ext_tsk,abo_tsk
|
ter_tsk
|
| suspend state
|
Run state
| Ready or wait state |
|
|
|
|
|
|
|
|
v
|
v
|
|
|
Dormant state
|
Suspend or
|
|
|
|
wait-suspend state |
+---------------------+---------------------------+-------------------------+
| Exiting a task
|
ext_tsk,abo_tsk
|
ter_tsk
|
|
|
Run state
| Ready or wait state |
|
|
|
|
|
|
|
|
v
|
v
|
|
|
Dormant state
|
Dormant state
|
+---------------------+---------------------------+-------------------------+
| Deleting a task
|
exd_tsk
|
del_tsk
|
|
|
Run state
|
Dormant state
|
|
|
|
|
|
|
|
|
v
|
v
|

|
|
Nonexistent state
|
Nonexistent state
|
+---------------------+---------------------------+-------------------------+
* In the ITRON specification, system calls addressed to the caller and those
addressed to another task are clearly separated to show clearly the state
transitions of a task and make system calls easy to understand. In other
words, system calls for transitions from the run state and those for
transitions from other states are clearly distinguished.
-----------------------1.3.1.4 Task scheduling
-----------------------Task scheduling in the ITRON specification is based on task priority. First
come first served (FCFS) scheduling applies to tasks with the same priority.
Figure 1.3 is an example of this scheduling.
Figure 1.3 (A) is the ready queue state after task A of priority 1, task E of
priority 3, and tasks B, C, and D of priority 2 have been started, in that
order. Task A has the highest priority among the current ready tasks, so
task A is executed. In the ITRON specification, the task priority is
absolute. If task A is being executed, other lower priority tasks are not
executed at all.
Here, when a system call causes task A to enter the wait state, the ready
queue at that time is as shown in Figure 1.3 (B). In this state, there are
three ready tasks with the highest priority (tasks B, C, and D). According to
the ITRON specification, if there are two or more tasks with the same
priority, the task that enters the ready state first is executed first. In
this example, task B is executed next. This method is called first come first
served (FCFS) scheduling. In the ITRON specification, FCFS scheduling applies
to tasks having the same priority.
If an external interrupt is generated in this state, rescheduling occurs on
return from the interrupt handler. However, task B is executed after the
return from the interrupt handler unless a task with higher priority than B is
placed in the ready state by the interrupt handler. That is, task B will not
lose the execution priority even if an external interrupt occurs because there
is no direct relationship between an external interrupt and the task being
executed at the point of interrupt.
However, when a task that has entered the wait or dormant state moves back to
the ready state, it is placed at the end of the ready queue of its priority.
In the ITRON specification, the rot_rdq system call rotates the ready queue of
the same priority as the task. When it is issued, task B is placed at the end
of the ready queue.
The user can apply round-robin scheduling to tasks having the same priority,
rather than using FCFS scheduling. Round-robin scheduling gives each task a
time slice of the processor. To implement the scheduling, the following two
steps are needed: (1) Activate the interrupt handler at fixed-time intervals
using timer interrupts. (2) Issue the rot_rdq system call.
A task priority can be changed dynamically by the chg_pri system call.
Head of ready queue
+-----------------+
|
----------------+
+-----------------+
|
|

Priority
High
^
|
|
|
|
|
|
|
v
Low

Priority 1

Priority 2

Priority 3

|
+----> Task A ---->---+
|
+---------------------+
|
+----> Task B ----> Task C ----> Task D ----+
|
+-------------------------------------------+
|
+----> Task E ---->

(A) Initial ready queue state

Head of ready queue
+-----------------+
|
---------------+
+-----------------+
|
|
Priority
|
High
Priority 1
|
^
|
|
|
|
|
|
Priority 2
+----> Task B ----> Task C ----> Task D----+
|
|
|
+------------------------------------------+
|
|
|
Priority 3
+----> Task E ---->
v
Low
(B) Ready queue state after task A has entered the wait state
Figure 1.3 Tasks in ready queue (ITRON specification)
-------------------------------------------------------1.3.1.5 System status during non-task portion execution
-------------------------------------------------------To program tasks which run on the ITRON specification OS, look at the task
state transition diagram, and follow the state transitions of each task.
Users may program the interrupt handler or extended SVC handler, which require
kernel-level programming rather than task-level programming. The system
status must be carefully examined when a non-task portion is being executed to
avoid programming errors. This section explains the ITRON specification
system statuses.
The ITRON specification system statuses are classified as shown in Figure 1.4.
Statuses during operating system execution (system call execution) are
included in the transient statuses shown in Figure 1.4. From the user's point
of view, it is important that all system calls issued by the user are executed
with continuity. Because the internal status during system call execution is
unknown to the user, it is considered a transient status and its control
mechanism is treated as a black box.
Task-independent portions and quasi-task portions include all kinds of
handlers (except exception handlers, executed as task portions). Quasi-task

portions contain the task-specific context, and task-independent portions

contain the task-independent context. Specifically, extended SVC handlers,
which process user-defined extended system calls, mainly form quasi-task
portions. Interrupt handlers, activated by external interrupts, form
task-independent portions. Task state transitions in quasi-task portions are
the same as those for tasks, and system calls which place the caller in the
wait state can be issued.
In the ITRON specification, the transient statuses, task-independent portions,
and quasi-task portions are called non-task portions. The status in which
task programs are executed is called "task portion being executed."
+-|
|
|
System statuses --+-- Non-task
--+-| portion being |
| executed
|
|
|
|
+-|
|
+-- Task portion
being executed

Transient statuses
(operating system
(being executed)
Task-independent
portion being executed
(interrupt handlers)
Quasi-task portion being
executed
(Extended SVC handlers)

Figure 1.4 ITRON specification system statuses

-------------------------------------------------------1.3.1.6 Task-independent portion and quasi-task portion
-------------------------------------------------------Interrupt handlers form the task-independent portion. Task-independent means
that the portion has no relationship with the task that was being executed
immediately before the task-independent portion was entered, and that the
portion is not related to any task. Hence, it is not possible for the
task-independent portion to issue system calls which place the caller in the
wait state, or those which implicitly address the caller. The currently
executed task cannot be determined if the task-independent portion is being
executed. This means that task switching (dispatching) does not occur.
Dispatching is delayed until the execution of the task-independent portion is
completed. This is called the delayed dispatching principle.
If dispatching is caused by an interrupt handler, which belongs to the
task-independent portion, execution of the remaining part of the interrupt
handler is delayed until the execution of a handler-activated task is
completed.If an interrupt nesting occurs during this period, problems may
occur.
Figure 1.5 shows the status where interrupt X occurs during execution of
task A,and higher priority interrupt Y occurs during the execution of the
interrupt handler. In this case, when dispatching is caused immediately on
the return from interrupt Y at 1 and task B starts, execution of processes
between 2 and 3 in interrupt X is delayed until task B is completed.
Processes between 2 and 3 are executed when task A enters the run state.
Interrupt X has lower priority so the handler for interrupt X may be preempted
not only by a handler for a higher priority interrupt, but also by task B,
activated by that handler. Hence, the interrupt handler no longer has priority
over tasks, and programming an interrupt handler is not possible. This is why
the principle of delayed dispatching has been established in the ITRON

specification.
By contrast, the quasi-task portion consists mainly of the user-expanded parts
of the operating system. These include the extended SVC handlers.
Some processors, however, do not have a quasi-task portion, and the extended
SVC handler is contained in the task-independent portion.
The quasi-task portion identifies the task that was being executed immediately
before the quasi-task portion was entered (requesting task). The quasi-task
portion defines the task status in the same way as in the task portion, and it
can enter the wait state. Hence, dispatching occurs in the quasi-task portion
in the same way as in a usual task execution. As a result, a quasi-task
portion, such as the expanded portion of an operating system, is not always
executed prior to all other tasks even though it belongs to the non-task
portion, in contrast to the interrupt handler, which is always executed prior
to all other tasks.
The following two examples show the differences between task-independent
portions and quasi-task portions:
- An interrupt occurred during execution of task A (priority 8 (low)), and
wup_tsk was executed for task B (priority 2 (high)) by the interrupt handler
(task-independent portion). However, in accordance with the delayed
dispatching principle, dispatching does not yet occur; wup_tsk is executed,
then the remaining part of the interrupt handler is executed. Dispatching
is eventually caused by ret_int placed at the end of the interrupt handler,
and then task B is executed.
- An extended system call was executed during task A (priority 8 (low)), and
wup_tsk was executed for task B (priority 2 (high)) in the extended SVC
handler (quasi-task portion). However, because the delayed dispatching
principle does not apply, dispatching occurs during wup_tsk, task A enters
the ready state of the quasi-task portion, and task B enters the run state.
Hence, task B is executed before the remaining part of the extended SVC
handler. When dispatching occurs again and task A enters the run state, the
remaining part of the extended SVC handler is executed.
| : Task-independent portion
! : Task portion
Task A
Task B
Interrupt X
Interrupt Y
(low priority) (high priority)
(low priority)
(high priority)
!
!
Interrupt !--------------------------------->|
|
Interrupt +------------------->|
nesting
|
wup_tsk B
|
|
2 +<--------------ret_int 1
|
|
wup_tsk C
|
|
4 !<---------------ret_int 3
!

When dispatching occurs at 2, execution of the remaining part of the interrupt

X handler is delayed.
Figure 1.5 Interrupt nesting and delayed dispatching
---------------------------------------------------1.3.1.7 ID (identification) numbers and access keys
---------------------------------------------------In the ITRON specification, tasks and other items which receive system call
operations are called objects. Objects include memory pools and
synchronization and communications facilities such as event flags, semaphores,
and mailboxes. The operating system provides an object management table for
each object (called a TCB for a task). Objects are identified by ID
(identification) numbers. To create an object, an ID number is specified as
a parameter. However, using ID numbers to reference frequently accessed
objects lowers the performance, because translation from an ID number to the
management table address for each access takes time. When an object is
created, a key value for later accesses is returned by the operating system as
the return parameter.
Key values used for this purpose are called access keys in the ITRON
specification.
The base addresses of object management tables are usually used as access
keys, so access keys are also called access addresses. In the ITRON
specification, the terms access key and access address are synonymous.
However, if ID numbers are used as access keys, or if object management block
segment values are used, hash values that vary depending on the operating
system data structure are used,so access keys do not always indicate object
management table addresses.
In the uITRON specification, objects are not created dynamically. They are
all created statically when the system is activated. Access keys are not
needed to identify objects. ID numbers are used instead. The same is true in
the ITRON2 specification, so applications written under different
implementations of the operating system will be compatible. Only the ITRON1
specification uses access keys.
-------------------------------------------------------------------------1.3.1.8 Standardization policies and compatibility in ITRON specification
-------------------------------------------------------------------------The ITRON specification OS is a standard operating system to be implemented on
many processors. To prevent performance degradation caused by standardization
or virtualization, or to make full use of processor-specific architectures,
some variations in specifications are permitted. In the ITRON specification,
the execution environment depends heavily on the target system hardware, so
tightly controlling the conformance to specifications for the operating system
makes it difficult to attain object-level compatibility. Instead, the ITRON
specification uses loose specifications for the operating system to improve
the performance of each implementation. For this reason, the ITRON1 and
uITRON specifications do not guarantee complete compatibility for different
target processors or different implementations. There are many
implementation-dependent items in the specifications. Implementation
dependency in the ITRON specification increases in the order ITRON2, ITRON1,
and uITRON specifications. For the same reason, compatibility is not complete
between the ITRON1 and ITRON2 specifications, or between the ITRON1 and uITRON
specifications.
The ITRON1 and ITRON2 specifications are each divided into three classes:
processor-independent parts, processor-dependent parts, and

implementation-dependent parts. This section explains the standardized items

of the ITRON specification.
ITRON specifications common to all processors are as follows:
System call functions and names
Parameter types and names
Error code types, names, and values
Function code numbers (numbers that identify system calls)
However, since it is not necessary to adhere strictly to all specifications
for these items, specifications may be changed depending on the
implementation. Between ITRON1 and ITRON2 specifications, some function may
be added or differently specified even in processor-independent
specifications.
By contrast, parameter passing, bit length, or system call activation depend
strongly on the processor architecture. Making these specifications the same
for ITRON1 and ITRON2 specifications may impair the performance. Because no
object-level compatibility is provided between different processors, there is
little benefit in making parameter passing, etc. the same.
However, these specifications can be standardized for a specific processor.
The ITRON specification provides a set of standard specifications for popular
processors such as the Intel iAPX86, Motorola MC68000, and National
Semiconductor NS32000, proposing a desirable implementation for each
processor.
The ITRON specification basically stipulates only external specifications and
does not restrict the implementation method. In the details of system call
execution, however, the implementation method affects some external
specifications. These are called implementation-dependent specifications.
Although they are external specifications, parts of the
implementation-dependent specifications can be determined by the implementor
to maximize the ITRON specification OS performance. Implementation-dependent
specifications include the error detection levels.
In the uITRON specification, operating system specifications vary greatly
according to differences in processors. All uITRON specifications are
therefore guidelines. There are three types of specifications although they
are not strictly distinguished: processor-independent specifications,
processor-dependent specifications, and implementation-dependent
specifications. The processor-independent specifications need not be strictly
followed; specifications can all be processor-dependent and
implementation-dependent.
Although the ITRON specifications do not guarantee complete compatibility, the
importance of standardization for realtime operating systems lies in the
following:
- To make training courses common for all variations of the ITRON
specification by making system call names and terminology consistent
- To maintain portability by clarifying differences from the standard
specifications
---------------------------1.3.2 System call interfaces
---------------------------------------------------------------------

1.3.2.1 Interfaces with assembly language

-----------------------------------------In the ITRON specification, the method of issuing system calls in assembly
programming, that is, the method of interfacing with the assembly language,
depends on the processor. However, in the ITRON1 and ITRON2 specifications,
there are several conventions which apply to all processors, as listed below.
- System call parameters and return parameters are usually placed in four to
eight registers.
- Function codes that indicate system call type are usually placed in
registers used as accumulators.
- If many parameters are used or if the data is long, packets are created in
memory. The start address of the packet is placed in the register used as
an address register or an index register.
- Registers that are not used for return parameters should all remain
unchanged.
All processor-specific operating systems implemented on the iAPX86 (iAPX286),
MC68000, NS32000, and TRON-architecture microprocessor use these conventions.
The same conventions can be used for the uITRON specification. Because
performance is given priority, these conventions are all
implementation-dependent.
----------------------------------1.3.2.2 Interfaces with C language
----------------------------------In the ITRON specification, the virtualization concept is not used, so object
codes are not compatible between different processors. To ensure the
portability of ITRON specification OS application programs, they must be
written in a high-level language. The ITRON specification uses the C language
as the standard high-level language, and provides the standard interface with
C language for executing ITRON specification system calls. The following
general rules apply to the interface between the ITRON specification and the
C language:
- All system calls are defined as C functions, and system call error
conditions are the return values for those functions. Return parameters
other than error codes are normally passed using pointers.
- The pointer to the return parameters is placed first, and other parameters
follow the pointer. In the ITRON1 specification, a command option may be
placed as the first parameter.
In the ITRON specification, the C language system call interface is basically
processor-independent. However, specifications vary depending on the
processor for interrupt and exception processing system call functions and for
addressing using iAPX86 (iAPX286) processor segments. This is not really a
problem of the ITRON specification; it is more a problem of processor
architectures. There are some differences in the C language system call
interfaces even between the ITRON1 and ITRON2 specifications.
************************************
* 1.4
*
* uITRON and ITRON2 Specifications *

************************************
This section explains the uITRON and ITRON2 specifications.
--------------------------------------1.4.1 Overview of uITRON specification
--------------------------------------Standard operating systems have seldom been used in single-chip computers used
in electrical appliances and automobiles. This is because of the limited ROM
and RAM capacity. Instead, operating system functions have been included in
the application program. The uITRON specification OS is a standard operating
system for these applications. Its adaptability minimizes memory overhead and
degraded performance.
------------------------------------------------1.4.1.1 Basic philosophy of uITRON specification
------------------------------------------------Semiconductor manufacturers have recently introduced 8-bit and 16-bit
processors using their own architectures. Those processors are to be
incorporated in single-chip computers or application-specific integrated
circuits (ASICs). Since these processors are often used in realtime and
embedded-system applications, there are many demands to implement the ITRON
specification as the standard operating system.
The ITRON1 specification was designed for general-purpose 16-bit processors.
There are too many functions to be implemented on single-chip computers or
8-bit processors, and these processors often do not have enough ROM or RAM.
In the ITRON specification, functions can be deleted. This does not mean that
any function can arbitrarily be deleted by the user, but means that function
subsets and tuning for individual applications are provided. Because
compatibility is lost if there are functions not supported by the operating
system, the minimum functions required for implementation have been determined
for the ITRON specification.
To form a function subset for an application, the user may want to delete
parts of functions. For example, because the ITRON specification semaphore is
a counting type, the wait semaphore (wai_sem) system call permits the resource
count to be specified, using the cnt parameter. To delete only the variable
resource count, the resource count is fixed to 1, thus eliminating the cnt
parameter. In the same way, if the time-out function in the wait semaphore is
deleted, the tmout parameter, which specifies time-out, is not needed.
Deleting parameters saves ROM and RAM space. This is an important factor for
single-chip computers.
However, the presence or absence of parameters affects the system
interfaces. Parameters cannot be deleted arbitrarily by the user
compatibility with a high-level language is necessary. The ITRON
specification provides tuning for applications; however unlimited
not permitted so that compatibility with high-level languages is

call
when
tuning is
maintained.

The uITRON specification is an architecture provided to overcome the tuning

limits set on the ITRON specification adaptability. In other words, the ITRON
specification places emphasis on standardization rather than tuning, while the
uITRON specification place emphasis on tuning rather than standardization.
This means that even 8-bit processors in single-chip microcomputers, where RAM
and ROM space is extremely limited, can have sufficient performance.
Specifically, several items in the standardized ITRON specification were moved

in recommended specifications and implementation-dependent specifications.

They include system call interfaces and parameters. As a result, much more
freedom is given to implementation. Function subsets at the operating system
level are provided; these allow the implementor to select the necessary
functions.
There is a trade-off between standardization and freedom in tuning. The
uITRON specification is given more freedom in tuning at the operating system
level and less standardization. Complete compatibility cannot be guaranteed
because several functions are not implemented in the operating system and
there are differences between detailed specifications of the system call
interfaces.
The many differences between processors that use the uITRON specification
cause more compatibility problems than the differences between uITRON
specifications. Because different processors have different word length,
address space size, and addressing methods, compatibility for high-level
languages cannot be guaranteed even if the user program does not use any
operating system calls. Compatibility at the high-level language level
between uITRON specifications has less effect on program portability than do
variations of hardware and I/O devices connected to microcontrollers. This
means that all programs must be reviewed and corrected for program migration.
The advantages of standardization by the use of the uITRON specification
include ease of training and consistent system call names and functions.
Reduced programmer training costs and increased program productivity are
strong motives for standardization. As stated above, programs often need to
be rewritten in applications of the uITRON specification, which means that
reduction of the training costs is more important than program portability.
Converting a uITRON specification OS application program to another processor
is easy because the one-to-one correspondence of the name and function of each
system call is maintained between the source and target system of the
conversion. Understanding either the ITRON specification or uITRON
specification makes it easier to understand the other.
The uITRON specification is used as a guideline for designing operating
systems and naming system calls. The uITRON specification provides a separate
specification for each processor or application, following a single guideline.
It can be considered as a set of operating systems covering many
specifications for different operating systems. Conforming to the uITRON
specification signifies that the system call names determined by the uITRON
specification are used.
-----------------------------------1.4.1.2 uITRON specification design
-----------------------------------The uITRON specification is basically a subset of the functions determined by
the ITRON specification, and many implementation-dependent specifications are
permitted. The uITRON specification system call names and interfaces are not
always the same as those of ITRON specifications. Changes were made because
adopting a subset of the ITRON specifications creates unbalanced functions or
wasteful parameters for unsupported functions. The fundamental design
philosophy is to simplify specifications in order to gain high performance.
--------------------------------------------1.4.1.3 uITRON specification OS requirements
--------------------------------------------Too many variations of uITRON specification applications make it difficult to

stipulate necessary functions and system calls. For this reason, the main
objective of this specification is to set up guidelines for determining the
correspondence between system call names and functions. The uITRON
specification has two necessary functions:
1 There are three task states: run, ready, and wait (multitasking operating
system).
Depending on the implementation, the dormant and suspend states may also be
used.
2 An implementation-specific interrupt handler can be defined.
Tasks may wake up when the interrupt handler issues a system call (realtime
operating system).
The interrupt handler may be defined statically (at system generation or
initialization) or by the def_int system call.
For example, a uITRON specification operating system may have only two system
calls: the sleep task (slp_tsk) system call that places a task in the wait
state, and the wakeup task (wup_tsk) or return and wakeup task (ret_wup)
system call, issued by the interrupt handler, that wakes up a task in the wait
state.
A uITRON specification operating system does not guarantee that specific
functions are available to users. Conformity to the uITRON specification
simply assures the correspondence between system call names and functions.
In other words, it is easy to find out which system call should be used to
obtain a certain function or what a system call is doing in a program. This
"training compatibility" is extremely important in programming for embedded
systems.
--------------------------------------1.4.2 Overview of ITRON2 specification
--------------------------------------The ITRON2 specification is a higher level version of the ITRON1
specification, assuming that the ITRON specification is implemented on a
32-bit processor.
------------------------------------------------1.4.2.1 Basic philosophy of ITRON2 specification
------------------------------------------------The major purpose of the ITRON2 specification is improvement of the
compatibility between ITRON specification operating systems and the
portability of application programs. The following points have been added to
the conventional ITRON specification philosophy during the design stage.
- Higher standardization level
Responding to improved performance of processors, compatibility levels are
raised by widening the scope of standardization. For example, standard
specifications are available for the exception management functions, which
have been processor-dependent. However, virtualization is not adopted in
the ITRON2 specification, and the best performance policy still continues to
be as in the ITRON1 specification.
- Integration as the TRON specification family
Consistency of names and terminology is stipulated among BTRON, CTRON, and
ITRON specifications.
- System call classes

The ITRON2 specification has quite a few more functions than the ITRON1
specification. For ease of user understanding and migration from the ITRON1
specification, the system calls have been divided into three classes: basic
functions (I1), extended functions (I2), and system operation functions.
The class I1 functions are almost the same as those in the ITRON1
specification.
-----------------------------------1.4.2.2 ITRON2 specification design
-----------------------------------This section explains the concepts of the ITRON2 specification design and the
differences between ITRON1 and ITRON2 specifications.
- System call splitting and naming
Each generic function given to a system call in the ITRON1 specification is
now split into several primitive system calls in the ITRON2 specification.
This improves compatibility with the uITRON specification, reduces system
call options, adds functions, and provides flexibility in selection of
system calls.
For the names of split system calls, it is desirable to retain the original
names. However, it is difficult to assign a name as in the conventional
format of xxx_yyy.
Therefore, eight-character system call names, zxxx_yyy, are added to the
conventional format (xxx_yyy). The xxx and yyy parts represent the
operation and object, as in the conventional form, and the prefix z
indicates that the name is a derivative.
- Object access method
Unlike for ITRON1, the ITRON2 specification does not allow object accesses
to use access keys obtained dynamically during object creation; values (ID
number, for example) established before execution should be used. This
makes it easier to write programs and improves compatibility.
- Exception management
Specifications such as exception classification, nested activation of
exception handlers, and exception management in extended SVC handlers have
been clarified, and standardization has been improved for exception
processing programs.
Exception handlers in another task can be activated by software. This
function is named "forced exception" and is classified as a class I2
function in the ITRON2 specification. The exit processing routine in the
ITRON1 specification is treated as an exception handler (exit handler) in
the ITRON2 specification.
******************************************************************************
* Chapter 2
*
* uITRON specification
*
******************************************************************************
This chapter explains the concept of the uITRON specification design, the
relationship between ITRON1 specification and uITRON specification, and the
syntax of the system call specifications in later chapters.

******************
* 2.1
*
* Design Concept *
******************
Semiconductor manufacturers have recently introduced 8-bit and 16-bit
processors using their own architectures. Those processors are to be
incorporated in single-chip computers or application-specific integrated
circuits (ASICs). Since these processors are often used in realtime and
embedded-system applications, there are many demands to implement the ITRON
specification as the standard operating system.
The ITRON1 specification was designed for general-purpose 16-bit processors.
There are too many functions to be implemented on single-chip computers or
8-bit processors, and these processors often do not have enough ROM or RAM.
In the ITRON specification, functions can be deleted. This does not mean that
any function can arbitrarily be deleted by the user, but means that function
subsets and tuning for individual applications are provided. Because
compatibility is lost if there are functions not supported by the operating
system, the minimum functions required for implementation have been
determined for the ITRON specification. Figure 2.1 shows the tuning concept
in the ITRON specification.
To form a function subset for an application, the user may want to delete
parts of functions. For example, because the ITRON specification semaphore is
a counting type, the wait semaphore (wai_sem) system call permits the resource
count to be specified, using the cnt parameter. To delete only the variable
resource count, the resource count is fixed to 1, thus eliminating the cnt
parameter. In the same way, if the time-out function in the wait semaphore is
deleted, the tmout parameter, which specifies time-out, is not needed.
Deleting parameters saves ROM and RAM space. This is an important factor for
single-chip computers.
However, the presence or absence of parameters affects the system call
interfaces. Parameters cannot be deleted arbitrarily by the user when
compatibility with a high-level language is necessary (See Figure 2.2).
The ITRON specification provides tuning for applications; however unlimited
tuning is not permitted so that compatibility with high-level languages is
maintained.
Function in the ITRON specification
+------------+-------+-------+-------+--------+-------+
|
Task
| Event | Sema- | Mail- | Memory | Other |
| management | flag | phore | box | pool |
|
+-----------------------------------------------------+
|
| Affected by processor architecture
|
v
Function implemented on the OS for the iAPX86
+------------+-------+-------+-------+--------+-------+ - - - - - - - - - -+
|
Task
| Event | Sema- | Mail- | Memory | Other | Processor|
| management | flag | phore | box | pool |
| dependent functions|
+-----------------------------------------------------+ - - - - - - - - - -+
Function implemented on the OS for the MC68000
+------------+-------+-------+-------+--------+-------+ + - - - - - - - - - +
|
Task
| Event | Sema- | Mail- | Memory | Other | |Processor|
| management | flag | phore | box | pool |
|-|dependent functions|
+-----------------------------------------------------+ + - - - - - - - - - +

Function implemented on the OS for the NS32000

+------------+-------+-------+-------+--------+-------+ + - - - - - - - - - +
|
Task
| Event | Sema- | Mail- | Memory | Other | |Processor|
| management | flag | phore | box | pool |
|--|dependent functions|
+-----------------------------------------------------+ + - - - - - - - - - +
|
| Tuning for each application
|
v
ITRON specification adapted for application A
+ - - - - - -+
+ - - - +
+ - - - -+
+ - - - - - - - - - +
|
Task
|
| Sema- |
| Memory |
|Processor|
| management |-------| phore |-------| pool |--------|dependent functions|
+- - - - - - +
+ - - - +
+- - - - +
+ - - - - - - - - - +
ITRON specification
+ - - - - - -+ - - |
Task
| Event
| management | flag
+- - - - - - - - - -

adapted for application B

+
+ - - - -+
+ - - - - - - - - - +
|
| Memory |
|Processor|
|---------------| pool |---------|dependent functions|
+
+- - - - +
+ - - - - - - - - - +

ITRON specification adapted

+ - - - - - -+
+ - - |
Task
|
| Sema| management |-------| phore
+- - - - - - +
+ - - -

for application C
+ - - - +
+ - - - - - - - - - +
| Mail- |
|Processor|
| box |-------------------|dependent functions|
- - - - +
+ - - - - - - - - - +

Figure 2.1 Tuning in ITRON specification

+-------------------------------------------+
| wai_sem interface in ITRON1 specification |
+-------------------------------------------+
ercd = wai_sem
option:
a_sem:
cnt:
tmout:
ercd:

(option, a_sem, cnt, tmout);

Specification of time-out detection/no time-out detection
Semaphore access key (semaphore ID number)
Resource acquisition count
Time-out
Error code

+----------------------------------------------------------------------------+
|wai_sem interface when resource acquisition count and time-out specification|
|are not required
|
+----------------------------------------------------------------------------+
ercd = wai_sem (a_sem);
a_sem: Semaphore access key (semaphore ID number)
ercd: Error code
* When compatibility in a high-level language is required, parameters
cannot be deleted even if they are not needed.
Figure 2.2 Example of wait semaphore (wai_sem) system call interface
The uITRON specification is an architecture provided to overcome the tuning
limits set on the ITRON specification adaptability. In other words, the ITRON
specification places emphasis on standardization rather than tuning, while the
uITRON specification place emphasis on tuning rather than standardization.
This means that even 8-bit processors in single-chip microcomputers, where RAM

and ROM space is extremely limited, can have sufficient performance.

Specifically, several items in the standardized ITRON specification were moved
in recommended specifications and implementation-dependent specifications.
They include system call interfaces and parameters. As a result, much more
freedom is given to implementation. Function subsets at the operating system
level are provided; these allow the implementor to select the necessary
functions. Figure2.3 shows the tuning concept in the uITRON specification.
Function in the uITRON specifications
+------------+-------+-------+-------+--------+-------+ - - - - - - - - - +
|
|
|
|
|
|
| Added functions |
|
Task
| Event | Sema- | Mail- | Memory | Other | or functions
|
| management | flag | phore | box | pool |
| dependent on
|
|
|
|
|
|
|
| processor
|
|
|
|
|
|
|
| architecture
|
+-----------------------------------------------------+ - - - - - - - - - +
|
| Affected by processor architecture
|
| Affected by applications
|
| Implementor's choice
|
v
Functions implemented in uITRON specification specification OS of processor A
+ - - - - - -+
+ - - - +
+ - - - -+
+ - - - - - - - - - +
|
Task
|
| Sema- |
| Memory |
|Processor|
| management |-------| phore |-------| pool |-------|dependent functions|
+- - - - - - +
+ - - - +
+- - - - +
+ - - - - - - - - - +
Functions implemented in uITRON specification specification OS of processor B
+ - - - - - -+ - - - +
+ - - - -+
+ - - - - - - - - - +
|
Task
| Event |
| Memory |
|Processor|
| management | flag |---------------| pool |--------|dependent functions|
+- - - - - - + - - - +
+- - - - +
+ - - - - - - - - - +
Functions implemented
+ - - - - - -+
+
|
Task
|
|
| management |-------|
+- - - - - - +
+

in uITRON specification specification OS of processor C

- - - + - - - +
+ - - - - - - - - - +
Sema- | Mail- |
|Processor|
phore | box |------------------|dependent functions|
- - - + - - - +
+ - - - - - - - - - +

Figure 2.3 Tuning concept in uITRON specification

There is a trade-off between standardization and freedom in tuning.
The uITRON specification is given more freedom in tuning at the operating
system level and less standardization. Complete compatibility cannot be
guaranteed because several functions are not implemented in the operating
system and there are differences between detailed specifications of the system
call interfaces.
The many differences between processors that use the uITRON specification
cause more compatibility problems than the differences between uITRON
specifications. Because different processors have different word length,
address space size, and addressing methods, compatibility for high-level
languages cannot be guaranteed even if the user program does not use any
operating system calls. Compatibility at the high-level language level
between uITRON specifications has less effect on program portability than do
variations of hardware and I/O devices connected to microcontrollers.

This means that all programs must be reviewed and corrected for program
migration.
The advantages of standardization by the use of the uITRON specification
include ease of training and consistent system call names and functions.
Reduced programmer training costs and increased program productivity are
strong motives for standardization. As stated above, programs often need to
be rewritten in applications of the uITRON specification, which means that
reduction of the training costs is more important than program portability.
Converting a uITRON specification OS application program to another processor
is easy because the one-to-one correspondence of the name and function of each
system call is maintained between the source and target system of the
conversion. Understanding either the ITRON specification or uITRON
specification makes it easier to understand the other.
The uITRON specification is used as a guideline for designing operating
systems and naming system calls. The uITRON specification provides a separate
specification for each processor or application, following a single guideline.
It can be considered as a set of operating systems covering many
specifications for different operating systems. Conforming to the uITRON
specification signifies that the system call names determined by the uITRON
specification are used.
The following sections give details of the uITRON specification design, and
explain the implications of standardization in the uITRON specification.
********************************
* 2.2
*
* uITRON Specification Design *
********************************
The uITRON specification is basically a subset of the functions determined by
the ITRON specification, and many implementation-dependent specifications are
permitted. The uITRON specification system call names and interfaces are not
always the same as those of ITRON specifications. Changes were made because
adopting a subset of the ITRON specifications creates unbalanced functions or
wasteful parameters for unsupported functions. The fundamental design
philosophy is to simplify specifications in order to gain high performance.
The following sections explain the concept of uITRON specification design and
differences between the ITRON and uITRON specifications.
----------------2.2.1 Task states
----------------Like the ITRON specification, the uITRON specification is for a realtime
operating system that performs preemptive scheduling. As in the ITRON
specification, a task having a smaller priority number takes priority over one
having a greater number.
Unlike the ITRON specification, however, the uITRON specification does not
support dynamic creation of objects, such as tasks and semaphores. It
therefore has no task state corresponding to the nonexistent state in the
ITRON specification. The uITRON specification has five states as follows:
(1) Run state
In the run state, a task is being executed.

(2) Ready state

In the ready state, a task is ready for execution but cannot be executed
because a higher priority (or same-priority) task is being executed.
(3) Wait state
In the wait state, the task cannot be executed because an execution condition
has not been satisfied. The difference between the wait state and the suspend
state (explained in item (4)) is whether execution is stopped by a system call
issued by the caller task or another task.
(4) Suspend state
In the suspend state, execution of the task is forcibly suspended by a system
call issued by another task. Sometimes this state may be nested in the wait
state explained in item (3). This nested state is called the wait-suspend
state.
(5) Dormant state
In the dormant state, the task has not yet been started or has already
terminated. In this state, unlike the wait state, all the resources are
released, and the context, such as the registers or program counter, is
initialized at start.
The suspend state and dormant state are not always implemented in the uITRON
specification OS. Figure 2.4 shows the uITRON specification task state
transitions, which are a subset of the ITRON specification.
+---------+ ------------------ Dispatch ---------------> +-------+
--| READY | <----------------- Preempt ---------------- | RUN |
^
+---------+ <------+ Release
Wait +-------- +-------+
|
| ^ ^ |
|
|
|
Necessary
| | | |
|
+----------+
|
|
states
| | | |
+------- | WAIT | <-----+
|
|
| | | |
|
| Terminate
|
|
| | | |
+----------+ ---------------+ |
|
| | | |
| ^
(ter_tsk)
| |
v
| | | |
| |
| |
--| | | |
Suspend | | Resume
| |
^
| | | |
(sus_tsk) v | (rsm_tsk,frsm_tsk) | |
|
| | | |
+----------+
| |
|
| | | |
+---> | WAIT- | Terminate
| |
|
| | | |
|
| SUSPEND | ---------------+ |
|
| | | |
+---- +----------+ (ter_tsk)
| |
|
| | | |
|
| |
|
| | | |
| Relese
| |
|
| | | |
|
| | Implementation| | | | Suspend
v
| | dependent states
| | | | (sus_tsk)
+----------+
| |
|
| | | +-----------------> | SUSPEND | Terminate
| |
|
| | +-------------------> |
| ---------------+ |
|
| | Resume
+----------+ (ter_tsk)
| |
|
| | (rsm_tsk,frsm_tsk)
|
^
| |
|
| |
|
|
| |
|
| |
+------+
| |
|
| |
| |
|
| | Start (sta_tsk)
+----------+
| |
|
| +---------------------- | DORMANT | <--------------+ |
|

+-----------------------> |
| <------------------+
Terminate (ter_tsk)
+----------+ Exit (ext_tsk)

v
---

*
*
*
*

Boxes with solid lines indicate necessary state.

Boxes with dotted lines indicate implementation-dependent states.
The initial task state is specified at system generation or initialization.
System calls that enter the wait state are:
slp_tsk, wai_tsk, wai_flg, cwai_flag, wai_sem, rcv_msg, rcv_tmb, get_blk
* System calls that release from the wait state are:
wup_tsk, rel_wai, set_flg, sig_sem, snd_msg, snd_tmb, rel_blk, ret_wup,
iwup_tsk, irel_wai, iset_flg, isig_sem, isnd_msg, isnd_tmb
Figure 2.4 Task state transitions (uITRON specification)
--------------------------------2.2.2 Functions that form subsets
--------------------------------Some ITRON specification functions have been grouped into subsets with
simplified specifications, to fit applications of the uITRON specification.
The following paragraphs explain those functions.
- Dynamic creation of objects
In the ITRON specification, it is possible to create and delete objects
(task, event flag, semaphore, mailbox, memory pool) dynamically. In the
uITRON specification, however, the basic policy is to create objects
statically at initial activation. Objects are not created or deleted during
execution. Hence, the create object (cre_xxx) and delete object (del_xxx)
system calls are not supported by the uITRON specification. This is because
memory management for dynamic creation and deletion of objects is complex,
and the implementation workload increases. xxx represents tsk, flg, sem,
mbx, or mpl.
In the uITRON specification, since objects are not created dynamically, the
cre_xxx system call cannot be used to obtain the access key from the ID
number. Thus, object access using the access key is not possible. Since
the access key must have a fixed value, the ID number is usually used as the
access key.
In the uITRON specification, ID numbers are expressed in one to two bytes;
the maximum size depends on the implementation. Implementation can restrict
the range of ID numbers, or access keys may be assigned by the linker (the
assembler or linker converts the ID number to an access key). In any case,
the object is accessed with the value established before the start of
execution (ID number or other value); it is not accessed with the access key
which, in ITRON1 specifications, is obtained dynamically during object
creation.
- Queuing
In the ITRON specification, if the wup_tsk system call to wake up a task is
issued twice to the same task, the second request is held; it is not treated
as an error. This is called the request queuing. The target task of
wup_tsk enters the wait state when the sleep task (slp_tsk) system call is
executed three times, not twice. In the ITRON specification, task-dependent
synchronization mechanisms using the wup_tsk and slp_tsk system calls, and
execution suspend and resume using the suspend task (sus_tsk) and resume
task (rsm_tsk) system calls can be enqueued more than once.
However, to realize the queuing function, the request count must be kept.

This is not a major problem in the ITRON specification, but, in the uITRON
specification where RAM space should ideally be reduced, it makes
implementing the queuing function difficult. In the uITRON specification,
the multiple-queuing function for the wup_tsk and sus_tsk system calls is
implementation-dependent, so implementations having single queueing are
permitted.
- Time-out
The ITRON specification permits specifying time-out for system calls which
enter the wait state, but the uITRON specification does not as implementing
the time-out processing may increase the implementation workload.
- Event flags
The ITRON specification treats 16 to 32 event flag bits as a word to permit
an OR or AND operation on the specified bits. Use of these functions,
however, requires many parameters to issue system calls for event flag
operations, thus causing performance degradation and memory shortage.
The uITRON specification permits single-bit event flag operations as an
alternative implementation. The single-bit operations form a subset of the
event flag word operations. Figure 2.5 shows the parameters and return
parameters used for single-bit and word operations.
+-----------------------+
| Single-bit event flag |
+-----------------------+
System call
Parameter
Return parameter
----------- ------------------------- ---------------wai_flg
flgid
Clear not specified
cwai_flg
flgid
Clear specified
+-----------------+
| Word event flag |
+-----------------+
System call
Parameter
Return parameter
----------- --------------------------- ---------------wai_flg
flgid
waiptn
wfmode
flgptn
flgid:
waiptn:
wfmode:
flgptn:

Event flag ID number

Wait bit pattern
AND/OR selection and whether to clear when released from WAIT
Event flag bit pattern when released from WAIT

* Many parameters are necessary to use event flag words.

Figure 2.5 System call parameters for event flag operations
- Semaphore count
The ITRON specification semaphore is of a counting type, and there are two
system calls: the wait semaphore (wai_sem) system call is for the P
operation and the signal semaphore (sig_sem) system call is for the V
operation. The count for acquired and returned resources can be specified.
In the uITRON specification, the resource acquisition count and return count
are fixed to 1 to reduce system call parameters.
- Variable-length memory block

The ITRON specification supports both variable-length and fixed-length

memory block management functions. Generally, however, variable-length
memory block management places a burden on implementation, and realtime
response is easily lost. For this reason, the uITRON specification does not
support variable-length memory block management functions; it supports only
fixed-length memory block management functions.
- Exception handling
The ITRON specification has two types of exceptions: system call and CPU
exceptions. A system call exception activates an exception handler when an
error occurs during system call execution. A CPU exception activates a task
exception handler when an error occurs in the CPU (zero division, for
example). System call exception handling often generates system call
execution overhead, and thus is not supported by the uITRON specification.
CPU exception handling also depends largely on the processor architecture,
and so it too is not supported by the standard uITRON specification.
Depending on the implementation, however, exception handlers may be appended
to support debugging.
---------------------------2.2.3 System call interfaces
---------------------------The ITRON specification provides both high-level function calls and generic
function calls. For example, time-outs can be specified for all system calls
that enter the wait state. A system call option as a parameter specifies
whether time-out detection is needed. This sort of specification enables to
use the same system call whether or not the time-out function is needed and
makes it easy for users to select system calls and understand the entire
operating system.
Conversely, implementing many functions in one system call increases decisions
and branches during system call execution, thus leading to degraded
performance.
If individual system calls have high-level or many other functions, little
benefit may result from deleting unneeded functions. Suppose there are
separate system calls for whether time-out detection is needed. The system
call with time-out detection can be deleted if the time-out function is not
needed. This reduces the program size. However, if there is only one system
call, the system call cannot be deleted even if the time-out function is not
needed. The corresponding processing program cannot be deleted because
whether time-out detection is needed is dynamically determined by parameters.
uITRON specification implementation is more difficult than ITRON1
specification implementation due to memory size limitations and required
performance. By reviewing system calls with high-level functions, complex
functions, or many parameters, we can split their individual functions into
primitive functions. Making each system call functionally primitive allows
us to write higher performance programs which fit applications and save memory
by deleting unneeded functions.
Only a few system calls have been split, but consistency and continuity of
system calls must be maintained between ITRON1 and uITRON specifications.
The names of derived system calls should be associated with their original
names. However, it is difficult to assign names that suggest their functions
using the format xxx_yyy (xxx is the operation and yyy is the object).

The uITRON specification uses eight-character system call names of the format
zxxx_yyy in addition to the conventional format xxx_yyy. The xxx and yyy
parts have the conventional meanings of operation and object, while z
indicates that the system call has been derived from the original system call.
Within the entire TRON specification, the zxxx_yyy form is used for complex
system calls in the ITRON specification and for shell system calls in the
BTRON specification.
The following uITRON specification functions have been split into their
primitive functions:
- Polling functions
For resource acquisition system calls in the ITRON1 specification,
time-out = 0 must be set to avoid entering the wait state when a resource
cannot be allocated. Normal termination indicates that the resource has
been acquired, and a time-out error indicates that it has not been acquired.
It can be said that the ITRON1 specification has only one system call for
resource acquisition, polling, and time-out functions.
For the three primitive functions mentioned above, the time-out function has
been removed from the uITRON specification. The primitive system calls for
resource acquisition have the same name as in the ITRON1 specification, and
the system call for polling is prefixed by p.
For example, the receive message (rcv_msg) system call, which waits to
receive a message, is provided in both ITRON1 and uITRON specifications.
The task that issued this system call enters the wait state if the message
has not been received. To avoid this, time-out (tmout) can be set to 0, and
for the ITRON1 specification, the same rcv_msg system call can be executed,
while for the uITRON specification, the poll and receive message (prcv_msg)
system call can be executed.
The following system calls execute polling:
preq_sem Equivalent to wai_sem with tmout = 0
prcv_msg Equivalent to rcv_msg with tmout = 0
pget_blk Equivalent to get_blk with tmout = 0
The get object status (xxx_sts) system call is provided as a function
similar to polling, to examine the object or resource status. xxx_sts,
however, does not acquire any resource even if several resources are
available; it merely examines whether a resource is available. Polling
however, acquires a resource if it is available. Thus, examining the object
status and resource polling differ.
- System calls issued by task-independent portion
The ITRON1 specification does not distinguish between system calls issued by
tasks and those issued by the task-independent portion (interrupt handlers).
Dispatch requests generated in an interrupt handler are delayed until the
system escapes from the interrupt handler (the principle of delayed
dispatching). This means that processing inside the operating system
depends on whether a task or an interrupt handler issued the system call.
Since there is no distinction between the two, the operating system
determines the caller from the context where the system call was issued.
Conversely, the uITRON specification has separate system calls to be issued
by task-independent portions (interrupt handlers) and by tasks. This
removes overhead for the context determination by the operating system, and

improves performance. The name of a separate system call issued by

task-independent portions is prefixed by i, representing interrupt.
For example, in the ITRON1 specification, the wup_tsk system call, which
wakes up a task, may be issued by either a task or a task-independent
portion. In the uITRON specification, however, wup_tsk may be issued by a
task-independent portion or iwup_tsk may be issued instead of wup_tsk,
depending on the implementation. To reduce the operating system overhead
and to speed up the processing of system calls issued by task-independent
portions, the iwup_tsk system call issued by a task-independent portion and
the wup_tsk system call issued by a task portion should be separate. From
the user's viewpoint, it is convenient to use the wup_tsk system call for
both the task portion and the task-independent portion. In the uITRON
specification, selection out of the two choices is up to the implementor,
reinforcing the tuning capabilities for processors and applications.
- Cyclic handler and alarm handler
The ITRON1 specification has a system call that sends cyclic wakeup requests
to a task, starting from a specified time. This is named the cyclic wakeup
(cyc_wup) system call. The uITRON specification provides a simpler
primitive function: the cyclic handler and alarm handler. The cyclic
handler is activated cyclically and is task-independent. The alarm handler
is activated once at the specified time and is also task-independent.
The uITRON specification permits the user to write the cyclic handler and
alarm handler programs in which the wup_tsk system call is issued.
This realizes the task cyclic wakeup function.
In the uITRON specification, the cyclic handler and alarm handler are
implementation-dependent.
*******************************************************
* 2.3
*
* Standardization Philosophy in uITRON Specification *
*******************************************************
As stated previously, there are many factors that make uITRON specification OS
applications incompatible with specifications (for example, processor
architecture or hardware). Hence, ensuring complete program compatibility in
the operating system has little meaning; it is far more important to improve
the performance or reduce the required memory size. The basic policy of the
uITRON specification is that conformity to the standard specifications be
maintained, as long as performance or memory size is not affected.
Standardization which leads to performance degradation should be avoided.
When compatibility is highly necessary, the use of the ITRON2 specification
instead of the uITRON specification is recommended.
This section explains the items standardized by the uITRON specification and
the degree of standardization of specifications.
- Function sets and system calls
The system call functions and their names are standardized in the uITRON
specification. However, the user is free to form function subsets.
The main purpose of the uITRON specification is to ensure "training
compatibility" by using consistent system call names, thus the relationship
between functions and system call names must be standardized. Users can
select system calls to form subsets, but the same system call names must be
used for the same functions.

Some of the uITRON specification system calls have two sets of

specifications. For example, there are two sets of uITRON event flag
specifications: those for single-bit event flags and those for 8- to 32-bit
word event flags. Either may be selected at implementation, for the
following reason:
For current single-chip microcomputers, the single-bit specification of
event flags is considered the best. However, as device technology
progresses, it will be possible to realize the word specification of event
flags of the uITRON specification. If there is a strong demand from
applications, it may be better to realize 8- to 32-bit word event flags,
although it is not so easy. For conformity to the ITRON specification, the
event flag should eventually be an 8-, 16-, or 32-bit word. Considering the
uITRON specification design, unifying event flags to the single-bit
specification is not profitable. Rather, it is preferable to provide two
standard specifications: single-bit and word event flags.
Of course, users may not want too many specifications. Even in the uITRON
specification, functions offering several choices to the implementor are
kept to a minimum.
- Parameters
In principle, the same system call should have the same parameters.
However, users may want to reinforce specific functions for applications, or
it may be necessary to add parameters for some system calls. For example,
the resource acquisition functions form a subset, which is not supported by
ordinary implementations. However, if these functions are necessary for
specific applications, then the subset may be adopted. This means that
adding parameters to semaphore management system calls produces differences
from the standard uITRON specification parameters. The parameter-added
specification still conforms to the uITRON specification, although it is
necessary for the implementor to clarify the differences.
- Assembler interfaces (parameter passing)
Assembler interfaces are very much affected by the processor architecture
and compiler, so they are not standardized in the uITRON specification.
Specifications are determined for each processor.
- High-level language (C language) interfaces
Since the system call names and parameters are standardized, the C language
interfaces are also standardized, in principle. However, as stated in the
section on parameters, whether there are parameters depends on the specific
use; sometimes the C language interfaces may also change. Standard
specifications are provided, but are not strict; they belong to weak
standardization.
- Function codes
In the ITRON specification, the number that identifies the type of system
call is called a function code. Function codes used in the uITRON
specification are standardized, as in the ITRON specification.
In the uITRON specification, depending on the relationship between the
processor architecture and development environment, control is passed to the
system call processing routine in the operating system by using a subroutine
jump instruction, instead of using a trap instruction (software interrupt
instruction). In this case, function codes need not be used.

- Error codes
The uITRON specification has weakly standardized specifications for error
mnemonics and error code values.
Generally, standardized error codes do not affect the performance or object
size. However, precise specification of the error checking or the detection
priority of multiple errors may set restrictions on the implementation and
affect the performance. Hence, the uITRON specification proposes weakly
standardized error codes, and there are no detailed specifications for error
checking.
To reinforce consistency with BTRON and ITRON2 specifications, the uITRON
specification uses negative numbers as standard error codes. The ITRON2 and
uITRON specifications use the same standard values.
- Negative numbers
All of the TRON specification family use negative numbers for the operating
system and positive numbers for applications. The number 0 is for special
uses. The following gives examples of how these numbers are used:
- In the ITRON specification, tskid = 0 indicates the caller task.
- In the ITRON/MMU specification, spcid = (-1) indicates shared space.
- In the BTRON specification, a negative value returned from system call
indicates an error.
- In the BTRON specification, process_id = 0 indicates the caller process,
and process_id = (-1) indicates the parent process.
- In the TRON-architecture microprocessor specification, negative addresses
are shared semispace (SS) and positive addresses are unshared semispace
(US).
- In the CTRON specification, tmout = (-1) indicates no time-out.
In the uITRON specification, strict restrictions of individual processor
architectures make it difficult to apply these general rules. However, they
should be applied wherever possible in giving object ID numbers and
priority, as long as the performance does not decline. For example, to
provide I/O tasks together with the kernels, it is better the task ID number
is a signed number so that a negative ID number (for example, from -8 to -5)
indicates an I/O task.
Even for weak standardization items stated above, it is necessary to identify
which parameters in an implementation are different from the standard uITRON
specification parameters. Clarifying where to modify by the implementor is
absolutely necessary for program portability.
Some processors provide register-bank switching or special functions such as a
low-power mode in the idle state. These functions should be incorporated in
the uITRON specification. To support these optional functions, the uITRON
specification gives a range of function codes to these processor- or
implementation-dependent system calls.
**********************************
* 2.4
*
* Scope of uITRON Specification *
**********************************
As stated above, the uITRON specification is for an operating system having
many implementation-dependent functions. The explanations of uITRON

specification system calls in later chapters indicate the different importance

levels of system calls, although these need not be strictly followed.
To spare implementors confusion caused by these ambiguities, conformity to the
uITRON specification must be expressed as concrete requirements. In other
words, the scope of the uITRON specification operating system must be
clarified.
One method of clarification is to determine which system calls are absolutely
necessary in supporting the uITRON specification. However, there are many
fields of application for the uITRON specification OS, and functions to be
supported are quite different in different applications. There is no single
system call that must be used in all applications.
For example, the interrupt processing functions are necessary for a realtime
operating system, but the interrupt handler can be defined without using the
interrupt handler definition system call (def_int). The interrupt handler can
also be defined statically during operating system generation or
initialization. Hence, there is no absolutely necessary system call. By the
same token, there are no absolutely necessary task management functions.
If there is no dormant state, there is no need for the start task (sta_tsk)
or exit task (ext_tsk) system calls.
Synchronization and communications functions are essential in realtime
operating systems. The uITRON specification includes task-dependent
synchronization functions (wup_tsk), event flags, semaphores, and mailboxes.
If the choice of processor architecture and application has already been
fixed, the optimum synchronization and communications functions can be
determined and made absolutely necessary functions. However, this assumption
does not hold in the uITRON specification OS applications. For example,
semaphores may be preferred to mailboxes by one application, while mailboxes
are preferred by another application. Hence, there is no evidence to
determine that semaphores are preferred to mailboxes by all uITRON
specification OS applications.
In conclusion, the uITRON specification will not be complete even if necessary
functions and system calls are determined. Therefore, the main objective of
this specification is to set up guidelines for determining the correspondence
between system call names and functions. The uITRON specification has two
necessary conditions:
1 There are three task states: run, ready, and wait (multitasking
operating system). Depending on the implementation, the dormant and
suspend states may also be used.
2 An implementation-specific Interrupt handler can be defined: Tasks may
wake up when the interrupt handler issues a system call (realtime operating
system). The interrupt handler may be defined statically (at system
generation or initialization) or by the def_int system call.
Briefly, all realtime operating systems whose system call names are the same
as those of the ITRON specification are called the uITRON specification OS.
As an extreme, a uITRON specification OS may have only two system calls: the
sleep task (slp_tsk) system call that places a task in the wait state, and the
wakeup task (wup_tsk) or return from wakeup (ret_wup) system call, issued by
the interrupt handler, that wakes up a task in the wait state.
A uITRON specification operating system does not guarantee that specific
functions are available to users. Conformity to the uITRON specification
merely assures the correspondence between system call names and functions.
In other words, it is easy to find out which system call should be used to

obtain a certain function or what a system call is doing in a program.

This "training compatibility" is extremely important in programming.
Particularly in the area of realtime systems, there are no de facto standard
operating systems, like UNIX or MS-DOS. This fact suggests that using
consistent system call names would be beneficial for users.
Among the entire TRON specification family, the uITRON specification signifies
"training compatibility," and ITRON1 and ITRON2 specifications signify
operational program compatibility.
********************************************
* 2.5
*
* Functions Added to uITRON Specification *
********************************************
The philosophy of the uITRON specification is to provide higher adaptability
than the ITRON1 specification by providing as many functions as possible.
Quite few functions have been added to the uITRON specification that were not
in the ITRON1 specification. Some of these are common to the ITRON2
specification. These functions are implementation-dependent.
- Cyclic handler and alarm handler
As stated in section 2.2.3, the uITRON specification has the cyclic handler
and alarm handler as an alternative to the cyclic wakeup (cyc_wup) function
in the ITRON1 specification. The cyclic handler is task-independent.
The alarm handler is activated once at the specified time and is also
task-independent.
- Examining object status
The get object status system call (xxx_sts) has been provided to examine the
status of objects such as tasks, event flags, semaphores, mailboxes, and
memory pools.
In the ITRON1 specification, the object status is referenced by reading the
exact contents of the management block using system call xxx_adr, which is
provided to obtain the access address. However, to improve compatibility, a
system call that directly references the object status is preferable to
xxx_adr. The xxx_sts system call was introduced instead of the ITRON1
specification xxx_adr system call.
- Task-dependent mailbox functions
The philosophy of the ITRON specification is to use as few task-dependent
functions as possible to lighten the load of individual task specifications.
The ITRON specification mailbox functions are task-independent. In other
words, messages are addressed to mailboxes, not to tasks, and tasks that
have been waiting for messages at the addressed mailbox receive those
messages.
However, when the task that is to receive messages is known, the
task-specific mailbox may be provided in order to speed up message
communications. Thus, task-dependent mailboxes were introduced into the
uITRON specification. Since only the mailbox owner task can receive
messages sent to that mailbox, task queues waiting for messages do not form,
and message communications are sped up.
In the uITRON specification, the task-dependent functions are identified by
names prefixed with t. Hence, the name of a task-dependent mailbox object

is tmb.
- Task restart function
The task restart function restarts the specified task from the specified
address when control returns from interrupt processing. As viewed from the
task to be restarted, this function is a sort of exception processing
(forced exception by software). To simplify the specifications and achieve
a higher speed, the uITRON specification handles it separately from
exception processing.
This function can be used to return the program control to a checkpoint for
fault tolerance.
- Other
For the uITRON specifications to keep pace with future semiconductor
technology progress, the functions must be simplified and the specifications
made flexible so that the simplified functions can be expanded. Because the
ITRON1 and ITRON2 specifications are upper levels of the uITRON
specification, expanded uITRON specification functions should conform to
ITRON1 and ITRON2 specifications. The uITRON specification is not for a
single operating system, but can be considered as a guideline to how far
away from the ITRON1 and ITRON2 specifications it can be.
The following sections explain the standard uITRON specification system
calls, but they do not set the upper limits of functions in the uITRON
specification. System calls not listed in this specification can be added.
However, if added functions are supported by the ITRON2 specification,
system call names or system call interfaces must be consistent with those in
the ITRON2 specification.
************************************
* 2.6
*
* System Call Specification Syntax *
************************************
Chapter 3 explains the specifications for each system call in the following
syntax:
****************************
* [level] System call name *
* Function
*
****************************
* A number [level] indicates the level of implementation. Number 1 signifies
one of the most important functions, and higher numbers suggest the
possibility of deletions from each implementation.
* A number in [level] suffixed by A or B indicates that it is up to
implementor whether to use specification A or B.
* A number in [level] suffixed by # indicates that the system call can be
substituted by another method. For example, def_int is suffixed by #
meaning that a substitution for the interrupt handler (for example, static
definition at operating system initialization) makes this system call
unnecessary.
[Parameter]
This section explains the system call parameters to be passed to the uITRON
specification OS when the system call is issued.
[Return parameter]

This section explains the system call return parameters (except error
conditions) to be returned from the uITRON specification OS when the system
call execution is completed.
[Description]
This section explains the function of the system call.
* The following notation is used to express multiple choices:
(x || y || z) x, y, or z
x | y
x or y or both
(If both are specified, logical OR of x and y is used.)
[x]
x or none
Example:
wfmode := (TWF_ANDW || TWF_ORW)|[TWF_CLR] specifies that
wfmode be one of the four possible parameters listed below.
TWF_ANDW
TWF_ORW
(TWF_ANDW | TWF_CLR)
(TWF_ORW | TWF_CLR)
* The uITRON specification permits part of the functions described in
Description to be implemented. This must be explicitly written in the
manual. If an unsupported function of a system call is used, the E_NOSPT
error code is returned.
* In Description, an assumption is made that no interrupt occurs during
execution of a system call, nor causes the same object to be manipulated.
Suppose that an interrupt occurs during or immediately before or after a
system call is executed. Then, the system call function may have too many
cases to be explained. For example, an explanation might state that the
resource count becomes four when the sig_sem (rcnt=1) system call is issued
to a semaphore with resource count = 3. This explanation is incorrect if an
interrupt occurs during system call execution and sig_sem is executed.
Description explains the operation with the assumption that no interrupt
occurs during execution.
[Error codes]
This section explains errors that may occur during system call execution.
* The following error codes are for errors which are common to each system
call. They are not written in the specifications of individual system
calls.
E_SYS
E_RSFN
E_CTX

E_NOSPT

Error with unknown cause, which may affect the entire system
Error occurring if a reserved function code number is specified
Context error indicating that the context does not match the system
call (task/task-independent portion and handler execution status)
For a system call which possibly generates a context error, this
code appears in the error code explanation of the system call.
In the ITRON2 and uITRON specifications, implementation- dependent
system calls can be issued from the task-independent portion.
If such a system call is issued in the implementation which does not
support the context, the E_CTX or E_XNOSPT error code is also
returned.
Error occurring if an unsupported function is specified. The uITRON
specification permits part of the system call functions to be
implemented, so partial implementation of a system call may cause

this error.
* The uITRON specification does not detail error checking to avoid heavy
restrictions on the implementation and performance degradation. Therefore,
standard error codes are proposed, and those codes given in this section
need not be strictly followed. Depending on the implementation, some error
codes might not be supported, or error codes other than the standard code
might be supported, or error-detection conditions might differ slightly.
* The error codes in this
mean that all the codes
implementation or error
E_TNOSPT does not occur

section cover all possible errors. This does not

need to be generated. Because of the differences in
detection, some errors may not occur. For example,
in wai_tsk if a timer is always available.

******************************************************************************
*
ITRON Specification
*
*
microITRON
*
*
Ver. 2.01.00.00
*
*
*
*
Document number: MI-10-01-E (File#1)
*
******************************************************************************