E M B E D D E D S O F T W A R E W

H
I
T
E
P
A
P
E
R
w w w . m e n t o r . c o m
SELECTING AN OPERATING SYSTEM
FOR EMBEDDED APPLICATIONS
COLIN WALLS
EMBEDDED SOFTWARE TECHNOLOGIST
Selecting an Operating System for Embedded Applications
www. mentor. com
2
INTRODUCTION
It is rare nowadays to find an embedded system without an operating system (OS). Only the simplest kind of
device can be built efficiently without a kernel of some kind. But this possibility should not be dismissed. The
whole spectrum of embedded devices can be represented by a chart of CPU complexity broadly data bus
width against software complexity (Figure 1).
This can be roughly divided into four quadrants. The top right complex software on a high-end processor
is the traditional province of real-time operating systems (RTOSes) and other operating systems. On a less
powerful CPU, it may still be useful to deploy a basic kernel, if the software is reasonably complex. Sometimes,
a powerful chip is used to run quite simple software, where the CPU performance is required to get execution
speed. In this case, a kernel may not strictly be required, but using one may be prudent as it improves the
software architecture scalability and accommodates a future increase in complexity. It is really only when
simple software is running on a low-end device that no kernel of any kind is necessary.

Having concluded that an OS is required for a project, there is the question of making a selection. Broadly,
there are four options: select a high-end operating system, such as the Linux OS or an embedded variant of
Windows; select a real-time operating system, of which there is a very large choice; deploy one of the free
operating systems that are widely available; or implement a kernel in-house. There follows a review of these
options.
COMMERCIAL OPERATING SYSTEMS
There are a great many operating systems on the market and these products have a number of advantages
and disadvantages over the alternatives.
ADVANTAGES
There are many commercial RTOS products available and many of them are from very well established,
reputable suppliers. But this is something that should be carefully considered. The size of the company, the
maturity of the product, and the user base are all important factors. A key requirement is the availability of
technical support.

In selecting an RTOS, both the buyer and the seller are making a long term commitment. An aspect of the
relationship is a consideration of possible CPU migration in the future. A well established RTOS vendor may be
relied upon to support new devices in a timely fashion and their product is probably designed to simplify the
porting process.
Figure 1: The four quadrants: based on CPU complexity versus software
architecture complexity.
Selecting an Operating System for Embedded Applications
www. mentor. com
3
Good documentation is essential and may be expected from a commercial RTOS supplier. There is no reason
not to ask to see a sample of the manuals. In the past, this may have been challenging shipping books
around the world. Now, a PDF by return email is a fair expectation.

Source code is available for many commercial OSes sometimes free; sometimes there is a specific charge.
Its worth checking to see that the code is readable as source code can be rendered incomprehensible to the
human reader. The code must also be well commented. This is not a replacement for good documentation,
but a useful supplement.

Developing a multi-threaded application has many challenges and one of these is debugging. It is very
useful to have an RTOS-aware debugger of some kind. Support for stop mode where the CPU is paused
on a breakpoint is adequate. Run mode where only the current task is stopped can be useful under other
circumstances.

It is rare that an embedded application needs just a bare bones multi-threading kernel. There is generally a
requirement for other middleware components. A commercial OS is likely to have a wide range, including
communication protocols which should be fully validated along with file systems (including Flash), and a
graphics package to aid UI design.

A particular challenge with embedded development is working close to the hardware. With an OS, that means
developing drivers. A commercial OS will most likely have a wide range of drivers for standard devices and
support for custom driver development.
DISADVANTAGES
In technical terms, every embedded system is different. CPU, memory, and peripherals all vary from one
device to another. But systems differ commercially too, and the final price of a piece of equipment, along with
the volumes produced, affect the OS licensing options. In some cases, a few dollars per device is reasonable.
In other situations, where very large volumes are anticipated, a royalty free business model might be ideal.

A common objection, which is put forward against using a commercial OS, is that the developer has no
internal knowledge of its functions. This may be true, but does it really matter? If the OS behaves as
documented, why is it important to know exactly how it achieves the result? It may be argued that, since the
operation of an OS is a particular specialism, most embedded software development teams cannot afford to
maintain such expertise. If source code is available, it provides insurance in case the internal operation of the
OS needs to be checked.

Purchasers of operating systems, like people buying any product, do not want to get locked in to one supplier
even if the supplier would welcome that possibility. With commercial OS products, a key difference among
various options is the application program interface, the API. The reality is that these do not vary too much, so
porting later, if a change of OS vendor is required, may not be such a big issue. Adherence to standards, of
course, leads to at least some degree of vendor independence. In this case, the POSIX API is probably the best
option.

Another common objection to commercial OSes is that they have too much functionality, as they need to
cater for the requirements of a large customer base. Although this is true, the cost of the functionality is
widely amortized, so it has no real impact on an individual customer. It is also likely that an OS is offered as a
set of components, many of which are optional. In the early days of commercial RTOSes, the products were
monolithic chunks of code, but as available functionality increased, the idea of scalability emerged. A fully
scalable OS enables just the required functionality to be incorporated in the final executable image.
Selecting an Operating System for Embedded Applications
www. mentor. com
4
FREE OPERATING SYSTEMS
Free OSes, in this context, do not really include the Linux, as most embedded developers are likely
to spend money on a supported and packaged version, so it is not really free. This section takes into
consideration the smaller, more readily downloadable RTOSes which are quite popular.
ADVANTAGES
The obvious attraction here is clearly the lack of upfront costs, which also continues after deployment,
as there are no license fees to worry about.

Free OSes always tend to include source code. It is certainly useful for reference, as documentation may be
limited and support hard to come by. It is also a requirement for configuration and porting to a new hardware
environment, which is, of course, down to the user.

Like with many kinds of user-supported software, free RTOSes often attract a strong following, resulting in a
vibrant online community from which support is freely available. Although this is very attractive and useful,
a concern is its longevity. Embedded software tends to go through phases where different technologies or
products are fashionable. What if the RTOS that you have chosen goes out of fashion? Also, this kind of
community support is usually focused on the current version of the software. If your product uses an earlier
version, you may have trouble finding help with issues.
DISADVANTAGES
Deploying an OS in an embedded device is a long term commitment, so the question of long term support
is important. For a free OS, can you rely on the community being around for the long haul? Also, is the
documentation up to scratch, as it can often lead to solutions?

Developing multi-threaded code is challenging and suitable debug tools are needed. If a free OS is popular,
such a tool may have been developed by a third party, but the question of support remains.

There is a psychological challenge with free software. As the source code is readily available and developers
perceive the code as not having a monetary value, there is a strong temptation to improve it. This may be
small adjustments to make the code more efficient, or it could be the addition of new functionality. In either
case, the result can be numerous similar, but different versions of the OS used in different projects.
Maintenance then becomes a very big challenge.

In most embedded applications where an OS is deployed, something more than just a multi-threading kernel
is required things like a file system or networking. Such options may be available, but, if not, more work is
needed to locate the necessary middleware and port it or adapt it for the chosen OS.

One of the key criteria for selecting an OS whether it is free or not is support for the CPU that has been
chosen for your project. However, having selected the OS, a significant investment in time and effort is
required. This is worthwhile if it can be leveraged over a number of projects. If different CPUs are selected,
what guarantee is there that support is or will be available?

All software, whether free or commercial, is licensed in some fashion. The license may be a very complex
document that constrains the deployment of the software in some way. The penalties for infringing a license
can be severe. Open source software can be particularly tricky, as the license can compromise the status of
your application code, obliging you to make its source code openly available. Legal advice should be sought
before incorporating any open source code into your application.
Selecting an Operating System for Embedded Applications
www. mentor. com
5
CUSTOM OPERATING SYSTEMS
ADVANTAGES
The most commonly cited reason for developing an in-house kernel is to maintain control of the complete
code base. This sounds sensible, but it makes the assumption that the staff members with relevant expertise,
which is quite specialized, are retained.

There are, of course, no ongoing license costs for in-house developed code. But the continuing cost of
maintenance cannot be ignored.

Another common justification for in-house development is that the resulting RTOS will be an exact match to
the requirements of the project. It may be argued that the features of the kernel are more likely to be defined
by the amount of development that can be afforded. A fully scalable commercial OS is likely to be able to offer
an exact match to needs without compromise.
DISADVANTAGES
All software development takes money. However, the costs of developing an in-house kernel are commonly
absorbed into a project, so that they are not visible.

Once an OS has been deployed, it is likely to be in use for some time. Hence, there is a need for long term
support. This is not a problem if the developers stay on board. Also, it will be less of a problem if the code is
meticulously documented. But these are both dangerous assumptions.

As mentioned earlier, multi-threaded code can exhibit subtle bugs, which need an OS-aware debugger to
detect. Having created a kernel, it is unlikely that a lot of further effort would be expended in developing such
a tool. One option is to adapt a commercial debugger for the in-house kernel.

It is likely that an in-house kernel will be used in several projects over time. There is a danger, however, that
each project team will seek to improve upon the base code. This results in multiple versions of the kernel,
which exacerbates the support and maintenance problem.

It is unlikely that a plain kernel will be enough. The development of additional middleware would increase the
development costs still further and it is unlikely that commercial middleware suppliers would entertain the
idea of porting to non-commercial RTOS.

At some point, it will become necessary to change CPU as technology moves on. This is a problem if the kernel
has very heavy processor specificity. Typically, there is a significant proportion of assembly language and
endianity and interrupt support need to be reviewed.

The biggest downside to developing an in-house OS is philosophical. The most successful businesses always
focus on their core competencies. Unless you are a kernel developer, it makes most sense concentrate on your
main business.
OS SELECTION CRITERIA
Once the decision to look at commercial or, at least, commercially supported OSes, there are a series of
qualification questions to resolve:
Is your application real time?
Real time does not necessarily mean fast; it means predictable or deterministic. These are not absolute
terms. It is a question of how predictably you need your system to respond to events. How critical is the
Selecting an Operating System for Embedded Applications
www. mentor. com
6
timing? If you need a high level of determinism, then an RTOS is probably your best choice. Under some
circumstances, Linux may serve, particularly if the use of real time extensions is acceptable.
Is memory size limited?
Unlike a desktop computer, the memory size of most embedded systems is fixed. The amount of
available memory is another important selection criterion. Unless you have multiple megabytes available
for the OS, the implementation of Linux etc. is unlikely to be viable.
Is CPU power limited?
The available CPU power is significant too. If the processor has only just enough power to run the
application, there is no margin for runtime overhead introduced by the OS. Real-time operating systems
tend to use CPU time very efficiently, as well as predictably.
Is device power consumption an issue?
With many types of systems, it is becoming increasingly common to be concerned about power
consumption. This may be to preserve battery life in handheld devices or for environmental and
economic reasons with fixed systems. The previous criteria of memory size and CPU power have a
bearing here, so the size and execution efficiency of the OS is important. A number of operating systems
include power management facilities. Linux provides some such functionality and an increasing number
of RTOSes are incorporating power management frameworks, including our own Nucleus RTOS.
Do you have obscure or custom peripherals?
An embedded system always includes a number of peripherals along with the CPU. If these are
standard devices, then drivers should be available whichever OS that you choose. The same will go for
communications protocols. If you have more obscure devices, there may be a problem. Although many
RTOSes have very wide ranges of drivers, they will almost always be trumped by Linux. If you have
unique, custom hardware, then a driver will need to be written. A benefit of Linux is that there is a very
large pool of driver writing expertise available. So, there is the option of hiring staff or seeking help from
a vendor that supports embedded Linux, such as Mentor Embedded.
Do you have a memory management unit (or could one be included)
If your design does not include a memory management unit (MMU), there is no option to use Linux etc.,
as an MMU is mandatory for all process model operating systems. Most RTOSes are thread model and do
not need an MMU. However, some RTOSes can use an MMU in an efficient way, if one is available.
Is application security an issue?
Some embedded devices need additional security. Often this means that tasks must be protected from
one another. Such protection can only really be implemented if an MMU is available. High end operating
systems and a few RTOSes use process model, which offers a high level of security. Other RTOSes, which
use thread model, can also offer a good level of protection by using the MMU to simply render parts of
the memory inaccessible, instead of fully remapping the memory. This is commonly called thread
protected mode and has a lower overhead than process model.
Does your application require safety certification?
In certain industries, certification is a mandatory requirement. This can be an expensive process that
requires access to all the source code. As the cost of certification is somewhat related to the number of
lines of code, a smaller OS is naturally attractive. It is generally necessary to certify a complete
application. So it is not possible to buy a pre-certified OS. Some OS vendors can help by providing some
of the required documentation. It is obviously good practice to select an OS that has a proven track
record in the specific application area. For example, even though we cannot sell you a medical system
certified version of Nucleus RTOS, we do have a great many customers who have successfully used the
product in such applications.
Do you need interoperability with enterprise systems?
If your device needs to perform significant interoperation with enterprise systems, this may be a
circumstance when the Microsoft products would be a good choice.
Selecting an Operating System for Embedded Applications
www. mentor. com
7
Are selling price and shipping volume for application known?
It is easy to get wrapped up in the technicalities when looking at the selection of an operating system.
Often, like with many purchasing decisions, a very important factor is cost. In this case it is not simply a
matter of getting the best price. The business model is also important. For some embedded devices,
paying a royalty on each one is reasonable. For large volumes, a royalty free model might be better.
Open source is interesting of course, but, in this case, as with purely commercial products, the ongoing
maintenance costs must be factored in.
Do you or your team have relevant past experience of other OSes?
As training is expensive and time-consuming, it is always good practice to leverage existing experience
whenever possible. If the development team have experience of a particular API, that may be a significant
influence on the selection process. Of course, if that experience is with a standard, like POSIX, you have
more latitude. Experience with a supplier counts too. In particular, past interaction with Technical
Support is valuable. Likewise, take into account the quality of documentation and source code. There
is at least one vendor that supplies source code, but intentionally renders it unreadable.
MULTICORE ISSUES
MULTICORE ARCHITECTURES
Broadly, there are two types of multicore system. If the CPUs are all the same, it is termed homogeneous. If the
CPUs are not all the same architecture, it is heterogeneous. A system could also be a hybrid of the two.

There are also generally two software architectures. Symmetric multiprocessing (SMP) is when a single OS runs
across multiple cores, distributing work between them. SMP can only be implemented on a homogeneous
multicore system. Asymmetric multiprocessing (AMP) is when each CPU has its own instance of an OS. AMP
can be implemented on any multicore configuration. A hybrid, where parts of the system make up an SMP
subsystem and others are AMP, is quite possible.
SELECTING A MULTICORE OS
With an SMP system the OS distributes work across the available cores. This needs a specific OS variant.
All the high-end operating systems have this option, as it is common practice on desktop systems.
Increasingly, real time operating systems, like Nucleus RTOS, have an SMP version. Clearly, the efficiency
with which the multicore architecture is utilized may be a key OS selection factor.

Selecting the OS for each core in an AMP system requires the same procedure as selecting an OS for a single
core system. However, there is also the question of inter-core communication, where using MCAPI may be an
attractive option. Alternatively, a hypervisor can be used to provide overall supervision of an AMP system.

Thinking about tools is important. For any embedded software development, having the right tools is
essential. For a multicore, multi-OS project it is really critical. Maintaining visibility of a complete system,
assessing its performance and debugging the complex interactions between code on different cores all
require sophisticated tooling. Availability of such tools might be a major influence on the choice of operating
systems and the vendor that you select. Mentor Embedded Sourcery Analyzer is an ideal tool to support
multicore, multi-OS designs.
TECH12110-w MGC 05-14
2014 Mentor Graphics Corporation, all rights reserved. This document contains information that is proprietary to Mentor Graphics Corporation and may
be duplicated in whole or in part by the original recipient for internal business purposes only, provided that this entire notice appears in all copies.
In accepting this document, the recipient agrees to make every reasonable effort to prevent unauthorized use of this information. All trademarks
mentioned in this document are the trademarks of their respective owners.
F o r t h e l a t e s t p r o d u c t i n f o r ma t i o n , c a l l u s o r v i s i t : w w w . m e n t o r . c o m
Selecting an Operating System for Embedded Applications
CONCLUSIONS
The selection of an embedded OS is a complex process, requiring consideration of multiple factors, both
technical and commercial. Also, leveraging experience is essential. All desktop computers are essentially
identical. That is why there is a choice of about three operating systems, which are all broadly equivalent.
On the other hand, embedded systems are all different, which is why we have such a wide choice of OS
products on the market and why this selection process is necessary.
For additional information Mentor Embedded Sourcery Analyzer or to request your own evaluation,
please visit http://www.mentor.com/embedded-software/sourcery-tools/sourcery-analyzer/
You can learn more about Nucleus Real-Time Operating System by visiting,
http://www.mentor.com/embedded-software/nucleus



About the Author
Colin Walls has over twenty-five years experience in the electronics industry, largely dedicated to
embedded software. A frequent presenter at conferences and author of two books on embedded
software, Colin is a member of the marketing department at Mentor Graphics Embedded Software
Division.
Linux is the registered trademark of Linus Torvalds in the U.S. and other countries.