Operating Systems and Real Time Operating Systems.

An Operating System is a set of programs that control the operation of a central processing unit (CPU) and enables the user to communicate with the system. An Operating System can be regarded as set of programs which permits the continuous operation of a computer from program to program with the minimum amount of operator intervention; it acts as an interface between the operator, the computer and the processing program. An Operating System is a set of programs which takes control over the operation of the computer to the extent of being able to allow a number of programs to be run on the computer without human intervention by an operator. The American National Standards Institute(ANSI) definition of an Operating System is as follows Software which controls the execution of computer programs and which may provide scheduling, debugging, input/output control, accounting, compilation, storage assignment, data management and related service. The basic responsibilities of the operating system are: (i) scheduling, (ii) (deferred) interrupt servicing, (iii) inter-process communication and synchronization, (iv) memory management, and (v) task management. Now it cleared that the Operating System means only the software portion that is needed to control all hardwares f computer system automatically and not any real driving or dynamic systems in its hardware. Each Group of computers may have its own and unique operating system although not necessarily only one. Operating System programs are furnished by computer manufacturers and independent software vendors and commonly stored on a disk. The O.S Programs are then transferred from CDs to hard disk of the computer when the system is activated by making the system switch on, the computer permanent memory ROM automatically load a booting up program know as BIOS (BASIC INPUT/OUTPUT SYSTEM) which fetches the operating system program from hard disk to primary storage. It remains there during processing and copies other specialized O.S programs from the disk into primary but temporary storage as they are needed. A real-time system is a computer system that has timing constraints. In other words, a real-time system is partly specified in terms of its ability to make certain calculations or decisions in a timely manner. These important calculations are said to have deadlines for completion. There are two types of real-time systems: SOFT and HARD. In a SOFT real-time system, tasks are performed by the system as fast as possible, but the tasks don't have to finish by specific times. In HARD real-time systems, tasks have to be performed not only correctly but on time. Most real-time systems have a combination of SOFT and HARD requirements. Most applications for real-time systems are embedded.

Examples of embedded systems are: 1. Process control: Food processing Chemical plants 2. Automotive: Engine controls Anti-lock braking systems 3. Office automation: FAX machines. Copiers An RTOS comes in two basic flavours:

4. Computer peripherals: Printers, Scanners, Modems, Robots Terminals 5. Aerospace: Flight management systems Weapons systems Jet engine controls 6. Domestic: Microwave ovens, Dishwashers, Washing machines, Thermostats

1. kernels and 2. full operating systems. A kernel usually implements the basic task and memory management functions. A full operating system may have drivers for disk drives, serial ports, and other common resources. One common characteristic of RTOS is that the system hardware must generate a regular interrupt (called a timer tick or just a tick), say, at 20Hz (50ms).This is used for timekeeping, task scheduling, and other functions. Not all RTOS require a system timer interrupt. Real-time operating systems typically support the following functions: 1. Multitasking, which includes: a. Activation and deactivation of tasks b. Setting task priorities c. Scheduling tasks. 2. Communication between tasks. 3. Memory management. Multitasking: This is the process of scheduling tasks or processes so that they all appear to operate simultaneously. In the protocol converter example, the receive, XON, output, and XOFF processes appear to a human user to run simultaneously because the sequential, one-at-a-time operation is so fast. All the functions of task activation/deactivation, scheduling, and ranking are part of the multitasking function. Multitasking also can be implemented by time slicing. In this method, tasks are switched every tick. Every time the interrupt occurs, a different task is given control, so each task gets to execute for one tick time (50ms for the 20Hz tick example given previously). The overall execution speed for a given task depends on the number of tasks. Higher-priority tasks can be allowed to execute for more than one tick time. A task that needs less than a full tick to execute can terminate early, giving the remainder of its time to the next task. Sequential scheduling and time slicing are essentially the same except that sequentially scheduled tasks run until finished and time-sliced tasks run until their time is up. Most RTOSs can support time slicing or sequential scheduling. Sequential scheduling also can check for and stop tasks that hog the CPU. In any scheduling system, of course, only one task at a time actually has control of the CPU.

Pre-emptive Scheduling: Pre-emptive scheduling is the most common method of scheduling tasks when using an RTOS, and it is one of the primary advantages of using an RTOS. Under preemptive scheduling, a task runs until it is finished or until a task of higher priority pre-empts it. Activation and Deactivation of Tasks: Tasks under RTOS can be ready or not ready. The RTOS keeps a list of tasks that are ready and what their execution priority is. A ready task is added to the task list and executed in sequence. When a task becomes not ready, it is removed from the list. Event-Driven Scheduling: The practice of adding and removing tasks from the task list based on changing circumstances is called event-driven scheduling . The RTOS keeps track of tasks with a tusk control block (TCB). This is where the RTOS saves information about tasks. One TCB entry is made for every task managed by the RTOS. The TCB must store the following: 1.Task ID. This is typically the task number. Depending on the RTOS and the processor it is running on, there may be a maximum of 128 tasks, 256 tasks, 32,768 tasks, and so on. The maximum number of tasks usually is what can be identified with a byte/word/doubleword or whatever the word width of the processor registers. 2.Task State. Ready, blocked, and so on. 3.Task Priority. The priority level of the task; a numerical value, usually 0 to 127,0 to 32,767,
and so on. 4. Task Address. Where in memory the code for the task is located. 5. Task Stack Pointer. The microprocessor stack is used to pass variables and store the context for subroutine calls and interrupts.

Memory Management: The RTOS typically allocates memory as blocks, or chunks of contiguous memory of a minimum size. If the block size is lK, for example, a task that needs a l4byte buffer has to request a block and will get 1K allocated to it. Determining block size is important in the system design. A task that needs multiple blocks usually needs the memory to be contiguous, so the RTOS must find sufficient contiguous blocks of memory to meet the request. If blocks are too small, memory can become fragmented because blocks are not necessarily released by the task in contiguous order. On the other hand, if blocks are made too large, there will be too few blocks to meet all the memory requests of all the tasks.

Real-Time Analysis and Scheduling

Figure 1 provides an overview of the conventional CCS debugging techniques based on breakpoints, probe points, and profiler. Although these debugging tools are very useful to see whether an application program is logically correct or not, when it comes to making sure that realtime deadlines are met, they have limitations. The so-called DSP/BIOS feature of CCS complements the traditional debugging techniques by providing mechanisms to analyze an application program as it runs on the target DSP without stopping the processor. In traditional debugging, the target DSP is normally stopped and a snap shot of the DSP state is examined. This is not an effective way to test for real-time glitches.

Fig 1: Code Composer Studio IDE DSP/BIOS consists of a number of software modules that get glued to an application program to provide real-time analysis and scheduling capabilities. A listing of all available modules is provided in Figure 2. CCS provides an easy-to-use way to glue these modules to the application program.

Fig 2: DSO/BIOS API Modules.