TROS – Build your own Tiny Real Time OS/Scheduler (TROS)

Part-1: Introduction to Real Time OS (RTOS) 

Embedded Systems are Electro-Mechanical/Chemical systems usually tightly coupled with its environment responding to real time events. The system itself operates under a relatively complex software on limited power and resources with quite predictable execution pattern.

It all started in early 1960 when Apollo Guidance computer (AGC) was built and used by Apollo Mission astronauts to collect flight information. The Apollo guidance system is considered as the first modern Embedded System. Since then Embedded systems have really catched phase in terms of complexity and power (capable of performing complex tasks).

The more complex jobs a system (Embedded System) has to perform the more complex its software becomes and subsequently the more complex a software becomes the more difficult it becomes to Develop, Manage, Maintain, Test and document especially when a team of remote developers are working on Software. As the software gets more and more complex, keeping it flexible for additional features and producing desired response/results becomes difficult under SUPER LOOP modal. For more complex software it is highly desirable to use an OS or RTOS in case of Embedded Systems.

The use of an OS/RTOS inherits few advantages.

• More Abstraction
• Modularity
• Maintainability
• Tech Support
• Easy Testing
• ... and so on

What is a Real time OS?

Majority of newbies into the world of RTOS think of real time system as “Being Fast”. No its not, its PREDICTABLE. Infect the term real-time-OS can be split into the following two parts.

So an RTOS is a piece of software that includes Operating Systems features like abstraction etc. AND whose response/behavior is predictable / expected.

It has nothing to do with being fast or slow. Speed is a relative term usually to application under consideration. For some applications response within 1-usec is Real-time for other it may be 1sec. So its always relative. In general RTOS is a piece of software that provides a base for your application and produces predictable response to real time events.

Difference between an RTOS and GPOS:

There are two main areas on the basis of which a real-time OS can be differentiated from a General purpose OS.

1. Throughput
2. Predictable Response

Throughput: Throughput means the number of tasks performed per unit time. While General purpose OS (GPOS) is designed to produce high throughput, a real-time OS (RTOS) is designed under the mantra of "Most Important Deadline First". What this means is that in GPOS's, if there are 10 pending tasks and one of them is high priority while the other 9 are low priority tasks and combine the 9 low priority tasks take less time to complete than the single high priority task; then the GPOS will execute the 9 low priority tasks first to produce high throughput while the RTOS is certain to execute the most important tasks first leaving low priority tasks for later execution.

Predictable Response: Embedded Systems normally face very harsh environment coupled with some strict time deadlines. One of the core property of a real-time OS is its predictable response. While using a real time OS, the response within the desired time slot is not promised, RTOS's are pretty much desired to do the opposite e.g. A real time OS must respond to an accident and open the airbag before the driver gets injured. GPOS on the other hand doesn't have such restrictions or promises such response.

Types of a Real Time Application:

Based on the type of application, a real time system can be classified into one of the following types.

Hard Real Time Systems: Hard real time systems are ones that have some very strict time deadlines to meet. Fail to meet the deadline and the system is a total disaster. Example of such type of systems are airbag system and ABS (anti-locking break system) in automotive. i.e. If the airbag doesn’t open during short interval of accident, the system is useless.

Firm Real Time Systems: The firm real time system is one that do have deadlines to meet but if the deadline is missed the RESULTS are useless and the system is not considered a failure. In other words, the results must be generated within a specified time interval otherwise the RESULTS are no more useful. Example is VIOP/Video call. Video contains frames that are transmitted over the network. If a frame reaches passed the desired time, it is simply discarded rather than playing the late frame during the video call. In such type of systems missing a deadlines degrades system performance but the overall system is not considered as a total disaster.

Software Real Time Systems: In soft real time systems missing a deadline is not an issue though undesirable. The main difference between a firm real time system and a soft real time system is that in firm real time system the results produced after the deadline are simply discarded while in the case of soft real time systems the results are not discarded and used even after the deadlines. For example while typing in computer, the usual expected time (user experience) to display the typed character is within 300-msec but sometimes if the system is too busy, the typed characters are stored and displayed to the user after some time delay. Thought the deadline is missed still the results are not discarded and used after the deadline.

Commonly used Real Time OS:

Few of the most extensively used RTOS (commercial, free) in the market are given bellow. The list is quite lengthy [1].

• Nucleus RTOS by Mentor Graphics
• VxWorks by windriver
• ThreadX
• and off-course the legendary (Amazon)-FreeRTOS (which is absolutely free)
• ... [1]

Goals of this Tutorial Series: 

Most of the newbies find it difficult to understand whats happening inside the RTOS Kernel. For them it’s a complete black box and when EXAGGERATED considered very difficult to understand.... or labelled as "don’t touch it". This and the subsequent series of articles are for those who wants to find out how deep the rabbit hole goes. 

The goal of this tutorial series is in no way to indicate that in-house developed RTOS's are better than commercial ones or freely available ones (Personally I am pretty much fan of already available RTOS's out in the market [1]). It may be true when seen from application specific point of view but the main goal is to give you a deeper overview of how an RTOS works internally.

This and the subsequent tutorial in series will cover the following dimensions.

• Introduction to RTOS
• RTOS unit-functions or Tasks
• An overview of RTOS scheduler and Porting
• Dynamic Memory
• Test Application

Platform Used:

As we will advance with the tutorial series you will know that some parts of OS/RTOS are indeed both architecture and application independent but there are few underlying pieces of codes/portions that are specific to the architecture (called PORT) on which the RTOS runs. For the purpose of this tutorial series, we will use the WELL known and common platform i.e. ARM (Cortex-M in specific) though the concepts can be easily extended to any RISC architecture.

Stay tuned see you in the next part of the series....

cntd ...

References:

[1] Comparison of real-time operating systems

[2] Mentor Nucleus RTOS

[3] WindRiver VxWorks

[4] Amazon FreeRTOS

[5] Heading Picture