A summary of three articles on how to choose an RTOS

### [How To Choose The Best RTOS for IoT Devices](https://www.nabto.com/how-to-choose-best-rtos-for-iot/)

### [How to pick an RTOS](https://www.embeddedcomputing.com/technology/software-and-os/how-to-pick-an-rtos)

### [7 Characteristics to Consider when Selecting an RTOS](https://www.beningo.com/7-characteristics-to-consider-when-selecting-an-rtos/)

# How To Choose The Best RTOS for IoT Devices

## Key Points to Consider when choosing an RTOS

The key points when chosing an rtos according to this article are the following

- Performance
- Scalability
- GUI
- Connectivity
- Modularity
- Security
- Ecosystem

### Performance

According to this article, performance means choosing an RTOS that suits your needs in terms of memory- and processing footprint requirements.

### Scalability

Which architectures does the RTOS support? Scalability refers to different CPU architectures.

### Graphical User Interface

Do your application need a GUI, and in that case, does it need advanced gui concepts such as 3D rendering and multi-layer interfaces?

### Connectivity

Here we refer to communication protocols. For our purpose, suppose the most important is CAN, Ethernet maybe BLE? Zephyr seems to support them all.

### Modularity

How much work is done around the kernel. Or in other words, how much is laid on top of the kernel. For GPOS's this is often alot, and adds to footprint and complexity.

### Security

What security requirements does your system have? All RTOS's support some sort of security add-ons, but its up to the developer to make sure that the security of their system is met. For example secure boot, SSL and encryption drivers.

### Ecosystem

How well documated is the RTOS? is there support available, and how much of it? Community, open source etc.

## Popular open source RTOS for IOT

The article lastly provides us with a list of some popular open source RTOS's for IOT.

- RIOT
- NANO-RK
- FreeRTOS
- Apache Mynewt
- ARM mbed OS
- Raspbian
- DuinOS
- mipOS
- RT-Thread
- uOS
- Lepton
- (Zephyr)

# How to pick an RTOS

## Introduction

This article starts off by giving a brief introduction to some key-points and how implementations are often chosen for applications.
The author also refers to "kernels" as "RTOSs", which might be a little bit confusing.

Further on he starts discussing some key points

- RAM use
- ROM use
- Performance
- Debug features and error management
- Three-dimensional problem
- Picking a candidate
- Getting started
- Pros of this strategy

### RAM use

According to this article, the main RAM use for an RTOS is for the task stacks.

> If the RTOS doesn’t provide a system stack for interrupts, then each task’s stack must be large enough to handle the total ISR stack requirement. If interrupt nesting is permitted, worst-case ISR stack loading can add hundreds of bytes to each task’s stack. If there are around 20 tasks, this could easily add up to an additional 5 to 10 KB of RAM. Simple RTOSs usually have this problem. Some RTOSs even allow sharing stacks between tasks.

### ROM use

Here he describes how sometimes a simple RTOS may require more RAM and ROM than an advanced RTOS. This is the result of linkers leaving out unused RTOS functions. This in turn means, certain functionality has to be implemented in the application code which in turn cost more.

### Performance

Once again, make sure the performance for your application is met. According to this article a well written RTOS can achieve up against 50k task switches per second on a low-end 50MHz Cortex-M3 processor. He also states that with the technology moving forward, the figure of merits have swapped slightly from raw performance to instead being more utility focused.

### Debug features and error management

According to the article, if you want to keep your sanity whilst developing RTOS applications, you should pay attention to the fact that most simple RTOSs provides no more help than the C lib "zilch"

### Three-dimensional problem

The holy trinity of RTOSs, size, performance and features. The writer states that these three characteristics makes up the embedded space where the system will reside. On top of the holy trinity lies the holy grail of RTOSs, license and price.

#### Getting Started

Here he describes what he thinks to be the best way when starting from scratch. He suggests searching different vendors and making sure there are EVK's available. He thens suggests creating a block diagram for your application with blocks containing things such as threads and ISRs.

Things that may not be interesting for us.

# 7 Characteristics to consider when selecting and RTOS

This article aswell as the first, jumps straight to some of the main characteristics to look for in an RTOS.

- Performance
- Features
- COst
- Ecosystem
- Middleware
- Vendor
- Engineering Team

### Performance

This article states that not all RTOSs are created equal. He also suggests that things such as memory footprint requirements (RAM, ROM, flash) needs to be considered. He then mentions that processing speed such as sinterrupt latency and contect switching should be taken into consideration. He also mentions that a "good" RTOS should have these things documated for variety of architectures and clock speeds.

### Features

It is up to the developer to make sure that the most critical features of their system are supported by the RTOS they choose and that they are implemented in an efficient manner. Certain keypoints could be

- scalability
- safety certifications
- memory protection schemes

Another aspect, that is often forgotten is the ability to apply standard API's such as POSIX.

If the embedded system has alot of constraints, one would also has to be taken dynamic memory allocation into consideration. Most high-end RTOSs uses dynamic memory allocation for their tasks.

### Cost

This article also covers costs as an important characteristic. Cost usally only becomes an issue if you decide to go with a commercial RTOS. But can also be a consideration when discussing the complexity of the RTOS. If the RTOS is complex enough, alot of cost will go into learning the RTOS itself.

### Ecosystem

Once again. Is there an Ecosystem inform of a community of some sort, that makes the RTOS easier to integrate into your embedded application?

This aswell as determining if the RTOS is a "one trick pony" or if it supports multiple architectures and processors.

### Middleware

Middleware is defined as components integrated into the RTOS developed by third parties.

This could be communication protocols such as USB, TCP/IP, filesystems and graphic generators.

### Vendor

How well documented is the vendor? For example, how easily read is the source code, and the APIs? also how easy is it to get answers from the vendor when asking technical questions?

### Engineering Team

A key aspect but most often looked over according to the Article. Here he says that when choosing an RTOS we should use one that the engineers have previous knowledge of, or atleast is similar to one.

## Conclusions of the three articles.

All three articles covers Performance as one of- if not the most important aspect when chosing an RTOS. Perfomance can be brought down to two important key aspects. Memory footprint and context switching speed.

Scalability also seems to be important. Scalability can refer to two different things. One is the option to port the RTOS to different CPUs and architectures. The other is the possibility to scale down the kernel in order to optimize the footprint and speed of the RTOS.

Connectivity and middleware most definitely plays a huge roll when choosing an RTOS. Here we refer to communication protocls for the most part, and for this thesis, I believe that support for CAN, Ethernet and BLE is important.

Vendor and Ecosystem is another important part for chosing the correct RTOS. Make sure that the RTOS has a broad community and that the vendor is filled.

Security should also be looked upon, to the RTOS have the security features needed.

Lastly not covered in the articles, virtualization extensions has to be taken into consideration. Does the RTOS support virtualization, and more important, virtualization with Xen Hypervisor?

I believe that we can make a good case for Zephyr for all of these.