Embedded Operating Systems

By: Segiy Sergienko, 2 May 2018
6 minutes

Reading Time: 6 minutes

When you choose the operating systems for your personal computer, it is unlikely that you pay it that much attention. After all, the choice is not particularly wide – Windows, macOS or Linux. If we are talking about an operating system for embedded devices, however, here the diversity can be overwhelming. Experience shows that this factor significantly complicates the decision-making.

So, if you need an embedded OS to implement your, you can start by considering the following three basic groups of OSs:

  • general purpose (Linux/Windows/macOS) and real-time (RTOS) – for high-performance hardware, comparable to desktop PCs;
  • based on a simple core – either for running complex apps on low-fi hardware or for scalable projects with high demands to performance;
  • kernel-less firmware – for simple devices of limited functionality.

Regardless of which of these groups is most appropriate for your project, there are potentially three alternative approaches to acquiring them: commercial, free and self-written.

Commercial Operating Systems

Most of the known OSs are commercial. Below we will analyze their main advantages and disadvantages

Pros:

  • developers usually have high expertise in the field of system programming (this is, in fact, a kind of quality guarantee);
  • qualified customer service;
  • simple porting to new generation devices;
  • high-quality documentation, supplied in a public electronic format;
  • an extensive list of supported peripherals and hardware;
  • useful features for creating multi-threaded programs (for example, RTOS-debugger, the ability to interrupt the work of the CPU or individual tasks, IPC, various file systems, programs for working with computer graphics, etc.).

Cons:

  • the prices for a license can vary greatly depending on the licensing model or the set of programs that are included;
  • the source code in most cases is closed; thus, app developers have no complete understanding of how their software would work under this OS;
  • binding to a specific software vendor (differences in the APIs of different operating systems make it very difficult to transfer applications between platforms, but this problem can be solved by “workarounds” – for example, through the use of the POSIX API);
  • redundancy of functionality (there may be functions in the OS that you do not need but still have to pay for).

Free (Community) Operating Systems

As a rule, most programmers prefer to use commercial operating systems due to their wider target audiences. Nevertheless, there are also completely free OSs that have quite advanced functionality and a vast range of capabilities in terms of development. Below we have collected the main pros and cons of such operating systems.

Pros:

  • no fees (although some additional features or capabilities in such systems are usually chargeable);
  • open source code (this is useful in cases where the OS is not endowed with well-structured documentation or developers need to port an existing software suite to new hardware different from that for which the OS was designed);
  • in most cases, large and active online user communities.

Cons:

  • the problem of long-term support (as we noted earlier, such operating systems usually do not have very good documentation, which means that you may have problems when adapting them to your hardware environment);
  • difficulties in developing multithreaded programs (as a rule, effective debugging tools are developed by third-party companies and are quite costly);
  • large variety of different versions (due to the open program code, various development teams can constantly introduce changes into it, thereby creating new versions and forks);
  • the difficulty of finding middleware for porting – for example, graphics editors, storage systems, etc. (in free OS they may simply be absent).

Self-created (Proprietary) Operating Systems

Sometimes developers need to create an OS with specific features (for example, when it is necessary to provide comprehensive control of the code base). Of course, writing such solutions requires appropriate skills and knowledge from the developers. Below we will examine in more detail the pros and cons of such systems.

Pros:

  • relatively cheap, provided that you have the in-house team of experienced developers;
  • full compliance with the requirements and needs of the project.

Cons:

  • problems associated with long-term technical support (this is not a problem if those who created your OS are listed in your staff);
  • redundancy of developers’ actions (in some cases it will be faster and cheaper to convert a commercial solution to the requirements of the project, rather than creating a new solution from scratch);
  • uncontrollable changes in the code (there are situations when the OS is being upgraded as the project scales, so new versions of the kernel are created, which may complicate the maintenance procedure somewhat);
  • possible additional expenses associated with the porting of middleware for the newly created OS;
  • strong “attachment” to a specific hardware platform;
  • experts with the level of knowledge sufficient to create an efficient and cost-effective OS are rare and often ask for outrageous salaries.

Choosing an Operating System

Once you make a final decision about the type of future OS (commercial, free or self-written), ask yourself a series of questions to form a clear list of requirements.

Should your applications respond to external events within established time limits? If your answer is “yes” and for your project the maximum allowed reaction delays range from zero to several microseconds, this means that you will need a real-time operating system (RTOS). In a number of cases, the renowned GPOS Linux can show great results (when the application does not need “hard” compliance with the real-time mode, that is when response delays can reach tens or hundreds of microseconds).

Are there any limitations on the amount of RAM? For embedded hardware with rather modest technical specifications, the question of memory size can be quite critical (in this case, you can immediately exclude general purpose systems).

Are there any limitations on computing power? This is also a very important issue that affects the final choice of OS. Although the vast majority of modern device manufacturers supply powerful enough processors, you may want to look closely to real-time OSes, which employ CPU resources efficiently (for example, FreeRTOS, which runs smoothly even on 8-bit Atmega controllers).

Are there any restrictions on energy consumption? The level of power consumption in modern hardware is a critical issue. Sometimes excessive heat emissions may require the installation of additional dissipation measures or even the arrangement of special premises. In addition, some devices must be operational even in the case of power supply disruptions, which means that the power consumed during active operation of the OS can directly affect the rate of backup batteries’ discharge. In most of the well-known OS (for example, in Linux and many RTOS, including Nucleus RTOS), intelligent power management systems are included by default.

How wide is the estimated base of connected peripherals? As a rule, the use of peripheral equipment is required for efficient operation of complex applications. And while devices from known vendors should not present any problems, some equipment (especially outdated or custom models) may simply not be recognized by your OS without appropriate drivers. Note that many RTOSs support a huge number of drivers, however, none of them can match the adaptability of Mentor Embedded Linux. If your equipment is completely unique, be sure to write your own drivers and APIs for it.

Does your project assume the use of memory management units (MMUs)? As practice shows, most RTOSs (namely, those based on the Threads model) have no support for MMUs. In turn, this is a mandatory component of the operating environments based on the Processes model.

Should your software comply with generally accepted security certificates? Since the procedure of approval and receipt of a certificate is not a cheap thing, the more compact the OS and all applications based on it, the less expensive this will be. That is why it is better to choose an OS built by a vendor that has a well-deserved authority in the area in which you plan to implement your project.

Do you need to ensure compatibility with the operating environment in your company? If you want to provide comprehensive support for your OS and the possibility to customize your project from any user device, commercial solutions are best suited for this purpose.

What is the estimated budget for the implementation of the OS? In some situations, a ready-made commercial OS would be much more cost-effective than creating a new one from scratch. Therefore, carefully evaluate your financial capabilities before starting to design a new OS.

What other operating systems does your team have experience with? If your developers have a lot of experience in creating applications for a specific OS, perhaps this will be the best choice for your future project.

OS Choice: Nuances of Multi-processor Systems

Now a few words about the structure of multi-core systems, which can also affect the final choice of OS. If all the CPUs in the hardware have the same technical characteristics, this structure is called homogeneous; if your system includes completely different CPUs, then the structure of the system is called heterogeneous.

In homogeneous structures, an SMP software architecture can be implemented in which the same OS uses several cores at once, evenly distributing the load. In fact, SMPs are high-performance systems. It is in this format that most of today’s RTOSs are created.

In turn, in heterogeneous structures, AMP is implemented, where each processor/core runs a separate OS image. In this case, the choice of a particular OS is made taking into account the requirements for single-core systems (after all, in fact, each core “uses” its own OS). The main thing here is organizing the principles upon which the communication between the individual cores is performed (in particular, this can be done using the Multicore Communications API).

Lastly, you should check the availability of the necessary SDKs – sometimes the lack of the tools to create the required functionality forces you to abandon an OS that otherwise seemed ideal.

Summary

In order to properly select an embedded OS, you need a rather large list of special technical skills and knowledge. If you need help in choosing and setting up an embedded OS, please contact us today and we will happily join your project.