Mitron 2

******************************************************************************
*
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.
******************************************************************************
* Chapter 3
*
*
*
* System Call
*
******************************************************************************
This chapter explains the system calls provided in uITRON specification.
****************************
* 3.1
*
* Task Management Function *
****************************
This section explains system calls related to task management.
Level
----2
2
3
System call
----------sta_tsk
ext_tsk
ter_tsk
Parameter or
return parameter
(marked =)
---------------tskid
tskid
Function
-----------------------------Start task
Exit task
Terminate task
3
#3
chg_pri
ichg_pri
3
#3
rot_rdq
irot_rdq
5
#5
rel_wai
irel_wai
3
3
get_tid
tsk_sts
tskid tskpri
tskid tskpri
Change task priority

(for task-independent portion)
tskpri
Rotate ready queue
tskpri
Rotate ready queue
tskid
Release wait
tskid
Release wait
tskid=
Get task ID number
tskid tskpri= tskstat= Get task status
***************
* [2] sta_tsk *
* Start task *
***************
[Parameter]
tskid
TaskIdentifier
Task ID number
[Return parameter]
None
[Description]
In sta_tsk, the task indicated by tskid starts. That is, the task changes
from the dormant to the ready state.
This system call does not queue start requests. Therefore, if a start
request is issued by a caller task but the task indicated by tskid is not in
the dormant state, the E_NODMT error is returned to the caller task.
In the uITRON specification, tasks are created statically at system
activation. Parameters needed at task creation, such as the task start
address (stadr) and the initial priority (itskpri), are specified statically
at system activation.
The uITRON specification task states are a subset of the ITRON1
specification. The following states, other than nonexistent, are included in
the uITRON specification:
RUN
READY
WAIT
DORMANT
SUSPEND
WAIT-SUSPEND
However, in some implementations, there may be no dormant or suspend
(wait-suspend) state.
[Error codes]
E_OK
E_RSID
E_IDOVR
E_NOEXS
Normal termination
Reserved ID number (depends on implementation)
Outside ID range (depends on implementation)
Object does not yet exist (task indicated by tskid does not
exist)
E_NODMT Task is not dormant (task indicated by tskid is not dormant)
***************
* [2] ext_tsk *
* Exit task *
***************
[Parameter]
None
[Return parameter]
* Does not return to the context in which the system call was issued.
[Description]
The caller task exits, and moves to the dormant state.
In ext_tsk, resources (for example, memory block and semaphore) that the task
has acquired are not automatically released.
In the ret_xxx and ext_tsk system calls, the user must also check for an
error code, even when an error code is returned after an error is detected.
Otherwise the program will run wild. It is preferable that these system
calls not be returned to their issuer even when an error is detected.
[Error codes]
* The following error may be detected. However, control does not return to
the context in which the system call was issued. Hence, the error code
cannot be returned directly as a system call return parameter. Operation
when the error is detected depends on the implementation.
E_CTX
Context error (issued by task-independent portion)
******************
* [3] ter_tsk
*
* Terminate task *
******************
[Parameter]
tskid
TaskIdentifier
Task ID number
[Return parameter]
None
[Description]
In ter_tsk, the task indicated by tskid is forcibly terminated.
As in ext_tsk, resources acquired by the task indicated by tskid (for
example, memory block and semaphore) are not automatically released when the
task is terminated by ter_tsk.
When the task indicated by tskid has entered the wait state and is linked to
a queue, it may be deleted from the queue by executing ter_tsk. In other
words, task wait is released.
In this system call, the caller task cannot be specified.
[Error codes]
E_OK
E_RSID
E_IDOVR
E_NOEXS
E_DMT
E_SELF
Normal termination
exist)
Task is dormant (task indicated by tskid is dormant)
The caller task was specified (0 or the caller task ID number
was specified as tskid)
*******************************************************
* [3] chg_pri
*
* Change task priority
*
*-----------------------------------------------------*
* [#3] ichg_pri
*
* Change task priority (for task-independent portion) *
*******************************************************
[Parameter]
tskid
TaskIdentifier
tskpri
TaskPriority
Task ID number
Priority
[Return parameter]
None
[Description]
In chg_pri and ichg_pri, the current priority of the task indicated by tskid
is changed to the value indicated by tskpri. tskid = TSK_SELF specifies the
caller task.
The lower the number, the higher the task priority. If the task indicated by
tskid is linked to a queue, the order of the queue may be changed by this
system call, depending on the wait queue.
When tskpri = TPRI_INI(0) is specified, the task priority returns to the
initial priority specified when the system was activated (unique task
priority). This function is used in the following case: task priority is
temporarily raised to perform indivisible processing, and then returned to
the original priority.
Priority changed by this system call is valid until the task terminates.
When the task enters the dormant state, the task priority before termination
is discarded, and task priority when the next task starts becomes priority
itskpri, specified at system activation.
The task priority in the uITRON specification is, in principle, expressed in
a byte (for example, 0 to 255), but depending on the implementation or
application, the number of priorities may be fewer (for example, 1 to 4) in
order to increase the speed.
In the uITRON specification, system calls issued by task-independent portions
(interrupt handlers), ichg_pri, can be distinguished from those issued by
tasks, chg_pri. This is to improve the performance without incurring
overhead by context determination in the operating system. These system
calls should be divided into ichg_pri system calls, issued by
task-independent portions, and chg_pri system calls, issued by tasks.
This reduces the operating system overhead and speeds up the processing of
system calls issued by task-independent portions. From the user's viewpoint,
it is convenient to be able to issue chg_pri system calls from both task
portions and task-independent portions. The implementor should select which
specification to use.
[Error codes]
E_OK
E_CTX
E_TPRI
E_RSID
E_IDOVR
E_NOEXS
Normal termination
Context error (ichg_pri was issued by task portion)
Illegal task priority (illegal tskpri)
E_DMT
exist)
*****************************************************
* [3] rot_rdq
*
* rotate ready queue
*
*---------------------------------------------------*
* [#3] irot_rdq
*
* Rotate ready queue (for task-independent portion) *
*****************************************************
[Parameter]
tskpri
TaskPriority
Priority
[Return parameter]
None
[Description]
In rot_rdq and irot_rdq, the ready queue indicated by the priority tskpri is
rotated, that is, the task at the head of the ready queue of that priority is
linked to the end of the ready queue, and execution of tasks of the same
priority is switched. By issuing these system calls at fixed intervals,
round robin scheduling can be performed.
When tskpri = TPRI_RUN(0), the ready queue with the task in the run state at
the time (highest-priority ready queue) is rotated. In rot_rdq issued by
tasks, this means that the ready queue with priority of the caller task is
rotated, but if this sort of specification is used, rot_rdq (tskpri =
TPRI_RUN) can be issued by a task-independent portion, such as the cyclic
handler.
If TPRI_RUN or the caller task priority is specified as rot_rdq tskpri, the
caller task is linked to the end of the ready queue. By discarding the
execution right itself, rot_rdq can be issued. (Here, ready queue includes
the task in the run state.)
If there are no tasks in the ready queue of the specified priority, nothing
happens, but no error occurs.
[rot_rdq execution example]
Priority
High
^
|
|
v
Low
|
|
+----------+
| 1
|
+----------+
| 2
-------------> [Task B] ----> [Task C] ----> [Task D]
+----------+
| 3
-------------> [Task E]
+----------+
|
|
If this system call is issued in this status with tskpri = 2 as the parameter,
the new ready queue is:
Priority
High
^
|
|
|
|
+----------+
| 1
|
+----------+
| 2
-------------> [Task C] ----> [Task D] ----> [Task E]
+----------+
v
Low
| 3
-------------> [Task E]
+----------+
|
|
Task C will be executed next.

In the uITRON specification, system calls issued by task-independent
portions (interrupt handlers), irot_rdq, can be distinguished from those
issued by tasks, rot_rdq. This is to improve the performance without
incurring overhead by context determination in the operating system. These
system calls should be divided into irot_rdq system calls, issued by
task-independent portions, and rot_rdq system calls, issued by tasks.
system calls issued by task-independent portions. From the user's
viewpoint, it is convenient to be able to issue rot_rdq system calls from
both task portions and task-independent portions. The implementor should
select which specification to use.
[Error codes]
E_OK
E_CTX
E_TPRI
Normal termination
Context error (irot_rdq was issued by task portion)
Illegal task priority (illegal tskpri)
************************************************
* [5] rel_wai
*
* Release wait
*
*----------------------------------------------*
* [#5] irel_wai
*
* Release wait (for task-independent priority) *
************************************************
[Parameter]
tskid
TaskIdentifier
Task ID number
[Return parameter]
None
[Description]
In rel_wai and irel_wai, when the task indicated by tskid is in a wait state
(excluding the suspend state), it is forcibly released.
The E_RLWAI error is returned for tasks released from the wait state by these
system calls. A function similar to time-out can be realized by issuing
these system calls a specified time after the task has entered the wait
state, using the alarm handler.
Wait release request queuing using these system calls is not performed.
The wait state is released if the task indicated by tskid is already in the
wait state, but if it is not in the wait state, the E_NOWAI error is returned
to the caller. E_NOWAI is also returned when the caller task is specified by
these system calls.
The suspend state is not released by these system calls. If these system
calls are issued for a task in the wait-suspend state, the task enters the
suspend state. If the suspend state should also be released, frsm_tsk must
be issued.
The differences between rel_wai (irel_wai) and wup_tsk (iwup_tsk) are as
follows:
- wup_tsk releases only the wait state of slp_tsk and wai_tsk, but rel_wai
releases the wait state of them and other system calls (wai_flg, wai_sem,
rcv_msg, and get_blk, for example).
- Viewed from the task that was in the wait state, wait release by rel_wai is
the E_RLWAI error, whereas wait release by the wup_tsk is normal
termination.
- In wup_tsk, requests are enqueued even if slp_tsk or wai_tsk has not been
executed for the task indicated by tskid. If the task is not already in
the wait state in rel_wai, an error occurs.
(interrupt handlers), irel_wai, can be distinguished from those issued by
tasks, rel_wai. This is to improve the performance without incurring
calls should be divided into irel_wai system calls, issued by
task-independent portions, and rel_wai system calls, issued by tasks.
it is convenient to be able to issue rel_wai system calls from both task
[Error codes]
E_OK
E_CTX
E_RSID
E_IDOVR
E_NOEXS
Normal termination
Context error (irel_wai was issued by task portion)
exist)
E_DMT
E_NOWAI Task is not in the wait state (includes case when the caller
task ID number was specified as tskid)
**********************
* [3] get_tid
*
* Get task ID number *
**********************
[Parameter]
None
[Return parameter]
tskid
TaskIdentifier
Task ID number
[Description]
In get_tid, the caller task ID number is obtained. If get_tid is issued by a
task-independent portion, 0 is returned as tskid.
[Error codes]
E_OK
Normal termination
*******************
* [3] tsk_sts
*
* Get task status *
*******************
[Parameter]
tskid
TaskIdentifier
Task ID number
[Return parameter]
tskpri
TaskPriority
tskstat TaskState
Task priority
Task state
[Description]
In tsk_sts, the status of the task indicated by tskid are referenced, and the
current task priority, tskpri, and task status, tskstat, are returned as
return parameters.
Two interfacing methods are provided for this system call: the tskpri and
tskstat information is read together using packets, or the information is
read individually.
The following values are standard for tskstat:
tskstat:
TTS_RUN
TTS_RDY
TTS_WAI
TTS_SUS
TTS_WAS
TTS_DMT
Run state
Ready state
Wait state
Suspend state
Wait-suspend state
Dormant state
TTS_RUN, TTS_WAI, and other values are defined as tskstat, but this does not
mean that the same values must be placed in the TCB. The method of
expression of the status of the task in the TCB depends on the
implementation; at tsk_sts execution, the values can be translated to
standard values such as TTS_RUN and TTS_WAI.
Depending on the implementation, the following information may be referenced
in addition to tskpri and tskstat:
tskatr
itskpri
suscnt
wupcnt
/*
/*
/*
/*
Task attribute */
Initial task priority */
Suspend request count */
Wakeup request count */
tskid = TSK_SELF specifies the caller task, but the caller task ID number is
not known in this system call. To find out the caller task ID number, use
get_tid.
In tsk_sts, the E_NOEXS error is returned if the task indicated by tskid does
not exist.
[Error codes]
E_OK
Normal termination
E_RSID Reserved ID number (depends on implementation)
E_ILADR Illegal address (value where packet address for return
parameters cannot be used)
E_IDOVR Outside ID range (depends on implementation)
E_NOEXS Object does not yet exist (task indicated by tskid does not
exist)
********************************************
* 3.2
*
* Task-Dependent Synchronization Functions *
********************************************
This section explains the system calls for the synchronization function
related to tasks.
System call
----------sus_tsk
isus_tsk
Parameter or
return parameter
(marked =)
---------------tskid
tskid
3
#3
rsm_tsk
irsm_tsk
tskid
tskid
4
1
3
1
#1
frsm_tsk
slp_tsk
wai_tsk
wup_tsk
iwup_tsk
tskid
can_wup
tskid wupcnt=
Level
----3
#3
tmout
tskid
tskid
Function
-----------------------------Suspend task
Suspend task
Resume task
Resume task
Force resume task
Sleep task
Wait for wakeup task
Wakeup task
Wakeup task
Cancel wakeup task
***********************************************
* [3] sus_tsk
*
* Suspend task
*
*---------------------------------------------*
* [#3] isus_tsk
*
* Suspend task (for task-independent portion) *
***********************************************
[Parameter]
tskid
TaskIdentifier
Task ID number
[Return parameter]
None
[Description]
In sus_tsk and isus_tsk, execution of the task indicated by tskid is
suspended, and the task enters the suspend state. The suspend state is
released when the rsm_tsk or frsm_tsk system call is issued. The suspend
state means that execution is suspended by system calls of other tasks.
The caller task cannot be specified with these system calls.
Whether sus_tsk requests are enqueued and the number of times they may be
enqueued depends on the implementation. That is, if sus_tsk has already
been issued for a task in the suspend state, either the E_QOVR error is
returned or the task enters the multiple suspend state. This depends on the
implementation. If the task enters the multiple suspend state, pairs of
sus_tsk and rsm_tsk may be nested to return to the original state if rsm_tsk
is issued the same number of times that sus_tsk is issued (suscnt).
Resources are assigned to tasks in the wait-suspend state in the same way as
to tasks in the wait state. When resources are assigned, the task moves to
the suspend state. No special treatment is given to tasks in the
wait-suspend state (for example, delayed resource assignment), for the
following reasons:
- Semantic problem of system calls
Because the suspend state is interrelated with other states, changing its
specifications may affect other state specifications.
- Necessary action can be realized by combined system calls.
To lower the priority of a task in the suspend state temporarily, combine

sus_tsk, rsm_tsk, and chg_pri at the user task level.
(interrupt handlers), isus_tsk, can be distinguished from those issued by
tasks, sus_tsk. This is to improve the performance without incurring
calls should be divided into isus_tsk system calls, issued by
task-independent portions, and sus_tsk system calls, issued by tasks. This
reduces the operating system overhead and speeds up the processing of system
calls issued by task-independent portions. From the user's viewpoint, it is
convenient to be able to issue sus_tsk system calls from both task portions
and task-independent portions. The implementor should select which
[Error codes]
E_OK
E_CTX
E_RSID
E_IDOVR
E_NOEXS
E_DMT
E_SELF
E_QOVR
Normal termination
Context error (isus_tsk was issued by task portion)
exist)
Queue overflow (queuing not possible, suscnt overflow)
**********************************************
* [3] rsm_tsk
*
* Resume task
*
*--------------------------------------------*
* [#3] irsm_tsk
*
* Resume task (for task-independent portion) *
*--------------------------------------------*
* [4] frsm_tsk
*
* Force resume task
*
**********************************************
[Parameter]
tskid
TaskIdentifier
Task ID number
[Return parameter]
None
[Description]
In rsm_tsk, irsm_tsk, and frsm_tsk, when the task indicated by tskid has been
suspended, the suspend state of the task is released, and execution resumes.
In these system calls, the caller task cannot be specified.
In rsm_tsk, one sus_tsk request is released. Hence, if sus_tsk has been
issued twice or more for the same task (suscnt >= 2), the task remains in the
suspend state even after the rsm_tsk has ended. In frsm_tsk, all sus_tsk
requests are released. That is, suscnt is 0 even if sus_tsk has been issued
twice or more for the same task (suscnt >= 2). In other words, the suspend
state is always released, and execution of the task resumes as long as it is
not in the wait state (wait-suspend state).
(interrupt handlers), irsm_tsk, can be distinguished from those issued by
tasks, rsm_tsk. This is to improve the performance without incurring

calls should be divided into irsm_tsk system calls, issued by
task-independent portions, and rsm_tsk system calls, issued by tasks.
it is convenient to be able to issue rsm_tsk system calls from both task
[Error codes]
E_OK
E_CTX
E_RSID
E_IDOVR
E_NOEXS
Normal termination
Context error (irsm_tsk was issued by task portion)
exist)
E_DMT
E_NOSUS Task is not suspended (includes case when the caller task ID
number was specified as tskid)
************************
* [1] slp_tsk
*
* Sleep task
*
*----------------------*
* [3] wai_tsk
*
* Wait for wakeup task *
************************
[Parameter]
1 tmout Timeout
Time-out specification
[1 wai_tsk only]
[Return parameter]
None
[Description]
In slp_tsk, the caller task moves from the run state to the wait state.
The wait state is released when the wup_tsk (iwup_tsk) or rel_wai (irel_wai)
system call is issued addressing this task.
In wai_tsk, the caller task moves from the run state to the wait state for
the specified time. The wait state is released when the wup_tsk (iwup_tsk)
system call is issued addressing this task, when the rel_wai (irel_wai)
system call is issued addressing this task, or when the time specified by
tmout has elapsed. When wup_tsk (iwup_tsk) is issued, the system call
terminates normally; when time-out occurs, the time-out error E_TMOUT is
returned. This system call is the slp_tsk system call with the time-out
function added. It can be used for simple delays.
The number of wai_tsk tmout bits and data type (signed or unsigned) depends
on the implementation. In some implementations, time-out is not specified by
tmout = TMO_FEVR. In this case, operation is the same as slp_tsk because
permanent wait occurs until wup_tsk is issued.
Because this specification is for the caller task only, slp_tsk and wai_tsk
nesting is not possible, but when a task enters the wait state because of
slp_tsk or wai_tsk, sus_tsk may be executed by another task. In this case,
the task stays in the suspend state even if the wait state is released by
wup_tsk, and task execution does not resume until rsm_tsk (irsm_tsk,
frsm_tsk) is issued.
[Error codes]
E_OK
E_TNOSPT
E_ILTIME
E_CTX
E_TMOUT
E_RLWAI
Normal termination
Timer functions not supported (timer cannot be used)
Illegal time specification (depends on implementation)
Time-out
Wait state forced release (rel_wai accepted during wait)
***********************************************
* [1] wup_tsk
*
* Wake up task
*
*---------------------------------------------*
* [#1] iwup_tsk
*
* Wake up task (for task-independent portion) *
***********************************************
[Parameter]
tskid
TaskIdentifier
Task ID number
[Return parameter]
None
[Description]
In wup_tsk and iwup_tsk, the task in the wait state entered by slp_tsk or
wai_tsk is moved to the ready state. The task is indicated by tskid.
The caller task cannot be specified with this system call.
If the task indicated by tskid is not in the wait state and slp_tsk or
wai_tsk is not executed, the wup_tsk request is enqueued. The wup_tsk
request becomes valid later when the task executes the slp_tsk or wai_tsk
system call. When wup_tsk is executed, the wakeup request count of the task
is incremented by one. When the task executes slp_tsk or wai_tsk, the wakeup
request count of the task is decremented by one. The task enters the wait
state when the wakeup request count is about to change to -1.
The maximum enqueued wakeup request count (wupcnt) depends on the
implementation, but queuing can be performed at least once. Whether queuing
can be performed twice or more depends on the implementation.
(interrupt handlers), iwup_tsk, can be distinguished from those issued by
tasks, wup_tsk. This is to improve the performance without incurring
calls should be divided into iwup_tsk system calls, issued by
task-independent portions, and wup_tsk system calls, issued by tasks.
it is convenient to be able to issue wup_tsk system calls from both task
[Error codes]
E_OK
E_CTX
E_RSID
E_IDOVR
E_NOEXS
E_DMT
Normal termination
Context error (iwup_tsk was issued by task portion)
exist)
E_SELF
E_QOVR

Queue overflow (wupcnt overflow)
**********************
* [3] can_wup
*
* Cancel Wakeup task *
**********************
[Parameter]
tskid
TaskIdentifier
Task ID number
[Return parameter]
wupcnt
Wakeup Count
Enqueued wakeup request count
[Description]
In can_wup, the wakeup request count enqueued in the task indicated by tskid
is returned as the return parameter, and all wakeup requests are released at
the same time. tskid = TSK_SELF specifies the caller task.
This system call is used to examine whether processing has ended within the
set time in cyclic wakeup (whether the next wakeup request has been generated
before slp_tsk for the preceding wakeup request has been executed).
If wupcnt, the return parameter of can_wup, is not 0, a preceding wakeup
request has not been processed within the set time, suggesting that some
action must be taken.
[Error codes]
E_OK
E_RSID
E_IDOVR
E_NOEXS
E_DMT
Normal termination
exist)
***********************************************
* 3.3
*
* Synchronization and Communications Function *
***********************************************
This section explains the system calls for the synchronization and
communications functions.
System call
----------set_flg
iset_flg
Parameter/return
parameter (marked =)
-------------------flgid setptn
flgid setptn
3A
3A
clr_flg
wai_flg
flgid
flgid
3A
pol_flg
flgid
4A
3B
#3B
flg_sts
set_flg
iset_flg
flgid
flgid
flgid
3B
3B
clr_flg
wai_flg
flgid
flgid
Level
----3A
#3A
Function
-----------------------------Set event flag (word)
Set event flag (word)
clrptn
Clear event flag (word)
waiptn flgptn= wfmode
Wait event flag (word)
waiptn flgptn= wfmode
Poll event flag (word)
wtskid= flgptn=
Get event flag status (word)
Set event flag (bit)
Clear event flag (bit)
Wait event flag (bit)
3B
3B
3B
4B
cwai_flg
pol_flg
cpol_flg
flg_sts
flgid
flgid
flgid
flgid wtskid= flgptn=
1
#1
sig_sem
isig_sem
semid
semid
1
1
4
wai_sem
preq_sem
sem_sts
semid
semid
semid wtskid= semcnt=
2
#2
snd_msg
isnd_msg
mbxid pk_msg
mbxid pk_msg
2
2
rcv_msg
prcv_msg
mbxid pk_msg=
mbxid pk_msg=
mbx_sts
mbxid wtskid= pk_msg=
5
#5
snd_tmb
isnd_tmb
tskid pk_msg
tskid pk_msg
rcv_tmb
pk_msg=
prcv_tmb
pk_msg=
tmb_sts
tskid tmbwait= pk_msg=
Wait and clear event flag (bit)

Poll event flag (bit)
Poll and clear event flag (bit)
Get event flag status (bit)
Signal semaphore
Signal semaphore
Wait on semaphore
Poll and request semaphore
Get semaphore status
Send message to mailbox
Receive message from mailbox
Poll and receive message from
mailbox
Get mailbox status
Send message to task mailbox
Receive message from task
mailbox
task mailbox
Get task mailbox status
*******************************************************
* [3A] set_flg
*
* Set event flag (word)
*
*-----------------------------------------------------*
* [#3A] iset_flg
*
* Set event flag(word) (for task-independent portion) *
*-----------------------------------------------------*
* [3A] clr_flg
*
* Clear event flag(word)
*
*******************************************************
[Parameter]
flgid
EventFlagIdentifier
1 setptn SetBitPattern
2 clrptn ClearBitPattern
[1 set_flg only]
[2 clr_flg only]
Event flag ID number

Set bit pattern
Clear bit pattern
[Return parameter]
None
[Description]
In set_flg, the '1' bits indicated by setptn in the word event flag indicated
by flgid are set. That is, the setptn value is ORed with the word event flag
value indicated by flgid. In clr_flg, the '0' bits indicated by clrptn in
the word event flag indicated by flgid are cleared. That is, the clrptn
value is ANDed with the event flag value indicated by flgid.
In set_flg, if the wait release condition of the task waiting for the event
flag is fulfilled as a result of the event flag value change, the task moves
to the ready state. In the event flag, it is possible to wait for an event
with ORed or ANDed bit condition. Also if all bits in the event flag are
used, simple messages of one word can be transferred (no queuing).
In clr_flg, tasks that are waiting for the event flag are not released from
wait, that is, dispatching does not occur.
When all bits of setptn are 0 in set_flg or when all bits of clrptn are 1 in
clr_flg, no operation occurs for the event flag indicated by flgid. No error
occurs.
Multiple tasks can wait for the same event flag. Hence, tasks can form a
queue for the event flag. One set_flg can, therefore, release multiple tasks
from the wait state.
In the uITRON specification, event flags are created statically at system
activation. In the uITRON specifications, both word and single-bit event
flag specifications are provided. The implementor can select whichever is
required and support it. To implement high-level functions that are close to
the ITRON1 or ITRON2 specifications, the word event flag is better, while to
implement a high-speed event flag that does not require much memory, the
single-bit event flag is better.
(interrupt handlers), iset_flg, can be distinguished from those issued by
tasks, set_flg. This is to improve the performance without incurring
calls should be divided into iset_flg system calls, issued by
task-independent portions, and set_flg system calls, issued by tasks.
it is convenient to be able to issue set_flg system calls from both task
[Error codes]
E_OK
E_CTX
E_RSID
E_IDOVR
E_NOEXS
Normal termination
Context error (iset_flg was issued by task portion)
Object does not yet exist (event flag indicated by flgid does
not exist)
**************************
* [3A] wai_flg
*
* Wait event flag (word) *
*------------------------*
* [3A] pol_flg
*
* Poll event flag (word) *
**************************
[Parameter]
flgid
EventFlagIdentifier
waiptn
WaitBitPattern
wfmode
WaitEventFlagMode

Wait bit pattern
Wait mode
[Return parameter]
flgptn
EventFlagBitPattern
Bit pattern at wait release
[Description]
In wai_flg, following the wait condition indicated by wfmode, the task waits
for the event flag indicated by flgid to be set.
The following specifications are available for wfmode:
wfmode: = (TWF_ANDW || TWF_ORW) | [TWF_CLR]
TWF_ANDW AND wait
TWF_ORW
OR wait
TWF_CLR
Clear specification
If TWF_ORW is specified, the task waits for one of the bits specified by
waiptn in the event flag indicated by flgid to be set. If TWF_ANDW is
specified, the task waits for all of the bits specified by waiptn in the
event flag indicated by flgid to be set.
If TWF_CLR is not specified, the event flag value remains the same even if
the condition is fulfilled and task wait is released. If TWF_CLR is
specified, the event flag value (all bits) is cleared to zero when the
condition is fulfilled and task wait is released.
Time-out cannot be specified in the uITRON specification wai_flg. Permanent
wait occurs if the condition is not fulfilled. The pol_flg system call
provides an immediate return even when the condition is not fulfilled.
The pol_flg parameters have the same meaning as the wai_flg parameters.
In pol_flg, if the wait condition has been fulfilled, normal termination
occurs; if the wait condition has not been fulfilled, the E_PLFAIL error is
returned without entering the wait state. The flag is cleared by TWF_CLR
specification only at normal termination of pol_flg.
flgptn is the return parameter that indicates the event flag value (the value
before the event flag is cleared when TWF_CLR has been specified) when the
wait state has been released by this system call. The value returned by
flgptn fulfills the system call wait release condition.
Multiple task wait for one event flag is available. In this case, multiple
tasks may be released from wait by one set_flg. The task queue is defined in
the event flag, and performs the following operation:
- The order of the queue is FIFO. However, depending on the specified waiptn
and wfmode, the task at the head of the queue is not always released first
from wait.
- If there is a clear-specified task in the queue, the flag is cleared when
that task wait is released.
- Tasks in the queue behind the clear-specified task cannot be released from
wait because those tasks examine the event flag after it has already been
cleared.
Multiple task wait for one event flag is effectively used as follows.
For example, when tasks B and C are made to wait by wai_flg at 2 and 3
until task A executes set_flg at 1 (figure below), the result is the same
for whichever of system calls 1 , 2 , or 3 is executed first. If multiple
wait is not possible, wai_flg at 3 causes an error if the system call is
executed in the order 2 , 3 , 1 .
[Task A]
|
|
1 set_flg
[Task B]
|
|
2 wai_flg
[Task C]
|
|
3 wai_flg
|
|
|
|
|
|
|
|(not cleared)
|
|
|
|
|(not cleared)
|
|
When waiptn is 0, it is not possible to escape from the wait state by using
set_flg, so the E_PAR error is returned. Hence, if all bits are set by
set_flg, wait release is guaranteed for any task at the head of the queue
regardless of the wait condition in the event flag.
[Error codes]
E_OK
E_RSMD
E_RSID
E_PAR
E_IDOVR
E_NOEXS
Normal termination
Reserved mode or option (illegal wfmode)
Parameter error (waiptn = 0)
not exist)
E_CTX
E_RLWAI Forced release of wait state (rel_wai accepted during wait)
E_PLFAIL Polling failed
********************************
* [4A] flg_sts
*
* Get event flag status (word) *
********************************
[Parameter]
flgid
EventFlagIdentifier
[Return parameter]
wtskid
WaitTaskID
flgptn
EventFlagBitPattern
Wait task ID number

Event flag bit pattern
[Description]
In flg_sts, the statuses of the event flag indicated by flgid are referenced,
and the current flag value, flgptn, and wait task ID number, wtskid, of the
event flag are returned as return parameters.
Two interfacing methods are provided for this system call: the flgptn and
wtskid information is read together using a packet, or the information is
read individually.
The ID number of the task at the head of the queue is returned by wtskid.
That is, the ID number of the task that entered the wait state first of the
tasks waiting for the event flag is returned. NOTSK(0) is returned when no
tasks are waiting.
In some implementations, it may be possible to read other information in
addition to flgptn or wtskid.
If there is no event flag indicated by flgid in flg_sts, the E_NOEXS error is
returned.
[Error codes]
E_OK
E_RSID
E_ILADR
Normal termination
Illegal address (value where packet address for return
parameter cannot be used)
E_IDOVR
E_NOEXS

not exist)
********************************************************
* [3B] set_flg
*
* Set event flag (bit)
*
*------------------------------------------------------*
* [#3B] iset_flg
*
* Set event flag (bit) (for task-independent portion) *
*------------------------------------------------------*
* [3B] clr_flg
*
* Clear event flag (bit)
*
********************************************************
[Parameter]
flgid
EventFlagIdentifier
[Return parameter]
None
[Description]
In set_flg, the single-bit event flag indicated by flgid is set. In clr_flg,
the single-bit event flag indicated by flgid is cleared.
In set_flg, if there is a task waiting for the event flag by wai_flg or
cwai_flg, that task wait is released and moves to the ready state.
In clr_flg, tasks that are waiting for the event flag are not released from
wait, that is, dispatching does not occur.
In the single-bit event flag, events and event flag bits have one-to-one
correspondence, and ORed or ANDed wait is not permitted. To perform ORed or
ANDed wait for simple events, a combination of several set_flg operations or
wai_flg or cwai_flg operations may realize the desired operation.
Multiple tasks can wait for the same event flag. Hence, tasks can form a
queue for the event flag. One set_flg may release multiple tasks from wait.
In the uITRON specification, event flags are created statically at system
activation. Because the uITRON specification provides both word and
single-bit event flag specifications, the implementor can select whichever is
required and support it. To implement high-level functions that are close to
the ITRON1 or ITRON2 specifications, the word event flag is better, while to
implement a high-speed event flag that does not require much memory, the
single-bit event flag is better.
(interrupt handlers), iset_flg, can be distinguished from those issued by
tasks, set_flg. This is to improve the performance without incurring
calls should be divided into iset_flg system calls, issued by
task-independent portions, and set_flg system calls, issued by tasks.
it is convenient to be able to issue set_flg system calls from both task
[Error codes]
E_OK
Normal termination
E_CTX
E_RSID
E_IDOVR
E_NOEXS
Context error (iset_flg was issued by task portion)

not exist)
***********************************
* [3B] wai_flg
*
* Wait event flag (bit)
*
*---------------------------------*
* [3B] cwai_flg
*
* Wait and clear event flag (bit) *
*---------------------------------*
* [3B] pol_flg
*
* Poll event flag (bit)
*
*---------------------------------*
* [3B] cpol_flg
*
* Poll and clear event flag (bit) *
***********************************
[Parameter]
flgid
EventFlagIdentifier
[Return parameter]
None
[Description]
In wai_flg and cwai_flg, the event flag indicated by flgid is set to 1.
In wai_flg, the event flag value remains the same even if the event flag is
set and task wait is released. In cwai_flg, the event flag value is cleared
to zero when the flag is set and task wait is released.
Time-out cannot be specified in the uITRON specification wai_flg or cwai_flg.
Permanent wait occurs if the event flag is not set. The pol_flg or cpol_flg
system call provides an immediate return even when the event flag is not
fulfilled. The pol_flg and cpol_flg parameters have the same meaning as the
wai_flg and cwai_flg parameters. In pol_flg and cpol_flg, if the event flag
has been set, normal termination occurs; if it has not been set, the E_PLFAIL
error is returned without entering the wait state. In cpol_flg, the event
flag is cleared only after normal termination. While the event flag is
cleared in cpol_flg, the event flag value is only referenced in pol_flg.
Hence, the pol_flg function can be used instead of flg_sts, as follows, but
it is a separate system call because of the parameters and symmetry.
Multiple task wait for one event flag is available. In this case, multiple
tasks may be released from wait by one set_flg. The task queue is defined in
the event flag, and performs the following operation:
- The order of the queue is FIFO. In the single-bit event flag, the task at
the head of the queue is always released first from wait.
- If there is a clear-specified task (task made to wait by cwai_flg) in the
queue, the flag is cleared when that task wait is released.
- Tasks in the queue behind the clear-specified task cannot be released from
wait because those tasks examine the event flag after it has already been
cleared.
In the single-bit event flag, the task at the head of the queue is always
released first.
Multiple task wait for one event flag is effectively used as follows. For
example, when tasks B and C are made to wait by wai_flg at 2 and 3 until
task A executes set_flg at 1 (figure below), the result is the same for
whichever of system calls 1 , 2 , or 3 is executed first. If multiple wait
is not possible, wai_flg at 3 causes an error if the system call is executed
in the order 2 , 3 , 1 .
[Task A]
|
|
1 set_flg
|
|
|
|
[Task B]
[Task C]
|
|
|
|
2 wai_flg
3 wai_flg
|
|
|(not cleared)
|(not cleared)
|
|
|
|
[Error codes]
E_OK
E_RSID
E_IDOVR
E_NOEXS
Normal termination
not exist)
E_CTX
*******************************
* [4B] flg_sts
*
* Get event flag status (bit) *
*******************************
[Parameter]
flgid
EventFlagIdentifier
[Return parameter]
wtskid
WaitTaskID
flgptn
EventFlagBitPattern
Wait task ID number

Event flag bit pattern
[Description]
In flg_sts, the statuses of the event flag indicated by flgid are referenced,
and the current flag value (one bit), flgptn, and wait task ID number,
wtskid, of the event flag are returned as return parameters.
Two interfacing methods are provided for this system call: the flgptn and
read individually.
That is, the ID number of the task that entered the wait state first of the
tasks waiting for the event flag is returned. NOTSK(0) is returned when no
tasks are waiting.
In some implementations, it may be possible to read information in addition
to flgptn or wtskid.
If there is no event flag indicated by flgid in flg_sts, the E_NOEXS error is
returned.
[Error codes]
E_OK
Normal termination
E_NOEXS Object does not yet exist (event flag indicated by flgid does
not exist)
***************************************************
* [1] sig_sem
*
* Signal semaphore
*
*-------------------------------------------------*
* [#1] isig_sem
*
* Signal semaphore (for task-independent portion) *
***************************************************
[Parameter]
semid
SemaphoreIdentifier
Semaphore ID number
[Return parameter]
None
[Description]
In sig_sem and isig_sem, if there are tasks waiting for the semaphore
indicated by semid, the task at the head of the queue enters the ready state.
If there are no tasks waiting, the semaphore count (semcnt) is incremented by
one.
Even if the count exceeds isemcnt specified at system activation because of
an increment in the semaphore count, it is not treated as an error.
This occurs because it is assumed that semaphore is used for synchronization
(in the same way as wup_tsk and slp_tsk), not for resource management.
When the resource count is reset dynamically after semaphore has been
created, the count is sometimes greater than the initial semaphore count.
If the semaphore count (semcnt) exceeds the upper limit set by the
implementation, the E_QOVR error is returned.
In uITRON specification, semaphore is created statically at system
activation. Parameters necessary for semaphore creation, such as initial
semaphore count (isemcnt) are also specified statically at system activation.
In uITRON specification semaphore, the standard wait task queuing is FIFO
(TA_TFIFO). However, in some implementations, task priority (TA_TPRI)
queuing may be selected. In uITRON specification wai_sem, the resource
request count (rcnt) is fixed to 1, so the distinction made in ITRON2
specification between TA_FIRST, where the task at the head of the queue takes
priority, and TA_CNT, where the task with the lowest request count takes
priority, is meaningless.
(interrupt handlers), isig_sem, can be distinguished from those issued by
tasks, sig_sem. This is to improve the performance without incurring
calls should be divided into isig_sem system calls, issued by
task-independent portions, and sig_sem system calls, issued by tasks.
it is convenient to be able to issue sig_sem system calls from both task
[Error codes]
E_OK
E_CTX
E_RSID
E_IDOVR
E_NOEXS
E_QOVR
Normal termination
Context error (isig_sem was issued by task portion)
exist)
Queue overflow (semcnt overflow)
******************************
* [1] wai_sem
*
* Wait on semaphore
*
*----------------------------*
* [1] preq_sem
*
* Poll and request semaphore *
******************************
[Parameter]
semid
SemaphoreIdentifier
Semaphore ID number
[Return parameter]
None
[Description]
In wai_sem, if the count of the semaphore indicated by semid is greater than
or equal to 1, it is decremented by 1, and the task that issued this system
call continues execution. If the semaphore count is 0, the count is not
changed, and the task that issued this system call is linked to the queue.
The standard queuing is FIFO.
Time-out cannot be specified in the uITRON specification wai_sem. Permanent
wait occurs if the condition is not fulfilled. The preq_sem system call
provides an immediate return even when the condition is not fulfilled.
In preq_sem, if the count of the semaphore indicated by semid is greater than
or equal to 1, it is decremented by 1, and the task that issued this system
call terminates normally. If the semaphore count is 0, the E_PLFAIL error is
returned, and the semaphore count remains 0.
In the ITRON2 specification, the preq_sem function is realized by specifying
wai_sem (tmout = TMO_POL), but in uITRON specification, it is a separate
system call because time-out cannot be specified by wai_sem. While sem_sts
only references the semaphore count, preq_sem acquires resources when they
can be acquired (if the semaphore count is positive, it is decremented by 1).
[Error codes]
E_OK
E_RSID
E_IDOVR
E_NOEXS
Normal termination
Object does not yet exist (semaphore indicated by semid does
not exist)
E_CTX
************************
* [4] sem_sts
*
* Get semaphore status *
************************
[Parameter]
semid
SemaphoreIdentifier
Semaphore ID number
[Return parameter]
wtskid
WaitTaskID
semcnt
SemaphoreCount
Wait task ID number

Current semaphore count
[Description]
In sem_sts, the statuses of the semaphore indicated by semid are referenced,
and the current count of the semaphore, semcnt, and wait task ID number,
wtskid, are returned as return parameters.
Two interfacing methods are provided for this system call: the semcnt and
read individually.
That is, in a FIFO queue, the ID number of the task that entered the wait
state first of the tasks waiting for the semaphore is returned. NOTSK(0) is
returned when no tasks are waiting. Either semcnt or wtskid or both must
be 0.
to semcnt or wtskid.
If there is no semaphore indicated by semid in sem_sts, the E_NOEXS error is
returned.
[Error codes]
E_OK
Normal termination
parameter Cannot be used)
E_NOEXS Object does not yet exist (semaphore indicated by semid does
not exist)
**********************************************************
* [2] snd_msg
*
* Send message to mailbox
*
*--------------------------------------------------------*
* [#2] isnd_msg
*
* Send message to mailbox (for task-independent portion) *
**********************************************************
[Parameter]
mbxid
MailboxIdentifier
pk_msg
MessagePacket
Mailbox ID number
Start address of send message
[Return parameter]
None
[Description]
In snd_msg and isnd_msg, the message at the pk_msg address is sent to the
mailbox indicated by mbxid. The contents of the message are not copied;
only the address (pk_msg value) is transferred.
When there are no tasks waiting for messages in the mailbox indicated by
mbxid, any task that issues snd_msg does not enter the wait state. In this
system call, messages are placed in the mailbox, and linked to a queue called
the message queue. The task then continues execution. Messages are linked
to the queue; the task itself is not linked to the queue. In other words,
there are message queues and receive task queues, but no transmit task
queues.
Message queues may be realized either with a ring buffer or with a linear
list. This depends on the implementation.
If a message queue uses a ring buffer, the task that issued snd_msg does not
enter the wait state even if the ring buffer is full and messages cannot be
enqueued. If this happens, the E_QOVR error is returned to the task that
issued snd_msg, and the system call terminates immediately.
If a message queue uses a linear list, it is necessary to have a queue link
area used by the operating system in the message block. Hence, part of the
user message block is used for operating system management. This part is
called the message header. pk_msg is the start address of the message block
with the message header. The user enters the message after the header, not
from the pk_msg address. Whether there is a message header and its size
depends on the implementation.
[Message format]
pk_msg -----> |------------------------|
|
Message header
|
| (whether there is a
|
| message header and its |
| contents depends on
|
| implementation)
|
+------------------------+
|
Message contents |
|
|
|
|
|
|
|------------------------|
In the uITRON specification, mailboxes are created statically at system
activation. Parameters necessary for mailbox creation, such as the mailbox
attribute, are also specified statically at system activation.
In the uITRON specification mailboxes, the standard task and message queuing
is FIFO (TA_TFIFO and TA_MFIFO). However, in some implementations, task
priority (TA_TPRI) or message priority (TA_MPRI) queuing may be selected.
If either is selected, the mailbox attribute (mbxatr) specified in mailbox
creation at system activation is used. If the message priority attribute is
selected, the priority of each message (msgpri) in the message header is
specified.
(interrupt handlers), isnd_msg, can be distinguished from those issued by
tasks, snd_msg. This is to improve the performance without incurring
calls should be divided into isnd_msg system calls, issued by
task-independent portions, and snd_msg system calls, issued by tasks.
it is convenient to be able to issue snd_msg system calls from both task
[Error codes]
E_OK
E_CTX
E_RSID
E_ILADR
E_IDOVR
E_ILMSG
E_NOEXS
Normal termination
Context error (isnd_msg was issued by task portion)
Illegal address (value where pk_msg cannot be used)
Illegal message format (depends on implementation)
Object does not yet exist (mailbox indicated by mbxid does not
exist)
E_QOVR Queue overflow (message queue overflow)
*****************************************
* [2] rcv_msg
*
* Receive message from mailbox
*
*---------------------------------------*
* [2] prcv_msg
*
* Poll and receive message from mailbox *
*****************************************
[Parameter]
mbxid
MailboxIdentifier
Mailbox ID number
[Return parameter]
pk_msg
MessagePacket
Start address of receive message
[Description]
In rcv_msg, a message is received from the mailbox indicated by mbxid, and
the start address of that message is returned as the return parameter. If no
messages have arrived at the mailbox, the task that issued this system call
is linked to the queue waiting to receive messages. The standard queuing is
FIFO.
pk_msg is the start address of the message block that contains the message
header (reserved area used by the operating system, for example). The user
should enter the message after the message header, but whether there is a
message header and its size depends on the implementation.
Time-out cannot be specified in uITRON specification rcv_msg. Permanent wait
occurs if the message is not received. The prcv_msg system call provides an
immediate return even when the message has not reached the mailbox.
In prcv_msg, if the message is already in the mailbox indicated by mbxid, it
is received and the system call terminates normally. If there is no message,
E_PLFAIL error is returned without the task entering the wait state.
In the ITRON2 specification, the prcv_msg function is realized by specifying
rcv_msg (tmout = TMO_POL), but in the uITRON specification, it is a separate
system call because time-out cannot be specified by rcv_msg. While mbx_sts
only finds out the next message to be received, prcv_msg receives the message
if it can be received (the first message is deleted from the message queue).
[Error codes]
E_OK
E_RSID
E_IDOVR
E_NOEXS
Normal termination
Object does not yet exist (mailbox indicated by mbxid does not
exist)
E_CTX
**********************
* [4] mbx_sts
*
* Get mailbox status *
**********************
[Parameter]
mbxid
MailboxIdentifier
Mailbox ID number
[Return parameter]
wtskid
WaitTaskID
pk_msg
MessagePacket
Wait task ID number

Start address of next message
[Description]
In mbx_sts, the statuses of the mailbox indicated by mbxid are referenced,
and the start address of the next message to be received, pk_msg, and wait
task ID number, wtskid, are returned as return parameters.
Two interfacing methods are provided for this system call: the pk_msg,
wtskid and other information is read together using packets, or the
information is read individually.
state first of the tasks waiting for the message at the mailbox is returned.
NOTSK(0) is returned when no tasks are waiting.
The start address of the message to be received next is returned by pk_msg.
If rcv_msg is executed immediately after that, the same value is returned as
pk_msg. When there are no messages, pk_msg is NADR (-1). Either
pk_msg = NADR or wtskid = NOTSK or both are true.
to pk_msg or wtskid.
If there is no mailbox indicated by mbxid in mbx_sts, the E_NOEXS error
occurs.
[Error codes]
E_OK
Normal termination
E_NOEXS Object does not yet exist (mailbox indicated by mbxid does not
exist)
**********************************
* [5] snd_tmb
*
* Send message to task mailbox *
*--------------------------------*
* [#5] isnd_tmb
*
* Send message to task mailbox *
* (for task-independent portion) *
**********************************
[Parameter]
tskid
TaskIdentifier
pk_msg
MessagePacket
Destination task ID number

Start address of send message
[Return parameter]
None
[Description]
In snd_tmb and isnd_tmb, the message in the pk_msg address is sent to the
task mailbox indicated by tskid. The contents of the message are not copied;
only the address (pk_msg value) is transferred. Send messages are enqueued
FIFO.
Message queues may be realized with either a ring buffer or a linear list.
This depends on the implementation. If a message queue uses a ring buffer,
the task that issued snd_tmb does not enter the wait state even if the ring
buffer is full and messages cannot be enqueued. If this happens, the E_QOVR
error is returned to the task that issued snd_tmb, and the system call
terminates immediately.
The task mailbox functions are not supported in either ITRON1 specification
or ITRON2 specification. They are specific to the uITRON specification.
(interrupt handlers), isnd_tmb, can be distinguished from those issued by
tasks, snd_tmb. This is to improve the performance without incurring
calls should be divided into isnd_tmb system calls, issued by
task-independent portions, and snd_tmb system calls, issued by tasks.
it is convenient to be able to issue snd_tmb system calls from both task
[Error codes]
E_OK
E_CTX
E_RSID
E_ILADR
E_IDOVR
E_ILMSG
E_NOEXS
E_QOVR
Normal termination
Context error (isnd_tmb was issued by task portion)
Illegal address (value where pk_msg cannot be used)
Illegal message format (depends on implementation)
exist)
Queue overflow (message queue overflow)
**********************************************
* [5] rcv_tmb
*
* Receive message from task mailbox
*
*--------------------------------------------*
* [5] prcv_tmb
*
* Poll and receive message from task mailbox *
**********************************************
[Parameter]
None
[Return parameter]
pk_msg
MessagePacket
Start address of receive message
[Description]
In rcv_tmb, a message is received from the task mailbox and the start address
of that message is returned as the return parameter. If no messages have
arrived at the task mailbox, the task enters the wait state. Only one task
can be in the wait state at one time in this system call because the mailbox
waiting for messages is task-dependent. Hence, message queues are not formed
in rcv_tmb.
Time-out cannot be specified in rcv_tmb. Permanent wait occurs if the
message is not received. The prcv_tmb system call provides an immediate
return even when the message has not reached the mailbox. In prcv_tmb, if
the message is already in the task mailbox, it is received and the system
call terminates normally. If there is no message, the E_PLFAIL error is
returned without the task entering the wait state.
While tmb_sts only finds out the next message to be received, prcv_tmb
receives the message if it can be received (the first message is deleted from
the message queue).
[Error codes]
E_OK
E_CTX
E_RLWAI
E_PLFAIL
Normal termination
Forced release of wait state (rel_wai accepted during wait)
Polling failed
***************************
* [5] tmb_sts
*
* Get task mailbox status *
***************************
[Parameter]
tskid
TaskIdentifier
Task ID number
[Return parameter]
tmbwait Task Mailbox Wait
pk_msg
MessagePacket
Task mailbox wait

Start address of next message
[Description]
In tmb_sts, the statuses of the task mailbox indicated by tskid are
referenced, and the start address of the next message to be received, pk_msg,
and presence or absence of a wait task, tmbwait, are returned as return
parameters.
tmbwait is a return parameter that returns a Boolean value. If the task
indicated by tskid is waiting for the task mailbox, TRUE (value that is
not 0, and is 1, standard) is returned by tmbwait. At other times, FALSE (0)
is returned. In the task mailbox, it is meaningless to find out the wait
task ID number, so the return parameter equivalent to wtskid in other system
calls (sem_sts and mbx_sts, for example) is the Boolean value, tmbwait.
The start address of the message to be received next is returned by pk_msg.
If the task indicated by tskid executes rcv_tmb immediately after that, the
same value is returned as pk_msg. When there are no messages, pk_msg is NADR
(-1). Either pk_msg = NADR or wtskid = NOTSK or both are true.
The interface format of this system call is that pk_msg and tmbwait
information is read together using packets, or that individual information is
read individually, or that tmbwait information is encoded in pk_msg or the
return value (error code) and read.
to tmbwait or pk_msg. It may also be possible to reference the number of
messages not yet received, instead of pk_msg.
[Error codes]
E_OK
Normal termination
E_ILADR Illegal address (value where packet address of return
E_NOEXS Object does not yet exist (task indicated by tskid does not
exist)
**********************************
* 3.4
*
* Interrupt Management Functions *
**********************************
This section explains the system calls for the interrupt management function.
Level
----#1
#1
3
#5
5
2A
2A
2B
3B
Parameter or
return parameter
System call (marked =)
----------- -------------------def_int
intno inthdr
ret_int
ret_wup
tskid
def_rst
tskid rstadr
ret_rst
tskid
dis_int
intno
ena_int
intno
chg_iXX
iXXXX
iXX_sts
iXXXX=
Function
-----------------------------Define interrupt handler
Return from interrupt handler
Return and wakeup task
Define task restart address
Return and restart task
Disable interrupt
Enable interrupt
Change interrupt XXXX
Get interrupt XXXX status
****************************
* [#1] def_int
*
* Define interrupt handler *
****************************
[Parameter]
intno
InterruptNumber
inthdr
InterruptHandlerAddress
Interrupt number
Interrupt handler address
[Return parameter]
None
[Description]
In def_int, the interrupt handler is defined and enabled. The correspondence
is set up between the address of the interrupt handler indicated by inthdr
and the interrupt number indicated by intno.
The exact definition of intno depends on the processor, but generally it may
express the interrupt vector number or interrupt device number. In some
processors, it may specify parameters other than these (for example, the
interrupt handler attribute or interrupt mask value at handler activation).
In the ITRON specification OS, the operating system does not mediate, in
principle, when the interrupt handler is activated. The interrupt handler
defined by this system call is activated by the hardware interrupt processing
mechanism when an interrupt occurs. Hence, the user must save and restore
registers used in this interrupt handler.
The interrupt handler terminates by system calls such as ret_int or assembler
return interrupt instructions.
When task dispatching is caused by a system call issued in the interrupt

handler, dispatching is delayed until the interrupt handler terminates, and
control returns to the operating system with the ret_int or other system
call. Hence, if dispatching in an interrupt handler is likely to occur,
control must return from the interrupt handler using the ret_int system call,
not assembler return interrupt instructions.
When inthdr is NADR (-1), the interrupt handler definition is released.
However, the def_int system call interface uses packets, and, when the intno
parameter, which specifies the object whose definition is to be released, is
not included in the packet, the definition may be released by setting the
packet address to NADR(-1).
It is not necessary to release the definition of a previous handler even for
def_int to redefine an interrupt handler. No error occurs if a new handler
is defined for intno defined for the previous handler.
The interrupt handler is treated as a task-independent portion. Hence,
waiting system calls, and system calls that effectively specify the caller
task using tskid = TSK_SELF cannot be executed in the interrupt handler.
System calls that can be used in interrupt handlers depend on the
implementation. In the uITRON specification, the following restrictions may
be imposed as implementation-dependent specifications.
- Some system calls can be issued only by task-independent portions
(interrupt handlers).
- To improve the performance, system calls are divided into those issued by
task portions and those issued by task-independent portions (interrupt
handlers). In the ITRON1 and ITRON2 specifications, system calls issued by
task portions and system calls issued by task-independent portions have the
same name, but in the uITRON specification, they may have different names.
If the name of a system call issued by a task portion is xxx_yyy, the name
of the system call issued by the task-independent portion is ixxx_yyy.
In the uITRON specification, functions defining interrupt handlers are
necessary. However, interrupt handlers need not be defined dynamically using
this system call, but can be defined statically at system activation, like
object creation. In other words, if the interrupt handler can be defined
using another method, this system call need not be supported.
[Error codes]
E_OK
E_NOSMEM
E_RSATR
E_PAR
E_ILADR
E_VECN
Normal termination
No system memory (depends on implementation)
Reserved attribute (depends on implementation)
Parameter error (depends on implementation)
Illegal address (value where inthdr cannot be used)
Illegal vector number (depends on implementation)
*********************************
* [#1] ret_int
*
* Return from interrupt handler *
*********************************
[Parameter]
None
[Return parameter]
[Description]
ret_int is issued at return from the interrupt handler.
In the ITRON specification OS, even if a system call is issued in an
interrupt handler, dispatching doesn't occur, in principle. The dispatching
is delayed until this system call is executed and the interrupt handler
terminates. However, in the uITRON specification OS, the delayed dispatching
principle need not be applied in some processor architectures and multiple
interrupt processing.
The status (stack or registers) when this system call is issued must be the
same as that when the interrupt handler started. That is, the user must save
and restore registers used by the interrupt handler.
Because the user restores registers, sometimes some function codes cannot be
used in this system call. Hence, the trap instruction of a different vector
is generally used to issue this system call.
When it is understood that execution of the same task will continue even
after return from the interrupt handler, control may return from the
interrupt handler by using the assembler return instruction rather than
ret_int.
[Error codes]
* The following error may be detected. If it is, control does not return to
the context in which the system call was issued. Hence, the error code
cannot be directly returned as a return parameter. Operation when this
error is detected depends on the implementation.
E_CTX
Context error (issued by task portion)
**************************
* [3] ret_wup
*
* Return and wakeup task *
**************************
[Parameter]
tskid
TaskIdentifier
Wakeup task ID number
[Return parameter]
[Description]
In ret_wup, control returns from the interrupt handler and wakes up the
interrupt processing task (task made to wait by slp_tsk and wai_tsk) at the
same time.
In ret_wup, requests are enqueued when the addressed task has not issued
slp_tsk or wai_tsk.
In the ITRON specification, all system calls that indicate the end of the
handler are prefixed by ret. System calls that do not return to the context
in which they were issued are all ret_xxx or ext_xxx (exd_xxx).
[Error codes]
* The following errors may be detected. If such an error is detected,
control does not return to the context in which the system call was issued.
Hence, an error code cannot be directly returned as a return parameter.
Operation when an error is detected depends on the implementation.

E_CTX
E_RSID
E_IDOVR
E_NOEXS
E_DMT
E_QOVR

exist)
Queue overflow (wupcnt overflow)
*******************************
* [#5] def_rst
*
* Define task restart address *
*******************************
[Parameter]
tskid
TaskIdentifier
rstadr
RestartAddress
Task ID number
Task restart address
[Return parameter]
None
[Description]
In def_rst, the restart address of the task indicated by tskid is defined.
The defined address is used when executing the ret_rst system call.
The task restart function restarts execution of the specified task from the
specified address by executing ret_rst at return from interrupt. Viewed from
the task which was specified for restart, this function is a sort of
exception processing (forced exception by software), but it is separate from
exception processing in the uITRON specification to simplify the functions
and increase speed.
This function can be used to return the execution program to a checkpoint for
fault tolerance.
The task restart address can be defined even when the task indicated by tskid
is in the dormant state.
The task restart function is not supported by the ITRON1 or ITRON2
specification. It is specific to the uITRON specification.
Even if the task restart function is provided, the restart address need not
be defined dynamically using this system call, but can be defined statically
at system activation, like object creation. (It is specified as a task
attribute.) In other words, if the task restart address can be defined using
another method, this system call need not be supported. It is like def_int
in this respect.
[Error codes]
E_OK
E_NOSMEM
E_RSID
E_IDOVR
E_NOEXS
Normal termination
exist)
E_ILADR Illegal address (value where rstadr cannot be used)
***************************
* [5] ret_rst
*
* Return and restart task *

***************************
[Parameter]
tskid
TaskIdentifier
Restart task ID number
[Return parameter]
[Description]
ret_rst is used to return from the interrupt handler and to restart the task
specified by tskid.
Tasks indicated by tskid have already had the restart address, rstadr,
defined by static specification at system activation or the def_rst system
call. In this system call, the program counter of the task is changed to
rstadr.
If the task specified by tskid is in the wait state, wait is forcibly
released, because of the possibility that the interrupt handler will specify
two types of restart of the task in the wait state by slp_tsk: restart by
ret_wup and restart by ret_rst.
[Error codes]
* The following errors may be detected. If such an error is detected,
control does not return to the context in which the system call was issued.
Hence, the error code cannot be returned directly as a system call return
parameter. Operation when an error is detected depends on the
implementation.
E_CTX
E_RSID
E_IDOVR
E_NOEXS
E_DMT

exist)
*********************
* [2A] dis_int
*
* Disable interrupt *
*********************
[Parameter]
intno
InterruptNumber
Interrupt number
[Return parameter]
None
[Description]
In dis_int, the interrupt specified by the interrupt number, intno, is
disabled.
The exact meaning of intno depends on the implementation, but may be the
interrupt vector number or interrupt device number.
[Error codes]
E_OK
E_PAR
E_VECN
Normal termination
********************
* [2A] ena_int
*
* Enable interrupt *
********************
[Parameter]
intno
InterruptNumber
Interrupt number
[Return parameter]
None
[Description]
In ena_int, the interrupt specified by the interrupt number, intno, is
enabled.
The exact meaning of intno depends on the implementation, but may be the
interrupt vector number or interrupt device number.
[Error codes]
E_OK
E_PAR
E_VECN
Normal termination
*************************
* [2B] chg_iXX
*
* Change interrupt XXXX *
*************************
[Parameter]
iXXXX
Interrupt XXXX
Interrupt mask (level, priority)
[Return parameter]
None
[Description]
In chg_ixx, the processor interrupt mask (level, priority) is changed to the
value specified by ixxxx.
The xxxx part of system call names and parameter names corresponds to each
processor architecture, for example, chg_ims, chg_ipl, and chg_ilv. In some
processors, the system call may have intno or some other parameter added to
ixxxx.
Normally, this system call is used to disable interrupts for part of the user
task.
While the interrupt is disabled by this system call, dispatching is delayed
until the interrupt mask is released, like during interrupt handler
execution. It is because if dispatching occurs with interrupt disabled, the
disabled interrupt will be suspended or will create contradictions in
executing the instruction.
[Error codes]
E_OK
E_PAR
E_VECN
E_IMS
Normal termination
Illegal imask (depends on implementation)
*****************************
* [3B] iXX_sts
*
* Get interrupt XXXX status *

*****************************
[Parameter]
None
[Return parameter]
iXXXX
Interrupt XXXX
Interrupt mask (level, priority)
[Description]
In ixx_sts, the processor interrupt mask (level, priority) is returned as
return parameter ixxxx.
The xxxx part of system call names and parameter names corresponds to each
processor architecture, for example, ims_sts, ipl_sts, and ilv_sts. In some
processors, the system call may have intno or some other parameter added to
ixxxx.
[Error codes]
E_OK
E_PAR
E_VECN
Normal termination
**********************************
* 3.5
*
* Exception Management Functions *
**********************************
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 standard uITRON specification.
CPU exception handling also depends largely on the processor architecture, and
so it too is not supported by the standard uITRON specification. uITRON
specification exception management functions all depend on the processor or
implementation.
Exception management functions are not always necessary in uITRON
specification OS applications, but implementation-dependent exception
management functions may be appended to support debugging.
************************************
* 3.6
*
* Memory Pool Management Functions *
************************************
The memory pool management functions explained in this chapter manage the
memory pools and memory blocks by software. They do not include MMU operation
(MMU support functions).
The uITRON specification normally supports only fixed-length memory blocks
shared by tasks.
Level
----4
Parameter or
return parameter
----------- -------------------get_blk
mplid blk=
Function
-----------------------------Get memory block
3
3
4
pget_blk
rel_blk
mpl_sts
mplid blk=
mplid blk
mplid wtskid= frbcnt=
Poll and get memory block

Release memory block
Get memory pool status
*****************************
* [4] get_blk
*
* Get memory block
*
*---------------------------*
* [3] pget_blk
*
* Poll and get memory block *
*****************************
[Parameter]
mplid
MemoryPoolIdentifier
Memory pool ID number
[Return parameter]
blk
BlockStartAddress
Start address of memory block
[Description]
In get_blk and pget_blk, a fixed-length shared memory block is acquired from
the memory pool indicated by mplid. The start address of the acquired memory
block is returned by blk. The size of the acquired memory block is the value
(blksz) specified for each memory pool at system activation.
In get_blk, when memory blocks cannot be allocated immediately from the
specified memory pool, the task that issued get_blk is linked to the memory
acquisition queue of the memory pool, where it waits until it can acquire a
block. In pget_blk, control is immediately returned even when the memory
block cannot be acquired. In pget_blk, if the memory block can be acquired
immediately from the memory pool indicated by mplid, it is acquired and the
system call terminates normally. If it cannot be acquired immediately, the
task does not enter the wait state, and the E_PLFAIL error is returned.
In the ITRON2 specification, the pget_blk function is realized by specifying
get_blk (tmout = TMO_POL), but in the uITRON specification, it is a separate
system call because time-out cannot be specified by get_blk. In realtime
operating systems, task execution does not usually stop in memory acquisition
wait, so pget_blk is more necessary than get_blk.
In the uITRON specification, the memory pool is created statically at system
activation. Parameters necessary for memory pool creation, such as memory
block size (blksz) and total memory pool size (mplsz) are also specified
statically at system activation.
In the uITRON specification memory pool, the standard wait task queuing in
get_blk is FIFO (TA_TFIFO). However, depending on the implementation,
queuing may be by task priority (TA_TPRI). In uITRON specification get_blk,
it is standard to use only fixed-length memory blocks, so the distinction
made in ITRON2 specification between TA_FIRST, where the task at the head of
the queue takes priority, and TA_CNT, where the task with the lowest request
count takes priority, is meaningless.
Since the uITRON specification supports only fixed-length memory blocks, only
memory blocks of a single size are available if there is only one memory
pool. Therefore, multiple memory pools are supported in the uITRON
specification by including mplid as a parameter of get_blk and pget_blk.
[Error codes]
E_OK
E_RSID
Normal termination

E_NOEXS Object does not yet exist (memory pool indicated by mplid does
not exist)
E_CTX
************************
* [3] rel_blk
*
* Release memory block *
************************
[Parameter]
mplid
blk
BlockStartAddress

Start address of memory block
[Return parameter]
None
[Description]
In rel_blk, the memory block indicated by blk is returned to the memory pool
indicated by mplid.
The memory pool to which the memory block is returned must be the same as
that from which the memory block was acquired. If it is different, the
E_ILBLK error is returned.
[Error codes]
E_OK
E_RSID
E_IDOVR
E_NOEXS
Normal termination
Object does not yet exist (memory pool indicated by mplid does
not exist)
E_ILBLK Illegal memory block release or operation
**************************
* [4] mpl_sts
*
* Get memory pool status *
**************************
[Parameter]
mplid
[Return parameter]
wtskid
WaitTaskID
frbcnt
FreeBlockCount
Wait task ID number

Free area block count
[Description]
In mpl_sts, the statuses of the memory pool indicated by mplid are
referenced, and the current number of free blocks in the memory pool, frbcnt,
and wait task ID number, wtskid, are returned as return parameters.
Two interfacing methods are provided for this system call: the frbcnt and
wtskid information is read together using packets, or the information is read
individually.
state first of the tasks waiting to acquire memory blocks from the specified
memory pool is returned. NOTSK(0) is returned when no tasks are waiting.
Either frbcnt or wtskid or both must be 0.

In some implementations, it may be possible to reference information in
addition to frbcnt or wtskid (for example, total memory size, mplsz, or block
size, blksz).
If there is no memory pool indicated by mplid in mpl_sts, the E_NOEXS error
is returned.
[Error codes]
E_OK
Normal termination
E_NOEXS Object does not yet exist (memory pool indicated by mplid does
not exist)
***********************************************
* 3.7
*
* Time Management and Timer Handler Functions *
***********************************************
This section explains the system calls for the time management and timer
handler functions.
Level
----2
2
#4
4
4
#4
4
#4
Parameter or
return parameter
----------- -------------------set_tim
time
get_tim
time=
def_cyc
cyhno cychdr cyhact cytime
act_cyc
cyhno cyhact
cyh_sts
cyhno cyhact= lftime=
def_alm
alhno almhdr time tmmode
alh_sts
alhno lftime=
ret_tmr
Function
----------------------------Set time
Get time
Define cyclic handler
Activate cyclic handler
Get cyclic handler status
Define alarm handler
Get alarm handler status
Return from timer handler
***************
* [2] set_tim *
* Set time
*
***************
[Parameter]
time
CurrentDateTime
Current date and time
[Return parameter]
None
[Description]
In set_tim, the current value of the system clock held by the system is set
to the value indicated by time.
The bit length of the system clock depends on the implementation, but a
48-bit clock is recommended. Processors that cannot handle the necessary bit
length as time at one time normally divide it into parameters: either upper
(utime) and lower (ltime), or upper (utime), middle (mtime), and lower
(ltime).
The meanings and units of the system clock depend on the implementation, but
unless there are other restrictions, the recommended meanings and units are
milliseconds, counted consecutively from midnight (GMT), January 1, 1985.
When the system clock is changed using set_tim during system operation, tasks
that have been waiting or the operation timing of handlers that have been
waiting for activation (cyclic or alarm handlers) may go wild. Operation in
these cases depends on the implementation.
[Error codes]
E_OK
Normal termination
E_TNOSPT Timer functions not supported (timer cannot be used)
E_ILTIME Illegal time specification (depends on implementation)
***************
* [2] get_tim *
* Get time
*
***************
[Parameter]
None
[Return parameter]
time
CurrentDateTime
Current date and time
[Description]
In get_tim, the current value of the system clock held by the system is read
and returned by the return parameter, time.
The bit length of the system clock depends on the implementation, but a
48-bit clock is recommended. Processors that cannot handle the necessary bit
length as time at one time normally divide it into parameters: either upper
(utime) and lower (ltime), or upper (utime), middle (mtime), and lower
(ltime).
The meanings and units of the system clock depend on the implementation, but
unless there are other restrictions, the recommended meanings and units are
milliseconds, counted consecutively from midnight (GMT), January 1, 1985.
[Error codes]
E_OK
Normal termination
E_TNOSPT Timer functions not supported (timer cannot be used)
*************************
* [#4] def_cyc
*
* Define cyclic handler *
*************************
[Parameter]
cyhno
CyclicHandlerNumber
cychdr
CyclicHandlerAddress
cyhact
CyclicHandlerActivation
cytime
CycleTime
Cyclic handler specification number

Cyclic handler address
Cyclic handler activation status
Cycle time
[Return parameter]
None
[Description]
The cyclic handler is a task-independent portion that operates cyclically.
In def_cyc, the cyclic handler is defined.
cyhno is the number used to distinguish between multiple cyclic handlers; it

is used in act_cyc and cyh_sts. cychdr represents the start address of the
cyclic handler, cytime represents the cyclic handler cycle time, and cyhact
represents the temporary on/off selection (activation status) of the cyclic
handler. cyhact can be specified as follows:
cyhact:=(TCY_OFF || TCY_ON)
TCY_OFF
TCY_ON
Cyclic handler not active

Cyclic handler active
cyhact = TCY_OFF means that the cyclic handler has halted; it is not active
during this period.
Since the cycle count is cleared when def_cyc is executed, the handler is
first activated exactly one specified cycle after def_cyc execution.
When cychdr is NADR (-1), the handler definition is released. However, if
the def_cyc system call interface uses packets and the parameter (cyhno) that
specifies the object whose definition is to be released is not in the packet,
the definition can be released by setting the packet address to NADR (-1).
Since the number of activation cycles cannot be specified in def_cyc, cyclic
operations continue until either cyhact is set to TCY_OFF with act_cyc, or
the handler definition is released. If def_cyc is executed again for cyhno
of a cyclic handler already defined, all previous definitions are released
and the new definition is valid. Even if the cyclic handler is redefined,
the previous definition need not be released beforehand. This is the same as
for def_int.
The user must save and restore registers in the cyclic handler.
System calls that enter the wait state and system calls that effectively
specify the caller task by using tskid = TSK_SELF cannot be executed in the
cyclic handler because the cyclic handler is executed as a task-independent
portion. In principle, if system calls are executed during the cyclic
handler, dispatching is delayed until the cyclic handler can be escaped by
issuing the ret_tmr system call.
The cyclic handler and alarm handler are considered as task-independent
portions because tasks that issued def_cyc or def_alm can be terminated or
deleted while the cyclic handler or alarm handler definition is valid.
Since the cyclic handler is not an object, cyhno, not the ID number,
distinguishes between multiple handlers.
Even if cyclic handler functions are provided, the cyclic handler need not be
defined dynamically using this system call, but can be defined statically at
system activation, like object creation. In other words, if the cyclic
handler can be defined using another method, this system call need not be
supported. This is the same as for def_int.
[Error codes]
E_OK
E_NOSMEM
E_TNOSPT
E_RSMD
E_RSATR
E_PAR
Normal termination
Reserved mode or option (illegal cyhact)
Parameter error (illegal cyhno)
E_ILADR Illegal address (value where cychdr cannot be used)

E_ILTIME Illegal time specification (depends on implementation)
***************************
* [4] act_cyc
*
* Activate cyclic handler *
***************************
[Parameter]
cyhno
CyclicHandlerNumber
cyhact
CyclicHandlerActivation Cyclic handler activation status
[Return parameter]
None
[Description]
In act_cyc, the cyclic handler activation status (cyhact) is changed.
cyhact is specified as follows:
cyhact:=(TCY_OFF || TCY_ON) | [TCY_INI]
TCY_OFF Cyclic handler not active
TCY_ON Cyclic handler active
TCY_INI Cyclic handler count initialized
When cyhact = TCY_ON is specified, the handler activation status is
independently set to on after a cycle has passed. In internal operating
system operation, the specified cycle count is performed even while the
activation status is off, so the time from when act_cyc is executed to when
the cyclic handler is first executed is not fixed.
When cyhact = (TCY_ON|TCY_INI) is specified, the cycle count is cleared when
the activation status is set to on. Hence, the handler is first activated
exactly one specified cycle after act_cyc execution.
[Error codes]
E_OK
Normal termination
E_RSMD Reserved mode or option (illegal cyhact)
E_NOEXS Object does not yet exist (cyclic handler indicated by cyhno
does not exist)
*****************************
* [4] cyh_sts
*
* Get cyclic handler status *
*****************************
[Parameter]
cyhno
CyclicHandlerNumber
[Return parameter]
cyhact
CyclicHandlerActivation
lftime
LeftTime
Cyclic handler activation status

Time left until next handler activation
[Description]
In cyh_sts, the status of the cyclic handler specified by cyhno is
referenced, and the cyclic handler activation status, cyhact, and time left
until the next handler activation, lftime, are returned as return parameters.
Of these, only either TCY_ON or TCY_OFF is returned in cyhact. TCY_INI
information is not returned.

The interface format of this system call is either that cyhact, lftime, and
other information is read together using packets, or that individual
information is read individually.
to cyhact or lftime (for example, cytime).
If there is no cyclic handler indicated by cyhno in cyh_sts, the E_NOEXS
error is returned.
[Error codes]
E_OK
Normal termination
E_PAR
E_NOEXS Object does not yet exist (cyclic handler indicated by cyhno
does not exist)
************************
* [#4] def_alm
*
* Define alarm handler *
************************
[Parameter]
alhno
AlarmHandlerNumber
almhdr
AlarmHandlerAddress
time
AlarmTime
tmmode
TimeMode
Alarm handler specification number

Alarm handler address
Alarm handler activation time
Initial time specification mode
[Return parameter]
None
[Description]
The alarm handler is a task-independent portion that is activated at a
specified time. In def_alm, the alarm handler is defined.
alhno is the number used to distinguish between multiple alarm handlers.
almhdr represents the start address of the alarm handler. The alarm handler
activation time is specified by time. tmmode specifies time in absolute time
or in relative time as follows:
tmmode:=(TTM_ABS || TTM_REL)
TTM_ABS Specification in absolute time
TTM_REL Specification in relative time
If the specified time is in the past, the E_ILTIME error is returned.
The bit length depends on the implementation, but 48 bits (the same as the
bit length in the system clock) is recommended. Processors that cannot
handle the necessary number of bits as time at one time normally divide it
into parameters: either upper (utime) and lower (ltime), or upper (utime),
middle (mtime), and lower (ltime).
When almhdr is NADR (-1), the handler definition is released. However, if
the def_alm system call interface uses packets and the parameter (alhno) that
specifies the object whose definition is to be released is not in the packet,
the definition can be released by setting the packet address to NADR (-1).
If the alarm handler is redefined by def_alm, the previous definition need

not be released. Even if a new handler is defined for alhno specified for
the previous alarm handler, no error occurs. The previous definition is
canceled, and the new definition is valid. This is the same as for def_int.
The user must save and restore registers in the alarm handler.
System calls that enter the wait state and system calls that effectively
specify the caller task by using tskid = TSK_SELF cannot be executed in the
alarm handler because the alarm handler is executed as a task-independent
portion. In principle, if system calls are executed during the alarm
handler, dispatching is delayed until the alarm handler can be escaped by the
ret_tmr system call.
Since the alarm handler is not an object, alhno, not the ID number,
distinguishes between multiple handlers.
Even if alarm handler functions are provided, the alarm handler need not be
defined dynamically using this system call, but can be defined statically at
system activation, like object creation. In other words, if the alarm
handler can be defined using another method, this system call need not be
supported. This is the same as for def_int.
A function similar to time-out can be realized by issuing rel_wai or irel_wai
during the alarm handler and releasing task wait.
[Error codes]
E_OK
E_NOSMEM
E_TNOSPT
E_RSMD
E_RSATR
E_PAR
E_ILADR
E_ILTIME
Normal termination
Reserved mode or option (illegal tmmode)
Parameter error (illegal alhno)
Illegal address (value where almhdr cannot be used)
Illegal time specification (depends on implementation)
****************************
* [4] alh_sts
*
* Get alarm handler status *
****************************
[Parameter]
alhno
AlarmHandlerNumber
Alarm handler specification number
[Return parameter]
lftime
LeftTime
Time left until next handler activation
[Description]
In alh_sts, the status of the alarm handler specified by alhno is referenced,
and the time left until the next handler activation, lftime, is returned as
the return parameter.
to lftime.
The interface format of this system call is either that lftime and other
information is read together using packets, or that individual information is
read individually. Processors that cannot handle the necessary number of
bits as lftime at one time normally divide it into parameters: either upper
(lfutime) and lower (lfltime), or upper (lfutime), middle (lfmtime), and

lower (lfltime).
If there is no alarm handler indicated by alhno in alh_sts, the E_NOEXS error
is returned.
[Error codes]
E_OK
Normal termination
E_PAR
E_NOEXS Object does not yet exist (alarm handler indicated by alhno
does not exist)
*****************************
* [#4] ret_tmr
*
* Return from timer handler *
*****************************
[Parameter]
None
[Return parameter]
[Description]
ret_tmr is used to return from the timer handler (cyclic or alarm handler).
In this system call, delayed dispatching may occur during the timer handler,
like ret_int.
Depending on the processor architecture and operating system implementation,
this system call may be realized by subroutine return instructions or
interrupt return instructions.
In ret_int, the system must return from the same task-independent portion,
but in ret_tmr, the implementor can select whether the operating system
mediates at handler activation. In other words, ret_int represents return
from a task-independent handler activated directly by hardware, whereas
ret_tmr represents return from a task-independent handler activated by the
operating system.
[Error codes]
* The following error may be detected. Even if it is, control does not
return to the context in which the system call was issued. Hence, the
error code cannot be returned directly as a system call return parameter.
Operation when this error is detected depends on the implementation.
E_CTX
******************************
* 3.8
*
* System Management Function *
******************************
This section explains the system calls for the system management function.
Level
Parameter or
return parameter
Function
----1
----------- -------------------get_ver
pk_ver
----------------------------Get version number
**********************
* [1] get ver
*
* Get version number *
**********************
[Parameter]
pk_ver
Packet of Version Numbers
Start address of packet that returns

version management information
[Return parameter]
None
[Description]
In get_ver, an overview of uITRON specification OS being executed, the
operating system model number, and version number are obtained.
The purpose of this system call is to read the uITRON specification OS
manufacturer and version number from the program.
The version number is read using the following packets. In the following, UH
represents the 16-bit unsigned integer data type.
typedef struct
UH
UH
UH
UH
UH
UH
UH
} T_VER;
t_ver {
maker;
id;
spver;
prver;
prno[4];
cpu;
var;
T_VER *pk_ver;
/*
/*
/*
/*
/*
/*
/*
Manufacturer */
Model number */
Specification version */
Product version */
Product management information */
CPU information */
Variation descriptor */
/* Pointer to version management block */
The packet and parameter formats are basically common to processors, ITRON1
specification, ITRON2 specification, uITRON specification, and BTRON
specification.
The parameter formats are as follows:
[maker]
+---------------+---------------+---------------+---------------+
1 | 0 0 0 0 0 0 0 0 |
MAKER 1
|
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
+---------------+---------------+---------------+---------------+
2 |
MAKER 2
|
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
MAKER1 and MAKER2:
The manufacturers who produced this product (ITRON specification OS, BTRON
specification OS, and TRON-architecture microprocessor)
After consultation between the manufacturers participating in the ITRON,
BTRON, and TRON-architecture microprocessor projects, format 1 is assigned.

The MAKER1 codes are common for ITRON specification OS, BTRON specification
OS, and TRON-architecture microprocessor. Other manufacturers use format 2 ,
to which codes 0000000100000001 and onwards are assigned. MAKER2 codes must
be registered, and are different in ITRON specification OS, BTRON
specification OS, and TRON-architecture microprocessor.
MAKER1 codes 00000001 to 00001111 have been assigned to the University of
Tokyo and the following seven corporations:
- MAKER1 code assignment (in alphabetical order)
00000000
00000001
...
00001001
00001010
00001011
00001100
00001101
00001110
00001111
00010000 to 11111111
No version number (experimental systems)

University of Tokyo
Fujitsu
Hitachi
Matsushita
Mitsubishi
NEC
Oki
Toshiba
Reserved
Subsidiary and affiliated companies of manufacturers using MAKER1 codes may

use those codes at the discretion of the manufacturer, or may use a new,
registered MAKER2 code.
[id]
+---------------+---------------+---------------+---------------+
|
id
|
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
Identification numbers for operating systems and VLSI types
These numbers are used to identify products when one manufacturer makes
several types of products, some of which support MMU and some of which do
not.
The manufacturer may assign numbers as desired. However, these numbers are
used only to identify products. They must be used systematically after
careful investigation.
[spver]
+---------------+---------------+---------------+---------------+
|
MAGIC
|
Spec Ver
|
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
MAGIC: Identification number for TRON specifications
0 Common to TRON specifications (TAD and others)
1 ITRON1 or ITRON2 specification
2 BTRON specification
3 CTRON specification
4 Reserved
5 uITRON specification
6 uBTRON specification
SpecVer: This is the version number of the University of Tokyo TRON
specification, which is the original specification of the product.
A three-digit BCD code is used.

Example: ITRON Ver 2.34 specification
spver = H'1234
[prver]
+---------------+---------------+---------------+---------------+
|
MAJOR
|
MINOR
|
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
Version number for internal implementation
MAJOR represents major distinctions between version numbers, and MINOR
represents minor distinctions between version numbers. The manufacturer may
assign the numbers as desired.
[prno]
+---------------+---------------+---------------+---------------+
|
prno[0]
|
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
+---------------+---------------+---------------+---------------+
|
prno[1]
|
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
+---------------+---------------+---------------+---------------+
|
prno[2]
|
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
+---------------+---------------+---------------+---------------+
|
prno[3]
|
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
Field that each manufacturer may use as desired, for example, to enter
product management information or serial numbers.
[cpu]
+---------------+---------------+---------------+---------------+
1 | 0 0 0 0 0 0 0 0 |
CPU1
|
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
+---------------+---------------+---------------+---------------+
2 |
MAKER1
|
CPU2
|
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
Processor that executes this ITRON specification OS
Format 1 is used for TRON-architecture microprocessor, Motorola MC68000,
Intel iAPX86, National Semiconductor NS32000, and NEC V-series(*1)
processors. Processors made by other manufacturers using their own
architecture use format 2.
*1 V-series is a trademark of NEC corporation.
Format 2 is mainly used for uITRON specification OS. Format 2 MAKER1 code
assignment is the same as that explained in the maker section. MAKER1
manufacturers determine the CPU2 code assignment.
CPU1 code assignment in format 1 is as follows. It is common to ITRON and
BTRON specification OS, and the CPU type section of the BTRON specification
for TRON-architecture microprocessor standard object format takes the same
number.
CPU1:
H'00
(H'01
CPU not specified, no CPU information

32-bit TRON-architecture microprocessor, manufacturer
not specified)
H'02 to H'04 Reserved
(H'05
<<L1R>> TRON-architecture microprocessor)
(H'06
<<L1>> TRON-architecture microprocessor)
(H'07
TRON-architecture microprocessor with LSID functions)
H'08
Reserved
H'09
G-micro/100
H'0a
G-micro/200
H'0b
G-micro/300
H'0c
Reserved
H'0d
TX1
H'0e
Reserved
H'0f
TX3
(H'01 to H'3f TRON-architecture microprocessor)
H'40
H'41
H'42
H'43
(H'40 to H'4f
68000
68010
68020
68030
68000 series)
H'50
32032
(H'50 to H'5f NS32000 series)
H'60
H'61
H'62
H'63
(H'60 to H'6f
8086, 8088
80186
80286
80386
86 series)
(H'70 to H'7f V-series)

Manufacturers of the V-series determine the assignment.
[var]
+---+-----------+---+---+---+---+---+---+---+---+---+---+---+---+
| - |
LEV
| - | M | V | P | - | - | FIL | IO | - | - |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
Overview of the functions that can be used by ITRON2 and uITRON specification
OS
-:
Reserved
0 returned
LEV: Kernel specification level classification
000
uITRON specification
001
Reserved
010
Reserved
011
Basic ITRON2 specification
(<<I1>> specification)
100
Partially extended ITRON2 specification
(partial <<I2>> specification)
101
Extended ITRON2 specification
(<<I2>> specification)
110
Reserved
111
Reserved
M=1:
M=0:
V=1:
P=1:
FIL:
IO:
Multiprocessor support
For single processor
Virtual memory support
MMU support version
File specification level classification
00
No support
01
<<FI0>> specification
10
<<FI1>> specification
11
Reserved
I/O specification
00
No support
01
Standard specification
10
Reserved
11
Reserved
Product types are identified by the id field. var and cpu are used only for
convenience, that is, var and cpu are different and cannot be used as
equivalent to id.
In uITRON specification, the M, V, and P fields are 0. In uITRON
specification, var = H'0000 is used when file and standard I/O support is not
given.
In the first version of ITRON2 specification, spver is as follows:
MAGIC = 1 (ITRON2 specification)
SpecVer = H'200 (Version 2.00)
spver = H'1200
In the first version of uITRON specification, spver is as follows:
MAGIC = 5 (uITRON specification)
SpecVer = H'200 (Version 2.00)
spver = H'5200
* uITRON specification conforms closely to ITRON2 specification, so the first
version is 2.00, not 1.00.
[Error codes]
E_OK
Normal termination
E_ILADR Illegal address (value where pk_ver cannot be used)
*******************************************
* 3.9
*
* uITRON specifications System Call List *
*******************************************
Parameters marked '=' are return parameters.
Task management functions
Level
----2
2
3
3
#3
System call
----------sta_tsk
ext_tsk
ter_tsk
chg_pri
ichg_pri
Parameter/return
parameter(marked =)
------------------tskid
tskid
tskid tskpri
tskid tskpri
Function
-----------------------------Start task
Exit task
Terminate task
3
#3
rot_rdq
irot_rdq
5
#5
rel_wai
irel_wai
3
3
get_tid
tsk_sts
tskpri
tskpri
Rotate ready queue

Rotate ready queue
tskid
Release wait
tskid
Release wait
tskid=
Get task ID number
tskid tskpri= tskstat= Get task status
Task-dependent synchronization functions

System call
----------sus_tsk
isus_tsk
Parameter/return
parameter(marked =)
------------------tskid
tskid
3
#3
rsm_tsk
irsm_tsk
tskid
tskid
4
1
3
1
#1
frsm_tsk
slp_tsk
wai_tsk
wup_tsk
iwup_tsk
tskid
can_wup
tskid wupcnt=
Level
----3
#3
tmout
tskid
tskid
Function
-----------------------------Suspend task
Suspend task
Resume task
Resume task
Force resume task
Sleep task
Wait for wakeup task
Wakeup task
Wakeup task
Cancel wakeup task
Synchronization and communications functions

Level
----3A
#3A
System call
----------set_flg
iset_flg
3A
3A
clr_flg
wai_flg
3A
pol_flg
4A
3B
#3B
flg_sts
set_flg
iset_flg
3B
3B
3B
3B
3B
4B
clr_flg
wai_flg
cwai_flg
pol_flg
cpol_flg
flg_sts
1
#1
sig_sem
isig_sem
1
1
4
wai_sem
preq_sem
sem_sts
snd_msg
Parameter/return
parameter(marked =)
------------------flgid setptn
flgid setptn
Function
-----------------------------Set event flag (word)
Set event flag (word)
flgid clrptn
Clear event flag (word)
flgid waiptn flgptn= wfmode
Wait event flag (word)
flgid waiptn flgptn= wfmode
Poll event flag (word)
flgid wtskid= flgptn= Get event flag status (word)
flgid
flgid
flgid
Clear event flag (bit)
flgid
Wait event flag (bit)
flgid
Wait and clear event flag (bit)
flgid
Poll event flag (bit)
flgid
Poll and clear event flag (bit)
flgid wtskid= flgptn=
Get event flag status (bit)
semid
Signal semaphore
semid
Signal semaphore
semid
Wait on semaphore
semid
Poll and request semaphore
semid wtskid= semcnt=
Get semaphore status
mbxid pk_msg
#2
isnd_msg
mbxid pk_msg
2
2
rcv_msg
prcv_msg
mbxid pk_msg=
mbxid pk_msg=
mbx_sts
mbxid wtskid= pk_msg=
5
#5
snd_tmb
isnd_tmb
tskid pk_msg
tskid pk_msg
rcv_tmb
pk_msg=
prcv_tmb
pk_msg=
tmb_sts
tskid tmbwait= pk_msg=

Receive message from mailbox
mailbox
Get mailbox status
Receive message from task
mailbox
task mailbox
Get task mailbox status
Interrupt management functions

Level
----#1
#1
3
#5
5
2A
2A
2B
3B
System call
----------def_int
ret_int
ret_wup
def_rst
ret_rst
dis_int
ena_int
chg_iXX
iXX_sts
Parameter/return
parameter(marked =)
------------------intno inthdr
tskid
tskid rstadr
tskid
intno
intno
iXXXX
iXXXX=
Function
-----------------------------Define interrupt handler
Return from interrupt handler
Return and wakeup task
Define task restart address
Return and restart task
Disable interrupt
Enable interrupt
Change interrupt XXXX
Get interrupt XXXX status
Memory pool management functions

Level
----4
3
3
4
System call
----------get_blk
pget_blk
rel_blk
mpl_sts
Parameter/return
parameter(marked =)
------------------mplid blk=
mplid blk=
mplid blk
mplid wtskid= frbcnt=
Function
-----------------------------Get memory block
Poll and get memory block
Release memory block
Get memory pool status
Time management and timer handler functions

Level
----2
2
#4
System call
----------set_tim
get_tim
def_cyc
4
4
act_cyc
cyh_sts
#4
def_alm
4
#4
alh_sts
ret_tmr
Parameter/return
parameter(marked =)
Function
-----------------------------------------------time
Set time
time=
Get time
cyhno cychdr cyhact cytime
Define cyclic handler
cyhno cyhact
Activate cyclic handler
cyhno cyhact= lftime=
Get cyclic handler status
alhno almhdr time tmmode
Define alarm handler
alhno lftime=
Get alarm handler status
Return from timer handler
System management function

Level
----1
System call
----------get_ver
Parameter/return
parameter(marked =)
------------------pk_ver
Function
-----------------------------Get version number
* The numbers indicated by (level) indicate the necessity for implementation.

The lower the number, the greater the necessity for implementation.
* If the numbers in (level) are suffixed by A or B in a system call, the
implementor should select specification A or specification B for
implementation. If possible, both may be implemented.
* If the numbers in (level) are suffixed by # in a system call, the system
call can be substituted by another method. For example, def_int is suffixed
by #; this means that if another method (for example, static definition at
operating system generation) is substituted for the interrupt handler
definition function, that system call is not needed.
* The xx of the chg_ixx and ixx_sts system calls that change and reference the
interrupt mask (level, priority) are based on the processor architecture.
* The xxx_sts return parameters, which view the object status, depend on the
implementation. The interfaces given in this list are examples only.
* If necessary, system calls that are not in these specifications can be
added. However, if added functions are supported by ITRON2 specification
OS, the specifications must not contradict ITRON2 specification system call
names or system call interfaces.
******************************************************************************
* Chapter 4
*
* Programming interface
*
******************************************************************************
This chapter explains the system call interfaces recommended for uITRON
specification. The explanation covers function codes, error codes, and the C
language interfaces.
************************
* 4.1
*
* Assembler Interfaces *
************************
The assembler interface for individual system calls in the uITRON
specifications determined for each processor. However, the following rules
apply to the uITRON specification for some function codes and flag changes.
These rules should be followed unless other restrictions prevent it.
---------------------------------------------4.1.1 Flag changes after system call execution
---------------------------------------------Flag values after system call execution are not specified. They are undefined
values.
In the ITRON1 specification, it was recommended to set the zero flag according
to whether there were errors. However, even if the operating system sets the
flag, it is not necessarily referenced, and if C language is used, the
function is not needed at all. Overhead for setting the flag cannot be
ignored.
For some processors, the operating system does not handle flag operations, but
the flag can be preserved by hardware during the execution of a trap
instruction. However, if system calls are implemented in future hardware, it

is possible that flag setting will be desirable. In this case, it will not be
good to specify that the flag should be preserved. For this reason, flag
values after system call execution are not specified at present.
-------------------4.1.2 Function codes
-------------------In the ITRON specification, function code numbers are used to identify the
type of system calls. A system call is issued by placing the corresponding
function code in a given register, and then executing the trap instruction.
In the uITRON specification, depending on 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, not a
trap instruction (software interrupt instruction). In this case, function
codes are sometimes not used. However, even in the uITRON specification,
function code values should be standardized if the system call interface uses
function codes, unless other restrictions prevent it.
The assignment policies and standard values of function codes in the uITRON
specification are as follows. Function codes are mainly common with the
ITRON2 specification. The tables below include system calls that are
supported only in the ITRON2 specification. Negative values are used in
standard function codes in accordance with overall TRON philosophy.
[Function code assignment policies]
- Alignment for multiples of 8 and common bit patterns for common functions
(cre_xxx, xxx_sts, uxxx_yyy, sxxx_yyy) have been considered.
- Function codes are not necessarily assigned in the order in which
specifications appear. However, a range of function codes is assigned to
each system call function group. (Some group may be incorporated in
another group if there are only a few system calls, for example, forced
exceptions.) The order of explanation in the specification is not directly
related to function codes.
- ixxx_yyy and pxxx_yyy used in the uITRON specification each form a group,
so each group is given a group of numbers; they are not mixed with other
groups.
[Function code range]
File management, device management, reserved:
H'fe00 to H'febf (-512) to
For debug support:
H'fec0 to H'feff (-320) to
For system configuration:
H'ff00 to H'ff1f (-256) to
Standard system calls (including I/O and MMU):
H'ff20 to H'fffb (-224) to
Reserved:
H'fffc to H'0000 (-4) to 0
For users (extended SVC):
H'0001 and greater values
(-321)
(-257)
192 values
64 values
(-225)
32 values
(-5)
220 values
5 values
[Standard function code values]

* -:
* *:
Reserved or system calls which do not need function codes.

System calls used only in uITRON specification, not in ITRON2
specification.
* Distinction between 'available to users' and 'not available to users' is
not strict.
+-------+----------------+---------------+---------------+----------------+
|
| +H'0
| +H'4
| +H'8
| +H'c
|
+-------+----------------+---------------+---------------+----------------+
|
|
|
|
|
|
|H'fec0 |
Debug support
|
|
|
|
|
|
|
|
| - - - - - - - - - - - - - - - - |
|
|
|
|
|
|
+-------+----------------+---------------+---------------+----------------+
|
|
|
|
|
|
|H'fed0 |
Debug support
|
|
|
|
|
|
i i i
|
|
| - - - - - get get get - get - get get get get get |
|
|
|
ext sex cex|
cyc
dly|fex ext sex cex |
+-------+----------------+---------------+---------------+----------------+
|
|
|
|
|
|
|H'fee0 |
Debug support
|
|
|
|
|
|
-s s s s
|
|
| get get get get get get get get get set get set get rum sgl brk |
|
| svh inh cyh alh|fex ext sex cex|reg reg bpt bpt|tcb tsk tsk tsk |
+-------+----------------+---------------+---------------+----------------+
|
|
|
|
|
|
|H'fef0 |
Debug support
|
|
|
|
|
|
a
|
|
| - - - - prf set por por - lmp mbf mpl mbx sem flg tsk |
|
|
|sts prf que que|
que que que|que que que que |
+-------+----------------+---------------+---------------+----------------+
+-------+----------------+---------------+---------------+----------------+
|
| +H'0
| +H'4
| +H'8
| +H'c
|
+-------+----------------+---------------+---------------+----------------+
|
|
|
|
|
|
|H'ff00 |
For system configuration, implementation-dependent
|
|
|
(available to users)
|
|
|
|
|
|
|
+-------+----------------+---------------+---------------+----------------+
|
|
|
|
|
|
|H'ff10 |
For system configuration, implementation-dependent
|
|
|
(not available to users)
|
|
|
|
|
|
|
+-------+----------------+---------------+---------------+----------------+
|
|
|
|
|
|
|H'ff20 | (System calls ixxx_yyy for task-independent portion only)
|
|
|
|
|
| *i
*i
*i *i *i *i
*i
*i *i
*i *i |
|
| snd - snd - snd sig set wup - rsm - sus rel - rot chg |
|
| tmb
mbf
|msg sem flg tsk|
tsk
tsk|wai
rdq pri |
+-------+----------------+---------------+---------------+-------+--------+
|
|
|
|
|
|
|
|H'ff30 | (Polling function pxxx_yyy) | (Task-dependent
| Excep- |
|
|
| messages xxx_tmb) | tions |
|
| *p *p *p *p *p *p * *c|
*
* *
| * * |
|
| rcv get rcv get rcv req pol pol| - snd - rcv tmb - |ret def |
|
| tmb lbl mbf blk|msg sem flg flg| - tmb - tmb|sts
|rst rst |
+-------+----------------+---------------+---------------+-------+--------+
|
|
|
|
|
|
|H'ff40 |
Standard I/O
|
|
|
|
|
| put get put get cio cio - req - - ret ret - - def def |
|
| lin lin chr chr|sts ctl
gio|
cio gio|
cio gio |
+-------+----------------+---------------+---------------+----------------+
|
|
|
|
|
|
|H'ff50 |
Reserved
|
|
|
|
|
| - - - - - - - - - - - - - - - - |
|
|
|
|
|
|
+-------+----------------+---------------+---------------+----------------+
|
|
|
|
|
|
|H'ff60 |
MMU support
|
|
|
|
|
| - - sha trf map set del cre - mov get set spc - del cre |
|
|
map map|sts prt map map|
dat dat dat|sts
spc spc |
+-------+----------------+---------------+---------------+----------------+
|
|
|
|
|
|
|H'ff70 | Local memory pool management |
Rendezvous (port)
|
|
|
|
|
|
| u
u
|
|
|
| rel rel get get lmp lbl del cre|fwd rpl acp cal por rdv del cre |
|
| lbl lbl lbl lbl|sts sts lmp lmp|
|sts sts
|
+-------+----------------+---------------+---------------+----------------+
+-------+----------------+---------------+---------------+----------------+
|
| +H'0
| +H'4
| +H'8
| +H'c
|
+-------+----------------+---------------+---------------+----------------+
|
|
|
|
|
|
|H'ff80 |
Message buffer
| System operation exception
|
|
|
| management
|
|
|
|
-s -s -s s s s |
|
| - snd - rcv mbf - del cre| - - end ret def def def def |
|
|
|sts
|
|fex ext sex cex |
+-------+----------------+---------------+---------------+----------------+
|
|
|
|
|
|
|H'ff90 |
Exception management, forced exception
|
|
|
|
|
|
- i i i
|
|
| set clr ref - ems def def def ras - end ret def def def def |
|
| ems ems exd
|sts ext sex cex|fex
|fex ext sex cex |
+-------+----------------+---------------+---------------+----------------+
|
|
|
|
|
|
|H'ffa0 |
Timer handlers
|
Time management
|
|
|
|
|
|
| - - act ret cyh alh def def|can cyc - dly get set - - |
|
|
cyc tmr|sts sts cyc alm|cyc wup
tsk|tim tim
|
+-------+----------------+---------------+---------------+----------------+
|
|
|
|
|
|
|H'ffb0 |
Memory pool management
|
Interrupt management
|
|
|
|
|
|
| u
u
| * * - - *
|
|
| rel rel get get mpl blk del cre|dis ena ret ret iXX chg - def |
|
| blk blk blk blk|sts sts
|int int wup int|sts iXX
int |
+-------+----------------+---------------+---------------+----------------+
|
|
|
|
|
|
|H'ffc0 |
Mailbox
|
Semaphore
|
|
|
|
|
|
| u
u
| u
u
|
|
| snd snd rcv rcv mbx - del cre|sig sig wai wai sem - del cre |
|
| msg msg msg msg|sts
|
|sts
|
+-------+----------------+---------------+---------------+----------------+
|
|
|
|
|
|
|H'ffd0 |
Event flag
| Task-dependent synchronization |
|
|
|
|
|
|
*c
|
f
|
|
| set clr wai wai flg - del cre|can wup slp wai rsm rsm - sus |
|
|
|sts
|wup
|
|
+-------+----------------+---------------+---------------+----------------+
|
|
|
|
|
|
|H'ffe0 |
Task management
|
|
|
|
|
|
|
|
| ras rel ref - rot chg abo ter get sta exd ext tsk hdr del cre |
|
| ext wai scd
|rdq pri
|tid
|sts sts
|
+-------+----------------+---------------+---------------+----------------+
|
|
|
|
|
|
|H'fff0 |
System management
|
Reserved
|
|
|
|
|
|
| get - - ret psw - - def| - - - = = = = = |
|
| ver
svc|sts
svc|
|
|
+-------+----------------+---------------+---------------+----------------+
***************************************
* 4.2
*
* C Language Interfaces and Mnemonics *
***************************************
---------------------------------------------4.2.1 Common principles in assigning mnemonics
---------------------------------------------- Data type names
All data type names, including structures, are in uppercase letters.
Pointer data type names are xxxP. Structure names are T_xxx.
- Constant mnemonics
Error code names are E_xxx. The names of modes used only in specific system
calls and parameters are Txy_xxx. The xy changes depending on the system
call or parameter.
- Parameter and return parameter names
Parameter and return parameter names are assigned according to the following
rules:
p_
pk_
xxxcd
ar_
ixxx
xxxsz
Pointer to return parameter area

Packet address
xxx code
Pointer to array
Initial value
Size
- If the parameter names are the same, they are the same data type, in
principle.
--------------------------4.2.2 Data types and syntax
--------------------------- In the uITRON and ITRON2 specification, the following data types are used
under the assumption that BTRON specification syntax will be integrated in
the future:
typedef
typedef
typedef
typedef
typedef
typedef
char
short
long
unsigned char
unsigned short
unsigned long
B;
H;
W;
UB;
UH;
UW;
/*
/*
/*
/*
/*
/*
Signed 8-bit integer */

Unsigned 8-bit integer */
typedef
typedef
typedef
typedef
long
short
char
void
VW;
VH;
VB;
*VP;
/*
/*
/*
/*
Variable data type (32 bits) */

Pointer to variable data */
(*FP)();
/* Program start address */
typedef void
* Note the difference between VB, VH, VW and B, H, W. the first three are
used when the data type is unknown and the bit length is known. The latter
three are used for data type integer. For example, if a message or memory
block is defined as an array of bytes, the actual data type is not known,
so VB should be used. For a reserved area in a packet, the data size is
known but whether the data is an integer cannot be determined, so VH or VW
should be used.
- Data types that appear frequently or have special meanings have the
following names to clarify parameter meanings and to make description
independent of the bit length of the processor. The bit length of the data
type, value range, and whether the data is signed or unsigned depend on the
processor and implementation.
BOOL
ID
HNO
ER
TMO
TIME
/*
/*
/*
/*
/*
/*
FN
TPRI
T_MSG
INT
UINT
/*
/*
/*
/*
/*
Boolean value, false (0) or true (1) */

Object ID number (XXXid) */
Handler number */
Error code (generally signed) */
Time-out */
Time specification (often separated into upper and
lower fields) */
Function code */
Task priority */
Message packet structure */
Signed integer (processor bit width) */
Unsigned integer (processor bit width) */
* Because the bit length of the processor in the uITRON specification is not
fixed, description that identifies the bit length, such as W, H, UW, and
UH, is not used in the following explanation. INT and UINT are often used
instead. However, since the bit length of the processor is known in
individual uITRON specification OS implementations, W, H, UW, and UH may be
used instead of INT and UINT in uITRON specification product manuals.
* For example, INT and H, and UINT and UH have the same meaning for a 16-bit
processor. This can be written as follows:
typedef
typedef
H INT;
UH UINT;
/* 16-bit processor */
/* 16-bit processor */
The correspondence between the above data types and the bit length must be
shown clearly for each implementation.
[Sample syntax]
ER ercd = sta_tsk (ID tskid);
-----------------------------------------------4.2.3 Common principles of C language interfaces
------------------------------------------------ Return values of functions are, in principle, system call error codes
(ercd). At normal termination, ercd is 0; if an error occurs, ercd is not 0
(negative is standard).
- When a return parameter (xxx) other than an error code is returned, a
pointer (p_xxx) to the area to contain the return parameter is specified as
the parameter.
- The pointer to the return parameter comes before the parameter. Even when
the specification in the assembler interface is for a pointer (packet
address), this principle applies (xxx_sts) if it is semantically equivalent
to a return parameter.
-------------------------------------------------4.2.4 C language interface standard specifications
-------------------------------------------------------------------------Task management functions
------------------------ER ercd = sta_tsk (ID tskid);
void
ext_tsk ( );
ER ercd = ter_tsk (ID tskid);
ER ercd = chg_pri (ID tskid, TPRI tskpri);
ER ercd = ichg_pri (ID tskid, TPRI tskpri);
ER ercd = rot_rdq (TPRI tskpri);
ER ercd = irot_rdq (TPRI tskpri);
ER ercd = rel_wai (ID tskid);
ER ercd = irel_wai (ID tskid);
ER ercd = get_tid (ID *p_tskid);
ER ercd = tsk_sts (UINT *p_tskstat, TPRI *p_tskpri, ID tskid);
* The tsk_sts interface may use packets.
---------------------------------------Task-dependent synchronization functions
---------------------------------------ER
ER
ER
ER
ER
ER
ercd
ercd
ercd
ercd
ercd
ercd
=
=
=
=
=
=
sus_tsk (ID tskid);

isus_tsk (ID tskid);
rsm_tsk (ID tskid);
irsm_tsk (ID tskid);
frsm_tsk (ID tskid);
slp_tsk ( );
ER
ER
ER
ER
ercd
ercd
ercd
ercd
=
=
=
=
wai_tsk (TMO tmout);

wup_tsk (ID tskid);
iwup_tsk (ID tskid);
can_wup (INT *p_wupcnt, ID tskid);
-------------------------------------------Synchronization and communications functions

-------------------------------------------[Word event flag]
ER
ER
ER
ER
ER
ER
ercd = set_flg (ID flgid, UINT setptn);

ercd = iset_flg (ID flgid, UINT setptn);
ercd = clr_flg (ID flgid, UINT clrptn);
ercd = wai_flg (UINT *p_flgptn, ID flgid, UINT waiptn, UINT wfmode);
ercd = pol_flg (UINT *p_flgptn, ID flgid, UINT waiptn, UINT wfmode);
ercd = flg_sts (ID *p_wtskid, UINT *p_flgptn, ID flgid);
* The flg_sts interface may use packets.
[Single-bit event flag]

ER
ER
ER
ER
ER
ER
ER
ER
ercd = set_flg (ID flgid);

ercd = iset_flg (ID flgid);
ercd = clr_flg (ID flgid);
ercd = wai_flg (ID flgid);
ercd = cwai_flg (ID flgid);
ercd = pol_flg (ID flgid);
ercd = cpol_flg (ID flgid);
ercd = flg_sts (ID *p_wtskid, BOOL *p_flgptn, ID flgid);
* The flg_sts interface may use packets.
ER
ER
ER
ER
ER
ercd = sig_sem (ID semid);

ercd = isig_sem (ID semid);
ercd = wai_sem (ID semid);
ercd = preq_sem (ID semid);
ercd = sem_sts (ID *p_wtskid, INT *p_semcnt, ID semid);
* The sem_sts interface may use packets.
ER
ER
ER
ER
ER
ercd = snd_msg (ID mbxid, T_MSG *pk_msg);

ercd = isnd_msg (ID mbxid, T_MSG *pk_msg);
ercd = rcv_msg (T_MSG **ppk_msg, ID mbxid);
ercd = prcv_msg (T_MSG **ppk_msg, ID mbxid);
ercd = mbx_sts (ID *p_wtskid, T_MSG **ppk_msg, ID mbxid);
* The mbx_sts interface may use packets.
ER
ER
ER
ER
ER
ercd = snd_tmb (ID tskid, T_MSG *pk_msg);

ercd = isnd_tmb (ID tskid, T_MSG *pk_msg);
ercd = rcv_tmb (T_MSG **ppk_msg);
ercd = prcv_tmb (T_MSG **ppk_msg);
ercd = tmb_sts (BOOL *p_tmbwait, T_MSG **ppk_msg, ID tskid);
* The tmb_sts interface may use packets.
----------------------------Interrupt management function

----------------------------ER ercd = def_int (UINT intno, FP inthdr);
void
ret_int ( );
void
ret_wup (ID tskid);
ER ercd = def_rst (ID tskid, FP rstadr);
void
ret_rst (ID tskid);
ER ercd = dis_int (UINT intno);
ER ercd = ena_int (UINT intno);
ER ercd = chg_iXX (UINT iXXX);
ER ercd = iXX_sts (UINT *p_iXXX);
* The intno and ixxx data types are sometimes not UINT.
-------------------------------Memory pool management functions
-------------------------------ER
ER
ER
ER
ercd = get_blk (VP *p_blk, ID mplid);

ercd = pget_blk (VP *p_blk, ID mplid);
ercd = rel_blk (ID mplid, VP blk);
ercd = mpl_sts (ID *p_wtskid, INT *p_frbcnt, ID mplid);
* The mpl_sts interface may use packets.
------------------------------------------Time management and timer handler functions

------------------------------------------ER ercd = set_tim (TIME time);
ER ercd = get_tim (TIME *p_time);
* The set_tim and get_tim interfaces may use packets.
ER ercd = def_cyc (HNO cyhno, FP cychdr, UINT cyhact, TIME cytime);
ER ercd = act_cyc (HNO cyhno, UINT cyhact);
ER ercd = cyh_sts (UINT *p_cyhact, TIME *p_lftime, HNO cyhno);
ER ercd = def_alm (HNO alhno, FP almhdr, TIME time, UINT tmmode);
ER ercd = alh_sts (TIME *p_lftime, HNO alhno);
* The def_cyc, cyh_sts, def_alm, alh_sts interfaces may use packets.
void
ret_tmr ( );
--------------------------System management functions
--------------------------ER ercd = get_ver (T_VER *pk_ver);
--------------------------------4.2.5 Constants and packet format
--------------------------------The mnemonics and standard values of common constants used by this system are
as follows:
/*--------------------------------------------------------------------------*/
(Common constants)
Overall:
NADR
TRUE
FALSE
(-1)
1
0
/* Address or pointer value invalid */

/* true */
/* false */
tskid:
TSK_SELF
/* Caller task specification */
TPRI_INI
TPRI_RUN
/* Specifies initial priority at task start.

(chg_pri) */
/* Specifies highest priority during
execution. (rot_rdq) */
tskpri:
wtskid:
NOTSK
/* No wait tasks */
TTM_ABS
TTM_REL
0
1
/* Specification in absolute time */

/* Specification in relative time */
tmmode:
tskstat:
TTS_RUN
TTS_RDY
TTS_WAI
TTS_SUS
TTS_WAS
TTS_DMT
H'00000001
H'00000002
H'00000004
H'00000008
H'0000000c
H'00000010
/*
/*
/*
/*
/*
/*
RUN */
READY */
WAIT */
SUSPEND */
WAIT-SUSPEND */
DORMANT */
* The task status expression by tskstat is in bit correspondence, which makes

it useful when judging the sum-set (for example, when judging whether the
status is wait or ready).
cyhact:
TCY_OFF
TCY_ON
TCY_INI
0
1
2
/* Cyclic handler not activated */

/* Cyclic handler activated */
/* Cycle count initialized */
/*--------------------------------------------------------------------------*/
typedef struct t_msg {
%%%
/* Depending on the implementation, the operating system reserved
area may be entered here. */
%%%
VB msgcont[];
} T_MSG;
/*--------------------------------------------------------------------------*/
typedef struct t_ver {
UH
maker;
/* Manufacturer */
UH
id;
/* Model number */
UH
spver;
/* Specification version */
UH
prver;
/* Product version */
UH
prno[4]; /* Product management information */
UH
cpu;
/* CPU information */
UH
var;
/* Variation descriptor */
} T_VER;
/*--------------------------------------------------------------------------*/
***************
* 4.3
*
* Error Codes *
***************
In the uITRON specification, mnemonics for errors which occur in each system
call and the error code values have been standardized. These standardizations
are common to uITRON and ITRON2 specifications.
Standard error codes are negative, and consist of the excls (exception class)
and errno information. The exception class shows the severity and class of
the exception. In the uITRON specification, the exception class does not
directly affect the operating system operation, but in the ITRON2
specification, the exception class is used to determine whether a system call
exception handler has been activated.
----------------------4.3.1 Error code format

----------------------+-+-------------+---------------+
ercd 1 |0|
RETURN_CODE
| Normal termination (>0)
| | | | | | | | | | | | | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+---------------+---------------+
ercd 2 |0...0 0 0 0 0 0|0 0 0 0 0 0 0 0| Normal termination (=0)
| | | | | | | | | | | | | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+---------------+---------------+
ercd 3 |1...1 1 1 1 1 1|
ERRNO
| Error occurred (<0)
| | | | | | | | | | | | | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-----+---------+---------------+
ercd 4 |1...1 EXCLS |
ERRNO
| Error occurred (<0)
| | | | | | | | | | | | | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
EXCLS is the ones complement of excls, and
ERRNO is the twos complement of errno.
* The exception class of the system call exception is expressed by excls
(4 <= excls <= 31).
* Multiple errors in the same exception class are distinguished by errno.
(1 <= errno <= 255)
* The ercd value is expressed by (- (excls << 8) - errno). In principle, the
ercd 4 format is used. '<<' means left shift.
* Combinations making errno equivalent although excls is different are not
allowed to occur. In other words, even if there is no excls part, ercd can
be identified by errno alone. (excls and an independent sequential number
are assigned to errno.)
* To find the value of only the errno part when looking at the ercd value
directly with a debugging facility, ercd can be treated as a one-byte signed
number. If there is an eight-bit restriction in uITRON specification, only
the errno part need be used (ercd 3 format). excls information can be
omitted.
* The ercd 1 format is not used in uITRON specification, but is used in file
management in ITRON2 specification.
----------------------4.3.2 Exception classes
----------------------The exception classes (excls) in ITRON2 and uITRON specification are as
follows:
excls:
EC_NONE
EC_TER
EC_FEX
EC_CPU
EC_SYS
EC_NOMEM
EC_RSV
EC_PAR
EC_OBJ
1
2
3
4
5
6
7
8
/* Class where system call exceptions do not

occur in ITRON2 specification */
/* Termination request class */
/* Forced exception class */
/* CPU exception class */
/* System error exception class */
/* Insufficient memory error exception class */
/* Reserved function error exception class */
/* Parameter error exception class */
/* Illegal object specification exception
EC_ACV
EC_CTX
EC_EXEC
EC_EXCMP
9
10
11
12
EC_RLWAI
EC_RSLT
13
14
class */
Access violation exception class */
Context error exception class */
Execution error exception class */
Execution completed error exception
class */
/* Forced release wait exception class */
/* Exception class showing execution result */
/*
/*
/*
/*
eclsptn:
/* Items converted to a pattern where excls is a
/* '>>' indicates a logical right shift. */
ECM_TER
((UW) H' 80000000 >> EC_TER)
/* H' 40000000
ECM_FEX
((UW) H' 80000000 >> EC_FEX)
/* H' 20000000
ECM_CPU
((UW) H' 80000000 >> EC_CPU)
/* H' 10000000
ECM_SYS
((UW) H' 80000000 >> EC_SYS)
/* H' 08000000
ECM_NOMEM
((UW) H' 80000000 >> EC_NOMEM)
/* H' 04000000
ECM_RSV
((UW) H' 80000000 >> EC_RSV)
/* H' 02000000
ECM_PAR
((UW) H' 80000000 >> EC_PAR)
/* H' 01000000
ECM_OBJ
((UW) H' 80000000 >> EC_OBJ)
/* H' 00800000
ECM_ACV
((UW) H' 80000000 >> EC_ACV)
/* H' 00400000
ECM_CTX
((UW) H' 80000000 >> EC_CTX)
/* H' 00200000
ECM_EXEC
((UW) H' 80000000 >> EC_EXEC)
/* H' 00100000
ECM_EXCMP
((UW) H' 80000000 >> EC_EXCMP)
/* H' 00080000
ECM_RLWAI
((UW) H' 80000000 >> EC_RLWAI)
/* H' 00040000
ECM_RSLT
((UW) H' 80000000 >> EC_RSLT)
/* H' 00020000
power of 2 */
*/
*/
*/
*/
*/
*/
*/
*/
*/
*/
*/
*/
*/
*/
* eclsptn (ECM_NONE = H'80000000) corresponding to EC_NONE is not provided

because it is not needed.
---------------------------------------4.3.3 Standard error code specifications
---------------------------------------- Errors used generally have general-purpose names. Errors with special names
can be assumed to have special meanings, so that there is no confusion.
- There are errors which actually occur only in relation to one type of
object, but which can be predicted to occur in other objects. To prevent
confusion, those object names have been included in the error name.
For example, in errors indicating file access violation, the name F is
included to distinguish them from memory access violation.
- Parts that distinguish between illegal errors (semantically illegal
operation) and reserved function errors (errors that will not be errors when
functions are added in future) use that distinction.
- Continuity and conformity to error codes in ITRON1 specification have been

taken into account.
[Error code (ercd) values]
-----------------------------------------------------------------------------Class where system call exceptions do not occur (EC_NONE = 0) errno: 0
Mnemonic
ercd
Explanation
-----------------------------------------------------------------------------E_OK
Normal termination
Corresponds to ITRON1 specification
TE_OK
-----------------------------------------------------------------------------System error exception class (EC_SYS =4)

errno: 1 to 8
Mnemonic
ercd
Explanation
-----------------------------------------------------------------------------E_SYS
-H'401
(-(EC_SYS<<8)-1)
System error
Error whose cause is unclear or that
affects the entire system. In ITRON2
specification, exception handlers for
the task-independent portions are
activated only for system errors.
TE_SYS
-----------------------------------------------------------------------------Insufficient memory error exception class (EC_NOMEM)

errno: 9 to 16
Mnemonic
ercd
Explanation
-----------------------------------------------------------------------------E_NOSMEM
-H'509
(-(EC_NOMEM<<8)-9)
No system memory
Insufficient memory, such as when an
object management block cannot be
secured
TE_MEM
E_NOMEM
-H'50a
No memory
(-(EC_NOMEM<<8)-10) Insufficient memory, such as at user
stack area, memory pool area, or
message buffer area acquisition
TE_MEM, (TE_MPLSZ)
-----------------------------------------------------------------------------Reserved function error exception class (EC_RSV = 6)

errno: 17 to 32
Mnemonic
ercd
Explanation
-----------------------------------------------------------------------------E_NOSPT
-H'611
(-(EC_RSV<<8)-17)
Unsupported function
E_INOSPT
-H'612
Function not supported in ITRON/FILE

specification
TE_INOSPT
(-(EC_RSV<<8)-18)
E_TNOSPT
-H'613
(-(EC_RSV<<8)-19)
Unsupported timer function

TE_NOTMR
E_RSFN
-H'614
(-(EC_RSV<<8)-20)
Reserved function code number

TE_UDF
E_RSSFN
-H'615
(-(EC_RSV<<8)-21)
Reserved subfunction code number

TE_UDS
E_RSMD
-H'616
(-(EC_RSV<<8)-22)
Reserved mode or option

TE_OPT
E_RSID
-H'617
(-(EC_RSV<<8)-23)
Reserved ID number
Occurs when ID numbers 0 to (-4) are
specified
TE_IDOVR
E_RSATR
-H'618
(-(EC_RSV<<8)-24)
Reserved attribute
Occurs when undefined system object
attributes are specified
-----------------------------------------------------------------------------Parameter error exception class (EC_PAR = 7)

errno: 33 to 48
Mnemonic
ercd
Explanation
-----------------------------------------------------------------------------* Mainly errors that can be checked statically
E_PAR
-H'721
Parameter error
(-(EC_PAR<<8)-33)
TE_PAR, (TE_MPLSZ)
E_ILADR
-H'722
(-(EC_PAR<<8)-34)
Illegal address
When the start address is odd
TE_MA, TE_SA, TE_PA
E_IDOVR
-H'723
(-(EC_PAR<<8)-35)
Outside ID number range

The specified object ID number exceeds
the maximum system value. Because
E_IDOVR and E_RSID are for the objects
having ID numbers, these errors do not
occur for interrupt vector or handler
numbers; instead, E_PAR is returned if
such a number is outside the range or
is reserved.
TE_IDOVR (at object creation)
E_SZOVR
-H'724
(-(EC_PAR<<8)-36)
Parameter size exceeds limit
E_PPRI
-H'725
(-(EC_PAR<<8)-37)
Illegal process priority
E_TPRI
-H'726
(-(EC_PAR<<8)-38)
Illegal task priority

TE_TPRI
E_ILTIME
-H'727
(-(EC_PAR<<8)-39)
Illegal time specification

Error in ltime, utime, cytime, or tmout
specification
TE_PAR
E_ILFN
-H'728
(-(EC_PAR<<8)-40)
Illegal function code number

Occurs in extended SVC definition
TE_SVC
E_ILMSG
-H'729
(-(EC_PAR<<8)-41)
Illegal message format

Occurs when message msgtype is not 0
E_VECN
-H'72a
(-(EC_PAR<<8)-42)
Illegal vector number

TE_VECN
E_IMS
-H'72b
(-(EC_PAR<<8)-43)
Illegal imask
TE_IPRI
-----------------------------------------------------------------------------Illegal object specification exception class (EC_OBJ = 8)

errno: 49 to 64
Mnemonic
ercd
Explanation
-----------------------------------------------------------------------------E_SELF
-H'831
(-(EC_OBJ<<8)-49)
Caller task specification

TE_SELF
E_NOPRC
-H'832
(-(EC_OBJ<<8)-50)
Process does not yet exist
E_EXS
-H'833
(-(EC_OBJ<<8)-51)
Object already exists

TE_EXS
E_NOEXS
-H'834
(-(EC_OBJ<<8)-52)
Object does not yet exist

This includes undefined extended SVCs
specified in sdef_sex. If the object
of a system call cannot be found,
E_NOEXS or E_IDOVR is returned. These
error differ in that E_IDOVR is
detected statically, while E_NOEXS is
detected dynamically. However, since
the range of valid ID numbers depends
on the implementation, so does the
distinction between the two errors.
TE_NOEXS
E_DMT
-H'835
(-(EC_OBJ<<8)-53)
Task dormant
TE_DMT
E_NODMT
-H'836
(-(EC_OBJ<<8)-54)
Task not dormant

TE_NODMT
E_NOCYC
-H'837
(-(EC_OBJ<<8)-55)
cyc_wup not issued for the task

TE_NOCYC
E_NOSUS
-H'838
(-(EC_OBJ<<8)-56)
Task not suspended

TE_NOSUS
E_ILSEM
-H'839
(-(EC_OBJ<<8)-57)
Illegal semaphore operation
E_ILAKEY
-H'83a
(-(EC_OBJ<<8)-58)
Illegal semaphore access key
E_ILBLK
-H'83b
(-(EC_OBJ<<8)-59)
Illegal memory block release or

operation
TE_ILBLK
E_NOWAI
-H'83e
(-(EC_OBJ<<8)-62)
Task not in wait state
E_OBJ
-H'83f
(-(EC_OBJ<<8)-63)
Other errors related to object status.
-----------------------------------------------------------------------------Access violation exception class (EC_ACV = 9)

errno: 65 to 68
Mnemonic
ercd
Explanation
-----------------------------------------------------------------------------* Access violation
* Includes object and memory access violation; does not include file access
violation.
* Does not occur in uITRON specification OS.
E_MACV
-H'941
(-(EC_ACV<<8)-65)
Memory access violation

Includes bus access errors
TE_ACCES
E_OACV
-H'942
(-(EC_ACV<<8)-66)
Object or handler access violation

When user task (excluding in extended
SVC handler) operates system object
E_ULEVV
-H'943
(-(EC_ACV<<8)-67)
User level violation
-----------------------------------------------------------------------------Context error exception class (EC_CTX = 10)

errno: 69 to 72
Mnemonic
ercd
Explanation
-----------------------------------------------------------------------------E_CTX
-H'a45
(-(EC_CTX<<8)-69)
Context error
TE_CTX
-----------------------------------------------------------------------------Execution error exception class (EC_EXEC = 11)

error: 73 to 80
Mnemonic
ercd
Explanation
-----------------------------------------------------------------------------E_QOVR
-H'b49
(-(EC_EXEC<<8)-73)
Queue overflow
TE_QOVR, TE_MBOVR
E_OOVR
-H'b4a
(-(EC_EXEC<<8)-74)
Object number overflow
-----------------------------------------------------------------------------Execution completed error exception class (EC_EXCMP = 12)

errno: 81 to 84
Mnemonic
ercd
Explanation
-----------------------------------------------------------------------------* Execution completed
E_DLT
-H'c51
Wait object deleted
(-(EC_EXCMP<<8)-81) Corresponds to ITRON1 specification
TE_DLT
E_INIHDR
-H'c52
Initialization handler error
(-(EC_EXCMP<<8)-82)
-----------------------------------------------------------------------------Forced release wait exception class (EC_RLWAI = 13)

errno: 85 to 88
Mnemonic
ercd
Explanation
-----------------------------------------------------------------------------* Release wait
E_TMOUT
-H'd55
Time-out
(-(EC_RLWAI<<8)-85) Corresponds to ITRON1 specification
TE_TMOUT
E_RLWAI
-H'd56
Forced release wait
(-(EC_RLWAI<<8)-86)
-----------------------------------------------------------------------------Class of exceptions showing execution result (EC_RSLT = 14)

errno: 89 to 96
Mnemonic
ercd
Explanation
-----------------------------------------------------------------------------E_PLFAIL
-H'e59
(-(EC_RSLT<<8)-89)
Polling failed (no message/semaphore)

(polling fail)
E_AROVR
-H'e5a
(-(EC_EXEC<<8)-90)
Array too short
E_MPURG
-H'e5b
(-(EC_RSLT<<8)-91)
Memory block deleted
E_MRELOC
-H'e5c
(-(EC_RSLT<<8)-92)
Memory block remapped
-----------------------------------------4.3.4 Implementation-dependent error codes

------------------------------------------
The following values are used for implementation-dependent error codes and
user (extended SVC exclusive in ITRON2 specification) error codes:
Implementation-dependent:
errno = 225 to 256, ERRNO = B' 000XXXXX
ercd = B' 11...111YYYYY000XXXXX
User (extended SVC exclusive):
errno = 193 to 224, ERRNO = B' 001XXXXX
ercd = B' 11...111YYYYY001XXXXX
errno 193 to 224 are assigned as extended SVC error codes in ITRON2
specification, but other error codes (including standard error codes 1 to 96)
may be returned in extended SVC. This simply means that codes 193 to 224 are
not assigned for anything other than extended SVC.
In exception classes (excls) for individual errors, 0 or another value may be
used for the error type or meaning.
errno 97 to 128 and 129 to 192 are reserved for file, device, and standard I/O
management.
******************************************************************************
*
ITRON Specification
*
*
microITRON
*
*
Ver. 2.01.00.00
*
*
*
*
Document number: MI-10-01-E (File#2)
*
******************************************************************************

Mitron 2

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Mitron 2

Caricato da

Copyright:

Formati disponibili

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

The Real-time Operating system Nucleus.

Change task priority

Context error (issued by task-independent portion)

Task C will be executed next.

To lower the priority of a task in the suspend state temporarily, combine

overhead by context determination in the operating system. These system

The caller task was specified (0 or the caller task ID number

Enqueued wakeup request count

mbxid wtskid= pk_msg=

tskid tmbwait= pk_msg=

Wait and clear event flag (bit)

Event flag ID number

Event flag ID number

Bit pattern at wait release

Event flag ID number

Wait task ID number

Outside ID range (depends on implementation)

Event flag ID number

Context error (iset_flg was issued by task portion)

Event flag ID number

Event flag ID number

Wait task ID number

Wait task ID number

Start address of receive message

Wait task ID number

Destination task ID number

Start address of receive message

Task mailbox wait

When task dispatching is caused by a system call issued in the interrupt

Context error (issued by task portion)

Wakeup task ID number

Operation when an error is detected depends on the implementation.

Context error (issued by task portion)

* Return and restart task *

Restart task ID number

Context error (issued by task portion)

Interrupt mask (level, priority)

* Get interrupt XXXX status *

Interrupt mask (level, priority)

Poll and get memory block

Memory pool ID number

Start address of memory block

E_IDOVR Outside ID range (depends on implementation)

Memory pool ID number

Memory pool ID number

Wait task ID number

Either frbcnt or wtskid or both must be 0.

Current date and time

Current date and time

Cyclic handler specification number

cyhno is the number used to distinguish between multiple cyclic handlers; it

Cyclic handler not active

E_ILADR Illegal address (value where cychdr cannot be used)

Cyclic handler specification number

Cyclic handler activation status

information is not returned.

Alarm handler specification number

If the alarm handler is redefined by def_alm, the previous definition need

Alarm handler specification number

Time left until next handler activation

(lfutime) and lower (lfltime), or upper (lfutime), middle (lfmtime), and

Context error (issued by task portion)