R8C Family General RTOS Concepts
Selection of RTOS
RTOS tends to be a selection for many embedded projects. But is an RTOS always necessary? The answer lies on careful analysis in understanding what an application needs to deliver to determine whether implementing RTOS is a requirement or an extravagance.
Most programmers are not familiar with RTOS constraints and requirements. An RTOS is usually chosen based on its performance or one’s comfort and familiarity with the product. However, such a selection criteria is insufficient. To make matter worse, there is a wide variety of RTOS ranging from commercial RTOS, open-source RTOS to internally developed RTOS to choose from. Therefore, it is incumbent upon the programmers to exercise extra caution in the selection process.
The selection criteria of RTOS can be broadly classified into two main areas; technical features of RTOS and commercial aspect of the implementation.
Size or memory footprint is an important consideration. Most RTOS are scalable in which only the code required is included in the final memory footprint. Looking for granular scalability in an RTOS is a worthwhile endeavor, as it minimizes memory usage.
Often, a current application may outgrow the hardware it was originally designed for as the requirements of the product increases. An RTOS with such a capability can therefore be ported between processor architectures and between specific target systems.
Run-time facilities refer to the services of the kernel (i.e. intertask communication, task synchronization, interrupts and events handling, etc). Different application systems have different sets of requirements. Comparison of RTOSs is frequently between the kernel-level facilities they provided.
Run-time performance of an RTOS is generally governed by the interrupt latency, context switching time and few other metric of kernel performance. This consideration is useful if the performance assessment of the application on a given RTOS is to prototype its performance-critical aspects on standard hardware.
A sufficient set of development tools including debugger; compiler and performance profiler might help in shortening the development and debugging time, and improve the reliability of the coding. Commercial RTOSs usually have a complete set of tools for analyzing and optimizing the RTOSs’ behavior whereas Open-Source RTOSs will not have.
Costs are a major consideration in selection of RTOS. There are currently more than 80 RTOS vendors. Some of the RTOS packages are complete operating systems including not only the real-time kernel but also an input/output manager, windowing systems, a file system, networking, language interface libraries, debuggers, and cross platform compilers. And the cost of an RTOS ranges from US$70 to over US$30,000. The RTOS vendor may also require royalties on a per-target-system basis, which may varies between USS5 to more than US$250 per unit. In addition, there will be maintenance required and that can easily cost between US$100 to US$5,000 per year.
An RTOS vendor usually has a few license models for customers to choose from. A perpetual license enables customers to purchase the development set and pay an annual maintenance fee, which entitles he/her to upgrades and bug fixes. An alternative model known as subscription model allow customers to “rent” the development set whilst paying an annual
Page 14 of 18