Selecting an operating system for an embedded application
Editor's note: In this article, the process of selecting an operating system for an embedded system is outlined and reviewed. Colin Walls of Mentor Graphics discusses whether or not you need to use an OS and if so, whether it will be a free, open source version, commercial, or a custom designed one. Then he drills down and looks at the pros and cons of various features you will need in the OS you have chosen.
On desktop computers, the selection of an operating system (OS) is largely a matter of taste - Windows vs Apple vs Linux. There is relatively little choice. For an embedded system, the matter is much more complex. The large number of options available reflect the wide diversity of embedded applications.
Do you really need an OS?It is rare nowadays to find an embedded system without an 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 (Figure 1) of CPU complexity – broadly, data bus width – against software complexity.
Figure 1 has been 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 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 Linux or an embedded variant of Windows; select a real-time operating system from among many choices; 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 many commercial operating systems on the market. These products have a number of advantages and disadvantages over the alternatives.
Advantages. There are numerous commercial RTOS products available and many of them are from 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 consideration of possible CPU migration in the future. A well-established RTOS vendor may be relied on to support new devices in a timely fashion, and their product is probably designed to simplify the porting process.
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. It is worth checking that the code is readable, as source code can be rendered incomprehensible to the human reader, and it should also be well commented. This is not a replacement for good documentation, but a useful supplement
Developing a multithreaded application has many challenges and one of these is debugging. It is 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 some circumstances.
It is rare that an embedded application needs just a bare-bones multithreading 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; 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 others, where very large volumes are anticipated, a royalty free business model might be ideal.
A common objection 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 between them 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 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.
“Free” operating systems
Free OSes, in this context, do not really include Linux, as most embedded developers are likely to spend money on a supported and packaged version, so it is not really free. This section looks at some of the smaller, readily downloadable RTOSes that are quite popular.
Advantages. The obvious attraction is clearly the lack of upfront costs, which continues after deployment as there are no license fees to worry about.
Free OSes tend to include source code, which 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.
As 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 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 multithreaded 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 just 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 is then a big challenge.
In most embedded applications where an OS is deployed, something more than just a multithreading kernel is required, things like a file system or networking. Such options may be available but if not, more work would be 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. However, 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 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.
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 may be 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 is affordable. A fully scalable commercial OS is likely 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, multithreaded code can exhibit subtle bugs that 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 development costs still further, and it is unlikely that commercial middleware suppliers would entertain the idea of porting to a 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 heavy processor specificity. Typically, there is a significant proportion of assembly language and endianity, and interrupt support needs to be reviewed.
The biggest downside to developing an in-house OS is philosophical. The most successful businesses focus on their core competencies. Unless you are a kernel developer, it makes the most sense to concentrate on your main business.
OS selection criteria
Once the decision has been made 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 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 to be introduced by the OS. Real-time operating systems tend to use CPU time efficiently, as well as predictably.
Is device power consumption an issue? With many types of systems power consumption is an increasingly common concern. 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 (Figure 2). Linux provides some such functionality and an increasing number of RTOSes are incorporating power management frameworks, including the 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 regardless of what OS you choose. The same will go for communications protocols. If you have more obscure devices, there may be a problem. Although many RTOSes have 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 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 an MMU, 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.
Does your app require safety certification? In certain industries, certification is mandatory. 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. Obviously, it is good practice to select an OS that has a proven track record in the specific application area. For example, even though Mentor Embedded cannot sell you a “medical system certified” version of Nucleus RTOS, we do have many customers who have successfully used the product in such applications
Is enterprise system interoperability needed? If your device needs to perform significant interoperation with enterprise systems, this may be a circumstance when Microsoft products would be a good choice.
Are selling price and shipping volume known? It is easy to get wrapped up in the technicalities when looking at the selection of an operating system. Often, as with many purchasing decisions, an 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 have useful past experience with other OSes? As training is expensive and time-consuming, it is always good practice to leverage existing experience whenever possible. If the development team has 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 to consider
Broadly, there are two types of multicore systems. If the CPUs are all the same architecture, the system is termed homogeneous. If the CPUs are not all the same architecture, it is heterogeneous. A system can also be a hybrid of the two.
There are broadly 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 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. (Sourcery Analyzer from Mentor Embedded is an ideal tool to support multicore, multi-OS designs.)
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.
Colin Walls has over thirty years experience in the electronics industry, largely dedicated to embedded software. A frequent presenter at conferences and seminars and author of numerous technical articles and two books on embedded software, Colin is an embedded software technologist with the Mentor Graphics Embedded Software Division and is based in the UK. His regular blog is located at: mentor.com/colinwalls. His email is firstname.lastname@example.org.