Real Time Operating System for Embedded DSP Applications

Transcription

1 Real Time Operating System for Embedded DSP Applications By P.S.Dey Lecturer Computer Science & Engg. Dept. I.I.T. Kharagpur Organization of the Talk 1. Real Time Systems an Overview. 2. Key Features of Embedded Systems. 3. Real Time Operating Systems Key Features. 4. Case Studies. Real Time Systems Any Real Time System MUST be capable to sense some external / outside external world events like Overheating of a Boiler, Incoming call in a mobile. 2. Any Real Time System, MUST react/ respond to the relevant External Events within a prespecified Deadline. ( Timeliness). 3. In addition to Timeliness, the Response generated by the concerned Real Time System MUST be correct in some way.

2 Reference Model of Real Time System : The Key Elements 1) A resource Model that describes the the system resources available to the applications. 2) Workload Model that describes the applications supported by the system. 3) Scheduling Algorithms that define how the application system use the resources at all times. This is where Real Time Operating Systems has a key role to play. N.B: In most cases we shall assume that all the resources as well as the applications are already specified and we are primarily concerned with specifying the Scheduling and Resource Usage & Management Algorithms. Modeling Real Time System Key Components 1. Job / Thread Unit of work that is scheduled & executed by a system e.g. Control Law Computation, FFT Computation, A Packet Transmission etc. 2. Task : A set of related jobs that jointly provide a function e.g. the task of frequency control in a Thermal Power Generating Station consists of a Host of jobs ranging from Boiler Temperature Monitoring, Turbine Speed Control, Gas recycling, Alternator Frequency Monitoring, Grid Frequency Monitoring etc. 3. Associated Timing Constraints of a Job/ Task. 4. Available Resources. 5. The Scheduling Policy of Tasks to available Resources. Real Time System Key Timing Constraints of a Job Release Time of a Job : The instant of time when the job becomes available for execution I.e. the instant of time when the concerned job comes in the Ready State / Ready Queue. The job can be scheduled and executed at any time after its release time whenever its data and control dependency conditions are met. Release time of a job J i will hence forth be referred to as r i

3 Real Time System Release Time Example Furnace Controlling System : a) Several say N number of Furnaces are to be controlled. b) Samples, Reads as well as stores the Temperature of each Furnace at an Interval of 100 msec ( T units of time ). c) It also computes the control law of each furnace once in every 100 msec (T units of time) in order to process the temperature reading as well as determines the various control parameters. d) Suppose the system, after start up begins the first operation ( Control law computation ) at 20 msec ( S units of time). e) The different Control Law computation of jobs of the N furnaces are denoted by J 0, J 1, J 2,,,.., J N I.e. J k( K = 0 N) f) Release Time of the job J k in this job sequence considering periodic release sequence of the jobs once in every 100 msec ( T units of time) after a starting time of 20 msec ( S units of time). r tk = 20 ( S) + k X 100 ( T ). N.B: The jobs have no release Time if all the jobs are released / ready to be scheduled and executed as soon as the system starts execution. Real Time System Key Timing Components Deadline (Relative & Absolute), Response Time & Execution Time Deadline of a Job J i : The instant of time by which its execution is to be completed. Response Time of a Job J i [ T i ]: The interval of time between a job s release time and its completion time. Relative Deadline of a Job J i [ D i ] : Maximum allowable response time of a job. Deadline / Absolute deadline of a job J i [ d i ]= It s Release Time + It s Relative Deadline. Relative Deadline [ D i ] is the most Important parameter of any job J i in any Real Time System. Execution Time of a Job J i [ e i ] = The amount of time required to complete the job when it executes alone with exclusive ownership of all its resources. Clearly in a real life scenario Response Time [ T i ] OR Deadline [ D i ] > Execution Time [e i ]. Real Time System Timing Constraints : Hard & Soft Deadlines Hard Deadline : Failure to meet such a deadline is considered to be a fatal fault and will lead to disastrous consequences e.g. Response of the break system of a speeding Train approaching a Red Signal to the stop command must come before the train crosses the Red signal. Soft Deadline : Failure to miss a Soft Deadline is undesirable but a few misses does no serious harm like occasional delay in an on line trading of stocks. However the system s overall performance becomes poorer and poorer as more and more jobs starts missing the deadline.

4 Hard & Soft Timing Constraints Measure of Usefulness How serious the consequence of any job missing the specified deadline OR finishing earlier than it s Deadline / Usefulness of the concerned Real Time system = function of Tardiness / Lateness of that Job. Tardiness of a job : The time interval between its actual completion time / Response Time and its pre-specified deadline ( relative/absolute) always +ve. Lateness of a job : The time interval between its actual completion time and its pre-specified deadline ( relative/absolute) can be ve OR +ve ideally Zero. The usefulness of the result produced by any soft real time job decreases gradually with increase in its tardiness or +ve lateness. However for a Hard Deadline JOB finishing early (-ve lateness) is also undesirable since it amounts to wastage of resource. Embedded System Key Features 1. These are special purpose computer systems built into a larger device. 2. Most of these are usually Non User Programmable. 3. These systems are produced in Bulk. 4. It is less costly because of Bulk Production. 5. The devices like Mobile Phones usually work under severe power budget constraints to enhance their Battery life. 6. All such systems are usually application specific hence general purpose peripheral interfaces are absent. 7. Any Embedded System should have less Memory Requirement. 8. Relocation facility of faulty Electronic Memory to some unused good Memory block should exist. 9. Usually Hard Timing Constraints are associated for most of it s functions necessitating usage of Real Time System features. 10. In general, each & every Embedded System happens to be application specific Uni-Processor system, which is built on a simple hardware architecture platform. Real Time Operating System Key Features 1. Real-time operating system (RTOS) is a class of operating system intended for real-time applications. Embedded Systems like programmable thermostats, household appliance controllers, mobile telephones, industrial robots, represent the largest class of such systems. 2. An RTOS does not necessarily have high throughput; rather, a RTOS provides facilities which, if used properly, guarantee that system deadlines can be met generally ("soft real-time") or deterministically ("hard real-time"). 3. An RTOS is valued more for how quickly and/or predictably it can respond to a particular event than for the given amount of work it can perform over time. Key factors in an RTOS are therefore minimal interrupt Latency as well as minimal Context switching Time. 4. An RTOS will typically use specialized scheduling algorithms in order to provide the real-time developer with the tools necessary to produce deterministic behavior in the final system.

5 Real Time Operating System Various Aspects & Their Applicab ility in Emb edded Applications A. Overall System Architecture. B. Process Handling. C. Scheduling Strategy. D. Synchronization & Inter Process Communication. E. Network Support & Other Features. Various Aspects of RTOS 1 Overall Architecture 1. Monolithic. 2. Layered. 3. Micro Kernel. Various Types of Real Time Operating System Overall Architecture Monolithic a) Uni _Prcessor and Single layered. b) Operating System mostly runs in previliged mode. c) All type of Service Requests are made by the User Processes through dedicated System Calls. d) Interrups are handled directly by the Kernel and Interrupt Handlers are not full fledged processes. e) Interrupt handlers cannot invoke / use most of the system services. f) O.S. Schedulers are disabled during Handling of the Interrupt since it operates at the Highest priority. g) Useful for very small application specific systems, because of it s simplicity and very low processor and memory overhaead. h) Applications, as a whole can also be run in the Supervisor mode by bnding it with the O.S. code during Link Time. However this can make debugging very very difficult. i) Upgradation of individual software components is NOT POSSIBLE, without replacing the old Operating System as a whole followed by reboting.

6 Various Types of Real Time Operating System Overall Architecture Layered : a) Modular design where any O.S. Module is dependent on the Modules lying in the layer below it as well as it provides service to it s upper layer (s). b) O.S. Interface as well as Interrupt Handling are like Monolithic Systems. c) Easier maintainability as well as Upgradeability because of Layered Organization. Various Types of Real Time Operating System Overall Architecture Micro Kernel : a) Modular design with a Minimal Privileged O.S. KERNEL code. b) Most Operating System Functions are moved from the KERNEL up to the User level. c) Applications request O.S. services by sending a message to the appropriate O.S. Server and waiting for a reply. d) Handling of Inter Process Communications, enforcing securities, Accessing I/O Peripherals are done in the User mode. e) Easier to manage and maintain. f) Reliability increases because since the Operating System Services run in User Mode, failure of some will make that service unavailable but will not cause a System Crash. Moreover failed system can be restarted and replaced without shutting down the System. g) Easily extendable to distributed systems where operating system functions can be split across a set of distinct machines connected by a communication network. Micro Kernel Architecture is one of the best suited for handling Embedded Applications. Various Aspects of RTOS 2 Process Handling Options 1. Multi Programming & Multi Tasking. 2. Multi Processing. 3. Multi Threading 4. Hyper Threading.

7 Multi Programming (State Diagram) Ready Queue of User Programs Dispatch / Schedule (Predefined Policy) Running Finished Peripheral Oper. [Interrupt #1] Waiting ( doing Peripheral # 1) Request for Peripheral Operation (SVC) Finished Peripheral Operation [ Interrupt #n] Wait ing (doing Peripheral # n) Mul tipr ogr amming Timin g D ia g r a m ( 3 Us er Pr o g r a ms ) P1 Running Peripheral Operation P2 P3 Ready Ready Runnin g Ready Peripheral Operation Running T1 T2 T3 Time Multi Programmed System Key Features Single CPU / Uni-processor system. Simultaneous existence of more than one user program in memory. Established & Well Defined Peripheral usage protocol must exist for each of the peripherals. Dedicated CALLs ( System Calls/ Software Interrupts) must exist enabling any user program to utilize essential services, by invoking any Peripheral Operation. Dedicated Peripheral Interfaces (I/O Channels ) must exist for each of the peripherals. Device Driver / I/O Channel Programs for each & every type of peripherals must exist along with exclusive Supervisor Mode accessibility. Existence of Hardware / Device Interrupt mechanism is a must.

8 Multi -programming / Shortcomings 1. New user program /process gets to execute / allocated CPU provided the currently running process releases the CPU due to Peripheral request. 2. Such voluntary CPU release skews in favour of the User Process that gets the CPU first. 3. Processes coming in later on may starve thereby affecting their Response Time. Hence one way to overcome this is to increase resource by incorporating several instances of the processor itself. Mul t i Pr ocessing I ( St at e Diagr am) Several User processes Several CPU / CPU Cores with Identical Functionality. CPU / Core #1 Centralized O.S. & Global Memory. Global Ready Queue Scheduled / Dispatched Scheduled / Dispatched Scheduled / Dispatched CPU/ Core # J CPU/ Core #N Peripheral Over (H/W Interrupt) Peripheral WAIT Queue Peripheral Over (H/W Interrupt) Peripheral request (SVC) Peripheral Request (SVC) Peripheral Request (SVC) Multiprocessing - II ( Timing Diagram for 2 CPUs / 2 Cores ) P1 Running on CPU1 Doing I/O Running on CPU 1 / CPU 2 P2 Running on CPU2 Running on CPU 1 / CPU 2 Doing I/O P3 Ready Running on CPU2 Exit Time

9 Multi Processing Problems 1. Requires more than one processor unit/core. 2. All managed by Common Operating System and share same Memory ( Tightly Coupled System). 3. Synchronization & management overhead increases since it involves allocating User tasks to each of the existing Processors whenever it becomes Free. 4. Achieving Load Balance among the various processors is difficult. Multi Processing Multi-Tasking 1. CPU speed is much higher than the Real World clock. 2. Single CPU core can be used to handle multiple user tasks with not much degradation in response time. 3. Share the time of one CPU core among several processes i.e. Concurrently running several processes each within it s pre-fixed Time Slice. Multitasking ( State Diagram) Dispatch the Selected Process (for allocated Time) Ready Queue Of Processes Time Out ( After Pre-fixed Interval) Running Event Takes Place (Interrupt) Request for Peripheral / Wait for Event # 1 Request for Peripheral / Wait for Event #n Event Takes Place (Interrupt) Wait / BLOCKED for Event # 1 Wait / BLOCKED for Event # n

10 Multitasking (Timing Diagram) P 1 P 2 P 3 Running Doing I/O Running Ready Running Time Out Running Time Out Ready Runnin Time Out Doing I/O g T1 T2 T3 Mul t i Tasking ( Sal ient Feat ur es) Eliminates / Minimizes CPU waiting time / process in order to give guaranteed response time to each user process lying in the READY Queue. Eliminates need for multiple CPUs. Round Robin / Time shared scheduling of tasks/processes to a single CPU. ( Co-Operative / Pre_Emptive). Each process is granted a prefixed Time Slice based on a prefixed policy. After using CPU for that prefixed Time Period, the concerned process either voluntarily yields the CPU to other processes [ Co-Operative] or is preempted through a internally generated Timer Interrupt. Existence of a dedicated Hardware Interval Timer which is initialized by the O.S. in addition to all the features of any Multi programmed System is necessary. Multi Threading 1. Thread is the basic Execution unit. 2. Threads share among themselves address space [ global variables+ code], peripherals [ NOT CONCURRENTLY]. 3. Each thread has got its own set of Registers and Stack. 4. Sharing a CPU among several peer threads of the same process OR among peer threads of different User Processes in a Time Shared Fashion. 5. Whenever the currently running thread becomes BLOCKED / goes to WAIT state some other thread is scheduled for execution. 6. Multi Threading hence represents a very fine grain multi tasking at the level of a very few instructions thereby permitting FAST SWITCHING among them.

11 Multithreading ( State Diagram) Dispatch one Thread of the Selected Process (for allocated Time) Ready Queue of Threads? Time Out ( After Pre-fixed Interval) Running Event Takes Place (Interrupt) Request for Peripheral / Wait for Event # 1 Request for Peripheral / Wait for Event #n Event Takes Place (Interrupt) Wait / BLOCKED for Event # 1 Wait / BLOCKED for Event # n Hyper Threading 1. Existence of several identical CPU cores. 2. Governed by single O.S. 3. Shared Memory. 4. Threads are allocated to a Core whenever it is free. 5. Time Slice allocated to a Thread is CPU core independent. 6. It aims to mimic Symmetric Multi Processing by allocating separate CPU Cores to execute separate threads. 7. Symmetric Multi Threading.

12 Hyper Thr eading ( St at e Diagr am) Several threads Several identical CPU Cores Centralized O.S. & Some Global l Memory. Ready Queue Of THREADS? Scheduled / Dispatched Scheduled / Dispatched Scheduled / Dispatched TIMED OUT TIMED OUT CPU / Core #1 CPU/ Core # J TIMED OUT CPU/ Core #N Peripheral Over (H/W Interrupt) Peripheral WAIT Queue Peripheral Over (H/W Interrupt) Peripheral request (SVC) Peripheral Request (SVC) Peripheral Request (SVC) Preferred Process Mgt Strategy for Embedded Applications Multi Threading because of the following reasons : 1) Uni- Processor System. 2) Basic Schedulable & Executable entity happens to be the Thread which allows Fast Context Switching that helps in satisfying Deadlines. Various Aspects of RTOS 3 Scheduling Strategies 1. First in First out ( FIFO ) with pre Fixed Static Priority Classes. [ Priority Inversion may happen (to be discussed later)]. 2. Earliest Deadline First (EDF) : Allows dynamic assignment of Priorities based on the Thread whose Deadline is nearest. The most suitable for Embedded Applications. 3. Sporadic Server : Useful for handling sporadic Events only depends on the Execution Capacity & Replenishment period of each Thread.

13 Various Aspects of RTOS 4 Synchronization & Inter process Communication 1. Semaphores : Requires low level System Supported Synchronization Primitives. Works on the principle of Shared Memory. 2. Monitors : High Level Synchronization Primitives based on Shared Memory. 3. M essage Passing : Supports explicit Data Transfer through SEND & RECEIVE primitives and do not require shared Memory Structure. Message Passing is most Suitable. Various Aspects of RTOS 5 Network Support & Other Features 1. Socket Paradigm: Supported by the POSIX ( Portable Operating System Interface for Computing Environments) supports uniform way of communication. 2. Application Programming Interface (API) : Less general than socket based but more rich & efficient. In Micro Kernel Based Design API is most Suitable. Case Studies A. Mars Pathfinder ( A Classic Case of Priority Inversion). B. Symbian Operating System used in Mobile Phones.

14 The Spacecraft : Mars Pathfinder This mission was accomplished in July 4, 1997 with it s landing on the Maritan Surface. The mission includes the following : 1) Unconventional landing ( bouncing onto the Maritan surface surrounded by Air Bags). 2) Deploying the Sojourner Rover. 3) Gathering and Transmitting Voluminous data back to Earth Stations that included Meteorological Data as well as Photographs. The Fault : The Spacecraft began experiencing Total System Resets, each resulting in a loss of Data. The Embedded Kernel used inside Mars Pathfinder was VxWorks, developed by Wind River Systems. Mars Pathfinder & VxWorks The Inside Story 1. Each of the Tasks carried out by the Space Craft was treated as a Thread with pre-fixed static priority. 2. VxWorks provides pre-emptive priority based scheduling of these threads. 3. The Pathfinder contained an information bus which can be thought of as a shared memory area used for passing information between it s different components. 4. Access to this piece of shared memory was controlled by mutual exclusion locks (Semaphores). 5. A Bus Management task ran frequently with high priority to move certain kinds of data in and out of this shared information Bus. 6. Meteorological Data Gathering was a low priority thread while the communications task having medium priority. 7. If at any point of time, albeit infrequently, any of the lower priority threads holds the shared information bus thereby forcing the high priority Bus Management task to WAIT for more than a predefined period a time out signal from a watchdog timer will cause system reset. Solution : Allow the low priority thread currently using the BUS to INHERIT the high priority of the Blocked process for the time being to prevent the WATCHDOG TIMER to go off. Symbian Operating System Symbian OS is an operating system, designed for mobile devices, with associated libraries, user interface frameworks and reference implementations of common tools, produced by Symbian Ltd. It is a descendant of Psion's EPOC and runs exclusively on ARM processors. Symbian is currently owned by Ericsson (15.6%), Nokia (47.9%), Panasonic (10.5%), Samsung (4.5%), Siemens AG (8.4%), and Sony Ericsson (13.1%).

15 Symbian Operating System for Mobile Phones ( The Primary Motivational Factors ) 1. Mobile phones are both small and mobile. 2. Mobile phones are ubiquitous they target a mass-market of consumer, enterprise and professional users. 3. Mobile phones are occasionally connected they can be used when connected to the wireless phone network, locally to other devices, or on their own. 4. Manufacturers need to differentiate their products in order to innovate and compete in a fast-evolving market. 5. The platform has to be open to enable independent technology and software vendors to develop third-party applications, technologies and services. 6. Reliability is a major issue for mass-market phones. Data loss in a personal mobile phone causes a loss of trust between the user and the phone. A mobile phone therefore must be at least as resilient as paper diaries and agendas. 7. Even though nobody can guarantee bug-free software, a good operating system can make it much easier to write robust and reliable applications. Symbian Operating System Key Features 1. It is a 32 bit multitasking operating system wherein events often happen asynchronously and applications are designed to interact with one another. 2. It includes a file system, a graphical user interface framework, multimedia support, a TCP/IP stack and libraries for all the communication features found on smart phones. 3. Symbian OS has software development kits available for third-party application development. 4. The hardware layers of the operating system are abstracted, so that phone manufacturers can port the OS to the specific requirements of their phone. Symbian Operating System Overview

16 Symbian Operating System The Kernel (EKA 2) The Symbian Kernel (EKA 2) Distinctive Features 1. Second Iteration of Symbian s 32 bit kernel Architecture. 2. It is able to run full Telephone Signalling stacks. 3. It allows many Threads easing up tasks of writing Device drivers that involve complex state machines. 4. The HAL provides a generic hardware Independent API to the KERNEL. Symbian ( User vs. KERNEL)

17 Symbian O.S. [ Client Server Model ] Symbian O.S. [ Communication Architecture ] References 1. The Embedded Systems Handbook. 2. Real Time Systems by Prof. Rajiv Mall. 3. Prof. P.S.Dey s Lecture Slides. 4. The Term Paper submitted by M.Tech. Students.

18