Presentation is loading. Please wait.

Presentation is loading. Please wait.

Real-Time Systems Reny Sebastian, SEG, ER&DCI, TVM.

Similar presentations

Presentation on theme: "Real-Time Systems Reny Sebastian, SEG, ER&DCI, TVM."— Presentation transcript:

1 Real-Time Systems Reny Sebastian, SEG, ER&DCI, TVM

2 Real-Time Systems Sessions 1.Introduction to Real-Time Concepts. 2. Real-Time Operating Systems. 3. Case Study.

3 Real-Time Systems Introduction to Real-Time Concepts. Session 1

4 Real-Time Systems Real-Time System Definition A real-time system (defined by IEEE) is a system whose correctness includes its response time as well as its functional correctness. In other words, in a real-time system, it not only matters that the answers are correct, but it matters when the answers are produced. A Late Answer is a Wrong Answer!

5 Real-Time Systems Real-Time Systems - Categories 1. Hard Real-Time Systems 2. Soft Real-Time Systems

6 Real-Time Systems Hard Real-Time Systems Hard real-time means that the system (i.e., the entire system including OS, middleware, application, HW, communications, etc.) must be designed to GUARANTEE that response requirements are met. Hard Real-Time doesnt mean fast execution.

7 Real-Time Systems Examples Electronic Engines Automotive and Flight Control Systems Medical Systems Industrial Control Systems Robotics

8 Real-Time Systems Soft-Real Time Systems Soft real-time is exactly the same as hard real-time in its infrastructure requirements, but it is not necessary for system success that EVERY time constraint be met.

9 Real-Time Systems Example Telecommunication Systems Internet Video ATM

10 Real-Time Systems The Real-Time Spectrum

11 Real-Time Systems Real-Time Design Issues How many things are under control? How hard are the timing constraints? Will there be user interaction? What is the mix of synchronous vs. asynchronous threads of control?

12 Real-Time Systems Real-Time Design Approaches There are two primary techniques used in real-time designs - Super- loops One program running -Multitasking Many programs running, taking turns

13 Real-Time Systems Super-Loops Also called Foreground/Background Systems There is a background loop that is always running anytime an ISR isnt executing The CPU is always busy Can be taken to the extreme of an idle loop and all of the work being done in the ISRs

14 Real-Time Systems Super-Loop ISR BackgroundForeground Time

15 Real-Time Systems Multi-Tasking Operation With multi- tasking, multiple tasks or threads compete for the CPU based on a scheduling policy This scheduling policy is implemented in the Kernel The tasks give up the CPU: -Voluntarily: cooperative multi- tasking Developer determined via system call - Involuntarily: preemptive multi- tasking Process scheduling algorithm

16 Real-Time Systems Multi-Tasking

17 Real-Time Systems Session 2 Real-Time Operating Systems

18 Real-Time Systems What Is An RTOS? A Real- Time Operating System is software that allows a program to: – Communicate with peripherals and other tasks – React in a deterministic way to external events – Share the CPU and resources in a rigidly established manner between competing threads of execution

19 Real-Time Systems Commercial RTOSs VxWorks pSOS System QNX Nucleus Windows CE MircoC/OS-II

20 Real-Time Systems Commercial RTOS Shortcomings Can be very expen$ive High, per- seat costs Royalties Access to source

21 Real-Time Systems Free RTOSs Embedded Linux Real-Time Linux RTAI RTEMS eCOS

22 Real-Time Systems Multi-Tasking Revisited Multitasking is the process of scheduling and switching the CPU between several tasks Maximizes the utilization of the CPU Facilitates modular construction of applications Simplifies the design of application programs

23 Real-Time Systems Task A task (thread) is a simple program that thinks it has the CPU all to itself. A Real-Time application consists of several tasks executing concurrently. Each task is assigned a priority, its own set of CPU registers, and its own stack area.

24 Real-Time Systems Task States Waiting Dormant ReadyRunning ISR

25 Real-Time Systems Context Switch Occurs when a Multi-Tasking kernel decides to run a different task. Steps involved in a context switch 1.Save current tasks context(CPU registers) in the current tasks context storage area(its stack) 2.Restore the new tasks context from its storage area(its stack). 3.Resume execution of the new tasks code.

26 Real-Time Systems Multiple Tasks Task Control Block CPU Registers Status SP Priority Status SP Priority Status SP Priority SP TASK 1TASK 2TASK n CPU MEMORY Stack

27 Real-Time Systems Kernel Definition Kernel is the part of the multi-tasking system responsible for the management of tasks and communication between tasks. Services - Context switching - Inter task communication services(Semaphore management, mail boxes, queues, time delays, etc.)

28 Real-Time Systems Scheduler Scheduler is the part of the kernel responsible for determining which task will run next Most real-time kernels are priority based Each task is assigned a priority based on its importance The priority of each task is application specific Control is always given to the highest priority task ready to run.

29 Real-Time Systems Kernel There are two types of priority based kernels Non-Preemptive Kernel Preemptive Kernel

30 Real-Time Systems Non-Preemptive Kernel Require that each task does something to explicitly give up the control of the CPU Also called cooperative multitasking ISR always returns to the interrupted task Advantages - Low interrupt latency - It can use Non-Reentrant functions Disadvantages - Responsiveness is very law Very few kernels are non-preemptive

31 Real-Time Systems Non-Preemptive Kernel Low Priority Task ISR ISR makes the higher priority task ready High Priority Task Low-priority task relinquishes the CPU Time

32 Real-Time Systems Preemptive Kernel It is used when system responsiveness is important. High priority task ready to run is always given control of the CPU Most real-time kernels are preemptive. Application code using a preemptive kernel should not use non-reentrant functions or an appropriate mutual exclusion method should be applied to prevent data corruption.

33 Real-Time Systems Preemptive Kernel Low Priority Task ISR High Priority Task ISR makes high priority task ready Time

34 Real-Time Systems Reentrancy A reentrant function can be interrupted at any time and resumed at a later time without loss of data. It either uses local variables or protects data when global variables are used. It can be used by more than one task without fear of data corruption.

35 Real-Time Systems Mutual Exclusion Mutual Exclusion is used to ensure the exclusive access to a shared resource without data corruption. Common Methods are –Disabling interrupts –Disabling scheduling –Using Semaphores

36 Real-Time Systems Common Inter task Communication methods are 1. Message Queues 2. Mail Boxes 3. Semaphores Intertask Communication

37 Real-Time Systems Session 3 Case Study TETRA Mobile

38 Real-Time Systems Tetra Air Interface Tetra Systems use TDMA protocol. TDMA defines time slots of duration ms A TDMA Frame contains 4 time slots Each time slot is a physical channel which may be used for signaling or traffic. There is an offset of two time slots between uplink and downlink slots.

39 Real-Time Systems TDMA Structure

40 Real-Time Systems What is the real-time requirement? Offset of 2 slots Total Processing Time (15.11 ms) 8.46 ms for uC 6.65 ms for DSP

41 Real-Time Systems Hardware Architecture Texas TMS320VC5472 (Orion Processor) Processor External RAM 8 MB SDRAM Flash Memory 8 MB

42 Real-Time Systems Orion Processor Integrates A DSP subsystem based on the TMS320C54x architecture and a RISC microcontroller subsystem based on the AR7TDMI core.

43 Real-Time Systems DSP Subsystem Includes TMS320C54X DSP Core 74K X 16 Bit internal SRAM ARM Port Interface Two multi channel buffered serial ports(McBSPs) Timer DMA Programmable wait-state generator External Memory Interface

44 Real-Time Systems MCU Subsystem ARM7TDMI Core Memory interface for external SRAM, Flash, ROM and SDRAM. On-chip 16K-byte zero wait-state SRAM. General purpose I/Os (GPIOS), including support for an 8x8 keyboard. Three Timers(Two generic, one watchdog) Two UARTs Interrupt Handler Subsystem

45 Real-Time Systems Orion DSP Subsystem API Interface ARM7TDMI TMS320C54x API Memory API Interface

46 Real-Time Systems Software Architecture The software is split up into five major components DSP MMI (Man Machine Interface) PEI (Peripheral Equipment Interface) Protocol Stack RTOS (uC/OS-II)

47 Real-Time Systems Software Architecture

48 Real-Time Systems ARM Software Architecture

49 Real-Time Systems uC/OS-II uC/OS-II is a real-time operating system developed by Jean J. Labrosse. Characteristics Preemptive Multi-tasking Romable Scalable

50 Real-Time Systems uCOS-II Maximum number of Tasks is 64 Task priority levels can be 4 –56 Task priority should be unique. Supports fixed block memory management. Supports Inter task communication methods such as Message Queues, Mail Boxes etc.

51 Real-Time Systems An Example using uC/OS-II Eg: A producer - Consumer Scenario. void Sender(void *arg) { void *mPtr; char err; for(;;) /*for ever */ { mPtr = OSMemGet(AMemPool, &err); /* do some processing here.. And put the result in the buffer mPtr */ err = OSQPost(AQueue, mPtr);/* post it to the receiver task */ OSTimeDly(2); /* wait for 2 ticks. It gives an opportunity to execute the receiver task */ }

52 Real-Time Systems Example - Continued void Receiver(void *arg) { void *mPtr; char err; for(;;) /*for ever */ { /* process the received message */ mPtr = OSQPend(AQueue, 0, &err); /* deallocate the memory after use */ err = OSMemPut(AMemPool, mPtr); }

53 Real-Time Systems Example - Continued OS_MEM * AMemPool; OS_STK stack1[64], stack2[64]; void main() { OSInit() /* Initilize the Kernel */ /* Create memory pool */ AMemPool = OSMemPoolCreate(..); /* arguments omitted */ /* Create message queue */ AQueue = OSQCreate(..); /* arguments omitted */ /* Create tasks */ OSCreateTask(Sender, 0, &stack1[0], 5 ); /* higher priority */ OSCreateTask(Receiver, 0, &stack1[0], 6); OSStart(); /* start Multi tasking */ }

54 Real-Time Systems SDL Specification and Description Language(SDL) is the best suited language for developing telecommunication Protocols. It is a graphical language. It uses a state machine approach for developing applications

55 Real-Time Systems Telelogic Tau SDL Suit A graphical Tool Set for SDL Development Tools for Simulating the system under development. Automatic Code generation is supported using CAdvanced SDL to C compiler.

56 Real-Time Systems Structure of a Telelogic SDL Application Having three parts The SDL system. The physical environment of the system. The environment functions, where you connect the SDL system with the environment of the the system.

57 Real-Time Systems Structure of a Telelogic SDL Application

58 Real-Time Systems Telelogic Tau RTOS Integration C Advanced SDL to C compiler is designed to run on different platforms. Portablility is achieved by representing platform dependent concepts by C macros that can be expanded appropriately for each environment. Platforms which are fully supported by Telelogic Tau. 1. OSE Delta 2. VxWorks and Tornado 3. pSOS 4. Win32 5. Solaris 2.6

59 Real-Time Systems Integration Models Two different run time models Light Integration Tight Integration Further divided into two models. - Standard Model - Instance-Set Model. All models use the same generated code.

60 Real-Time Systems Light Integration Simplest of all the models. Minimum integration with the operating system is required. The Complete SDL system runs as a single OS task. Scheduling of SDL processes is handled by the standard kernel. Worst case scheduling latency is the duration of the longest transition

61 Real-Time Systems Light Integration

62 Real-Time Systems Tight Integration The generated code interacts directly with the underlying operating system when creating processes, sending signals, etc. The SDL processes run as separate OS tasks Scheduling is handled by the OS and is normally time- sliced, priority based and preemptive. Communication takes place using the inter-process communications mechanisms offered by the OS, normally message queues. There are no environment functions

63 Real-Time Systems Tight Integration In the standard model of the Tight integration each SDL process is implemented as OS task. The the Instance Set Model of the Tight integration each SDL process INSTANCE is implemented as OS task.

64 Real-Time Systems Tight Integration

65 Real-Time Systems SDL Kernel The main function of a Telelogic Application is defined in the kernel (sctsdl.c) void main( void ) { xMainInit(); Code from #MAIN xMainLoop(); } void xMainInit( void ) { xInitEnv(); /* environment function */ Init of internal structures }

66 Real-Time Systems Main Loop void xMainLoop (void) { while (1) { xInEnv(...) if ( a timer has expired ) send the corresponding timer signal else if ( a process can execute a transition ) { remove the signal from the input port set up Sender in the process to Sender of the signal call the PAD function for the process } }

67 Real-Time Systems Main Loop for RTOS Integration void xMainLoop (void) { while (1) { xInEnv(...) if ( a timer has expired ) send the corresponding timer signal else if ( a process can execute a transition ) { remove the signal from the input port set up Sender in the process to Sender of the signal call the PAD function for the process } else { relinquish control to a lower priority task which is waiting for the CPU } Added for RTOS Integration

68 Real-Time Systems SDL Kernel sctos.c contains Operating System specific functions Those function should be modified to suite the selected RTOS Examples: xAlloc() - Used by the SDL system to allocated memory for Process Instances, Signals etc. - Standard implementation calls C Library function calloc() xClock() - Used by the SDL System to get the current time. - Implementation is different for different platforms

69 Real-Time Systems Task Level Design Tasks ISRs in the order of task priority API_Isr (ISR) ProtocolStack (Task) MMI (Task) PEI (Task)

70 Real-Time Systems Message Queues Message Queues are used for inter task communication Message Queues used are PS_PDU_Queue (Protocol Stack Input) MMI_PDU_Queue (MMI task Input) PEI_PDU_Queue (PEI task Input)

71 Real-Time Systems Working API Memory API_Isr Protocol Stack MMI PEI PS_PDU_Queue PEI_PDU_Queue MMI_PDU_Queue Queue Write Queue Read API write and Interrupt API Interrupt

72 Real-Time Systems

Download ppt "Real-Time Systems Reny Sebastian, SEG, ER&DCI, TVM."

Similar presentations

Ads by Google