Embedded Systems Design Europe - August/September 2008 - (Page 32)

rtos selection designated processor architecture. This rigid license structure can cause difﬁculty when you want to change one of these three elements, as you will need to purchase the license all over again. This license will also probably have an annual support and maintenance component, which is typically 20% the cost of the license fee. Do consider whether you feel having access to source code an important issue. Historically, the majority of software vendors preferred to provide all software in binary form. However, to alleviate their support burden on forever increasing complexity, many vendors now provide source code upon request – although be warned, the vendor may not provide support on a ‘modiﬁed’ product. FACTORS IN RTOS SELECTION Choosing and deploying the correct RTOS can be a make or break issue for an OEM company - it should never be underestimated. Understanding the exact licensing issues around a Linux deployment, or verifying the claims of commercial RTOS vendors, are not easy. You must also balance the different priorities of your decision: by choosing the RTOS that will get you to market fastest, are you storing up long-term support or licensing problems? Broadly, the issues around choosing an RTOS can be organised into two separate areas: TECHNICAL FEATURES The main technical characteristics to bear in mind when choosing an RTOS include: ● run-time facilities ● scalability ● portability 32 Choosing and deploying the correct RTOS can be a make or break issue for an OEM company ● run-time performance ● development tools In the early days of commercial RTOSs, they could often be distinguished by what kernel-level facilities they provided, for example for scheduling, interrupt handling, inter-task communication and synchronisation. As the market has matured, there is typically little to choose between the most widely-used RTOSs in this respect. However, there may still be differences between them at a higher level, for example support for particular communication protocols, buses and devices. Scalability is an often-overlooked characteristic of an RTOS, to occupy minimum memory for small applica- tions or to support the features required for larger applications. This is usually achieved by customising the RTOS at build time to include or exclude support for the components needed by a speciﬁc application. How easy the conﬁguration process is depends on the complexity of the product and the tools provided by the RTOS vendor. To minimize the memory occupied by the RTOS you should look at the granularity of the conﬁguration process: the components should each be small (which may mean there are many of them) and there should be few dependencies between them. At some stage, your current application may outgrow the hardware it was originally designed for. Portability can be considered between processor architectures, and between speciﬁc target systems. Usually, commercial RTOSs are ported by the vendor to a range of different processor architectures and this cannot be done by the customer. It’s also worth checking that the programming interface will be the same on different processor architectures. One of the areas in which vendors used to compete vigorously was in the run-time performance of their RTOSs. The main ammunition in this battle was the infamous benchmark, whether it was interrupt latency, task switching time or some other metric of kernel performance. Although benchmarks can be useful in some circumstances, especially if the performance of your application depends critically on a speciﬁc performance metric that the vendor happens to quote, they are generally unreliable as a guide to choosing an RTOS. AUGUST – SEPTEMBER 2008 | embedded systems design europe | www.embedded.com/europe 030-031-032-033_ESDE.indd 32 29/08/08 11:03:05 http://www.embedded.com/europe

Table of Contents Feed for the Digital Edition of Embedded Systems Design Europe - August/September 2008

Embedded Systems Design Europe - August/September 2008 Contents TI Overhauls DSP Lineup, Adds 15 Processors QNX Publishes Source Code for File System Congatec to Take on Proprietary Market Swiss Multicore Project Wins Microsoft Grant OpenCores Bundles Development Tool ARM Compiler Boosts Freescale i.MX31 LabVIEW Updated for Multicore and Wireless Cover Feature: Interactive Tool Supports Multiprocessor SoC Design Wanted: Benchmaking for Embedded VMM Hypervisors Graphical Design Empowers Spider Robots Building a Power Supply for Discontinuous Transmission Wireless Networks RTOS Selection & Best Practices Achieving Cache Coherence in a MIPS32 Multicore Design New Products Advertising Contacts

Embedded Systems Design Europe - August/September 2008

For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.