Making embedded processing development easy - part 2

by Nick Lethaby , TechOnline India - August 17, 2011

In the second installment in a sequence created to introduce you to the fundamentals of embedded software design and considerations to aid with embedded processor design Nick Lethaby answeres the question Do I need an operating system for my embedded design? If yes, which operating system should I select

Welcome to a six-part series on 'Making embedded processing development easy.' We’re on the second installment in a sequence created to introduce you to the fundamentals of embedded software design and considerations to aid with embedded processor design.  This series is derived from the expertise of embedded processor software experts from Texas Instruments (TI) and is meant to provide an objective view of easing software design.  

This week’s edition is brought to you by Nick Lethaby, a manager in TI’s software development organization.

Q:  Do I need an operating system for my embedded design?  If yes, which operating system should I
select?

A:  The choice of whether an operating system (OS) is appropriate for your embedded design is primarily governed by a combination of hardware cost constraints, application complexity, development

team expertise and available development time. For example, many traditional microcontroller (MCU) applications such as power control, motor control or white goods, only perform a few functions and don’t require an OS. In addition, they need to have a small memory footprint as they reside and execute entirely in on-chip memory. As a general guideline, an application that has a code size of <32Kbytes is typically not a good candidate for an OS. Conversely an application that is >128 Kbytes will likely have enough different functions to benefit from a multitasking OS.

Another reason to use an OS is the need to support standard communication interfaces such as Ethernet or USB or to provide a sophisticated user interface (UI).  USB and Ethernet interfaces require associated software stacks that need to cover a myriad of protocol or class driver options. Since the main benefit of these peripherals is interoperability with networks or other USB host/devices, there is little scope for custom differentiation. Therefore, it makes sense to simply adopt an OS that already provides these. Likewise, any GUI framework will need the services of an underlying OS. It should be self-evident that the great majority of 32-bit embedded microprocessor applications will use an OS since such devices typically include USB, Ethernet and MMC/SD devices on chip, as well as having relatively complex applications.

Once you have determined whether your application needs an OS, you’ll need to select which one. The selection decision will likely be driven by both business and technical criteria. Important considerations

include real-time performance, boot time, memory footprint, application and driver availability, development tool support and licensing model. For heterogeneous multicore System-on-Chips, you may need to make different OS choices for different cores.

We’ll start by explaining some of the business criteria, especially licensing, and then look at the technical aspects of different classes of OSs.

Operating system licensing and business criteria

The licensing terms vary from completely free, such as open source offerings like FreeRTOS, Linux or Android, to commercial real-time operating system (RTOS) products requiring both up-front development licenses and run-time royalties for production systems. Note that commercial versions of open source OSs also exist and these require some form of payment, such as a subscription. Some OS products, such as Windows CE, are available largely free for development but require run-time royalties. In contrast, many commercial RTOS products do not charge run-time royalties and only require an

initial investment for the development licenses. However, please be aware that you may need to buy new development licenses for your next project. In addition to the licensing costs, you’ll also need to consider other potential costs. For example, will the choice of OS require a more powerful processor or more memory that increase overall system costs? You may also need training courses or support and consulting contracts depending on the experience and resourcing in your team.

Developers may choose a commercial OS for a number of reasons. An important one is ‘one-stop-shopping’ technical support that can speed the development process when those inevitable difficulties and setbacks are encountered along the way. Because they are charging for their products, a commercial OS vendor will make sure that tools, software libraries and plug-ins are tested to work together, easing and simplifying the integration of third-party software into your software system.

An open source OS can be obtained free of charge from its community or from semiconductor vendors
providing distributions for their specific devices. Linux is the most prominent example of an open source OS. The community sustains the OS, as well as providing additional applications that work on the OS. One benefit of an open source OS like Linux is the availability without a procurement cost of creative
and innovative software application and driver modules from the community. Of course, the software development team that has adopted an open source OS ultimately becomes responsible for integrating all open source code and ensuring it will work properly together. Given the complexity of many embedded

applications, this effort is often considerable.

 

OS choices

With embedded processors becoming so powerful, today’s embedded OS alternatives are much richer than they have been in the past. You can choose from richly-featured OS offerings stemming from the desktop or smart phone worlds, such as Android, Linux and Windows CE, from minimal real-time
executives, to anything in between. Generally OS products can be categorized into two categories, a high-level operating system (HLOS) and a RTOS. We will highlight the relative technical merits of these
below.

High-level operating systems

HLOSs offer the convenience of providing an embedded OS that is identical or at least based on a desktop one. As a result, much of the embedded application can be easily developed and tested in a desktop environment with only the final integration phase needing to be done on the embedded hardware. Since desktops allow use of many low-cost development tools not readily available on an embedded target, such as memory leak detection, this can significantly speed development. An even

more important benefit of HLOSs is the wealth of applications and device which are available. This makes it possible to quickly assemble much of the software for even the most sophisticated applications from existing modules. The widespread use of HLOSs in the desktop and smart phone markets also ensure a broad pool of developers and consultants to choose from if additional engineering resources are needed.

If your system is using an appropriate embedded microprocessor, that is one with a memory management unit (MMU), efficient support for external memory, and at least 300 Mhz, then a HLOS will be

a good option. Developers will generally choose between Windows CE (or similar embedded Windows variants), Linux and Android.

Windows CE requires royalties but has attracted many developers because of the ease of use it offers

for developing user interface applications. It provides a fully supported OS with GUI framework and tools, along with applications and training support from a large and well-established network of partners.

At the other extreme is Linux. A major attraction of Linux is that it can be used completely free of any licensing fees. The fast moving nature of the Linux community also usually ensures that Linux drivers are the first to take advantage of latest hardware features. Linux developers also have tremendous flexibility in tailoring their systems. The downside of Linux is that the core OS doesn’t include many essential features such as web servers or GUI frameworks. These features need to be added via a root file system that includes all the user space applications desired. In practice building a root file system and its associated embedded applications for an embedded target can be quite challenging for even an experienced team and increases the complexity of using Linux. Semiconductor vendors typically provide a root file system containing many of the commonly required Linux applications. For new adopters of Linux who need a more customized offering, one option is use an OS vendor such as Mentor Graphics, MontaVista, RidgeRun, Timesys or Wind River who provide commercial versions of Linux with fully supported root file systems and configuration tools.

Finally, the third option – Android –  is experiencing a rapid adoption because it appears to blend the best aspects of WinCE and Linux. Android, of courses, uses Linux as its underlying OS and then adds a

standardized user space and application framework. This includes WiFi, multimedia playback, GUI frameworks with built-in touch screen support and many other features essential to many of today’s embedded applications. Like Linux, Android is available royalty-free from Google. It is built on Linux but its content and how various plug-ins are integrated into it, such as its various multimedia processing capabilities, is controlled by Google. Google’s control of the all the applications integrated into Android does restrict the flexibility of developing software for Android, when compared to Linux. But for a developer who just wants something that works, it accelerates the development process as a whole by simplifying and streamlining the integration of third-party code when compared with the effort that is required for the same task under Linux.

 

Real-time operating systems

While HLOSofferings have much to offer, they have several disadvantages, especially in the realms of memory footprint and real-time performance. HLOSs were not generally designed and developed specifically for real-time systems where predictable and pre-determined response times are critical. While they are often fine for use in ‘soft’ real-time applications such as multimedia playback, if the embedded processing application will be a real-time system that has hard real-time constraints that cannot be missed, you will need to use an RTOS.

The deterministic responsiveness of some real-time systems can be a matter of life or death. For example, an embedded braking system in an automobile must be able to respond immediately when the brake is applied. An RTOS will have much faster interrupt response time than a HLOS and will also be deterministic, which means that certain operations are guaranteed to always execute within a specific time span. Equally important is that the smaller code size of an RTOS means that the interrupt handlers and core kernel can be locked into a processor’s internal memory, eliminating the effect of cache misses causing unpredictable execution times. RTOS products can be obtained through third-party vendors such as QNX, Wind River, Mentor Graphics, Green Hills and many others.  

A second key benefit of an RTOS is memory footprint. RTOSs are generally designed to be more code efficient in the first place and are additionally much more modular than a HLOS. This makes it easy to configure out unneeded modules or functions. For applications that need to meet constrained memory requirements, such as those running on MCUs with on-chip memory, this is critical. Even with systems with external memory, an RTOS will usually result in lower memory costs compared to a HLOS.

Next week, we’ll discuss how to protect your software investment and make your code reusable.  And future topics include the open source community, multimedia and graphics development. You can read the first installment here.

About the author:

Nick Lethaby is a manager in TI’s software development organization, working with Linux, Android and real-time operating system (RTOS) technology and providers. Previously, he worked for nine years as the product manager for TI’s digital signal processing/BIOS RTOS and xDAIS/codec engine multimedia stack. Prior to joining TI, Nick spent 15 years working with embedded software companies in product marketing and applications roles. He received a Bachelor of Science in computer science from London University in Great Britain.

About Author

Comments

blog comments powered by Disqus