Blog
Please visit our website for more information on this topic.
Almost all modern embedded systems are built using an operating system (OS) of some sort. This means that the selection of that OS tends to occur early in the design process. How do you choose an OS?
Almost all modern embedded systems are built using an operating system (OS) of some sort. This means that the selection of that OS tends to occur early in the design process. Many developers find this selection process challenging. How do you choose an OS for your specific application?
This was the question posed to me by a potential customer not so long ago. He was after some process &#; some methodical guidance &#; to drive his selection process. I explained that this really was not possible &#; there are too many interrelated factors to make anything like a flowchart possible. The process is all about considering a wide selection of factors, asking the right questions and weighing up the answers. That is where I can provide guidance.
As I work for a vendor of embedded operating systems, my first instinct, on being asked what to do, would be: &#;Give me a call. I will help you.&#; I might be biased. In this article, I will do my very best to give a balanced view of the process and your options. Of course, if you still want to give me a call, that is fine &#;
For many embedded applications, it is obvious that an OS is needed. If the application is complex and is running on a high-end processor, it is almost certain that an OS would be beneficial. At the other end of the scale, simple software running on a low-end chip has no need of an OS at all. There are two other possibilities: complex software on a low-end CPU and simple software on a complex processor. In both these cases, it may seem that an OS would not provide much advantage and may, indeed, get in the way of efficiency. However, architecting your code around a multi-tasking model is a great way to make it scalable, thus minimizing work when, at some future point, you move to a more powerful device and/or need to add further complexity to your application.
Broadly there are three ways to obtain an embedded operating system:
Option (1) is very rarely a good choice, as it is unlikely that your specific needs are so specialized that they are not addressed by an existing product. It is unusual for &#;reinventing the wheel&#; to ever be a wise decision. The only likely exception might be writing an OS as an academic exercise to fully appreciate how such a product works.
The choice of an OS is driven by a series of questions that you might ask yourself or others. It is easy to imagine that this is all about the technicalities of an OS and, indeed, these issues dominate the process. However, commercial considerations &#; like cost &#; need to be addressed and factors like personal experience cannot be ignored.
The technical facets of an OS are dominant in the selection process. These matters need to be completely clear before other parameters are considered.
A real-time application is one where response time is of paramount importance. It may not be fast but needs to respond to an external event in a predictable (deterministic) time; it must be fast (or slow) enough. The implication on OS selection is that a real-time operating system (RTOS) is most likely to be the right choice, as it is specifically designed to accommodate the application&#;s requirements. Linux is not intrinsically real time, but real-time extensions might make it a viable option.
In the past, embedded systems often had very small memory capacities &#; maybe only a few K. Nowadays, there is a much more generous provision, though on-chip memory with microcontrollers may still be quite restrictive. Adding more memory to a system after the design is signed off is rarely straightforward. More heavyweight OSes, like Linux, are very memory hungry, so space restrictions are a real challenge. Most RTOS products are much more lightweight and are likely to be scalable, meaning that memory is only used for the functionality that is actually required.
The power of a CPU is a measure of how much work it can do &#; how many instructions it can execute &#; in a given time. Most embedded designs will have a CPU that has sufficient power, but probably none to spare. Any kind of OS is an overhead; its execution uses CPU power but does not contribute directly to the application functionality. Keeping this overhead to a minimum is generally important. The efficiency of OSes vary widely, but RTOS products tend to make the most frugal use of a CPU.
It is increasingly common for power consumption of an embedded system to be a priority. This is commonly used to preserve battery life but may also be driven by environmental considerations. Historically, power consumption was assumed to be a purely hardware issue. It is now recognized that software can contribute greatly to optimizing energy usage.
In simple terms, the smaller the code, the less memory needed and that saves power. Similarly, the efficiency of the code has implications on the necessary CPU power. An RTOS is likely to be compact and efficient.
Many systems include power management capabilities. This may be just the availability of low-power mode (like sleep and suspend), but more advanced power management is becoming common. This may include selective power-down of peripherals and control of the CPU&#;s voltage and clock frequency. Support for power management is available in Linux and in a number of RTOS products.
RoyalRay Product Page
Some of the most challenging code in an embedded application is the interface to peripheral devices. When using an OS, this is generally encapsulated in drivers. Most RTOSes are provided with drivers for a great many standard devices. Linux has even more and includes support for a lot of quite obscure hardware.
If you have custom peripherals, obviously no support will be available, so a custom driver will be needed. RTOS vendors typically provide good support in this matter. Linux driver development expertise is quite widely available.
Most higher-end embedded CPUs have an MMU, at least as an option. This permits remapping and/or protection of memory areas. An MMU is essential to deploy Linux; if no MMU is available, Linux is not an option. RTOSes generally do not need an MMU, but a number can make use of one, if it is available, by facilitating a &#;lightweight process model&#; (also called &#;thread protected mode&#;).
Some embedded applications are security conscious &#; the code must be protected from outside interference. This can be looked at as protecting each task from the actions of others. The process model, employed by Linux etc., using an MMU, is a very good way to increase security. If an RTOS can utilize an MMU, as mentioned above, this provides almost as much security with less overhead.
In a number of industries &#; like aerospace, medical, automotive and industrial &#; there are safety certification programs. The process to obtain certification is complex and expensive. Normally all the source code for the whole application is needed &#; including the OS. So, having the OS source code is essential; source code is not always available. To some extent, the size of the code to be certified influences the cost of the process, so the smaller the OS the better.
It is not generally possible to have just the OS certified &#; the whole application is assessed. However, some RTOS vendors can provide a &#;pre-certification pack,&#; which provides much of the initial documentation that is needed concerning the OS. It is also wise, of course, to select an OS that has a &#;track record&#; of being used and certified in similar application areas.
Although engineers enjoy the technical challenges of embedded software development, such projects are also subject to commercial considerations. Everything is down to money. Implementing an OS costs money, however it is obtained:
Commercial OS products are offered with various business models. For example, there may be a low starting payment and ongoing royalties on each unit shipped or there could be a larger up-front charge and no ongoing royalties. An acceptable model depends on the selling price and the projected shipping volume.
An aspect of the OS selection process that may easily be overlooked is drawing on past experience. You and your team may have used one or more OSes before and this may have a significant influence.
For example, a detailed knowledge of an OS&#;s API takes some time to acquire, so being able to reuse this knowledge is a great benefit. If the API is proprietary, this may be a strong pointer to a particular product. If the API is a standard, like POSIX, you still have a choice. Of course, a bad experience with a confusing and inflexible API may have the opposite effect!
Experience with working with a particular vendor is another factor. Was their technical support any good? Was the documentation up to scratch? Was source code available and well commented?
It is becoming increasing common to implement embedded systems using a multicore design. From the software perspective, there are two kinds of multicore systems:
With an SMP system, the selection of OS is made in the way described in this article so far, with the additional factor that the OS must support SMP functionality. Linux is available in SMP form and many RTOS products also offer it as an option.
With an AMP system, the selection of OS for each core needs to be made, using the methodology above, according to its specific requirements.
Overall, it may be seen that there is no real simple answer to the question of selecting an embedded OS. There are numerous inter-linked factors. It is essential to not just focus on technical considerations, but also consider commercial matters and past experience.
For desktop computers, there is a choice of about four operating systems. In the embedded world there are dozens, at least. Why is that? Simply put, desktop computers are all much the same, but every embedded system is different. This difference is both technical and commercial. Hence the need for the detailed selection process.
If you want to learn more, please visit our website embedded module.