I-51-01E-011

ITRON Newsletter No.11
ITRON Technical Committee, TRON Association

Katsuta Building 5F, 3-39, Mita 1-chome, Minato-ku, Tokyo 108, JAPANTEL: (03) 3454-3191
FAX: (03) 3454-3224

ITRON-related Publications

loaded as a device driver, ITRON system calls canbe used not only by ordinary applications, but also
by TSR or other device drivers. The present version
does not implement timer-related functions, since it isintended for general-purpose use with DOS; but there
are plans to add this support in the future.
One more feature of ASURA-I is its adoption of a
BTRON real/virtual object network in its source code.
The real/virtual object source list is not contained in
the DOS archive, but it is found in the provisional
documentation \Inside of ASURA-I."
Applications are bundled with this software for displaying the states of each object, and for simple CLI
work area testing. Include les for an assembler arealso provided.
ASURA-I can be downloaded from the PersonalMedia Forum (FPMC) in the NIFTY-Serve on-line
service, or from Internet ftp servers at the University of Tokyo and Waseda University. The ftp addresses are: utsun.s.u-tokyo.ac.jp [133.11.11.11] andftp.waseda.ac.jp [133.9.1.4].

Listed in another page are the publications preparedand issued by the ITRON Technical Committee asof October 1, 1994. The ITRON-ITRON StandardHandbook is a one-volume compilation of ITRON(Ver 2.0) and ITRON2 speci cations. Each of thepublications below can be obtained directly from thesources indicated.
The latest version of ITRON3.0 is now Ver
3.02.00. Changes made since the ITRON3.0 Standard Handbook was released (Ver 3.00.00) are noted
in Newsletter No.5 and here below.
The ITRON Standard Guidebook '92-'93 still applies to users of ITRON (Ver 2.0) and ITRON2 speci cations, even though the dates in its title are nowpast. A new edition of the ITRON Standard Guidebook, focusing primarily on the ITRON3.0 speci cation, is now being prepared.

Revisions to ITRON3.0 Speci cation
IssuedRecent Works on ITRON

Revisions have been made to the ITRON3.0 speci cation to correct problems discovered since the issuingof the ITRON3.0 Standard Handbook. The changes
are summarized in the table below. The new version
number is 3.02.00.

The Information Processing Society of Japan devotes
the October 1994 issue of its monthly journal (Vol.35,No.10) to a series of articles on the present status andfuture outlook of the TRON Project. The ITRON
subproject is covered in an article entitled, \ThePresent and Future of the ITRON Subproject { Kernel
Speci cations and their Implementation," written by
the University of Tokyo's Hiroaki Takada, Toshiba's
Kiichiro Tamaru, and other members of the ITRONTechnical Committee.
The article starts by explaining the present situation in the eld of small-scale embedded systems,
and outlines the design policy adopted for the ITRON
speci cations. It then reports on implementations
and applications of ITRON-speci cation OSs, anddiscusses the bene ts gained from standardization.
Next, the authors present a technical introduction tothe real-time kernel implementation technologies de-Free Software Available
The software introduced below is not sold commercially, and is therefore not registered with the TRON
Association. Instead it is available free by downloading from NIFTY-Serve or the Internet, as explained
below.
ASURA-I

Mineyuki Kimoto

ASURA-I is a ITRON3.0-speci cation OS thatruns as a resident program in MS-DOS. Since it isy This newsletter is reprinted from TRONWARE vol.30 and
TRON PROJECT BIMONTHLY No.35.

1I-51-01E-011

ITRON-related Publications
NameTypePrice
Publisher
ISBN No.
ITRON-ITRON Standard Handbook Speci cation (Japanese)
4,800Yen Personal Media Co. 4-89362-079-7
ITRON3.0 Standard Handbook
Speci cation (Japanese)
4,000Yen Personal Media Co. 4-89362-106-8
ITRON/FILE Standard Handbook
Speci cation (Japanese)
3,000Yen Personal Media Co. 4-89362-092-4
ITRON Standard Guidebook '92-'93
Textbook (Japanese)
3,500Yen Personal Media Co. 4-89362-197-6
ITRON Speci cation Ver 2.01.00.00
Speci cation (English) 12,000Yen TRON Association{
ITRON2 Speci cation Ver 2.02.00.10
Speci cation (English) 15,000Yen TRON Association{
ITRON3.0 Speci cation Ver 3.00.00
Speci cation (English){
TRON Association{
NOTES:- Prices do not include consumption tax.
- The documents issued by the TRON Association are available to Association members at a special discount rate.
- English-language speci cations are distributed free of charge on the Internet as explained in Newsletter No.8.

Revisions to the ITRON3.0 speci cation (Ver 3.01.00 ! Ver 3.02.00)
1. In the System Call Index on p.VIII, the page number for cre sem is corrected as follows (p.VIII).
Wrong: cre sem [EN] Create semaphore
11
Correct: cre sem [EN] Create semaphore
111
2. The following clari cation is added to Fig.3: ITRON State Transition Diagram (p.27).
* This state transition diagram is only intended to illustrate typical state transitions. Dependingon the implementation, state transitions not shown here may occur as well.
3. The following correction is made on p.27, the second line from the bottom.
Wrong: 1 1 1 the execution of interrupt A, parts 2 { 3 1 1 1Correct: 1 1 1 the execution of interrupt X, parts 2 { 3 1 1 1ii
ii

veloped through the ITRON subproject. They explain the ITRON3.0 speci cation with its added support for distributed systems, and conclude by looking
ahead to the future of the project. The article as awhole does not presuppose knowledge of the ITRON
subproject and is therefore a useful introduction for
those reading about the project for the rst time, or
those with little detailed prior knowledge.

2I-51-01E-011

Revisions to the ITRON3.0 speci cation (Ver 3.01.00 ! Ver 3.02.00) (Cont.)
4. The following section is added to 1.6 Basic ITRON Concepts, following the section on the \TaskIndependent and Quasi-Task Portions."

Task States During a Dispatch Delay

Dispatching of tasks in ITRON may be temporarily disabled, because of the principle of delayed
dispatch, or when a system call is issued that prohibits dispatching. During that time, task states
are as explained below.
During the time dispatching is disabled, even if a situation occurs that would normally call for arunning task to be preempted, the task that would preempt it is not dispatched. The dispatchingof the latter task is delayed until the dispatch disabled state is cleared. While the dispatch isdelayed, the running task remains in RUN state, and the task to be executed after the dispatch
disabled state is cleared is treated as in READY state. As for the sequence of tasks in RUN statein the ready queue during a dispatch delay, this is an implementation-dependent matter.
If, while dispatching is disabled, a sus tsk system call is issued for the running task to put itin SUSPEND state, or if ter tsk is issued to put it in DORMANT state, the task transition isdelayed until the dispatch disabled state is cleared. During this time, the running task is considered
to be in a transient state, with the speci c handling of this status an implementation-dependentmatter. Here too, the task to be executed after the dispatch disabled state is cleared is treated asin READY state.
5. In the explanation of dis dsp, the following explanation replaces the earlier one for the rst pointon operation during dispatch disabled state (p.74).
- Even in a situation where normally a task executing dis dsp should be preempted by a systemcall issued by an interrupt handler or by another task executing dis dsp, the task newly going
to executable state is not dispatched. Instead, dispatching of this task is delayed until thedispatch disabled state is cleared by ena dsp.
6. In the explanation of dis dsp, the following explanation is added to the second point on operation
during dispatch disabled state (p.74).
- If an interrupt handler invoked during dispatch disabled state issues sus tsk for a running task(one that executed dis dsp) to put it in SUSPEND state, or ter tsk to put it in DORMANTstate, the task transition is delayed until the dispatch disabled state is cleared.
7. The following explanation replaces the second paragraph in the explanation of rot rdq (p.81).
When rot rdq is issued by the task portion, the ready queue with the priority of the calling task
is rotated by means of tskpri=TPRI RUN=0.
8. The last paragraph in the explanation of rot rdq is made a supplementary explanation. Also, thefollowing is added as a supplementary explanation for rot rdq (p.82).
Depending on the implementation, it may be possible to issue rot rdq(tskpri=TPRI RUN) from atask-independent portion, such as a cyclic start handler. In this case the ready queue containing
the running task, or the ready queue containing the highest priority task, is rotated. Normallythese two are the same, but not always, as when the task dispatch is delayed. In that case it isimplementation dependent whether to rotate the ready queue containing the running task or theready queue containing the highest priority task. Note that this is an extended function [Level X],
for which compatibility and connectivity are not guaranteed; so it cannot always be used.

3

I-51-01E-011

Revisions to the ITRON3.0 speci cation (Ver 3.01.00 ! Ver 3.02.00) (Cont.)
9. The following replacement is made for the rst sentence in paragraph three giving the reasons for
speci cation decisions for rsm tsk (p.100).
From a speci cation standpoint, even if a given task is in SUSPEND state, preferably there should
be no in uence on the scheduling sequence, as also with preemption.
The following replacement is made for the second sentence in paragraph four giving the reasons for
speci cation decisions for rsm tsk (p.100).
Hereafter \ready queue" means a ready queue in the implementation sense, as distinct from a readyqueue as de ned in the speci cations, in the sense of including only tasks in RUN state and tasks
in READY state.
10. The following replacement is made for paragraph two of the explanation of can wup (p.105).
The calling task can be designated by means of tskid=TSK SELF=0. An E ID error will result,however, if tskid=TSK SELF=0 is designated with a system call issued from a task-independent
portion.
11. The following supplementary explanation is added at del sem (p.115).

[Supplementary Explanation]

When a semphore being waited for by more than one task is deleted, the sequence of tasks in theready queue after the wait state is cleared is implementation dependent in the case of tasks having
the same priority.
A similar explanation is added at del flg, del mbx, del mbf, del por, del mpl, del mpf.
12. The following addition is made to the fourth sentence in the last paragraph of the explanation of
set flg (p.132).
In this case, the sequence of tasks in the ready queue after the wait state is cleared is guaranteed
for tasks having the same priority.
13. The explanation of E PAR error under the snd msg error codes is corrected as follows (p.149).
E PAR

parameter error (value unusable with pk msg, or illegal parameter (msgpri,etc.) in message header)

14. The following replacement is made for sentence one in paragraph six of the def int explanation(p.212).
Even when the issuing of a system call in an interrupt handler results in a situation where a task
in RUN state should go to another state and another task should go to RUN state, no dispatch(switching of the running task) takes place while the interrupt handler is running.
A similar revision is made in the explanations at def cyc and def alm.
15. The following replacement is made in the loc cpu explanation for the second point on operations
during an interrupt and dispatch disabled state (p.220).
- Even when a task that executed loc cpu is in a situation where it should be preempted becauseof a system call issued by a task that executed loc cpu, the task newly going to executablestate is not dispatched. Instead, dispatching of this task is delayed until the dispatch disabledstate is cleared by unl cpu.

4

I-51-01E-011

Revisions to the ITRON3.0 speci cation (Ver 3.01.00 ! Ver 3.02.00) (Cont.)
16. The following addition is made to the supplementary explanation for the def cyc system call (p.275).
In an implementation allowing def cyc to be called by a timer handler, it is possible to rede ne acyclic start handler with the same number in the handler.
17. In the addition to the supplementary explanation of the def alm system call that was added as of
Ver 3.01.00 (see Newsletter No.5), the following replacement is made (p.285).
At the time an alarm handler is started, the de nition of that handler is considered as alreadycanceled. Thus if ref alm is used to refer to information on the started handler in a handler, aE NOEXS error will result. Also, in an implementation allowing def alm to be called by a timerhandler, it is possible to rede ne an alarm handler with the same number in a handler.
18. In the explanation of get ver, the following revision is made in the third line from the top of p.295.
Wrong: 1 1 1 is common to ITRON and BTRON.
Correct: 1 1 1 is common to ITRON, ITRON, and BTRON.
19. In the explanation of ref sys, the following revision is made in the rst line on p.298.
Wrong: 1 1 1 execution state of the CPU and ITRON3.0 1 1 1
Correct: 1 1 1 execution state of the CPU and OS 1 1 1
20. In the explanation of def svc, the following revision is made in the eighth line from the top of p.303.
Wrong: - the indivisibility of system calls
Correct: - the indivisibility of an extended SVC handler
21. The following addition is made at the end of the section on high-level-language-support routines, insection 5.2 (p.356).
Note that if routines written in C-language functions are called using the same interface as assemblyroutines, use of high-level-language-support routines is not necessarily required even when TA HLNG
is designated.
22. The following replacement is made in 6.4 Data Types, in the section on \Universal data types"(p.376).
B
H
W
UB
UH
UW
VB
VH
VW
VP
FP

Signed 8-bit integer
Signed 16-bit integer
Signed 32-bit integer
Unsigned 8-bit integer
Unsigned 16-bit integer
Unsigned 32-bit integer
Data of indeterminate type (8-bit size)
Data of indeterminate type (16-bit size)
Data of indeterminate type (32-bit size)
Pointer to data of indeterminate typeProgram start address (in general)

23. The section title on p.384 is revised as follows.
Wrong: 6.5 List of C-language Interfaces
Correct: 6.6 Common Constants and Packet Format of Structures5