8/16/2019 mitron-1

1/43

******************************************************************************* 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. *

8/16/2019 mitron-1

2/43

* 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 isbelieved to be reliable, TRON ASSOCIATION is not assuring its contents norassuming any liability of problems caused by this document.

TRON is an abbreviation of The Real-time Operating system Nucleus.BTRON is an abbreviation of Business TRON.CTRON is an abbreviation of Communication and Central TRON.ITRON is an abbreviation of Industrial TRON.MTRON is an abbreviation of Macro TRON.

***************************** Structure of This Manual *****************************

This manual explains uITRON specification which is the revised version of theITRON specification realtime operating system for microprocessors.

This manual is structured as follows:

1. Realtime Operating System and ITRON Specification overviews the necessity  for a realtime operating system and ITRON specification, and describes  ITRON1 specification, uITRON specification, and ITRON2 specification, and  their relationships.

2. uITRON Specification explains the concept of uITRON specification design,  the relationship between ITRON1 specification and uITRON specification,  and the syntax of system call specifications in later chapters.

3. System Call explains the uITRON specification system calls.

4. Programming Interface explains the system call interfaces recommended for  the uITRON specification, specifically, the function codes, error codes,

8/16/2019 mitron-1

3/43

  and C language interfaces.

Note: uITRON means microITRON.

************* Contents *************

------File#1------

Chapter 1 Realtime Operating System and ITRON Specification  1.1 TRON Project and ITRON Specification  1.2 Basic Philosophy of ITRON Specification  1.2.1 Multitasking and realtime operating systems  1.2.2 Advantages of ITRON specification  1.2.3 ITRON specification series  1.3 Functions

  1.3.1 Basic concepts  1.3.1.1 Tasks  1.3.1.2 Resources  1.3.1.3 Task states and operation  1.3.1.4 Task scheduling  1.3.1.5 System status during non-task portion execution  1.3.1.6 Task-independent portion and quasi-task portion  1.3.1.7 ID (identification) numbers and access keys  1.3.1.8 Standardization policies and compatibility  in ITRON specification  1.3.2 System call interfaces  1.3.2.1 Interfaces with assembly language  1.3.2.2 Interfaces with C language

  1.4 uITRON and ITRON2 Specifications  1.4.1 Overview of uITRON specification  1.4.1.1 Basic philosophy of uITRON specification  1.4.1.2 uITRON specification design  1.4.1.3 uITRON specification OS requirements  1.4.2 Overview of ITRON2 specification  1.4.2.1 Basic philosophy of ITRON2 specification  1.4.2.2 ITRON2 specification design

Chapter 2 uITRON Specification  2.1 Design Concept  2.2 uITRON Specification Design  2.2.1 Task states  2.2.2 Functions that form subsets  2.2.3 System call interfaces  2.3 Standardization Philosophy in uITRON Specification  2.4 Scope of uITRON Specification  2.5 Functions Added to uITRON Specification  2.6 System Call Specification Syntax

------File#2------

Chapter 3 System Call

  3.1 Task Management Functions  3.2 Task-Dependent Synchronization Functions  3.3 Synchronization and Communications Functions

8/16/2019 mitron-1

4/43

  3.4 Interrupt Management Functions  3.5 Exception Management Functions  3.6 Memory Pool Management Functions  3.7 Time Management and Timer Handler Functions  3.8 System Management Function  3.9 uITRON Specification System Call List

Chapter 4 Programming Interface  4.1 Assembler Interfaces  4.1.1 Flag changes after system call execution  4.1.2 Function codes  4.2 C Language Interfaces and Mnemonics  4.2.1 Common principles in assigning mnemonics  4.2.2 Data types and syntax  4.2.3 Common principles of C language interfaces  4.2.4 C language interface standard specifications  4.2.5 Constants and packet format  4.3 Error Codes  4.3.1 Error code format

  4.3.2 Exception classes  4.3.3 Standard error code specifications  4.3.4 Implementation-dependent error codes

******************************************* uITRON Specification System Call Index *******************************************

 This index lists all uITRON specification system calls arranged in alphabetical order.

 act_cyc [4] Activate cyclic handler alh_sts [4] Get alarm handler status

 can_wup [3] Cancel wakeup task chg_iXX [2B] Change interrupt XXXX chg_pri [3] Change task priority clr_flg [3A] Clear event flag (word) clr_flg [3B] Clear event flag (bit) cpol_flg [3B] Poll and clear event flag (bit) cwai_flg [3B] Wait and clear event flag (bit) cyh_sts [4] Get cyclic handler status def_alm [#4] Define alarm handler def_cyc [#4] Define cyclic handler def_int [#1] Define interrupt handler def_rst [#5] Define task restart address dis_int [2A] Disable interrupt ena_int [2A] Enable interrupt ext_tsk [2] Exit task flg_sts [4A] Get event flag status (word) flg_sts [4B] Get event flag status (bit) frsm_tsk [4] Force resume task get_blk [4] Get memory block get_tid [3] Get task ID number get_tim [2] Get time get_ver [1] Get version number ichg_pri [#3] Change task priority (for task-independent portion) irel_wai [#5] Release wait (for task-independent portion) irot_rdq [#3] Rotate ready queue (for task-independent portion)

 irsm_tsk [#3] Resume task (for task-independent portion) iset_flg [#3A] Set event flag (word) (for task-independent portion) iset_flg [#3B] Set event flag (bit) (for task-independent portion)

8/16/2019 mitron-1

5/43

 isig_sem [#1] Signal semaphore (for task-independent portion) isnd_msg [#2] Send message to mailbox (for task-independent portion) isnd_tmb [#5] Send message to task mailbox (for task-independent portion) isus_tsk [#3] Suspend task (for task-independent portion) iwup_tsk [#1] Wake up task (for task-independent portion) iXX_sts [3B] Get interrupt XXXX status mbx_sts [4] Get mailbox status

 mpl_sts [4] Get memory pool status pget_blk [3] Poll and get memory block pol_flg [3A] Poll event flag (word) pol_flg [3B] Poll event flag (bit) prcv_msg [2] Poll and receive message from mailbox prcv_tmb [5] Poll and receive message from task mailbox preq_sem [1] Poll and request semaphore rcv_msg [2] Receive message from mailbox rcv_tmb [5] Receive message from task mailbox rel_blk [3] Release memory block rel_wai [5] Release wait ret_int [#1] Return from interrupt handler

 ret_rst [5] Return and restart task ret_tmr [#4] Return from timer handler ret_wup [3] Return and wakeup task rot_rdq [3] Rotate ready queue rsm_tsk [3] Resume task sem_sts [4] Get semaphore status set_flg [3A] Set event flag (word) set_flg [3B] Set event flag (bit) set_tim [2] Set time sig_sem [1] Signal semaphore slp_tsk [1] Sleep task snd_msg [2] Send message to mailbox snd_tmb [5] Send message to task mailbox

 sta_tsk [2] Start task sus_tsk [3] Suspend task ter_tsk [3] Terminate task tmb_sts [5] Get task mailbox status tsk_sts [3] Get task status wai_flg [3A] Wait event flag (word) wai_flg [3B] Wait event flag (bit) wai_sem [1] Wait on semaphore wai_tsk [3] Wait for wakeup task wup_tsk [1] Wake up task

******************************************************************************* Chapter 1 ** Realtime Operating System and ITRON Specification *******************************************************************************

This chapter reviews the necessity for a realtime operating system and thesummary of ITRON specification, and explains ITRON1 specification, uITRONspecification, ITRON2 specification, and their relationships.

***************************************** 1.1 ** TRON Project and ITRON Specification *****************************************

Since microprocessors evolved at the beginning of the 1970s, the accompanyingtechnology has progressed rapidly and the scope of applications is stillexpanding. Microprocessors are being used everywhere and are already

8/16/2019 mitron-1

6/43

necessities in our daily lives. Their communication capabilities anddistributed processing power will bring us more comfortable lives. It ispredicted that million-gate VLSI chips will appear in the 1990s. With suchstate-of-the-art semiconductors, microprocessors will have enough power tosatisfy most every demand.

Existing microprocessors are not yet powerful enough to meet future demands.

They still use out-of-date architectures which have covered up many of thehardware constraints brought about by the technology in 1970s. Theseconstraints have distorted many aspects of the current architectures. Ifsemiconductor technology continues to develop at its present rate, theincreasing gap between hardware and architecture will reveal that only a smallpart of potential hardware power is available because of obsoletearchitectures. Although requests for wider coverage coming from applicationfields and improved semiconductor technology will force improvements in thecurrent architectures, no architecture will be able to satisfy the demandscompletely if innovation is not implemented in the current architecture.To respond to the predicted VLSI technology and the spreading desires formore sophisticated applications, the TRON project is providing a new

microprocessor architecture which can cover the wide range of needs that willbe required in the 1990s.

The TRON project was started in June 1984 to provide a new architecture tocover wide areas of computer-related technologies, ranging from microprocessorhardware to application programs. The goal of the project is to meet futuredemands for microprocessor applications based on the predictions andperspectives of VLSI technology in the 1990s, getting free from thelimitations of old architectures. The new architecture is realtime-, VLSI-,and distributed processing-oriented in order to be a standard architecture ofthe 1990s.

The following paragraphs summarize the philosophy of the TRON project:

 - The architecture design must meet the technology levels in the 1990s.

  Current microprocessor architecture is still restrained by compatibility  with 8-bit microprocessor architecture, sacrificing the benefits of  advanced VLSI technology. Ad-hoc architectures distorted to meet the VLSI  technology waste the potential performance of VLSI microprocessors.  The TRON project sets the goal at a VLSI-based design, freed from current  limitations.

 - Realtime processing is essential.

  As can be seen in batch or TSS processing, the way of using conventional  computers was for humans to wait for computers. In the future, however,  many computers will be used to control and interface with the external  environment, including natural phenomena, and to make life more  comfortable. This means that computers will wait for humans (or for  stimuli from the external environment). This environment must be treated  as realtime processing by nature. Realtime response is essential in  distributed processing and communications applications. For realtime  processing to obtain the same processing power as other processing,  however, higher performance computers are necessary because the computer  use ratio significantly drops in realtime processing. The TRON project  considers realtime capability essential and requests all designs to take  this into account.

- The goal is to produce the ultimate von Neumann computer.

8/16/2019 mitron-1

7/43

  The TRON project research is limited to general-purpose von Neumann  computers although much research is also being done on non-von Neumann  computers. Some researchers doubt the limited potential of von Neumann  computers. Because of the wide range of their coverage on applications  and the completeness of their computer technology, von Neumann computers  will certainly be the core of data processing in the 1990s. The TRON  project intends to propose a model of an ultimate von Neumann computer that

  makes full use of VLSI features.

- The TRON total architecture covers all layers of computer hierarchy.

The TRON project covers all levels of computer hierarchy, from microprocessorsto networks. Consequently, demands or requests from one design are fed backto a wide range of designs. For example, a problem in the operating systemcan be solved by reinforced processor instructions, and system calls necessaryto build networks can be built into the operating system. Thus, applicationexecution speed, which can be considered as the actual computer speed, isgreatly increased, because tuning between layers is possible in the designstage.

Five subprojects proceed in parallel in the TRON project. The kernel of theproject is the TRON-architecture microprocessor that will make full use of thesemiconductor technology of the 1990s. The TRON-architecture microprocessorwill be the optimum one for applications and operating system execution in the1990s. The operating system layer consists of three operating systemspecifications: the industrial TRON (ITRON) specification for realtimemicrocontroller operating systems, the business TRON (BTRON) specification forworkstation operating systems, and the communication and central TRON (CTRON)specification for operating systems implemented on data center machines thatperform large-volume data processing. The CTRON specification is intended formainframes rather than microcomputers. These three specifications each coverprocess control, workstations, and center mainframes because a single

operating system cannot cover all of these. The macro-TRON (MTRON)specification integrates the ITRON, BTRON, and CTRON specifications throughnetworks to achieve the overall goals of the TRON project.

The TRON project separates the design criteria (the architecture) from themeans of realization (the implementation). First, let us define the termarchitecture. The TRON project extended the meaning defined by G.M. Amdahl.In addition to the instruction set for programmers, an architecture specifiesall attributes of a system, including operating systems and man-machineinterfaces. Specifically, the TRON architecture contains all interfacespecifications, from the TRON-architecture based microprocessor specificationinstruction set to the ITRON- and BTRON-architecture system calls and theBTRON-architecture man-machine interfaces. Separating architecture andimplementation gives the advantage that higher layers are not affected evenif a lower layer implementation is completely changed. In other words,compatibility is maintained for each layer. Another important concept in theTRON project is that architecture is specified, but performance is not.Consequently, there is free competition between implementors. From theuser's viewpoint, many different products having the same functions anddifferent performance levels are offered by different manufacturers atdifferent times. The TRON project provides not only schemes forstandardization but also an arena for fair technological competition.

******************************************** 1.2 *

* Basic Philosophy of ITRON Specification ********************************************

8/16/2019 mitron-1

8/43

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

Microcomputers have pioneered a new computer application field, thereplacement of control devices. This is due to their compact size, and lowprice.

Specifically, microcomputer control is now used for telephone switchingsystems,industrial robots, numerically controlled machine tools, and homeappliances such as air conditioners, washing machines, and televisions.

These microcomputers are used as a single component within a larger system.For this reason, they are called embedded computer systems or embeddedsystems.

Embedded computer systems usually contain sensors and must be able to causeexternal devices to take proper actions periodically and be able to respond toexternal stimuli or changes. In an air conditioner, for example, sensorssense external temperature and humidity, and the sense information is used to

control the air conditioner output and wind direction. Programs in embeddedsystems differ from those in usual data processing. They must control theexternal environment with minimal delay by responding within milliseconds.

To improve program productivity and shorten the development period of thoserealtime programs, an operating system (OS) should be used in applicationprogramming. The operating system to be used is different from that used fora general-purpose computer, which protects user spaces and manages files.Its main purpose is to simplify programming, such as parallel processing andsynchronization with external events by interrupts.

Computers execute their instructions or programs sequentially; they cannot dotwo things at a time. Realtime systems, however, often have multiple sensors

and have to monitor several things in parallel. If there are two things to bemonitored, it is natural to cause two separate programs to run in parallel forsimpler programming. The concept of multitasking was invented because of thisproblem. In multitasking, each program to be executed in parallel is called atask. Programming each task improves understandability and productivity ofthe program. Of course, a single processor can only execute one instructionat a time, so multitasking is implemented by time-sharing under the operatingsystem control. Multitasking operating systems are required for embeddedsystems.

General-purpose computer operating systems are capable of multitasking and,their jobs (processes or tasks) are executed in parallel. Their jobs however,are mutually independent. For example, one computer is used for wordprocessing, compilation, and text editing, each job being submitted byseparate users. In this case, multitasking is used by that computer, butthere is no relationship between jobs. Multitasking is used to increase costeffectiveness,that is, to share one computer for mutually independent jobs.

In embedded systems, the entire work to be conducted is split into severaltasks to make programming easier. Tasks are thus closely related with eachother, and the relationship between tasks is extremely complex. The chiefsystem designer must know the operations of each task and coordinate thosetasks to complete the assigned work. The nature of multitasking is thus quitedifferent for general-purpose computers and embedded systems.

Another important point is their realtime response. Realtime response is theability of computers to follow changes in the external environment. The timetaken to produce a processing result is limited. More simply, it means that

8/16/2019 mitron-1

9/43

the response must always be quick enough, or that the worst response time mustbe predictable.

In conventional batch or TSS processing, users are waiting for availablecomputer time. The computer performs calculations, and there is norelationship with other systems. Consequently, delayed processing causesdelayed results, but does not lead to catastrophe.

In realtime systems, however, calculation is not the final objective; the realobjective of the system is to control other equipment using the calculationresults. There are thus strict requirements for processing time, and ifprocessing is too slow, results are useless even if they are correct.Processing delay in safety equipment control on the high-speed trains, forexample, may cause a serious accident because brakes may not operate in time.In another system that controls the ignition timing in car engines, thecalculated timing must be given to the engine before its rotation reaches theignition point.

The response time is thus as important as the processing results are, and late

results mean no results.

To satisfy the strict requirements of response time, the computer must be ableto process results quickly whenever external stimuli are received. The CPUuse ratio thus drops very low. This type of computer uses never happeneduntil computers have become popular and their prices have dropped.Application fields in realtime processing and embedded systems are still new.

In ordinary programming, algorithms, data structure, overall performance, andcalculation volume are usually estimated. However, the absolute programexecution time is not accurately estimated. Applications for realtime systemsrequire accurate estimation of execution time. They require the estimation ofresponse time, considering the execution status of other tasks and the load on

the entire system. Estimating the CPU time of individual programs is notrequired. This estimation is extremely difficult and is impossible on thecomplex operating system used on mainframes. The operating system must becompact and simple; otherwise the overhead time cannot be estimated.

Operating systems used in embedded systems are quite different from those usedin development systems or in general data processing systems. They must havemultitasking capability and realtime characteristics.

---------------------------------------1.2.2 Advantages of ITRON specification---------------------------------------

Industrial TRON (ITRON) specification is for a realtime-multitasking operatingsystem to be implemented in embedded industrial systems. The standardizationor hardware virtualization is kept to a minimum to improve the processingperformance. Another important feature is that it produces compact objectcode by system tuning, even though it has many functions.

Standardization and hardware virtualization are desirable from the viewpointsof software compatibility and user training, but may cause performancedegradation. Having many functions makes programming easier and improvesperformance, but the object code becomes larger. In designing an operatingsystem, it is necessary to balance these trade-offs, and the ITRONspecification is a good example of this. The concept of weak standardization,

which is common to the entire TRON project, has been adopted by realtimeoperating systems.

8/16/2019 mitron-1

10/43

The following paragraphs summarize the advantages of the ITRON specification.

- Availability on various processors

  The ITRON specification is to be implemented on many processors.  However, the implementation can be made processor-specific if so desired.

  When designing a standard operating system, the first step is to design a  virtual-processor architecture common to all processors, and to implement  the ITRON specification on it. However, there is an obvious gap between the  virtual-processor architecture and the native architecture of each  processor. This degrades performance. To obtain maximum performance as a  realtime operating system, the architecture must use the full potential of  the processor, and extreme virtualization of hardware and operating system  functions must be avoided. Object compatibility is not as important for the  application fields. Training compatibility, such as consistent system call  names and functions is important instead.

  In conclusion, the ITRON specification provides processor-independent

  specifications separated from processor-dependent specifications. To avoid  performance degradation, ITRON specifications are left as is where  standardization or virtualization was difficult.

- Many functions

  The ITRON specification has many system calls. For example, it offers  almost all conceivable synchronization mechanisms: event flags, semaphores,  and task-dependent functions (such as the slp_tsk and wup_tsk system calls).  Performance and program productivity can be improved by selecting the best  mechanism for the application.

- High-speed response

  Task switching (dispatching) and interrupt-handler activation are most  sensitive to the response time in realtime applications. Related to system  tuning as explained later, the ITRON specification allows high-speed  dispatching by limiting general-purpose registers to save.

  It also allows user-defined interrupt handlers to be activated without  operating system intervention when external interrupts occur. No overhead  results except that the user must save the registers used by interrupt  handlers.

- Adaptability

  The ITRON specification is flexible and adaptable, considering  embedded-system applications. Selection of system calls, specification of  the registers used during dispatching, use of low-power modes when there are  no running (or ready) tasks, and whether to perform error checking during  system call execution are all left for the implementor or user to decide.

  For example, checking memory-address parameters by software for whether to  cause memory-related errors, such as segmentation and bus errors, generates  high overhead for system call execution. If the parameters are fixed, and  the user program is correct, the parameters do not cause errors. Therefore,  complete error checking can be performed during debugging and the error  checking routine is removed after debugging. The ITRON architecture thus

  has a large degree of freedom regarding error checking.

- Ease of training

8/16/2019 mitron-1

11/43

  The ITRON specification design philosophy places an emphasis on training, so  considerations on programmer training are thought of as important functions.

  ITRON specification system call names and functions are determined  systematically, based on several criteria, to make them easy to understand.  For example, ITRON specification system call names consist of seven

  characters, xxx_yyy, or eight characters, zxxx_yyy. xxx represents the  operation and yyy the object (Figure 1.1). Table 1.1 lists the meanings of  xxx and yyy. Eight-character system calls prefixed by z are compound system  calls having multiple functions or those derived from seven-character system  calls without the z.

  The ITRON specification is generally independent of processor models, so  knowledge about the operating system is common to all models. This is a  major advantage for program development.

 +---------+---------+---------+ | cre_tsk | del_tsk | sus_tsk |

8/16/2019 mitron-1

12/43

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

The ITRON specification is standard one for the realtime operating systems, butits implementation is designed independently for each processor. As thoseprocessors increase, the standard specification needs to be expanded to

several specifications. Currently, three specifications are available: theITRON1, ITRON2, and uITRON specifications.

The ITRON1 specification is for processors such as the Intel iAPX86, MotorolaMC68000, National Semiconductor NS32000, and NEC V series. The ITRON2specification is for new high-performance processors, for example, those basedon the TRON architecture. Compared to the ITRON1 specification, the ITRON2specification has additional functions and improved compatibility. Unlike theITRON2 specification, the uITRON specification is for inexpensive processorssuch as single-chip processors.

Generally, there are trade-offs between compatibility with a standard

operating system and performance improvement by tuning. This means that theremust be balanced trade-offs between the two. The ITRON1 specification is forexisting 16-bit processors, the ITRON2 specification is for new 32-bitprocessors, and the uITRON specification is for single-chip processors.In other words, the ITRON2 specification is an improved version of the ITRON1specification, with higher standardization levels and extended specifications.The uITRON specification is an improved version of the ITRON1 specification,with higher tuning capabilities and simplified specifications.

************* 1.3 ** Function *************

--------------------1.3.1 Basic concepts--------------------

--------------1.3.1.1 Tasks--------------

In the ITRON specification, a task is defined as a unit of parallel processingof programs. Whereas a program in one task is executed sequentially, programsin different tasks are executed in parallel. However, parallel execution isonly a conceptual operation as viewed by the applications programmer(operating system user). Physically, each task is processed by the operatingsystem on a time-sharing basis.

The task being executed by the processor is switched to another task when asystem call that changes the task state is issued or when an interrupt whichcauses state transition occurs. Switching between tasks is calleddispatching, and the mechanism in the operating system that executes this iscalled the dispatcher.

When there is more than one task that can be executed, the order of executionis determined by an algorithm. This control of the task execution order iscalled task scheduling. The ITRON specification adopts a scheduling algorithm

based on the priority assigned to each task. Smaller numbers have higherpriority. In the ITRON specification, higher priority tasks are alwaysexecuted first. Lower priority tasks are never executed until higher priority

8/16/2019 mitron-1

13/43

tasks have been executed.

In the ITRON specification, numbers are used to identify tasks. These numbersare called task ID numbers. The maximum number of tasks that can be createddepends on the implementation, the target system hardware configuration, andthe content of the configuration table. In the uITRON specification, tasksare created statically when the system is started, while in the ITRON1 and

ITRON2 specifications, tasks are created dynamically using task ID numbers.After creation, tasks are identified using the task ID numbers or the taskaccess keys assigned when the tasks were created (in ITRON1 specificationonly).

The ITRON specification OS must collect task management information to controlthe execution of many tasks and to carry out multitasking. This collectedinformation is called the task control block (TCB). In principle, the contentof the TCB cannot be viewed by the user; the ITRON specification OS sets andchanges internal TCB values. In the ITRON specification, the TCB usuallyholds information such as the following (details depend on theimplementation):

 Task ID number Task priority Entry pointer (Task start address) Initial user stack pointer Exception handler address Save area for registers used by the task Flags indicating the task status

------------------1.3.1.2 Resources------------------

The elements necessary for task execution are called resources. Resourcesinclude hardware, such as processors, memories, and I/O units, and software,such as programs. Since the majority of resources cannot be used by more thanone task at a time, the operating system must coordinate limited resources sothat they are assigned exclusively among multiple tasks operating in parallel.The ITRON specification has synchronization and communications functions toassign resources exclusively.

----------------------------------1.3.1.3 Task states and operation----------------------------------

Figure 1.2 shows the task states and the system calls that cause statetransition. There are five task states:

(1) Run state

In the run state, a task is being executed.

(2) Ready state

In the ready state, a task is ready for execution, but cannot be executedbecause a higher priority (or equal-priority) task is being executed. In thisstate, a ready task can be executed as soon as the processor becomesavailable. If there are two or more ready tasks, they form a queue, waiting

for the processor to become free. This is called the ready queue.

(3) Wait state

8/16/2019 mitron-1

14/43

In the wait state, the task cannot be executed because an execution conditionhas not been satisfied. In the wait state, the task is waiting for thecondition to be satisfied.

The wait state can be further classified as the wait state, the suspend state,or the wait-suspend state. A task enters the wait state when the task issues

a system call to itself, while waiting for an event to occur. A task entersthe suspend state when the task is suspended by another task. A task entersthe wait-suspend state when the task already in the wait state is forced toenter the event wait state. In the ITRON specification, there is a distinctdifference between the wait and suspend states. A task cannot enter thesuspend state by itself. Resumption from the wait state begins at the pointat which the task was suspended, and environmental data such as the programcounter, registers, or other program execution status (called context) isrestored to previous value. In the wait state, the task keeps possession ofsemaphores and resources other than the processor.

(4) Dormant state

In the dormant state, the task has not yet been started or has alreadyterminated. A task enters this state when it is created.

In this state, unlike the wait state, all the resources are released, thecontext, such as the registers or program counter, is initialized at start,and operations (wup_tsk, ter_tsk, sus_tsk, chg_pri, and other system calls)issued to the task are treated as errors.

(5) Nonexistent state

The nonexistent state is a hypothetical state where a task is not registeredin the system; it has not been created or it has already been deleted.

The uITRON specification does not support the nonexistent state. Depending onthe implementation, it also might not support the suspend state, wait-suspendstate, or dormant state. All of states (1) to (5) are necessary in the ITRON1and ITRON2 specifications.

One of the features of the ITRON specification is that system calls addressedto the caller and those addressed to another task (Table 1.2) are separated toshow clearly the state transition of a task and to make the operations ofsystem calls easy to understand. In other words system calls for transitionsfrom the run state are distinguished from those for transitions from otherstates.

+---------+ -------------------- Dispatch -------------------> +-------+| READY |

8/16/2019 mitron-1

15/43

  | | | | +---- +----------+ (ter_tsk) | | |  | | | | | | | |  | | | | | Release | | |  | | | | | | | |  | | | | Suspend v | | |  | | | | (sus_tsk) +----------+ | | |  | | | +-------------------> | SUSPEND | Terminate | | |

  | | +---------------------> | | ---------------+ | |  | | Resume +----------+ (ter_tsk) | | |  | | (rsm_tsk,frsm_tsk) | ^ | | |  | | | | | | |  | | +------+ | | |  | | | | |  | | Start (sta_tsk) +----------+ | | |  | +------------------------ | DORMANT | | |

8/16/2019 mitron-1

16/43

 | | Nonexistent state | Nonexistent state | +---------------------+---------------------------+-------------------------+

* In the ITRON specification, system calls addressed to the caller and those  addressed to another task are clearly separated to show clearly the state  transitions of a task and make system calls easy to understand. In other  words, system calls for transitions from the run state and those for

  transitions from other states are clearly distinguished.

------------------------1.3.1.4 Task scheduling------------------------

Task scheduling in the ITRON specification is based on task priority. Firstcome first served (FCFS) scheduling applies to tasks with the same priority.Figure 1.3 is an example of this scheduling.

Figure 1.3 (A) is the ready queue state after task A of priority 1, task E ofpriority 3, and tasks B, C, and D of priority 2 have been started, in that

order. Task A has the highest priority among the current ready tasks, sotask A is executed. In the ITRON specification, the task priority isabsolute. If task A is being executed, other lower priority tasks are notexecuted at all.

Here, when a system call causes task A to enter the wait state, the readyqueue at that time is as shown in Figure 1.3 (B). In this state, there arethree ready tasks with the highest priority (tasks B, C, and D). According tothe ITRON specification, if there are two or more tasks with the samepriority, the task that enters the ready state first is executed first. Inthis example, task B is executed next. This method is called first come firstserved (FCFS) scheduling. In the ITRON specification, FCFS scheduling appliesto tasks having the same priority.

If an external interrupt is generated in this state, rescheduling occurs onreturn from the interrupt handler. However, task B is executed after thereturn from the interrupt handler unless a task with higher priority than B isplaced in the ready state by the interrupt handler. That is, task B will notlose the execution priority even if an external interrupt occurs because thereis no direct relationship between an external interrupt and the task beingexecuted at the point of interrupt.

However, when a task that has entered the wait or dormant state moves back tothe ready state, it is placed at the end of the ready queue of its priority.In the ITRON specification, the rot_rdq system call rotates the ready queue ofthe same priority as the task. When it is issued, task B is placed at the endof the ready queue.

The user can apply round-robin scheduling to tasks having the same priority,rather than using FCFS scheduling. Round-robin scheduling gives each task atime slice of the processor. To implement the scheduling, the following twosteps are needed: (1) Activate the interrupt handler at fixed-time intervalsusing timer interrupts. (2) Issue the rot_rdq system call.

A task priority can be changed dynamically by the chg_pri system call.

  Head of ready queue  +-----------------+

  | ----------------+  +-----------------+ |  |

8/16/2019 mitron-1

17/43

 Priority |  High Priority 1 +----> Task A ---->---+  ^ |  | +---------------------+  | |  | Priority 2 +----> Task B ----> Task C ----> Task D ----+  | |

  | +-------------------------------------------+  | |  | Priority 3 +----> Task E ---->  v  Low

  (A) Initial ready queue state

  Head of ready queue  +-----------------+  | ---------------+  +-----------------+ |

  |  Priority |  High Priority 1 |  ^ |  | |  | |  | Priority 2 +----> Task B ----> Task C ----> Task D----+  | |  | +------------------------------------------+  | |  | Priority 3 +----> Task E ---->  v  Low

  (B) Ready queue state after task A has entered the wait state

  Figure 1.3 Tasks in ready queue (ITRON specification)

--------------------------------------------------------1.3.1.5 System status during non-task portion execution--------------------------------------------------------

To program tasks which run on the ITRON specification OS, look at the taskstate transition diagram, and follow the state transitions of each task.Users may program the interrupt handler or extended SVC handler, which requirekernel-level programming rather than task-level programming. The systemstatus must be carefully examined when a non-task portion is being executed toavoid programming errors. This section explains the ITRON specificationsystem statuses.

The ITRON specification system statuses are classified as shown in Figure 1.4.

Statuses during operating system execution (system call execution) areincluded in the transient statuses shown in Figure 1.4. From the user's pointof view, it is important that all system calls issued by the user are executedwith continuity. Because the internal status during system call execution isunknown to the user, it is considered a transient status and its controlmechanism is treated as a black box.

Task-independent portions and quasi-task portions include all kinds ofhandlers (except exception handlers, executed as task portions). Quasi-task

8/16/2019 mitron-1

18/43

portions contain the task-specific context, and task-independent portionscontain the task-independent context. Specifically, extended SVC handlers,which process user-defined extended system calls, mainly form quasi-taskportions. Interrupt handlers, activated by external interrupts, formtask-independent portions. Task state transitions in quasi-task portions arethe same as those for tasks, and system calls which place the caller in thewait state can be issued.

In the ITRON specification, the transient statuses, task-independent portions,and quasi-task portions are called non-task portions. The status in whichtask programs are executed is called "task portion being executed."

  +-- Transient statuses  | (operating system  | (being executed)  | System statuses --+-- Non-task --+-- Task-independent  | portion being | portion being executed  | executed | (interrupt handlers)

  | |  | +-- Quasi-task portion being  | executed  | (Extended SVC handlers)  +-- Task portion  being executed

  Figure 1.4 ITRON specification system statuses

--------------------------------------------------------1.3.1.6 Task-independent portion and quasi-task portion--------------------------------------------------------

Interrupt handlers form the task-independent portion. Task-independent meansthat the portion has no relationship with the task that was being executedimmediately before the task-independent portion was entered, and that theportion is not related to any task. Hence, it is not possible for thetask-independent portion to issue system calls which place the caller in thewait state, or those which implicitly address the caller. The currentlyexecuted task cannot be determined if the task-independent portion is beingexecuted. This means that task switching (dispatching) does not occur.Dispatching is delayed until the execution of the task-independent portion iscompleted. This is called the delayed dispatching principle.

If dispatching is caused by an interrupt handler, which belongs to thetask-independent portion, execution of the remaining part of the interrupthandler is delayed until the execution of a handler-activated task iscompleted.If an interrupt nesting occurs during this period, problems mayoccur.

Figure 1.5 shows the status where interrupt X occurs during execution oftask A,and higher priority interrupt Y occurs during the execution of theinterrupt handler. In this case, when dispatching is caused immediately onthe return from interrupt Y at 1 and task B starts, execution of processesbetween 2 and 3 in interrupt X is delayed until task B is completed.Processes between 2 and 3 are executed when task A enters the run state.Interrupt X has lower priority so the handler for interrupt X may be preemptednot only by a handler for a higher priority interrupt, but also by task B,

activated by that handler. Hence, the interrupt handler no longer has priorityover tasks, and programming an interrupt handler is not possible. This is whythe principle of delayed dispatching has been established in the ITRON

8/16/2019 mitron-1

19/43

specification.

By contrast, the quasi-task portion consists mainly of the user-expanded partsof the operating system. These include the extended SVC handlers.Some processors, however, do not have a quasi-task portion, and the extendedSVC handler is contained in the task-independent portion.

The quasi-task portion identifies the task that was being executed immediatelybefore the quasi-task portion was entered (requesting task). The quasi-taskportion defines the task status in the same way as in the task portion, and itcan enter the wait state. Hence, dispatching occurs in the quasi-task portionin the same way as in a usual task execution. As a result, a quasi-taskportion, such as the expanded portion of an operating system, is not alwaysexecuted prior to all other tasks even though it belongs to the non-taskportion, in contrast to the interrupt handler, which is always executed priorto all other tasks.

The following two examples show the differences between task-independentportions and quasi-task portions:

- An interrupt occurred during execution of task A (priority 8 (low)), and  wup_tsk was executed for task B (priority 2 (high)) by the interrupt handler  (task-independent portion). However, in accordance with the delayed  dispatching principle, dispatching does not yet occur; wup_tsk is executed,  then the remaining part of the interrupt handler is executed. Dispatching  is eventually caused by ret_int placed at the end of the interrupt handler,  and then task B is executed.

- An extended system call was executed during task A (priority 8 (low)), and  wup_tsk was executed for task B (priority 2 (high)) in the extended SVC  handler (quasi-task portion). However, because the delayed dispatching  principle does not apply, dispatching occurs during wup_tsk, task A enters

  the ready state of the quasi-task portion, and task B enters the run state.  Hence, task B is executed before the remaining part of the extended SVC  handler. When dispatching occurs again and task A enters the run state, the  remaining part of the extended SVC handler is executed.

  | : Task-independent portion  ! : Task portion

  Task A Task B Interrupt X Interrupt Y  (low priority) (high priority) (low priority) (high priority)  !  ! Interrupt !--------------------------------->|  |  Interrupt +------------------->|  nesting |  wup_tsk B  |  |  2 +

8/16/2019 mitron-1

20/43

When dispatching occurs at 2, execution of the remaining part of the interruptX handler is delayed.  Figure 1.5 Interrupt nesting and delayed dispatching

----------------------------------------------------1.3.1.7 ID (identification) numbers and access keys----------------------------------------------------

In the ITRON specification, tasks and other items which receive system calloperations are called objects. Objects include memory pools andsynchronization and communications facilities such as event flags, semaphores,and mailboxes. The operating system provides an object management table foreach object (called a TCB for a task). Objects are identified by ID(identification) numbers. To create an object, an ID number is specified asa parameter. However, using ID numbers to reference frequently accessedobjects lowers the performance, because translation from an ID number to themanagement table address for each access takes time. When an object iscreated, a key value for later accesses is returned by the operating system asthe return parameter.

Key values used for this purpose are called access keys in the ITRONspecification.

The base addresses of object management tables are usually used as accesskeys, so access keys are also called access addresses. In the ITRONspecification, the terms access key and access address are synonymous.However, if ID numbers are used as access keys, or if object management blocksegment values are used, hash values that vary depending on the operatingsystem data structure are used,so access keys do not always indicate objectmanagement table addresses.

In the uITRON specification, objects are not created dynamically. They areall created statically when the system is activated. Access keys are not

needed to identify objects. ID numbers are used instead. The same is true inthe ITRON2 specification, so applications written under differentimplementations of the operating system will be compatible. Only the ITRON1specification uses access keys.

--------------------------------------------------------------------------1.3.1.8 Standardization policies and compatibility in ITRON specification--------------------------------------------------------------------------

The ITRON specification OS is a standard operating system to be implemented onmany processors. To prevent performance degradation caused by standardizationor virtualization, or to make full use of processor-specific architectures,some variations in specifications are permitted. In the ITRON specification,the execution environment depends heavily on the target system hardware, sotightly controlling the conformance to specifications for the operating systemmakes it difficult to attain object-level compatibility. Instead, the ITRONspecification uses loose specifications for the operating system to improvethe performance of each implementation. For this reason, the ITRON1 anduITRON specifications do not guarantee complete compatibility for differenttarget processors or different implementations. There are manyimplementation-dependent items in the specifications. Implementationdependency in the ITRON specification increases in the order ITRON2, ITRON1,and uITRON specifications. For the same reason, compatibility is not completebetween the ITRON1 and ITRON2 specifications, or between the ITRON1 and uITRONspecifications.

The ITRON1 and ITRON2 specifications are each divided into three classes:processor-independent parts, processor-dependent parts, and

8/16/2019 mitron-1

21/43

implementation-dependent parts. This section explains the standardized itemsof the ITRON specification.

ITRON specifications common to all processors are as follows:

  System call functions and names  Parameter types and names

  Error code types, names, and values  Function code numbers (numbers that identify system calls)

However, since it is not necessary to adhere strictly to all specificationsfor these items, specifications may be changed depending on theimplementation. Between ITRON1 and ITRON2 specifications, some function maybe added or differently specified even in processor-independentspecifications.

By contrast, parameter passing, bit length, or system call activation dependstrongly on the processor architecture. Making these specifications the samefor ITRON1 and ITRON2 specifications may impair the performance. Because no

object-level compatibility is provided between different processors, there islittle benefit in making parameter passing, etc. the same.

However, these specifications can be standardized for a specific processor.The ITRON specification provides a set of standard specifications for popularprocessors such as the Intel iAPX86, Motorola MC68000, and NationalSemiconductor NS32000, proposing a desirable implementation for eachprocessor.

The ITRON specification basically stipulates only external specifications anddoes not restrict the implementation method. In the details of system callexecution, however, the implementation method affects some externalspecifications. These are called implementation-dependent specifications.

Although they are external specifications, parts of theimplementation-dependent specifications can be determined by the implementorto maximize the ITRON specification OS performance. Implementation-dependentspecifications include the error detection levels.

In the uITRON specification, operating system specifications vary greatlyaccording to differences in processors. All uITRON specifications aretherefore guidelines. There are three types of specifications although theyare not strictly distinguished: processor-independent specifications,processor-dependent specifications, and implementation-dependentspecifications. The processor-independent specifications need not be strictlyfollowed; specifications can all be processor-dependent andimplementation-dependent.

Although the ITRON specifications do not guarantee complete compatibility, theimportance of standardization for realtime operating systems lies in thefollowing:

- To make training courses common for all variations of the ITRON  specification by making system call names and terminology consistent- To maintain portability by clarifying differences from the standard  specifications

----------------------------1.3.2 System call interfaces

----------------------------

------------------------------------------

8/16/2019 mitron-1

22/43

1.3.2.1 Interfaces with assembly language------------------------------------------

In the ITRON specification, the method of issuing system calls in assemblyprogramming, that is, the method of interfacing with the assembly language,depends on the processor. However, in the ITRON1 and ITRON2 specifications,there are several conventions which apply to all processors, as listed below.

- System call parameters and return parameters are usually placed in four to  eight registers.

- Function codes that indicate system call type are usually placed in  registers used as accumulators.

- If many parameters are used or if the data is long, packets are created in  memory. The start address of the packet is placed in the register used as  an address register or an index register.

- Registers that are not used for return parameters should all remain

  unchanged.

All processor-specific operating systems implemented on the iAPX86 (iAPX286),MC68000, NS32000, and TRON-architecture microprocessor use these conventions.

The same conventions can be used for the uITRON specification. Becauseperformance is given priority, these conventions are allimplementation-dependent.

-----------------------------------1.3.2.2 Interfaces with C language-----------------------------------

In the ITRON specification, the virtualization concept is not used, so objectcodes are not compatible between different processors. To ensure theportability of ITRON specification OS application programs, they must bewritten in a high-level language. The ITRON specification uses the C languageas the standard high-level language, and provides the standard interface withC language for executing ITRON specification system calls. The followinggeneral rules apply to the interface between the ITRON specification and theC language:

- All system calls are defined as C functions, and system call error  conditions are the return values for those functions. Return parameters  other than error codes are normally passed using pointers.

- The pointer to the return parameters is placed first, and other parameters  follow the pointer. In the ITRON1 specification, a command option may be  placed as the first parameter.

In the ITRON specification, the C language system call interface is basicallyprocessor-independent. However, specifications vary depending on theprocessor for interrupt and exception processing system call functions and foraddressing using iAPX86 (iAPX286) processor segments. This is not really aproblem of the ITRON specification; it is more a problem of processorarchitectures. There are some differences in the C language system callinterfaces even between the ITRON1 and ITRON2 specifications.

************************************* 1.4 ** uITRON and ITRON2 Specifications *

8/16/2019 mitron-1

23/43

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

This section explains the uITRON and ITRON2 specifications.

---------------------------------------1.4.1 Overview of uITRON specification---------------------------------------

Standard operating systems have seldom been used in single-chip computers usedin electrical appliances and automobiles. This is because of the limited ROMand RAM capacity. Instead, operating system functions have been included inthe application program. The uITRON specification OS is a standard operatingsystem for these applications. Its adaptability minimizes memory overhead anddegraded performance.

-------------------------------------------------1.4.1.1 Basic philosophy of uITRON specification-------------------------------------------------

Semiconductor manufacturers have recently introduced 8-bit and 16-bitprocessors using their own architectures. Those processors are to beincorporated in single-chip computers or application-specific integratedcircuits (ASICs). Since these processors are often used in realtime andembedded-system applications, there are many demands to implement the ITRONspecification as the standard operating system.

The ITRON1 specification was designed for general-purpose 16-bit processors.There are too many functions to be implemented on single-chip computers or8-bit processors, and these processors often do not have enough ROM or RAM.In the ITRON specification, functions can be deleted. This does not mean thatany function can arbitrarily be deleted by the user, but means that functionsubsets and tuning for individual applications are provided. Because

compatibility is lost if there are functions not supported by the operatingsystem, the minimum functions required for implementation have been determinedfor the ITRON specification.

To form a function subset for an application, the user may want to deleteparts of functions. For example, because the ITRON specification semaphore isa counting type, the wait semaphore (wai_sem) system call permits the resourcecount to be specified, using the cnt parameter. To delete only the variableresource count, the resource count is fixed to 1, thus eliminating the cntparameter. In the same way, if the time-out function in the wait semaphore isdeleted, the tmout parameter, which specifies time-out, is not needed.Deleting parameters saves ROM and RAM space. This is an important factor forsingle-chip computers.

However, the presence or absence of parameters affects the system callinterfaces. Parameters cannot be deleted arbitrarily by the user whencompatibility with a high-level language is necessary. The ITRONspecification provides tuning for applications; however unlimited tuning isnot permitted so that compatibility with high-level languages is maintained.

The uITRON specification is an architecture provided to overcome the tuninglimits set on the ITRON specification adaptability. In other words, the ITRONspecification places emphasis on standardization rather than tuning, while theuITRON specification place emphasis on tuning rather than standardization.This means that even 8-bit processors in single-chip microcomputers, where RAM

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

Specifically, several items in the standardized ITRON specification were moved

8/16/2019 mitron-1

24/43

in recommended specifications and implementation-dependent specifications.They include system call interfaces and parameters. As a result, much morefreedom is given to implementation. Function subsets at the operating systemlevel are provided; these allow the implementor to select the necessaryfunctions.

There is a trade-off between standardization and freedom in tuning. The

uITRON specification is given more freedom in tuning at the operating systemlevel and less standardization. Complete compatibility cannot be guaranteedbecause several functions are not implemented in the operating system andthere are differences between detailed specifications of the system callinterfaces.

The many differences between processors that use the uITRON specificationcause more compatibility problems than the differences between uITRONspecifications. Because different processors have different word length,address space size, and addressing methods, compatibility for high-levellanguages cannot be guaranteed even if the user program does not use anyoperating system calls. Compatibility at the high-level language level

between uITRON specifications has less effect on program portability than dovariations of hardware and I/O devices connected to microcontrollers. Thismeans that all programs must be reviewed and corrected for program migration.

The advantages of standardization by the use of the uITRON specificationinclude ease of training and consistent system call names and functions.Reduced programmer training costs and increased program productivity arestrong motives for standardization. As stated above, programs often need tobe rewritten in applications of the uITRON specification, which means thatreduction of the training costs is more important than program portability.Converting a uITRON specification OS application program to another processoris easy because the one-to-one correspondence of the name and function of eachsystem call is maintained between the source and target system of the

conversion. Understanding either the ITRON specification or uITRONspecification makes it easier to understand the other.

The uITRON specification is used as a guideline for designing operatingsystems and naming system calls. The uITRON specification provides a separatespecification for each processor or application, following a single guideline.It can be considered as a set of operating systems covering manyspecifications for different operating systems. Conforming to the uITRONspecification signifies that the system call names determined by the uITRONspecification are used.

------------------------------------1.4.1.2 uITRON specification design------------------------------------

The uITRON specification is basically a subset of the functions determined bythe ITRON specification, and many implementation-dependent specifications arepermitted. The uITRON specification system call names and interfaces are notalways the same as those of ITRON specifications. Changes were made becauseadopting a subset of the ITRON specifications creates unbalanced functions orwasteful parameters for unsupported functions. The fundamental designphilosophy is to simplify specifications in order to gain high performance.

---------------------------------------------1.4.1.3 uITRON specification OS requirements

---------------------------------------------

Too many variations of uITRON specification applications make it difficult to

8/16/2019 mitron-1

25/43

stipulate necessary functions and system calls. For this reason, the mainobjective of this specification is to set up guidelines for determining thecorrespondence between system call names and functions. The uITRONspecification has two necessary functions:

1 There are three task states: run, ready, and wait (multitasking operating  system).

  Depending on the implementation, the dormant and suspend states may also be  used.

2 An implementation-specific interrupt handler can be defined.  Tasks may wake up when the interrupt handler issues a system call (realtime  operating system).  The interrupt handler may be defined statically (at system generation or  initialization) or by the def_int system call.

For example, a uITRON specification operating system may have only two systemcalls: the sleep task (slp_tsk) system call that places a task in the waitstate, and the wakeup task (wup_tsk) or return and wakeup task (ret_wup)

system call, issued by the interrupt handler, that wakes up a task in the waitstate.

A uITRON specification operating system does not guarantee that specificfunctions are available to users. Conformity to the uITRON specificationsimply assures the correspondence between system call names and functions.In other words, it is easy to find out which system call should be used toobtain a certain function or what a system call is doing in a program. This"training compatibility" is extremely important in programming for embeddedsystems.

---------------------------------------1.4.2 Overview of ITRON2 specification

---------------------------------------

The ITRON2 specification is a higher level version of the ITRON1specification, assuming that the ITRON specification is implemented on a32-bit processor.

-------------------------------------------------1.4.2.1 Basic philosophy of ITRON2 specification-------------------------------------------------

The major purpose of the ITRON2 specification is improvement of thecompatibility between ITRON specification operating systems and theportability of application programs. The following points have been added tothe conventional ITRON specification philosophy during the design stage.

- Higher standardization level  Responding to improved performance of processors, compatibility levels are  raised by widening the scope of standardization. For example, standard  specifications are available for the exception management functions, which  have been processor-dependent. However, virtualization is not adopted in  the ITRON2 specification, and the best performance policy still continues to  be as in the ITRON1 specification.

- Integration as the TRON specification family  Consistency of names and terminology is stipulated among BTRON, CTRON, and

  ITRON specifications.

- System call classes

8/16/2019 mitron-1

26/43

  The ITRON2 specification has quite a few more functions than the ITRON1  specification. For ease of user understanding and migration from the ITRON1  specification, the system calls have been divided into three classes: basic  functions (I1), extended functions (I2), and system operation functions.  The class I1 functions are almost the same as those in the ITRON1  specification.

------------------------------------1.4.2.2 ITRON2 specification design------------------------------------

This section explains the concepts of the ITRON2 specification design and thedifferences between ITRON1 and ITRON2 specifications.

- System call splitting and naming

  Each generic function given to a system call in the ITRON1 specification is  now split into several primitive system calls in the ITRON2 specification.  This improves compatibility with the uITRON specification, reduces system

  call options, adds functions, and provides flexibility in selection of  system calls.

  For the names of split system calls, it is desirable to retain the original  names. However, it is difficult to assign a name as in the conventional  format of xxx_yyy.

  Therefore, eight-character system call names, zxxx_yyy, are added to the  conventional format (xxx_yyy). The xxx and yyy parts represent the  operation and object, as in the conventional form, and the prefix z  indicates that the name is a derivative.

- Object access method

  Unlike for ITRON1, the ITRON2 specification does not allow object accesses  to use access keys obtained dynamically during object creation; values (ID  number, for example) established before execution should be used. This  makes it easier to write programs and improves compatibility.

- Exception management

  Specifications such as exception classification, nested activation of  exception handlers, and exception management in extended SVC handlers have  been clarified, and standardization has been improved for exception  processing programs.

  Exception handlers in another task can be activated by software. This  function is named "forced exception" and is classified as a class I2  function in the ITRON2 specification. The exit processing routine in the  ITRON1 specification is treated as an exception handler (exit handler) in  the ITRON2 specification.

******************************************************************************* Chapter 2 ** uITRON specification *******************************************************************************

This chapter explains the concept of the uITRON specification design, the

relationship between ITRON1 specification and uITRON specification, and thesyntax of the system call specifications in later chapters.

8/16/2019 mitron-1

27/43

******************* 2.1 ** Design Concept *******************

Semiconductor manufacturers have recently introduced 8-bit and 16-bitprocessors using their own architectures. Those processors are to be

incorporated in single-chip computers or application-specific integratedcircuits (ASICs). Since these processors are often used in realtime andembedded-system applications, there are many demands to implement the ITRONspecification as the standard operating system.

The ITRON1 specification was designed for general-purpose 16-bit processors.There are too many functions to be implemented on single-chip computers or8-bit processors, and these processors often do not have enough ROM or RAM.In the ITRON specification, functions can be deleted. This does not mean thatany function can arbitrarily be deleted by the user, but means that functionsubsets and tuning for individual applications are provided. Becausecompatibility is lost if there are functions not supported by the operating

system, the minimum functions required for implementation have beendetermined for the ITRON specification. Figure 2.1 shows the tuning conceptin the ITRON specification.

To form a function subset for an application, the user may want to deleteparts of functions. For example, because the ITRON specification semaphore isa counting type, the wait semaphore (wai_sem) system call permits the resourcecount to be specified, using the cnt parameter. To delete only the variableresource count, the resource count is fixed to 1, thus eliminating the cntparameter. In the same way, if the time-out function in the wait semaphore isdeleted, the tmout parameter, which specifies time-out, is not needed.Deleting parameters saves ROM and RAM space. This is an important factor forsingle-chip computers.

However, the presence or absence of parameters affects the system callinterfaces. Parameters cannot be deleted arbitrarily by the user whencompatibility with a high-level language is necessary (See Figure 2.2).The ITRON specification provides tuning for applications; however unlimitedtuning is not permitted so that compatibility with high-level languages ismaintained.

 Function in the ITRON specification+------------+-------+-------+-------+--------+-------+| Task | Event | Sema- | Mail- | Memory | Other || management | flag | phore | box | pool | |+-----------------------------------------------------+  |  | Affected by processor architecture  |  v Function implemented on the OS for the iAPX86+------------+-------+-------+-------+--------+-------+ - - - - - - - - - -+| Task | Event | Sema- | Mail- | Memory | Other | Processor- || management | flag | phore | box | pool | | dependent functions|+-----------------------------------------------------+ - - - - - - - - - -+

 Function implemented on the OS for the MC68000+------------+-------+-------+-------+--------+-------+ + - - - - - - - - - +

| Task | Event | Sema- | Mail- | Memory | Other | |Processor- || management | flag | phore | box | pool | |-|dependent functions|+-----------------------------------------------------+ + - - - - - - - - - +

8/16/2019 mitron-1

28/43

 Function implemented on the OS for the NS32000+------------+-------+-------+-------+--------+-------+ + - - - - - - - - - +| Task | Event | Sema- | Mail- | Memory | Other | |Processor- || management | flag | phore | box | pool | |--|dependent functions|+-----------------------------------------------------+ + - - - - - - - - - +  |

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

 ITRON specification adapted for application B+ - - - - - -+ - - - + + - - - -+ + - - - - - - - - - +| Task | Event | | Memory | |Processor- |

| management | flag |---------------| pool |---------|dependent functions|+- - - - - - - - - - + +- - - - + + - - - - - - - - - +

 ITRON specification adapted for application C+ - - - - - -+ + - - - + - - - + + - - - - - - - - - +| Task | | Sema- | Mail- | |Processor- || management |-------| phore | box |-------------------|dependent functions|+- - - - - - + + - - - - - - - + + - - - - - - - - - +

  Figure 2.1 Tuning in ITRON specification

+-------------------------------------------+| wai_sem interface in ITRON1 specification |

+-------------------------------------------+

  ercd = wai_sem (option, a_sem, cnt, tmout);  option: Specification of time-out detection/no time-out detection  a_sem: Semaphore access key (semaphore ID number)  cnt: Resource acquisition count  tmout: Time-out  ercd: Error code

+----------------------------------------------------------------------------+|wai_sem interface when resource acquisition count and time-out specification||are not required |+----------------------------------------------------------------------------+

  ercd = wai_sem (a_sem);  a_sem: Semaphore access key (semaphore ID number)  ercd: Error code

 * When compatibility in a high-level language is required, parameters  cannot be deleted even if they are not needed.

  Figure 2.2 Example of wait semaphore (wai_sem) system call interface

The uITRON specification is an architecture provided to overcome the tuninglimits set on the ITRON specification adaptability. In other words, the ITRON

specification places emphasis on standardization rather than tuning, while theuITRON specification place emphasis on tuning rather than standardization.This means that even 8-bit processors in single-chip microcomputers, where RAM

8/16/2019 mitron-1

29/43

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

Specifically, several items in the standardized ITRON specification were movedin recommended specifications and implementation-dependent specifications.They include system call interfaces and parameters. As a result, much morefreedom is given to implementation. Function subsets at the operating systemlevel are provided; these allow the implementor to select the necessary

functions. Figure2.3 shows the tuning concept in the uITRON specification.

 Function in the uITRON specifications+------------+-------+-------+-------+--------+-------+ - - - - - - - - - +| | | | | | | Added functions || Task | Event | Sema- | Mail- | Memory | Other | or functions || management | flag | phore | box | pool | | dependent on || | | | | | | processor || | | | | | | architecture |+-----------------------------------------------------+ - - - - - - - - - +  |  | Affected by processor architecture

  |  | Affected by applications  |  | Implementor's choice  |  v Functions implemented in uITRON specification specification OS of processor A+ - - - - - -+ + - - - + + - - - -+ + - - - - - - - - - +| Task | | Sema- | | Memory | |Processor- || management |-------| phore |-------| pool |-------|dependent functions|+- - - - - - + + - - - + +- - - - + + - - - - - - - - - +

 Functions implemented in uITRON specification specification OS of processor B

+ - - - - - -+ - - - + + - - - -+ + - - - - - - - - - +| Task | Event | | Memory | |Processor- || management | flag |---------------| pool |--------|dependent functions|+- - - - - - + - - - + +- - - - + + - - - - - - - - - +

 Functions implemented in uITRON specification specification OS of processor C+ - - - - - -+ + - - - + - - - + + - - - - - - - - - +| Task | | Sema- | Mail- | |Processor- || management |-------| phore | box |------------------|dependent functions|+- - - - - - + + - - - + - - - + + - - - - - - - - - +

  Figure 2.3 Tuning concept in uITRON specification

There is a trade-off between standardization and freedom in tuning.The uITRON specification is given more freedom in tuning at the operatingsystem level and less standardization. Complete compatibility cannot beguaranteed because several functions are not implemented in the operatingsystem and there are differences between detailed specifications of the systemcall interfaces.

The many differences between processors that use the uITRON specificationcause more compatibility problems than the differences between uITRONspecifications. Because different processors have different word length,address space size, and addressing methods, compatibility for high-levellanguages cannot be guaranteed even if the user program does not use any

operating system calls. Compatibility at the high-level language levelbetween uITRON specifications has less effect on program portability than dovariations of hardware and I/O devices connected to microcontrollers.

8/16/2019 mitron-1

30/43

This means that all programs must be reviewed and corrected for programmigration.

The advantages of standardization by the use of the uITRON specificationinclude ease of training and consistent system call names and functions.Reduced programmer training costs and increased program productivity arestrong motives for standardization. As stated above, programs often need to

be rewritten in applications of the uITRON specification, which means thatreduction of the training costs is more important than program portability.Converting a uITRON specification OS application program to another processoris easy because the one-to-one correspondence of the name and function of eachsystem call is maintained between the source and target system of theconversion. Understanding either the ITRON specification or uITRONspecification makes it easier to understand the other.

The uITRON specification is used as a guideline for designing operatingsystems and naming system calls. The uITRON specification provides a separatespecification for each processor or application, following a single guideline.It can be considered as a set of operating systems covering many

specifications for different operating systems. Conforming to the uITRONspecification signifies that the system call names determined by the uITRONspecification are used.

The following sections give details of the uITRON specification design, andexplain the implications of standardization in the uITRON specification.

********************************* 2.2 ** uITRON Specification Design *********************************

The uITRON specification is basically a subset of the functions determined by

the ITRON specification, and many implementation-dependent specifications arepermitted. The uITRON specification system call names and interfaces are notalways the same as those of ITRON specifications. Changes were made becauseadopting a subset of the ITRON specifications creates unbalanced functions orwasteful parameters for unsupported functions. The fundamental designphilosophy is to simplify specifications in order to gain high performance.

The following sections explain the concept of uITRON specification design anddifferences between the ITRON and uITRON specifications.

-----------------2.2.1 Task states-----------------

Like the ITRON specification, the uITRON specification is for a realtimeoperating system that performs preemptive scheduling. As in the ITRONspecification, a task having a smaller priority number takes priority over onehaving a greater number.

Unlike the ITRON specification, however, the uITRON specification does notsupport dynamic creation of objects, such as tasks and semaphores. Ittherefore has no task state corresponding to the nonexistent state in theITRON specification. The uITRON specification has five states as follows:

(1) Run state

In the run state, a task is being executed.

8/16/2019 mitron-1

31/43

(2) Ready state

In the ready state, a task is ready for execution but cannot be executedbecause a higher priority (or same-priority) task is being executed.

(3) Wait state

In the wait state, the task cannot be executed because an execution conditionhas not been satisfied. The difference between the wait state and the suspendstate (explained in item (4)) is whether execution is stopped by a system callissued by the caller task or another task.

(4) Suspend state

In the suspend state, execution of the task is forcibly suspended by a systemcall issued by another task. Sometimes this state may be nested in the waitstate explained in item (3). This nested state is called the wait-suspendstate.

(5) Dormant state

In the dormant state, the task has not yet been started or has alreadyterminated. In this state, unlike the wait state, all the resources arereleased, and the context, such as the registers or program counter, isinitialized at start.

The suspend state and dormant state are not always implemented in the uITRONspecification OS. Figure 2.4 shows the uITRON specification task statetransitions, which are a subset of the ITRON specification.

+---------+ ------------------ Dispatch ---------------> +-------+ ---| READY | | | ---------------+ | |  | | Resume +----------+ (ter_tsk) | | |  | | (rsm_tsk,frsm_tsk) | ^ | | |  | | | | | | |  | | +------+ | | |

  | | | | |  | | Start (sta_tsk) +----------+ | | |  | +---------------------- | DORMANT |

8/16/2019 mitron-1

32/43

  +-----------------------> | |

8/16/2019 mitron-1

33/43

  This is not a major problem in the ITRON specification, but, in the uITRON  specification where RAM space should ideally be reduced, it makes  implementing the queuing function difficult. In the uITRON specification,  the multiple-queuing function for the wup_tsk and sus_tsk system calls is  implementation-dependent, so implementations having single queueing are  permitted.

- Time-out

  The ITRON specification permits specifying time-out for system calls which  enter the wait state, but the uITRON specification does not as implementing  the time-out processing may increase the implementation workload.

- Event flags

  The ITRON specification treats 16 to 32 event flag bits as a word to permit  an OR or AND operation on the specified bits. Use of these functions,  however, requires many parameters to issue system calls for event flag  operations, thus causing performance degradation and memory shortage.

  The uITRON specification permits single-bit event flag operations as an  alternative implementation. The single-bit operations form a subset of the  event flag word operations. Figure 2.5 shows the parameters and return  parameters used for single-bit and word operations.

+-----------------------+| Single-bit event flag |+-----------------------+

 System call Parameter Return parameter ----------- ------------------------- ----------------  wai_flg flgid - - - Clear not specified  cwai_flg flgid - - - Clear specified

+-----------------+| Word event flag |+-----------------+

 System call Parameter Return parameter ----------- --------------------------- ----------------  wai_flg flgid waiptn wfmode flgptn

  flgid: Event flag ID number  waiptn: Wait bit pattern  wfmode: AND/OR selection and whether to clear when released from WAIT  flgptn: Event flag bit pattern when released from WAIT

  * Many parameters are necessary to use event flag words.

  Figure 2.5 System call parameters for event flag operations

- Semaphore count

  The ITRON specification semaphore is of a counting type, and there are two  system calls: the wait semaphore (wai_sem) system call is for the P  operation and the signal semaphore (sig_sem) system call is for the V  operation. The count for acquired and returned resources can be specified.  In the uITRON specification, the resource acquisition count and return count

  are fixed to 1 to reduce system call parameters.

- Variable-length memory block

8/16/2019 mitron-1

34/43

  The ITRON specification supports both variable-length and fixed-length  memory block management functions. Generally, however, variable-length  memory block management places a burden on implementation, and realtime  response is easily lost. For this reason, the uITRON specification does not  support variable-length memory block management functions; it supports only  fixed-length memory block management functions.

- Exception handling

  The ITRON specification has two types of exceptions: system call and CPU  exceptions. A system call e