This document provides a glossary of the technical terms related to this seminar. The glossary includes technical terms used in general embedded systems and TRON-related (ITRON specification OS or T-Engine) technical terms. Among the technical terms listed in the glossary, terms specific to particular specifications are indicated by the following symbols.
(I) ITRON specifications in general
(I3) μITRON3.0 specification
(I4) μITRON4.0 specification
(T) T-Kernel specification
| Technical terms | Explanation | Note |
|---|---|---|
| AMP: Asymmetric Multi Processor | Asymmetric multiple processor is a multiprocessor that combine multiple MPUs of different types or with different functions. AMP is called functionally distributed multiprocessor or heterogeneous multiprocessor. | |
| API: Application Program Interface | An interface (set of functions) used when using the functions of the kernel or software components in an application program. | |
| Basic profile (I4) | A profile that groups service calls with equivalent functions in μITRON3.0, μITRON4.0, and T-Kernel. The basic profile was adopted in µITRON4.03. Using the basic profile makes it easier to port application programs among μITRON3.0, μITRON4.0, and T-Kernel. | μITRON4.0 Specification |
| Build | This is the process of compiling source code and linking libraries to create an executable file that will be executed. | |
| Chattering | A phenomenon that occurs when an input signal is repeatedly turned on and off due to the noise caused by the physical bouncing of the contacts of a switch. Various measures are implemented in application programs to prevent electronic circuit malfunctions caused by chattering. | |
| Configuration | A definition of the initial state of objects used by the TRON RTOS, the maximum number of resources, etc. The file for the definition is called system configuration file. | μITRON4.0 Specification |
| Configurator (I4) | In μITRON, configurator interprets the initial state of objects and the maximum number of resources in the system configuration file, converts them to a data format that kernel can handle directly, and embeds them in the system. | μITRON4.0 Specification |
| Context | The environment in which a program is executed is called context. In RTOS, there is a distinction between task context and non-task context. Non-task contexts are a general term for contexts that are not included in task contexts, and include interrupt handlers and CPU exception handlers. | |
| CPU: Central Processing Unit | A major hardware component that makes up computers and embedded systems. It interprets and executes machine language instructions read from memory, and performs control of, and processing of data for each device. In recent years, CPUs are usually implemented as a single LSI or as a CPU core, a part of an LSI. Since CPU is called a microprocessor when it is implemented in an LSI, CPU is also called Micro Processing Unit (MPU). In addition, by packing memory and the control functions for peripheral devices into the same LSI together with the CPU, the entire computer system for embedded control can be realized with one chip or a small number of chips. This type of single-chip computer for control is sometimes called Micro Controller Unit (MCU). | |
| CPU Lock: CPU Lock (I) | Embedded systems are either in a CPU locked state or a CPU unlocked state. In CPU locked state, all interrupts except for interrupts outside the control of the kernel are prohibited, and no dispatching occurs. Also, since interrupts are prohibited, the activation of time event handlers is also prohibited. | ITRON specifications in general |
| Cygwin | An emulator program that allows programs developed for UNIX, such as gcc compiler, to run on Windows PCs. Cygwin programs can be obtained free of charge from the Cygwin Project website. | |
| Deadlock | This refers to a situation where multiple tasks are waiting for others to release the resources they are occupying, and so as a whole, none of the tasks cannot be executed. | |
| Device driver | A generic term for software that performs device-related processing. In the T-Kernel specification, the interface specification for device drivers is also standardized. | |
| DIC: Device Interface Component (I4) | A software module that handles device drivers built in accordance with the μITRON Device Driver Design Guideline. | μITRON4.0 Specification |
| Dispatch | The switching of tasks executed by the processor is called dispatching. It is also called task dispatching. The mechanism within the kernel that achieves dispatching is called dispatcher or task dispatcher. | |
| Dynamic APIs (I4) | These are APIs that manipulate object inside a normal program. In the µITRON4.0 Specification, static APIs are written in uppercase, and dynamic APIs are written in lowercase. | μITRON4.0 Specification |
| Embedded system | A system that incorporates a computer or microprocessor for device control is called an embedded system. Embedded systems include mobile phones, car navigation systems, TVs, washing machines, etc. These devices have microprocessors and incorporate software for control. | |
| Emulator | The original meaning of “emulator” is a program that imitates another processor or execution environment using hardware. However, in the development of embedded systems, it often refers to various tools for debugging at hardware level. A typical example is an in-circuit emulator (ICE) that has the function of referencing and changing the status of CPU and memory of an embedded device (target) under development via JTAG, etc. In addition, development tools such as simulators that simulate the CPU functions of a target on a PC are referred to as “emulators” today. | |
| Event | The term “event” refers to any event that triggers a change in the state of a system, process, task, etc., such as the completion of input/output, connection of a new device, or input from a key or mouse. Event is first notified to the RTOS, device driver, and user application as a change in the hardware input signal or an interrupt. The operation triggered by each event differs depending on the type and meaning of the event. RTOSs such as ITRON specification OS and T-Kernel have various functions to efficiently process events. | |
| Event-driven system | An event-driven system operates by changing its state each time it receives an event. This concept is essential for real-time processing. | |
| Exclusion control | The mechanism that prevents conflicts due to simultaneous accesses from multiple tasks or processes to the same data or to the same region of program code is called exclusion control. | |
| Extended SVC (I,T) | System calls added by user applications or middleware. | ITRON specifications in general, T-Kernel specification |
| FCFS: First Come First Served | An ordering method to process the data in the order from the first data received when processing data. In embedded systems, when there are multiple tasks with the same priority, the scheduling method, which executes tasks in the order in which they become executable, is FCFS. | |
| FIFO: First In First Out | A method of storing data such as messages in which the first data entered is picked up for processing first. A data structure that is processed using FIFO is called a queue. It is the reverse of LIFO. | |
| GCC: GNU Compiler Collection | A free compiler package that runs on GNU software systems. It is compatible with many embedded CPUs and is used in T-Engine development kits, etc. | |
| GDIC: General DIC (I4) | In a computer system architecture, DIC architecture, built in accordance with the µITRON Device Driver Design Guideline, it is one of the software modules that handles devices and performs general-purpose processing. | μITRON4.0 Specification |
| GNU: GNU is Not UNIX | The name for the development project for the group of UNIX-compatible software being developed by Free Software Foundation (FSF). In addition, the FSF's free software UNIX-compatible system development environment is also called GNU. | |
| GUI: Graphical User Interface | A method of giving instructions to a computer by operating icons, buttons, etc. displayed on a graphic screen using a mouse, touch screen, etc. when operating a computer or an embedded device. | |
| Handler (I,T) | A program that is invoked after interrupting the ordinary processing of a system or task is generically called handler. It includes interrupt handler, exception handler, time event handler, etc. | ITRON specifications in general, T-Kernel specification |
| ICE: In-Circuit Emulator | See 'Emulator' in the glossary. | |
| ID number: Identification Number (I,T) | A number used to distinguish objects inside an RTOS, such as tasks and semaphores. In general, in a service call that manipulates such an object, one of the parameters is an ID number. | ITRON specifications in general, T-Kernel specification |
| Idle state | In a computer system, idle state is a state in which the system is not executing any operations, but is in a standby state that allows it to become ready (READY) to execute operations immediately. | |
Implementation-defined (I4, T) | In ITRON specification and T-Kernel specification, this means that something is not standardized in the specifications, and should be specified for each implementation instead. Product manuals, etc., must describe the detailed specifications of the implementation defined part of the particular implementation. Portability cannot be ensured for parts of an application program that depend on implementation-defined items. | μITRON4.0 Specification and T-Kernel specification |
| Implementation-dependent (I4,T) | In the ITRON specification and T-Kernel specification, this means that the behavior of something may change depending on the implementation or system operating conditions. If an application depends on implementation-dependent matters, its behavior is not guaranteed by the specification. Since there is a possibility that the implementation-dependent parts will not be compatible among different implementations of the OS, extra care is needed when a program is ported. | μITRON4.0 Specification and T-Kernel specification |
| Implementation-specific (I4) | In ITRON specification, an implementation-specific function means that the function is outside the scope defined by ITRON specification, and it is originally defined and specified in a particular implementation. | μITRON4.0 Specification |
| interrupt handler (I, T) | A handler that is activated when an external interrupt occurs. The execution of the task that was being executed at the time is interrupted by the activation of the interrupt handler. However, the activation of the interrupt handler is performed directly by the CPU hardware and does not go through the OS. Interrupt handlers are executed with a higher precedence than any task. | ITRON specifications in general, T-Kernel specification |
| IRC: Interrupt Request Controller | Hardware circuit for controlling interrupts. Interrupt is a function that allows the CPU to suspend the program that it is executing, to call another program when a hardware signal is received from a peripheral device, timer, etc. In the µITRON4.0 specification, there are interrupt handlers and interrupt service routines as processes that are started by external interrupts. | |
| ITRON: Industrial TRON (I) | One of the sub-projects of TRON Project. ITRON specification and µITRON specification, which are the standard specifications for real-time operating systems for embedded systems, have been drafted and released. µITRON specification has become the de facto standard for RTOSs in the Japanese embedded systems industry. | ITRON specifications in general |
| Kernel | Kernel means “nucleus,” a central part of something. In computer terminology, it refers to something that functions as the core of a system. Kernel in an RTOS means the part that implements the basic functions of the OS, such as memory management and task management. | |
| LIFO: Last In First Out | A method to process a group of data by picking up the last data received first. A data structure that is processed using LIFO is called a stack. It is the reverse of FIFO. | |
| Linked list | A data structure that connects multiple areas that hold data using pointers (links). There are singly linked lists, where the pointers are connected in only one direction, and doubly linked lists, where the pointers are connected in both directions. | |
| loose standardization (I) | The standardization policy adopted when the ITRON specification was created in an era when hardware such as CPUs was underpowered and restrictions were great is called loose standardization. The feature is that the specification is not very restrictive. The reason behind the adoption of a loose standardization policy for the ITRON specification was that, when the ITRON1 specification was developed in 1984, there were severe restrictions on microprocessor's performance, memory capacity, and the availability of high-performance compilers that could be used easily. For this reason, it was impossible to completely unify the implementation method of RTOSs and all APIs. Therefore, although the main API specifications of RTOS were standardized, the method of implementation, including the manner of passing the arguments to the API (packet method, register method, etc.), and the specifications for interrupts and exceptions, etc. were left to the discretion of each manufacturer. This is called loose standardization. The advantage was that even with the weak CPUs of the time, it was possible to create a processing system that adhered to the "loose standardization." On the other hand, the fact that it was not possible to distribute middleware as binaries due to the low compatibility between different implementations was a disadvantage. See also “strict standardization.” | ITRON specifications in general |
| make | When developing programs on UNIX OSs, you typically enter the command 'make' and compile and link the program according to the description in a text file called 'makefile.' When recompiling, the make command compiles only the updated files based on the dependencies between the files described in the makefile, so it can shorten the time taken for compilation. It is often used when converting source code into binary code, so the term, ‘make’ is used almost interchangeably with ‘build.’ | |
| message | Information communicated between tasks. | |
| Middleware | A generic term for programs that are located in the layer between OS and application, and provide common and general-purpose functions for applications. Examples of typical middleware include TCP/IP network stack, file management, and image compression/decompression programs. | |
| Multitask | It is an OS function that executes multiple tasks simultaneously in parallel. Multitasking is achieved by allocating the processing time of CPU to multiple tasks in a time-sharing manner. | |
| Object (I,T) | “objects” in TRON RTOSs is a generic term for tasks, event flags, semaphores, mailboxes, memory pools, message buffers, etc., which are the operation targets of service calls. | ITRON specifications in general, T-Kernel specification |
| Open source | Software whose source code is publicly available. Furthermore, there is free software whose source code is available free of charge. Anyone can improve the software, etc. However, there are variations in the details of the conditions imposed on redistribution, etc. T-Kernel specification OS is software that is open-sourced and released by TRON Forum, but in order to use or distribute it, you must follow the T-License agreement. | |
| OS: Operating System | OS is an abbreviation of operating system. In embedded systems, a real-time operating system (RTOS) is often used to perform real-time control. | |
| Overrun handler (I4) | This is a time event handler that is activated when a processor is used for longer than the specified time. | μITRON4.0 Specification |
| PDIC: Primitive DIC (I4) | In a computer system architecture, DIC architecture, built in accordance with the µITRON Device Driver Design Guideline, it is one of the software modules that handles devices. This module performs device-specific processing. PDIC accepts requests from applications and software components and performs synchronous processing and performs processing that depends on the OS. | μITRON4.0 Specification |
| Polling | In controlling communication and devices, polling is a method of checking for changes in state by periodically querying the states. | |
| precedence (I,T) | The order relationship that determines the order of processing is called precedence. When a higher-precedence process becomes ready for execution while a low-precedence process is in progress, as a general rule the higher-precedence process is run ahead of the other process. | ITRON specifications in general, T-Kernel specification |
| Preempt | Preempting a task means, in the state transition of a task, the execution right of the task is taken away by another task, and the task is moved from RUNNING to READY. | |
| priority (I,T) | Priority is a parameter given by application to control the processing order of tasks, messages, etc. For the numbers that represent priority, positive values from 1 are used, and the smaller the value, the higher the precedence in ITRON specification OS and T-Kernel. In contrast to priority, precedence is a concept used in the specification to make clear the order in which processing is to be executed. | ITRON specifications in general, T-Kernel specification |
| Process | A process is a program unit that operates with its own memory space and resources. This is a term used in T-Kernel Extension and UNIX OSs. In T-Kernel Extension, a single process contains multiple tasks. | |
| Profile (I4) | Profile specifications define the minimum functional requirements that kernel must meet in order to maintain the portability of application programs written in high-level languages. µITRON4.0 specification defines profiles such as standard profile, basic profile, and automotive control profile. | μITRON4.0 Specification |
| Protocol | Communication procedures that computers must follow in order to communicate with each other are called protocols. | |
| Queue | A data structure that uses the First-In First-Out (FIFO) ordering method for processing is called a queue. In RTOS, it is used as one of the methods for managing data inside the OS. | |
| READY | READY is one of the task states in an RTOS. A task has completed preparations for running, but cannot run because another task with higher precedence is running. In this state, the first task is able to run whenever it becomes the task with the highest precedence among the tasks in READY state. | T-Kernel 2.0 Specification and µITRON4.0 Specification |
| ready queue (I, T) | A queue used to manage tasks in an executable state in an RTOS. When a task becomes executable (READY), it is put in a queue according to its precedence. This queue is called ready queue. OS executes the first task with the highest precedence that is in the ready queue. Between tasks with the same precedence, a scheduling method called first come, first served (FCFS) is used. | ITRON specifications in general, T-Kernel specification |
| real-time handling | It means processing with strict time constraints. More specifically, it is processing that assures that the time it takes to return some response based on processing is within the time limit. | |
| Real-time Operating System | See 'RTOS.' | |
| real-time system | A system designed to adhere to strict time constraints is called a real-time system. There are two types of real-time systems: hard real-time systems and soft real-time systems. | |
| Resources | The various elements required for the execution of embedded systems are collectively referred to as resources. Resources include processors, memory, input/output devices, etc. | |
| ring buffer | A data structure that manages the data buffer area in a ring-like fashion, so that when the buffer is used up, the place to store/retrieve data returns to the beginning. | |
| round-robin | A method of using a processor in time-sharing mode, in which each task is executed in turn for a fixed period of time. It is also called cyclic parallel processing. In round-robin, tasks that have used up their time are paused and moved to the end of the queue (ready queue), and the next task in the queue is executed. In tasks that are subject to round-robin scheduling, all tasks are executed in turn in a time-sharing manner. | |
| RTOS: Real-Time Operating System | An operating system developed to control real-time systems (systems with strict execution time constraints). RTOS has a function that sets priorities for tasks to be executed and processes them in order of priority. By using such functions, scheduling that meets time constraints is possible. In embedded systems, it is necessary to respond to external interrupt as quickly as possible, so RTOS is often used. | |
| RUNNING | RUNNING is one of the task states in an RTOS. The task in the RUNNING state is currently being executed. When a task-independent portion is executing, except when otherwise specified, the task that was executing prior to the start of task-independent portion execution is said to be in the RUNNING state. | T-Kernel 2.0 Specification and µITRON4.0 Specification |
| Service call (I4) | This is an API provided as an OS function. Various functions of an RTOS in general, such as object manipulation for tasks and semaphores, are provided as service calls. It is called system call in µITRON3.0 specification and T-Kernel specification, and service call in µITRON4.0 specification. Generally, it is also called Supervisor call (SVC). The specifications for ITRON specification OS service calls and T-Kernel specification OS system calls consist of C language APIs, and their parameters, return parameters, error codes, etc. | μITRON4.0 Specification |
| SIL: System Interface Layer (I4) | In an architecture built in accordance with the µITRON Device Driver Design Guideline, this is a software module that handles parts that depend on the system's operating environment. | μITRON4.0 Specification |
| Single source | A method of unifying and providing OS and software source code, and also the entity thus provided, to improve the distributability of software for embedded systems. In the early days, they were called “single one source” to emphasize its uniqueness, but later the name “single source” became established. TRON Forum has enhanced the compatibility of the middleware on the OS by strictly unifying the specifications and implementation by making the T-Kernel source code a single source. | |
| SMP: Symmetric | SMP is an abbreviation of symmetric multiple processor, which is a multiprocessor with multiple identical cores. It is also called a load-balanced multiprocessor or a homogeneous multiprocessor. | |
| Stack | A data structure that uses the Last-In-First-Out ordering method for processing data is called a stack. It is used to store the return addresses of subroutines and interrupt handlers, and is used as a memory area for local variables. | |
| Standard profile (I4) | The μITRON4.0 specification strictly defines a standard set of functions and their specifications in order to improve software portability. This standard set of functions (API) is called standard profile. | μITRON4.0 Specification |
| Static APIs (I4) | ITRON specification provides an API for statically generating objects, so you can describe object generation in the configuration file. The API for this purpose is called static API. In the µITRON4.0 Specification, static APIs are written in uppercase, and dynamic APIs are written in lowercase. | μITRON4.0 Specification |
| Strict standardization (T) | A method of maximizing system compatibility and portability by unifying the specification and implementation in a very strict manner. In the T-Kernel specification, a strict standardization policy has been adopted to improve the distributability of middleware. Against the backdrop of the increased processing power and memory capacity of microprocessors for embedded systems, the source code of the T-Kernel specification OS was managed collectively by TRON Forum and released as a unified source. By compiling it into a binary using a C compiler that conforms to the application binary (ABI) of the target CPU, you can obtain an OS binary. By strictly unifying specification and implementation in this way, TRON Forum has adopted a standardization method that improves the compatibility and portability of the middleware that runs on the T-Kernel with the same type of target CPU, and this approach is called “strict standardization.” See also “loose standardization.” | T-Kernel specification |
| SVC: Supervisor call, Service Call | See 'Service Call' in the glossary. | |
| System call (I3),(T) | See 'service call.' | μT-Kernel 3.0 Specification and T-Kernel specification |
| Task control block | A data area for storing various attributes, states, and information about tasks that operate under the control of an RTOS. | |
| Task exception handling function (I,T) | Task exception handling function handles exceptions that occur in tasks. Interrupts and CPU exceptions are handled in a context different from that of the task (task-independent context), whereas task exception handling is executed in the same context as that of the task (task context). | ITRON specifications in general, T-Kernel specification |
| Task independent part (I3,T) | OS parts that are executed in a context independent of tasks, such as interrupt handlers. | μT-Kernel 3.0 Specification and T-Kernel specification |
| TCB: Task Control Block | See 'Task Control Block' in the glossary. | |
| T-Engine (T) | A standard development platform for developing ubiquitous computing devices proposed by T-Engine Forum. It consists of an evaluation board for embedded system development, standard real-time OS, i.e., T-Kernel, its related software, development tools, etc. | |
| Thread | This term was first used mainly in the UNIX world, and its meaning is similar to the term “task” in ITRON specification OS and T-Kernel. It refers to a unit of parallel processing in a program. There are single thread programs, in which only one C language function can operate at a time, and multi-thread programs, in which a multiple number of C language functions can operate logically at the same time and such number of functions that operate at the same time is the number of threads. | |
| Time event handler(I4,T) | A generic term for handlers that perform time-dependent processing (periodic handlers, alarm handlers, and overrun handlers). | μT-Kernel 4.0 Specification and T-Kernel specification |
| Time out (I,T) | Timeout means that the expected conditions have not been met within the predetermined time period. In a service call that enters a waiting state, if the processing is not completed within the specified time as a 'timeout' time, the waiting state is interrupted and the service call returns. In this case, the service call returns E_TMOUT error. | ITRON specifications in general, T-Kernel specification |
| Timer handler (I3) | See 'Time event handler.' | μITRON3.0 Specification |
| Timer queue | It is a queue for connecting tasks that are waiting for a timeout or waiting for a particular time. When a task is suspended for a certain period of time during execution, the TCB of the task that enters the waiting state is connected to the timer queue. The storage area for the pointer that points at the beginning of the timer queue is called Task Timer Control Block (TTCB). | |
| T-Kernel (T) | An RTOS developed by T-Engine Forum for next-generation embedded systems. In addition to the basic functions of µITRON specification OS, T-Kernel also has functions such as device driver management and subsystem management. By combining T-Kernel with an extension program called T-Kernel Extension, you can also use functions for large-scale systems such as process management, file management, and virtual memory. On the other hand, for small-scale systems, µT-Kernel specification has been developed, which incorporates the benefits of both µITRON and T-Kernel. Furthermore, MP T-Kernel has been developed for multi-processors and multi-core processors, and can be used in a variety of embedded systems. | T-Kernel specification |
| TRON: The Real-time Operating system Nucleus | The name of the project started by Dr. Ken Sakamura of the University of Tokyo in 1984, aiming to create an ideal computer architecture. The project has been researching how computers and networks should be in a highly computerized society in the near future. The ultimate goal is to realize a Highly Functionally Distributed System (HFDS) where devices with embedded computers are connected to the network, and work together in a coordinated manner. | |
| Ubiquitous computing environment | An environment in which computers are everywhere in all aspects of life and society, and computers work together autonomously to provide powerful backup for human living. The word "ubiquitous" is Latin for “omnipresent” and means that computers are everywhere (i.e., that computer functions are available everywhere). | |
| Undefined (I4) | In the ITRON4.0 specification, the parts of the OS operation and behavior that are not specified in the specification are defined as undefined. Undefined means that there are no guarantees regarding system behavior in such situations. In the worst case, it is possible that it will cause not only related tasks to fail, but also a system crash, so care is needed to avoid undefined situations. | μITRON4.0 Specification出典 |
Source
Practical Embedded Systems Programming Guide
For ITRON specification OS and T-Kernel
First edition published on August 1, 2008
Editor: Ken Sakamura
Author: TRON Association
Publisher: Gijutsu-Hyohron Co., Ltd.