Over the past few decades, software and hardware solutions for solar tracking & harvesting systems, battery management systems for enterprises and electric vehicles, Body Control Modules and Motor Control Solutions, have witnessed a steady shift in complexity of the application layer.
In this era of connected cars and Industry 4.0 automation, software and hardware solutions are expected to efficiently support features that are driven by real-time data.
This requires context-switching, at the speed akin to the blink of an eye.
For such applications, it is necessary to design software and hardware solutions that execute each functionality as a pre-defined task as per the assigned priority.
In order to achieve these objectives, an advanced level of multithreading has become the need of the hour. And the only architecture that can deliver such performance within the strictest of time boundaries is a Real Time Operating System or popularly known as RTOS.
Embedded Systems (like Solar Tracking Platforms, Body Control Modules, HVAC Systems, BMS in Electric Vehicles) have design limitations in terms of power, system clock-time, and memory footprints.
While General Purpose Operating Systems (GPOS) can handle multiple tasks efficiently, they usually do so without the pressure of time running out.
RTOS on the other hand is designed to deliver an accurate output within the expected timeline (which as stated earlier, is akin to the time taken for the blink of an eye).
In the rarest of instances of an RTOS delaying response, catastrophic events may occur. Hence, in an embedded system, an RTOS shoulders a highly critical responsibility.
Let’s delve a little deeper and try to explore this time-critical operating system a bit more.
Understanding the Basics of Real Time Operating System (RTOS)
An embedded RTOS is a high-performance, cause-and-effect driven operating system that’s perfectly suited for real-time embedded system applications.
RTOS is specifically required for applications which have time-critical requirements and need to respond instantly. It is used in systems where multiple operations are being executed at the same time and resources are being shared.
Usually, an RTOS has small memory footprints and hence can easily be integrated into a microcontroller (MCU) platform.
In the language of computer architecture, a Multithreading defines the ability of a processing unit to manage multiple threads concurrently. This approach helps in ensuring efficient
sharing and utilization of the computing resources by these concurrently executing threads.
At its best, an embedded RTOS creates an illusion of parallel execution by rapidly switching between the executing tasks. It enables you to inculcate a new level of abstraction into applications which paves the way for more complexity to be built into them.
It gives the product development teams complete control over multithreading, thus enabling deterministic real-time behavior.
Traditionally, in case of complex applications, development teams relied on custom states and logic for successful execution of the control mechanism.
However, as the complexity of electronic systems increased manifold, this became more error-prone and difficult to maintain.
With RTOS programming, the execution of control is now delegated to a highly optimized RTOS Kernel.
RTOS (Real Time Operating Systems ) v/s GPOS (General Purpose Operating Systems)
All tasks within an embedded RTOS have specific timelines associated with them. However, tasks within a GPOS aren’t bound by a timing mechanism. Let’s try to understand the difference with an example.
If you need to copy some data from one PC (Personal Computer) to another, a GPOS may take several minutes to do so. It might complete the procedure without glitches or may even hang during it since several tasks are being executed in parallel.
An embedded RTOS doesn’t enjoy this kind of liberty. Tasks must be completed within the strict deadlines and in parallel, in order for the system to honor the SLA.
For example, in an automatic air-bag control system, as soon as the vehicle senses a sharp jerk, the air-bags should be activated without the delay of even a second. This is because even a milli-second of delay can lead to a serious injury for the driver.
Image 2: RTOS vs GPOS: Comparison chart; Source: ami.com
Evaluating and Selecting an RTOS for an Embedded Product Development
While evaluating an embedded RTOS that can perfectly fulfill the business and technology requirements of an embedded application, your team should ensure that the RTOS in considerations supports a set of critical features.
Let us have a quick look at these features:
- Schedulers – Operating system schedulers are responsible for deciding which task should be executed at which time. They can suspend any task and resume it later, depending on availability of resources and priority. An embedded RTOS should have a scheduler built into it, which will enable it to perform real-time execution of the tasks.
- Software Timers – A software timer allows a function to be executed within a set time-window. Manually creating software timers within an RTOS can become very complex and error-prone . Hence, it is always advisable to select an RTOS with in-built software timer functionality.
- Queuing Mechanism – Queues are software mechanisms for exchanging information between tasks. In other words, queues facilitate smooth inter-task communication, or between tasks and interrupts. With queues built into an RTOS, different tasks will be able to exchange messages with each other
- Execution Trace Tools – To fully understand the runtime behavior of an RTOS based system, you need the ability to observe its real-time behavior at the RTOS level. This can be achieved with the help of a tracing tool. If an RTOS has execution trace tools built into it, development teams can track the execution of tasks and detect discrepancies if any.
- Low Memory Footprint – Since an RTOS needs to be integrated into a MCU platform, it should have a very low memory footprint. That is to say that its total size should not be in excess of 10 percent of the total size of the MCU.In addition to having the above-mentioned features, an embedded RTOS should be compatible with the target MCU architecture.
How to Port an RTOS Kernel to a Target MCU Platform
Once you’ve selected an ideal embedded RTOS for your desired embedded system, the next phase involves accurately porting an RTOS kernel into the target MCU platform.
The procedure involves several steps that should be carried out with care in order to make the system function smoothly. Let us look at the key steps involved in the successful embedded RTOS kernel porting onto target MCU architecture.
- Checking whether the RTOS is compatible with the MCUAs a developer, one must ascertain if the selected RTOS is compatible with your target MCU. This step often involves interfacing the required interrupts to the right ports and conducting rigorous integration tests to verify that everything is working together perfectly.
If any missing links are found, you might need to either switch to a different RTOS kernel or use some kind of middleware to ensure compatibility.
- Ensuring that the IDE supports the features of RTOSIn order to develop embedded systems with optimal performance, developers need comprehensive Integrated Development Environment (IDE) and a compatible RTOS. But selecting the two is only a part of the process. They need to make sure that both the IDE and RTOS are compatible with each other. In addition to selecting an RTOS, you need to choose an IDE which supports the features included in the particular embedded RTOS.
- Configuring the RTOS Kernel image based on the target microcontroller specificationsIf the selected RTOS is compatible with the target MCU and the chosen IDE, the RTOS kernel must next be configured according to the MCU’s specifications. This will ensure that once the system starts working, data and information exchange happens without glitches.
- Device Driver DevelopmentOnce all compatibility checks and required configurations have been done, the appropriate device drivers need to be developed for the target system.
- Connecting the BSP layer with the RTOS layerBSP or Board Support Package is a layer of software containing hardware specific drivers and routines which allows an RTOS kernel to access the resources of the specific hardware system. After driver development, one needs to interface the BSP layer with the RTOS kernel layer.
- End-to-end application developmentNow that all the conditions and pre-requisites for building a fully-functional embedded system with RTOS as the core is met. The next step is development of full-fledged embedded application.
- Debugging the applicationAnd finally, once the embedded application development is complete, you can progress to debugging the application using set of debugging tools.
For a detailed monitoring of the run-time behavior and performance of the RTOS based embedded system, as mentioned in the above section, developers prefer execution tracing tools during debugging. These tracing tools help in recording detailed execution events within the RTOS kernel and quick identification of any bugs/anomalies therein.
A Few Final Thoughts
As the market expectations for real-time responsiveness from modern embedded systems show a steep increase , usage of an RTOS as become more than a necessity than a desirable option.
In addition to real-time responsiveness, an RTOS powers such embedded systems with several advantages like low-memory footprint, deterministic task handling, optimal resource usage, and extensive multithreading capabilities.
In the era of connected systems brought in with the evolution of Internet of things that demand on-time response clubbed with optimal resource utilization, it won’t be wrong to say that the RTOS based systems are here to say!
