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

rtos selection a team of in-house RTOS experts to support an underlying piece of code beneath your core application? ● Do you have a clear idea of the technical characteristics that the RTOS requires to allow your application to meet its requirements? ● Is your company lawyer aware of the terms of the GNU General Public License associated with the use of open source? ● Are you ready to fund any necessary training associated with RTOS development? Answering these questions realistically and honestly is the ﬁrst step to successful deployment of an RTOS, and can save your company substantial time and money. RTOS CLASSIFICATION To help make sense of the wide variety of RTOSs available, a good starting point is classifying them according to the whether they use proprietary (closed) or open source technology, and whether they’re a commercial product or developed in-house (see Table 1). PROPRIETARY IN-HOUSE Some companies, typically with a strong engineering discipline, feel they are able to write their own real-time executive (RTX) or scheduler. This slim piece of code provides the most basic level of services for an application, and is often assembled as part of the actual application. While this development method was typical of the design of simple embedded systems in the 1990s, as software complexity has increased it has become less favoured. An in-house RTX inherently provides little portability, and we have witnessed endless difﬁculties where silicon obsolescence has led to the death and loss of core functionality of a company’s product. An RTX has limited tool support, because much of the softwarecrafting will have been conducted at machine code level, or through the creation of an in-house compiler. Problems in either of these weak debugging environments rely heavily on the individual who wrote the initial code. However certain advantages include the safe comfort of knowing each line of code within the RTX, including its behaviour, its tolerances and the satisfaction of having paid neither license fees nor royalties for shipping product. That’s ﬁne, until the developer who wrote the RTX leaves your company. OPEN SOURCE IN-HOUSE A natural move has occurred in recent years away from the in-house RTX towards embedded Linux. Not a single product, but more a term used to describe a particular technology, Linux is a free, open source operating system which is supported by the GNU toolchain, plus several commercial companies who now offer Linux development tools. Typically an open source development tree has regular releases which include latest features and bug-ﬁxes. The license terms for the deployment of Linux, and some other open-source RTOSs, in embedded devices are controlled by the GNU General Public License (GPL). Seeking legal advice before product shipment therefore makes pragmatic sense. Industry consensus suggests that linking at build time with GPL’d software brings your own software under the terms of the GPL, but the converse is not necessarily true. In practice, you can acquire the code for zero cost, but there are clearly detailed restrictions on how it should be deployed in a product. Support is also important: compare the support you will receive from a COTS vendor to an in-house embedded Linux distribution. Don’t underestimate the value of warranty in comparison with a COTS RTOS. You will own the responsibility for warranting the open-source code in your product. OPEN SOURCE COTS A number of vendors have spent their own development effort in maintaining their own paid-for COTS Linux distribution for commercial beneﬁt. Some charge for the development tools, others charge for ‘middleware’ supplied such as web-server, USB or UI technology. The key beneﬁt of a COTS Linux vendor is support: you will have a similar relationship as you would with a proprietary vendor. COTS Linux vendors often release their own distributions to their customers before passing them back to the community at large. PROPRIETARY COTS Probably the most signiﬁcant difference between in-house or COTS RTOSs is the level of support. In typical license terms, the vendor has a responsibility to respond to support requests. However, this is not the case for all. In some cases, there is no direct conduit to a support team, but you can log your bugs with the vendor in the hope that a ﬁx will appear in a subsequent release. Fees are always considered to be the worst part of engaging with a COTS RTOS vendor. Also, the ‘model’ by which you can license access to their technology often differs. Most vendors operate a ‘three Ps’ license model: ‘place’ is the physical location where the license is to be used, ‘project’ is the single project you will be restricted to, and ‘platform’ is the 31 www.embedded.com/europe | embedded systems design europe | AUGUST – SEPTEMBER 2008 030-031-032-033_ESDE.indd 31 29/08/08 11:02:47 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.