A system can be of a single purpose or multiple purpose. Here an ATM card user is supposed to get his money from the teller machine within 4 or 5 seconds from the moment he press the confirmation button. The card user will not wait 5 minutes at the ATM after he pressed the confirm button. So an ATM is a time critical system.
|Published (Last):||19 August 2011|
|PDF File Size:||11.42 Mb|
|ePub File Size:||13.58 Mb|
|Price:||Free* [*Free Regsitration Required]|
It is software that manages computer hardware and software resources and provides common services for computer programs. The operating system is an essential component of the system software in a computer system. Application programs usually require an operating system to function.
An operating system OS is software that manages computer hardware and software resources and provides common services for computer programs. Operating systems offer a number of services to application programs and users.
Applications access the services through application programming interfaces APIs or system calls. By invoking these interfaces, the application can request a service from the operating system, pass parameters, and receive the results of the operation.
Modern operating systems provide the capability of running multiple application programs simultaneously, which is referred to as multiprogramming. Each program running is represented by a process in the operating system. The operating system provides an execution environment for each process by sharing the hardware resources so that each application does not need to be aware of the execution of other processes. The central processing unit CPU of the computer can be used by only one program at a time.
What is an RTOS? A real-time operating system RTOS is an operating system that guarantees a certain capability within a specified time constraint. For example, an operating system might be designed to ensure that a certain object was available for a robot on an assembly line.
Some real-time operating systems are created for a special application and others are more general purpose. Some existing general purpose operating systems claim to be a real-time operating systems. Processing time requirements including any OS delay are measured in tenths of seconds or shorter. A hard real-time operating system has less jitter than a soft real-time operating system. The chief design goal is not high throughput, but rather a guarantee of a soft or hard performance category.
An RTOS that can usually or generally meet a deadline is a soft real-time OS, but if it can meet a deadline deterministically it is a hard real-time OS. An RTOS has an advanced algorithm for scheduling. Scheduler flexibility enables a wider, computer-system orchestration of process priorities, but a real-time OS is more frequently dedicated to a narrow set of applications. Key factors in a real-time OS are minimal interrupt latency and minimal thread switching latency; a real-time OS is valued more for how quickly or how predictably it can respond than for the amount of work it can perform in a given period of time.
Most operating systems appear to allow multiple programs to execute at the same time. This is called multi-tasking. In reality, each processor core can only be running a single thread of execution at any given point in time. A part of the operating system called the scheduler is responsible for deciding which program to run when, and provides the illusion of simultaneous execution by rapidly switching between each program.
The type of an operating system is defined by how the scheduler decides which program to run when. For example, the scheduler used in a multi user operating system such as Unix will ensure each user gets a fair amount of the processing time. As another example, the scheduler in a desk top operating system such as Windows will try and ensure the computer remains responsive to its user. This is particularly of interest to embedded systems as embedded systems often have real time requirements.
A real time requirements is one that specifies that the embedded system must respond to a certain event within a strictly defined time the deadline. Traditional real time schedulers, such as the scheduler used in FreeRTOS, achieve determinism by allowing the user to assign a priority to each thread of execution. The scheduler then uses the priority to know which thread of execution to run next. Real-time operating systems are often required in small embedded operating systems that are packaged as part of micro devices.
Some kernels can be considered to meet the requirements of a real-time operating system. However, since other components, such as device drivers, are also usually needed for a particular solution, a real-time operating system is usually larger than just the kernel. Before going deep down, it will be good if you read this article from Howstuffworks- about Operating Systems. Are ROTSs really fast? Many Embedded interviewer ask this question. Well, never use these words. More appropriate answer would be ROTS are deterministic.
RTOS guarantee you that particular operation would complete at the worst this much time. This is the very basic criteria of being a RTOS. Its all about money, if you can save even 25 cents on one embedded device hardware, and embedded devices are sold in millions of units say memory card Companies can make millions of dollars An RTOS is usually designed for a low end, stand alone device like an ATM, Vending machines, Kiosks etc.
A GPOS is made for high end, general purpose systems like a personal computer, a work station, a server system etc. A GPOS being too heavy demands very high end hardware configurations.
This ensurers the fairness with which programs are executed. But it gives no gaurntee that the high priroirty thread will be given preference to the lower priority one.
In some cases the OS may decay the priority or dyanamically adjust of the thread in order to achive fairness. Lets take the case of task scheduling first. GPOS is programmed to handle scheduling in such a way that it manages to achieve high throughput.
Here throughput means — the total number of processes that complete their execution per unit time. In such a case, some times execution of a high priority process will get delayed inorder to serve 5 or 6 low priority tasks. High throughput is achieved by serving 5 low priority tasks than by serving a single high priority one.
Where as in an RTOS — scheduling is always priority based. Most RTOS uses pre-emptive task scheduling method which is based on priority levels. Here a high priority process gets executed over the low priority ones. A high priority process execution will get override only if a request comes from an even high priority process. In General, the more the number of threads the more time GPOS takes to schedule and start executing the the thread. In highly time constraints RTOS system this delay could be devise.
All it tells is, the Algorithms of ROTS kernel should be deterministic and should be able to perform even if no of resources are more. The more number of threads to schedule, latencies will get added up! Consequently, a high-priority user thread can never preempt a kernel call, but must wait for the entier call to complete, even if the call was invoked by the lowerest priority proecess. In ROTS other hand, kernel opreations are preemptive.
It means low priority task will be preemted even if its executing any system call. There would be some delays some times, but a carefully designed RTOS will have those delays very small. And one more important point, even for these delatils the upper bound of delay time would be well defined. For example:- a request from a driver or some other system service comes in, it is treated as a kernel call which will be served immediately overriding all other process and threads. In an RTOS the kernel is kept very simple and only very important service requests are kept within the kernel call.
All other service requests are treated as external processes and threads. All such service requests from kernel are associated with a bounded latency in an RTOS. This ensures highly predictable and quick response from an RTOS. To achieve this goal, the RTOS kernel must be simple and as elegant as possible. Only services with a short execution path should be included in the kernel itself.
Any operations that require significant work for instance, process loading must be assigned to external processes or threads. Such an approach helps ensure that there is an upper bound on the longest nonpreemptible code path through the kernel. Moreover, a preemptive kernel does not address other conditions that can impose unbounded latencies, such as the loss of priority information that occurs when a client invokes a driver or other system service d Priority Inversion Problem This is problem which can arrive in preemptive priority based scheduling.
RTOS must handle this. Google it, Mars Path finder robot has this problem. How RTOS are deterministic? GPOS are usually not preemptive. So from where other Latency Comes? In between a high priority thread comes, If your kernel is non-preemptive until system call finishes your high priority thread would not get to execute.
So preemptive kernel is must. If kernel is preemptive you can determine the worst time where High priority thread would start execution. It means, say temperature sensor says, initiate the cooling process. It dump a signal to the processor. Normally, in OS terminology, we call this kind of signals interrupt. After a interrupt occurs following action are taken by OS a Interrupt intiated b A interrupt handler is found c Interrupt is handled d Makes the task runnable e Task is scheduled f Task, yeah dears actual RTOS task runs here.
Fast Interrupt Handler : In this type of interrupt handling all other interrupts are masked. This may cause jitters in RTOS env. Normally you can miss interrupts during this kind. Regular Interrupt Handling: Disable only current interrupt. To sum up interrupt latency comes from 1. Disabling of interrupts spin lock etc 2. Bad driver using Fast interrupt mode 3.
Process the high priority interrupt first. So RTOS interrupt handling mechanism should take of above points.
GPOS versus RTOS for an Embedded System