Can you afford an RTOS (Real-Time Operating System) in Mass Manufacturing?

Titoma > Insights  > Can you afford an RTOS (Real-Time Operating System) in Mass Manufacturing?
Real time operating system RTOS

Can you afford an RTOS (Real-Time Operating System) in Mass Manufacturing?

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 say: “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 which 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 open-source 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

Advantages of an RTOS, 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

Advantages of using an RTOS MultitaskingMost 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 synchronising 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

Power management and 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 offers professional Security

security issues with RTOS
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 vulnerabilities are found in these functions.

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.  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

RTOS and portabilitySuppose 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

the benefits of working with RTOS

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 synchronisation 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 are not great for systems which use lot of multi-threading because of their poor thread priority.

An RTOS often uses complex algorithms to achieve a 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. 

 

Consider an RTOS especially when you need: 

  1. A quick Proof of Concept 
  2. Delegate management of multitasking,  drivers and security 
  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 multitasking

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 which 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 are 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 offers professional security
  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 this type 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 which 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 Systems 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 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 real time kernel.
  • Inter task communication is done using RTOS, not with a general purpose system.
  • Latency is a problem with general OS but it ‘s overcome using 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 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 a RTOS?

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

Is Linux a 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?

A 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 synchronisation. FreeRTOS is an example of a real time kernel RTOS.

RTOS meaning

The meaning of RTOS is Real Time Operating System

Related Posts

Case Engelen

I'm the CEO of Titoma and I've been working in electronic product development in Taiwan & China since 1994. What I've discovered is that to get to market FAST you need to take time to prevent delays. And the most important way to do that is with early supplier involvement. With us doing both Design AND Manufacturing, we save our clients time, aggravation and a quite a bit of money.If you're an established B2B company needing a Reliable Custom Device, on Time and on Target, we should talk!

No Comments

Post a Comment

Comment
Name
Email
Website

CONTACT