RTOS standard cuts embedded-system-development time
Today's consumer-electronics devices have short development cycles, But the software that drives consumer electronics is more complex. the use of C and other high-level languages, along with RTOSs, has become increasingly common for improving embedded-application software productivity.
NS Manju Nath, Technical Editor -- EDN, January 20, 2000
|
The wide differences in OS specifications and the bewildering variety of microcontrollers in use have made the standardization of real-time operating systems (RTOSs) a major issue. Also, the lack of hardware resources on low-end microcontrollers is making software development difficult. The Tokyo-based Industrial TRON (the RTOS Nucleus), or ITRON, organization project creates standards for embedded-system RTOSs. The organization in 1987 issued the first ITRON specification, ITRON1. Thereafter, it developed the µITRON specification, with a smaller set of functions targeting 8- and 16-bit µCs, and the ITRON2 specification for 32-bit processors. In 1989, it released both the µITRON and the ITRON2 specifications.
The µITRON specification is a highly condensed version of the ITRON specification. Designers have implemented µITRON-specification OSs not only on 8-bit µCs but also on 16- and 32-bit µCs. The originators of ITRON, in their attempt to standardize RTOS specifications for embedded systems, had to grapple with the trade-off between optimizing systems for hardare and boosting software productivity.
In simpler terms, in a µC-based system with its limited hardware resources, you use an RTOS only if you can derive the maximum benefit from the available hardware. At the same time, using an RTOS can only boost software productivity. However, when you attempt to work on the higher service level of abstraction that the RTOS provides, you will find that runtime overhead penalizes hardware performance.
But it is also true that the embedded system in question plays a major role in the trade-off between hardware optimization and software productivity. For example, in an 8-bit microcontroller system, advanced functions that are of little use, such as memory-pool management, can add to the system-software overhead and degrade its performance. In a 32-bit microcontroller-based system, advanced functions contribute to software productivity via the RTOS.
ITRON designed its OS specifications to take maximum advantage of the hardware performance that is built into the microcontroller. Specifically, the ITRON specifications clearly distinguish between aspects that should be standardized across microcontroller hardware architectures and matters that should be decided optimally based on the nature of the hardware and its performance.
Furthermore, the µITRON specification recognizes that embedded systems have little need for object-code compatibility. On the other hand, the need for compatibility when naming system calls or their functions is important from a learning standpoint. Unlike other RTOSs, ITRON has standardized aspects, such as task-scheduling rules, system-call names and functions, parameter names (their order and meaning), and error code (names and meanings). Issues that affect real-time performance, such as the handling of interrupts and the size of parameters, are not standardized.
Also according to ITRON specifications, the functions that the kernel provides have been made as independent of each other as possible, allowing each application to select just the functions it requires. Toward this end, most µITRON-specification kernels are supplied in library format. You select the kernel functions and link them to the application program at runtime. In this way, the system incorporates only the required functions. In addition, each system call provides a single function, making it easy to incorporate only the necessary functions.
One of the features included in the µITRON specification is that the processor architecture is not virtualized. Although the ITRON-specification OSs run on different processors, the standard does not virtualize unnecessary operating conditions, so you may achieve higher processing performance.
The µITRON specification also specifies high-speed response. Factors that influence response times in a real-time application usually involve task-switching functions and interrupt-handling routines. The ITRON specification lets you swap registers out at a task-switching time that you specify to achieve high-speed task switching. You can also bypass the RTOS to activate an interrupt handler to run whenever an external interrupt occurs.
The way µITRON handles kernel calls makes for faster response, according to David Easler, senior technical applications engineer for V800 series tools at NEC. Easler says that the primary difference between µITRON and other RTOSs is that other RTOSs use software interrupts to call functions from the kernels library; µITRON specifies that you use standard C-style calls.
By separating architecture and implementation, µITRON offers an advantage over other RTOSs: If you need to change an implementation below a given layer, you can continue to use the higher level specifications without modification. Also, µITRON confines itself to architectural specifications. You, the developer, are free to implement the application however you choose. In this way, the µITRON standard provides a level playing field for fair technological competition.
A lot of hard work has gone into making the ITRON specification easy to learn and digest. For example, the ITRON committee has systematically defined system-call names and functions of the ITRON specification, making them easy to remember. All ITRON system calls are seven or eight characters long and in the form xxx_yyy and zxxx_yyy, respectively. The xxx portion represents the method of operation, and the yyy represents the object of the operation (Figure 1). In eight-letter system calls, z represents system calls that you derive from the seven-letter system calls that exclude z. Table 1 shows some abbreviations and what they stand for.
Easler says that learning µITRON, like learning C, is simple because developers no longer have to switch processors or learn about what other RTOS vendors call mailbox queues or how other RTOSs handle buffers.
Under the ITRON specification, the term "task" refers to a unit of concurrent processing. Programs inside a single task are executed sequentially; programs of multiple tasks are executed concurrently. The ITRON specification uses priority-based scheduling. Each task is assigned a priority level; the smaller the priority value, the higher the priority level. The ITRON specification uses a number, called a task ID, to designate a task. The task-control block (TCB) contains the information you use for managing tasks. The ITRON OS specification handles settings and changes to values inside the TCB through system calls.
According to µITRON, resources are elements necessary for the execution of a task. Resources include hardware, such as the processor; memory and I/O devices; and software, such as files and programs. The ITRON specification provides many synchronization and communication functions for exclusively assigning resources.
The ITRON specification includes five task states: run, ready, wait, dormant, and nonexistent (virtual). To ease program development, the ITRON specification clearly differentiates system calls used by a task to control itself and system calls used by a task to control other tasks. This method clarifies task-state transitions and simplifies the understanding of system calls.
Under the ITRON specification, an object is any item, such as a task, that a system call handles and that you identify with an ID number. In addition to tasks, objects include synchronization and communication mechanisms, such as memory pools, semaphores, event flags and mailboxes. The OS provides an object-management table for each type of object. (For example, it provides a TCB for tasks.)
The µITRON 3.0 specification is divided into three system-level calls: Level R (required), Level S (standard) and Level E (extended). In addition to these three levels, Level C handles CPU-dependent system calls. Level R deals with the functions necessary for implementing the µITRON 3.0 specification. Level S covers basic functions for achieving a real-time, multitasking OS. Level E comprises additional and extended functions. This level includes object creation and deletion functions, rendezvous functions, memory pools, and the timer handler. The CPU-dependent Level C provides hardware-dependent functions based on the CPU.
The µITRON-specification kernel, in particular, continues to find use with low-end microcontrollers. These devices previously could not use an RTOS, because of memory and execution-speed constraints. The µITRON process offers considerable advantages, and µITRON is well on its way to becoming the world's first standard kernel specification among 8- and 16-bit microcontrollers.
Support for µITRON is coming from US vendors as well. For example, in addition to its native kernel application-programming interface (API), Cygnus offers its embedded Cygnus OS (eCos) with a µITRON 3.0-compatible API. With its µITRON compatible API, eCos allows you to port and reuse µITRON applications. Note that eCos is an open source OS, and Cygnus will provide source code for eCos, GNU compilers, and debuggers (www.sourceware.cygnus.com). Many industry experts believe that Cygnus' move could result in the proliferation of the µITRON standard.
NEC is offering the RX850 RTOS, which is compatible with µITRON 3.0, to work with its NEC V850/E series microprocessors. The RX850 RTOS tool suite includes an RTOS-task-aware debugger, which lets you display state transitions. Using the RX850 RTOS tool suite, you can analyze and profile a system's performance by verifying the event-state transitions and view interrupt event-timing and function-thread duration. With the RD850 task debugger, you can also view various OS resources, such as tasks and semaphores, as well as system buffers and queues. When you use it on the NEC V851 microprocessor running at 25 MHz, the RTOS kernel has a binary code size of 3 to 8 kbytes. It also offers a maximum 1.3-µsec task-switch time and a minimum 5-µsec task-switch time. The RX850 is a licensed RTOS, so you pay according to how many devices you want to place it in. Prices for the RX850 start at $800.
Accelerated Technology Inc (ATI) has ported its real-time kernel, Nucleus Plus, to the µITRON interface standard, allowing its customers to freely move their legacy applications to any number of CPUs and offering the benefits of a royalty-free source code. ATI plans to port this kernel to the Hitachi SH family of processors.
Several events point to µITRON's potential for becoming the world standard for embedded RTOS. According to Paul Beeskens, director of engineering at Cygnus Solutions, ITRON needs to shed its Japanese-only outlook and be more international to have a chance at succeeding as a worldwide standard.
"It should offer a wider selection of English language documentation and technical information," says Beeskens. The µITRON committee must expand to incorporate a wider international constituency, for example, making available the standard as it is developed in English. Beeskens also notes that the ratification of µITRON as a formal standard by a US or international standards body would also be an advantage.
According to NEC's Easler, the US embedded market contains no universal standard for a high-performance, small-memory footprint OS. He says there is a standard for larger footprint OSs, such as Posix, that require a lot of conformance data and APIs that use a lot of memory. (A µITRON RTOS fits into 16 kbytes of memory.) Also, the standard defines the way that you call functions as well as the way the kernel uses tasks.
"For all its loose standardization," Easler says, "µITRON's timing is deterministic, whereas Posix doesn't care."
Quick portability across platforms and ease of use are µITRON's biggest advantages, according to Koji Mugita, marketing engineer from Grape Systems Inc. Mugita says that because the embedded-software industry is highly fragmented and consists of more than 50 software vendors worldwide, a standard such as µITRON would allow embedded-industry developers to use the software in future applications with minimal change, regardless of the microprocessor they use. However, Beeskens explains, µITRON must still overcome certain deficiencies.
"The µITRON 3.0 standard is well-constructed, straightforward, and simple. It lacks portable interrupt and device handling, which hampers the portability of µITRON applications between implementations and architectures," Beeskens says. He notes these issues must be fixed to some extent in the µITRON 4.0 standard, but because no English translation yet exists, he does not comment further.
Author info
|
|
You can reach Technical Editor NS Manju Nath at +852-2965-1555, fax +852-2976-0706, nsmanjunath@cahners.com.hk.
REFERENCE
1. Sakamura, Ken, "µITRON 3.0 Specification," I-01-02E, Version 3.02.00, TRON Association.
For more information...
For information on subjects discussed in this article, use EDN's InfoAccess service . When you contact any of the following manufacturers directly, please let them know you read about their products in EDN.
Accelerated Technology Inc
1-800-468-6853
www.atinucleus.com
Circle No. 364
Cygnus
1-408-542-9600
www.cygnus.com
Circle No. 365
Grape Systems Inc
1 (81) 45-323-6541
www.grape.co.jp
Circle No. 366
Hitachi
1-800-448-2244
www.hitachi.com
Circle No. 367
µITRON Technical Committee, ITRON Association
+ (81) 3-3454-3191
www.itron.gr.jp
Circle No. 368
NEC
1-408-588-6686
www.nec.com
Circle No. 369
