Real-Time Systems Reny Sebastian, SEG, ER&DCI, TVM.
-
Upload
elijah-burrus -
Category
Documents
-
view
224 -
download
1
Transcript of Real-Time Systems Reny Sebastian, SEG, ER&DCI, TVM.
Real-Time Systems
Reny Sebastian, SEG, ER&DCI, TVM
Real-Time Systems
Sessions
1. Introduction to Real-Time Concepts.
2. Real-Time Operating Systems.
3. Case Study.
Real-Time Systems
Introduction to Real-Time Concepts.
Session 1
Real-Time Systems
Real-Time System
• DefinitionA 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!
Real-Time Systems
Real-Time Systems - Categories
1. Hard Real-Time Systems
2. Soft Real-Time Systems
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 doesn’t mean fast execution.
Real-Time Systems
Examples
• Electronic Engines
• Automotive and Flight Control Systems
• Medical Systems
• Industrial Control Systems
• Robotics
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.
Real-Time Systems
Example
• Telecommunication Systems
• Internet Video
• ATM
Real-Time Systems
The Real-Time Spectrum
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?
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
Real-Time Systems
Super-Loops
• Also called Foreground/Background Systems
• There is a background loop that is always running anytime an ISR isn’t 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
Real-Time Systems
Super-Loop
ISR
ISRISR
Background Foreground
Time
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
Real-Time Systems
Multi-Tasking
Real-Time Systems
Session 2
Real-Time Operating Systems
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
Real-Time Systems
Commercial RTOSs
• VxWorks • pSOS System• QNX• Nucleus• Windows CE• MircoC/OS-II
Real-Time Systems
Commercial RTOS Shortcomings
• Can be very expen$ive
• High, per- seat costs
• Royalties
• Access to source
Real-Time Systems
Free RTOSs
• Embedded Linux• Real-Time Linux• RTAI• RTEMS• eCOS
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
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.
Real-Time Systems
Task States
Waiting
Dormant Ready Running ISR
Real-Time Systems
Context Switch• Occurs when a Multi-Tasking kernel decides to run a
different task.
• Steps involved in a context switch1.Save current task’s context(CPU registers) in the
current tasks context storage area(it’s stack)2.Restore the new task’s context from it’s storage
area(it’s stack).3.Resume execution of the new task’s code.
Real-Time Systems
Multiple Tasks
Task Control Block Task Control Block Task Control Block
CPU Registers
Status
SP
Priority
Status
SP
Priority
Status
SP
Priority
SP
TASK 1 TASK 2 TASK n
CPU
MEMORY
Stack Stack Stack
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.)
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.
Real-Time Systems
Kernel
There are two types of priority based kernels
• Non-Preemptive Kernel
• Preemptive Kernel
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
Real-Time Systems
Non-Preemptive KernelLow Priority Task
ISR
ISR makes the higher priority task ready
High Priority Task
Low-priority task relinquishes the CPU
Time
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.
Real-Time Systems
Preemptive Kernel
Low Priority Task
ISR
High Priority Task
ISR makes high priority task ready
Time
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.
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
Real-Time Systems
• Common Inter task Communication methods are
1. Message Queues
2. Mail Boxes
3. Semaphores
Intertask Communication
Real-Time Systems
Session 3
Case Study TETRA Mobile
Real-Time Systems
Tetra Air Interface • Tetra Systems use TDMA protocol.
• TDMA defines time slots of duration 14.167 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.
Real-Time Systems
TDMA Structure
Real-Time Systems
What is the real-time requirement?
1 2 3 4 1 2
3 4 1 2 3 4
Offset of 2 slots
Total Processing Time (15.11 ms)
8.46 ms for uC 6.65 ms for DSP
Real-Time Systems
Hardware Architecture
• Texas TMS320VC5472 (Orion Processor) Processor
• External RAM 8 MB SDRAM
• Flash Memory 8 MB
Real-Time Systems
Orion Processor
Integrates
• A DSP subsystem based on the TMS320C54x architecture
and a
• RISC microcontroller subsystem based on the AR7TDMI core.
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
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
Real-Time Systems
Orion
DSP Subsystem
API Interface
ARM7TDMI TMS320C54xAPI
MemoryAPI
Interface
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)
Real-Time Systems
Software Architecture
DSPFPGAUSER
I/FHW
STACK
MMI
OS
Orion
ARM
V+D
DMO
PEI
Real-Time Systems
ARM Software Architecture
uC-OS
OS
HARDWARE
DMO + V&D Stacks
MMI PEI
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
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.
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 */ } }
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);
} }
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 */ }
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
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.
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.
Real-Time Systems
Structure of a Telelogic SDL Application
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 Delta2. VxWorks and Tornado3. pSOS4. Win325. Solaris 2.6
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.
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
Real-Time Systems
Light Integration
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
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.
Real-Time Systems
Tight Integration
Real-Time Systems
SDL KernelThe main function of a Telelogic Application is defined in the kernel (sctsdl.c)
void main( void ){
xMainInit(); Code from #MAINxMainLoop();
}
void xMainInit( void ){
xInitEnv(); /* environment function */Init of internal structures
}
Real-Time Systems
Main Loop• void xMainLoop (void)
{while (1){
xInEnv(...)if (a timer has expired)
send the corresponding timer signalelse if (a process can execute a transition){
remove the signal from the input portset up Sender in the process to Sender of
the signalcall the PAD function for the process
}}
}
Real-Time Systems
Main Loop for RTOS Integration• void xMainLoop (void)
{while (1){
xInEnv(...)if (a timer has expired)
send the corresponding timer signalelse if (a process can execute a transition){
remove the signal from the input portset up Sender in the process to Sender of the signalcall the PAD function for the process
}else { relinquish control to a lower
priority task which is waiting for the CPU}
}
}
Added for RTOS Integration
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
Real-Time Systems
Task Level Design
Tasks ISRs in the order of task priority
• API_Isr (ISR)
• ProtocolStack (Task)
• MMI (Task)
• PEI (Task)
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)
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
Real-Time Systems