Unless you’re a highly-skilled firmware developer, it is not easy to program a microcontroller to perform at its full potential. An RTOS ( Real Time Operating System ) 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
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 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
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
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
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 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:
- A quick Proof of Concept
- Delegate management of multitasking, drivers and security
- Portability between microcontroller platforms
- 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.
