Real time operating systems (RTOS) concepts and applications
In most of the electronics system, the operating systems used are RTOS. For understanding RTOS, it is required to know Embedded systems, Real Time systems, Need for OS in embedded and so on. Recent days the engineering projects are done on Embedded systems. So it is mandatory to know about Real time operating systems. I would like to share some of the important RTOS concepts here.
Embedded systemsThere are many definition for describing the embedded systems. One among them is
“ Customized computer hidden inside a system to perform a specific task, but not itself a computer on it’s own “. Otherwise simply it can be defined as a computer on a single chip.
What is a real-time system?
Zero Processing time
Definition
The times by which tasks will execute can be predicted deterministically on the basis of knowledge about the system’s hardware and software
Real Time Systems• As you may have noticed, most embedded components operate under real-time constraints – in industry, the terms embedded and real-time computing are used interchangeably
• The real-time computing domain is continuously expanding to support automation and vertically integrating enterprises in industry, telecommunications, public services and consumer devices
Some of the examples of Real time systems are A web server, A word processor, An audio/video media center, A microwave oven, A chess computer
Real-Time Systems can be with time constraints which can be of soft or hard• In soft real-time systems, missed responses are undesirable, but do not result in complete failure (e.g.video decoder, network switch)
• In hard real-time systems, failure to meet constraints results in complete system failure and is, therefore, an unacceptable condition (e.g. air traffic controllers,missile guidance systems or health monitoring systems where a missed response can have catastrophic consequences)
Need for OS• We have seen that we can write program code for a microcontroller to enable it to perform various control and/or monitoring functions, e.g. a washing machine control system, without any operating system
• So, what is an operating system and why would one be needed for a microcontroller system?
Operating Systems• The most basic feature, common to all operating systems, is support for multitasking, on top of this support could be added for networking, peripheral interfacing, etc. as required
• An operating system such as MS Windows has a complete graphical user interface and sophisticated functions for printing, disk handling, networking, etc.
Embedded OS
• Maybe an embedded microcontroller system does not require all of these, but it may need some of them
• The types of operating systems used in real time embedded systems, which often have only the fundamental function of support for multitasking. These operating systems may vary in size from as little as 300 bytes to 10Kb, so they are small enough to fit inside on-chip ROMs
Why Multitasking ?• Embedded systems usually have access to only one processor, which serves many input and output paths
• Any concurrency must, therefore, be simulated and logical (rather than physical)
• Real-time systems must divide time between various activities in such a way that all the time deadlines (constraints) are met
Multitasking Advantages
• Activities / events occur concurrently (simultaneously) in the real world. Through multitasking, multiple applications can be logically modeled as task activities
• Better computing resource usage as multiple task execution can be interleaved on a single processor (rather than having a separate processor dedicated to each task)
Disadvantages
• Specific task execution time and sequence is usually non-deterministic due to interleaving (complicates timing problem)
• Debugging process is complex and difficult
Real-Time OS Real-time operating systems (RTOS) will always include the following features:
• Support for multiple tasks running concurrently
• A scheduler to determine which task should run at any point
• Ability for the scheduler to preempt a running task
• Ability for external events to preempt a task
• Support for inter-task communications – synchronization and communication constructs
Real-Time OS BasicsThe OS divides time into execution units called system ticks, at every system tick the scheduler is run and it decides which task should run next. A task is allowed to run for the duration of a system tick unless it is preempted by a higher priority task or it gets suspended
Some RTOS terminology:• The term kernel is used to refer to the operating system component which provides core system functionality
• A task is an entity maintained and run by the operating system as an independent thread of execution
• There are normally multiple tasks running in a system, the kernel data structure used to monitor, control, and schedule execution of these tasks is referred to as the scheduler (or task control block)
• A task can be in any one of three states, pending, ready or running
Task Context Switching
• In multitasking systems a mechanism is needed for switching the processing context from one task to another, this is achieved by storing the currently running task’s state in kernel data and then loading the ready task’s state, thereby changing the context
• Consider a system with two task threads, A and B, when task B is running the stack pointer and program counter are set for task B’s context
• Upon a context switch to task A from task B, task B’s state, which includes the contents of the registers, program counter, and stack pointers, is saved, and that of task A is simply loaded from the task control block by the kernel
Task Preemption
• Ideally the kernel should have the ability to preempt low priority tasks with a higher priority task whenever one becomes ready (for a real-time system this is pretty much a requirement), such support is termed preemption support
• A preemptive kernel can be essential if it is necessary to absolutely guarantee the real-time response of particular tasks
Embedded System Design Considerations There is little difference between the fundamental requirements of a general purpose OS and an embedded RTOS, however, there are a number of design considerations that apply specifically to embedded systems:
• Small footprint – there is a constant demand for ever smaller devices, and devices with more intelligence, a small embedded OS must often use no more than a couple of kilobytes of RAM and ROM memory
• Life time – embedded systems may be required to run for years without manual intervention, which means that the hardware and the software should never fail
Embedded System Design Considerations
• Failsafe – many embedded systems control devices that can be dangerous if they don’t work exactly as designed, therefore, the status of these devices has to be checked regularly. The embedded computer system itself, however, is one of these critical devices, and should also be checked, hence, hardware watchdogs are often included in embedded systems
• These watchdogs are usually retriggerable monostable timers attached to the processor’s reset input, the OS checks within specified intervals whether everything is working as desired, for example by examining the contents of status registers, it then resets the watchdog
• If the OS doesn’t succeed in resetting the timer, that means that the system is not functioning properly and the timer goes off, forcing the processor to reset
• Fast recovery – If the system does fail despite its designed robustness (e.g. RAM corruption from cosmic rays), there is usually no one around to take corrective actions, hence, the system itself should reboot autonomously, in a “safe” state, and “instantly” if it is supposed to control other critical devices
• Low power – embedded systems are often required to run for a long time on batteries (e.g. mobile phones), or are part of a larger system with very limited power resources (e.g. satellites)
• Low cost – embedded systems are often produced in quantities of several thousands or even millions, decreasing the unit price by even a small amount can generate enormous savings
RTOS timing Constraints• Different applications have different timing constraints and in an ideal world any RTOS would be able to satisfy all of them
• In practice, however, this is not possible and in general the RTOS scheduling algorithms must be tailored to suit one of the following classes of time constraint:
• Deadline: a task has to be completed before a given instant in time, but when exactly the task is performed during the time interval between now and the deadline is not important (e.g. the buffer of a sound card must be refilled before it empties;the voltage on an output port must reach a given level before another peripheral device comes and reads that value)
• Zero execution time: the task must be performed in a time period that is absolutely minimized (zero in the ideal case), e.g. digital control theory assumes that taking a measurement, calculating the control action, and sending it out to a peripheral device all take place instantaneously
• Quality of Service (QoS): the task must get a fixed amount of “service” per time unit (“service” most often means “CPU time”, but could also be “memory pages”, “network bandwidth” or “disk access bandwidth”), this is important for applications such as multimedia (streaming audio or video) or network servers (e.g. in order to guarantee a minimum service level for voice over IP or other latency critical applications)
• The major problem with achieving any of these goals is that the scheduler needs complete knowledge about how long each task is going to take in the near future,and when it will become ready to run
• This information is almost impossible to get in practice, and even when it is available, calculation of the optimal scheduling plan is a search problem with high complexity, and hence high cost in time
• Different tasks compete for the same resources: processors, network, memory, etc., . . . much more than in the case of a general purpose OS
• Programmers of real-time systems have to take into account worst-case scenarios: if various tasks could be needing a service, then sooner or later they will want it at the same time
• The latency (or tardiness) of a task is the difference between the instant of time on which the task should have started (or finished) and the instant of time on which it actually did
• Latencies are due to several factors:
• the timing properties of processor, bus, memory (on-chip cache, off-chip RAM and ROM) and peripheral devices
the scheduling properties of the operating system
the preemptiveness of its kernel
the load on the system (i.e., the number of tasks that want to be scheduled concurrently), and
the context switch time (the time the processor needs to save the data of the currently running task, e.g. registers, stack, and IP, and replace it with the local data of the next scheduled task)
