Sep 10, 2019

RTOS (Real-Time Operating System) is an operating system which goal is to serve operations in real-time that processes the data by switching between tasks so that multiple systems are functioning at the same time.

 

When to use RTOS?

 

You should use an RTOS when dealing with various functions, different communication interfaces and various interrupt sources.

 

Even though at the heart, RTOS is one system working in the background.

 

People use this system because:

1.  It has been proven to be dependable. 
2. It promotes team development   – as it caters in a way that means separate people able to work on different aspects of their design at the same time.
3. it uses priority-based scheduling so that the important stuff gets the focus needed,
4. it is compact. 
5. It has code reuse. Each time the code is recycled there is little to o code reuse.

 

 Learn RTOS

 

Unless you’re a highly-skilled firmware developer, it is not easy to program a microcontroller to perform at its full potential.

 

An RTOS can help you with that. It micromanages your microcontroller to take care of the nitty-gritty details like multitasking, memory allocation, input/output, and error handling.

 

And sets you free to focus on creating a really good application for your device.

 

Adopting an RTOS can shorten your development time. An RTOS can help you to prototype say a new IoT device very quickly.

 

Your firmware development team will work more cohesively because everyone will speak the same “RTOS Language”: the same coding conventions, code libraries, and firmware architecture.

 

For a quick summary please watch the following video

 

Some people say RTOS is a state of mind, as Lup Yuen Lee says: “Abandon antiquated, hardwired coding techniques… And embrace newer and more open tools and styles of coding (like Embedded Rust).”

 

But you need to trust that the RTOS will generally do the right thing for you. And in manufacturing a very important factor is always cost.

 

If you’re building a device that will be produced in serious quantities you want to optimize it for both cost and energy consumption, then an RTOS may not be for you.

Mynewt: small RTOS for IoT

 

FreeRTOS is the most popular RTOS today, supporting 35 microcontroller platforms. Seasoned embedded coders may refer to this as bloatware, as it has grown over time. 

Luckily these days there are many nimbler, modular open-source RTOS including Zephyr and Apache Mynewt. There are many other open-source and commercial RTOS available. (list of all RTOS’s available)

Advantages of using an RTOS

1. RTOS already has Drivers

In a modern RTOS, you will find a collection of drivers bundled with the RTOS.

 

You can use these drivers to connect popular sensors like the Bosch BME280 Humidity, Pressure, Temperature Sensor, or something like the ESP8266 wifi module.

 

Coding a driver for say a display from scratch yourself can be a lot of work, and if your RTOS happens to have this driver ready to go, you can quicken the time to market for your device.

 

Some RTOS have Sensor Frameworks that will make sensor programming really simple.  With a Sensor Framework, you only need a few lines of code to do this: “Look for the BME280 sensor, schedule the sensor to be polled every 10 seconds, and call my function with the sensor data”.

 

Here’s a tip: Even if you’re not using an RTOS, you can use its drivers! Apache Mynewt didn’t have a driver for the ESP8266 WiFi module, so we ported the open-source driver from another RTOS (Arm Mbed OS) and it worked beautifully.

 

So if you ever get stuck, consider borrowing bits of code from an open-source RTOS that works! 

2. Multitasking in RTOS

 

Most devices will need some form of multitasking, like reading a sensor while transmitting the data over a network (Bluetooth, WiFi, NB-IoT LoRa, …).

 

An RTOS lets you specify the priority of each task and schedule them accordingly, making the best use of the available CPU processing time.

 

An RTOS provides features for synchronizing the concurrent tasks, such as Semaphores (for locking access to shared resources) and Message Queues (for passing information between tasks).

 

Some patterns of multitasking may preclude the use of RTOS. For example, if all tasks on your device are high priority and you need precise rules to decide which task to run next. 

 

Or when you absolutely need to operate the CPU at 100% capacity. If you’re an experienced developer, coding on Bare Metal with Coroutines would be a better solution. (And if you haven’t heard of Coroutines… then you really should use an RTOS!)

3. Power management implementation in RTOS

 

Is your device required to run for extended periods of time on battery power?

 

Pick an RTOS that supports Deep Sleep Mode.  Deep Sleep programming on microcontrollers is tedious and error-prone because we need to configure the Real-Time Clock to wake our device at the right time.

 

A mistake in the firmware programming could cause your device to wake up too soon, thus wasting battery power. Or not waking up at all!

 

On the other hand, if you’re an experienced firmware programmer, coding your own Power Management functions on Bare Metal allows you to squeeze the very last mAh from your battery.

4. RTOS Solves Security Issues

Writing secure code is hard… so better leave that to the professionals.

 

An RTOS contains cryptographic functions, network stacks (like TCP/IP), and firmware distribution methods that have been reviewed by professionals.

 

When you program your device firmware with these peer-reviewed functions, you can be sure that your firmware is safe from attacks.  And you’ll get timely alerts when any security issues are found in these functions.

 

Coding these functions yourself is risky. 

 

Unless you have security experts in your team, you may inadvertently create security issues and make your firmware vulnerable to attacks. 

 

If you decide not to use an RTOS, then we really recommend using a trusted security library instead of coding it yourself.

5. RTOS allows MCU Portability

 

Suppose you design your device for an STM32 Arm microcontroller today.  What if you need to switch to a Nordic nRF MCU? Or even a RISC-V microcontroller?

 

The RTOS offers a unified programming interface for the microcontroller hardware.

 

When you code your firmware with these functions, the firmware source code may be recompiled to run on various microcontrollers like STM32, Nordic nRF, RISC-V, …

 

The RTOS in a sense functions as a Hardware Abstraction Layer (HAL) between your program and the electronic hardware.

 

For some products, it may be worth it to adopt an RTOS to prevent being locked-in to a specific microcontroller platform, but it likely will cost extra resources such as ROM, RAM, and CPU power.

6. RTOS Enforces Standards across teams

 

When you adopt an RTOS, it enforces a common development standard across the project.

 

Developers who code the device firmware will all use the same libraries provided by the RTOS, the same drivers, the same task synchronization primitives, …

 

For large projects, with many coders, perhaps even from different firmware design firms,  this ensures that all vendors will follow the same standard for coding your device firmware.

 

Without an RTOS, you would have to define your own coding guidelines, your own base libraries, your conventions for multitasking, memory allocation, and so on.

 

This increases the time to create the first version of the device firmware.

7. RTOS speeds up Proof Of Concepts (PoC) 

Out of the box, a modern RTOS provides a fast way to create a multitasking device that supports various microcontrollers, sensors, and networks.

 

Why not take advantage of this and use this to quickly build a Proof of Concept for the new IOT device that your company is considering to deploy? 

 

Discover new ways of solving problems by mixing and matching different sensors: motion, sound, light, touch, … Explore ways to reduce power consumption by switching networks: Bluetooth, ZigBee, WiFi, NB-IoT, Sigfox, LoRa, …

RTOS Downside 1

 

Even FreeRTOS does not come free

 

An RTOS requires RAM to keep track of its operational state. It also requires Flash ROM space for the RTOS code, and it needs CPU power to run it.

 

Here’s a peek into an STM32 Blue Pill development board with 20 KB RAM and 64 KB ROM.  Even a modular, lightweight RTOS (Apache Mynewt) still occupies 9 KB of RAM and 22 KB of ROM. 

 

That’s nearly half of Blue Pill’s RAM and one-third of Blue Pill’s ROM.

 

This may well mean that the RTOS forces you to use a higher-end MCU than without it. This increases the unit cost , and every dollar is important when you realize many electronic devices retail at 3 times BOM cost. 

 

The energy needed to run the RTOS also means that battery life will be reduced. 

 

So if you want a fully optimized device it is still better to code with Bare Metal 

RTOS Downside 2

 

Less Control & Visibility

 

An RTOS allows can make you more productive by using higher abstraction, but this also means you have less control over the details.

 

You need to trust that the RTOS will generally do the right thing for you, and for that, you need to be thoroughly familiar with it, which takes quite some time in itself. 

 

RTOS is not great for systems that use a lot of multi-threading because of their poor thread priority.

 

An RTOS often uses complex algorithms to achieve the desired output, making it difficult to sometimes very hard to debug.  

Conclusion

 

Microcontrollers are complex beasts that can be tamed by an RTOS, and if you are prepared to invest the time to fully learn and understand the RTOS, an  RTOS allows you to write simpler firmware code that will exploit all the capabilities that the microcontroller can provide. 

 

But serious engineers traditionally see RTOS’s such as FreeRTOS as bloatware: with the extra RAM, ROM, and CPU power it needs you are forced to use a higher grade, more expensive MCU, and a larger battery.

 

There are now RTOS’s which are much smaller and modular. With and with higher-powered MCU’s such as STM32 very affordable you may well have the headroom needed to afford an RTOS without any extra cost. 

 

When to use RTOS?

 

Consider to use RTOS when you need 

 

1. A quick Proof of Concept 
2. Delegate management of multitasking,  drivers, and security issues.
3. Portability between microcontroller platforms 
4. Standardization across different coders 

 

In all these cases it can be well worth it to consider a modern RTOS such as Zephyr or Mynewt or even good old FreeRTOS.   

 

Despite this, at Titoma we still prefer direct access and full control: “see the bits”. And more importantly: Cost.

 

Whenever there is a serious manufacturing forecast, most of our clients would rather not pay an extra $2 for a higher spec MCU, 50,000 times over.

RTOS FAQ

What is the difference between RTOS and HAL (Hardware Abstraction Layer)?

 

The HAL (Hardware Abstraction Layer) sits between the low-level drivers and provides a common interface for common firmware stacks such as an RTOS and middleware components like USB, ethernet, and file systems.

 

The HAL can act as a wrapper for providing a common interface between existing drivers and higher-level code or it can exist as the driver interface itself.

 

What is an embedded RTOS?

 

An embedded RTOS can be used when writing firmware for an embedded system such as smart home security systems, ATM machines, and air conditioners.

 

It generally makes life easier for the firmware writer by providing the following functions:

1. RTOS has built-in Sensor and Network Drivers
2. RTOS manages Multitasking
3. RTOS implements power management
4. RTOS offers professional security
5. RTOS allows MCU portability
6. RTOS enforces standards across teams
7. RTOS speeds up Proof of Concept (PoC)

 

Why is RTOS used in embedded systems?

 

RTOS (Real-Time Operating Systems) offers quite a number of advantages:

1. RTOS has built-in Sensor and Network Drivers

 

The drawback however is that to run the RTOS more computing power, and memory are needed, which may force you to use a more expensive microcontroller. 

 

2. RTOS offers to multitask

 

But if you’re an experienced developer, coding on Bare Metal with coroutines would be a better solution.

 

3. RTOS implements power management

 

However,  if you’re an experienced firmware programmer, coding your own Power Management functions on Bare Metal allows you to squeeze the very last mAh from your battery.

 

4. RTOS offers professional security

 

Coding these functions yourself is risky.  Unless you have security experts in your team, you may inadvertently create security holes and make your firmware vulnerable to attacks.

 

5. RTOS allows MCU portability

 

For some products, it may be worth it to adopt an RTOS to prevent being locked-in to a specific microcontroller platform.

 

6. RTOS enforces standards across teams

 

For large projects, with many coders, perhaps even from different firmware design firms,  this ensures that all vendors will follow the same standard for coding your device firmware.

 

7. RTOS speeds up proof of concept

 

Discover new ways of solving problems by mixing and matching different sensors: motion, sound, light, touch, …

 

Why is RTOS required?

 

An RTOS is NOT required for every embedded system, in fact, most products that are mass manufactured do not use an RTOS because of the extra cost which can be associated with the ROM, RAM, and calculating time needed to run it.

 

RTOS is useful for the following 7 reasons:

1. RTOS has built-in Sensor and Network Drivers
2. RTOS manages Multitasking
3. RTOS implements power management
4. RTOS security issues are low
5. RTOS allows MCU portability
6. RTOS enforces standards across teams
7. RTOS speeds up Proof of Concept (PoC)

 

Where are RTOS used?

 

An RTOS is most commonly used in embedded devices, such as IoT devices such as connected sensors, access control devices, washing machines, and automated pet feeders. 

 

It can also apply to highly sophisticated military devices, medical, and data communications systems (among others).

 

Examples of real-time operating systems include Air Traffic Control Systems, Networked Multimedia Systems, Command Control Systems.

 

What is the difference between OS and RTOS?

 

OS stands for a very generic Operating System that can be used for all sorts of electronic devices, but mainly in computers and smartphones.

 

Windows, Linux, and Android are well-known examples. The difference between OS and  RTOS is that a Real-Time Operating system is normally only used for Embedded Systems. 

 

• General-purpose operating systems don’t perform real-time tasks, RTOS is more suitable for real-time applications.

 

• There’s a deadline associated with real-time kernel but a general-purpose operating system doesn’t follow timely mechanism.

 

• The real-time kernel follows a preemptive scheduling policy, a general operating system follows non-preemptive scheduling techniques.

 

• Synchronization is a problem with general operating systems OS whereas synchronization is achieved in the real-time kernel.

 

• Inter task communication is done using RTOS, not with a general-purpose system.

 

• Latency is a problem with the general OS but it‘s overcome using the real-time OS.

 

• Priority inversion can’t be done in GPOS, it’s done with real-time kernel.

 

 

What is an example of a real time operating system?

 

The most common example of a real-time operating system (RTOS) is FreeRTOS, there are also many others such as:

• VxWorks
• QNX
• eCos
• RTLinux
•  Zephyr 
• Apache Mynewt. 

 

VxWorks has a long history in critical applications – for example, in cars and various NASA space platforms. VxWorks is however not open-source software.

 

You can find a complete list of all RTOS’s available here.

 

Is Android an RTOS?

 

Android is an operating system for smartphones, while RTOS (Real-Time Operating System) is used only on embedded systems that run on microprocessors such as STM32, generally not as fast as the processors used in smartphones.

 

Therefore Android is not an RTOS.

 

Is Linux an RTOS?

 

The stock Linux kernel is not an RTOS.  RTOS is only suitable for certain (mostly embedded) systems, like cars, plant management, network equipment, military systems, and such, not really suitable for a desktop.

 

What is Kernel RTOS?

 

An RTOS Real-Time Operating System can provide many resources to application coders – including TCP/IP stacks, files systems, etc.

 

The Kernel RTOS is the part of the operating system that is responsible for task management, and intertask communication and synchronization. FreeRTOS is an example of a real-time kernel RTOS.

 

RTOS meaning