2 Rtos
2 Rtos
2 Rtos
Is an Operating Systems with the necessary features to support a Real-Time System A Good RTOS is one that has a bounded (predictable)
behavior under all system load scenarios. What is a Real-Time System?
Application tasks
Hardware
3
Additional Requirements
RTOS A myth!
Kernel
Task Management. Timer Management. Intertask Communication. Memory Management Dynamic Memory Allocation. Device I/O Supervisor
10
Task management includes the following Task Creation : Task creation should be dynamic; that is task creation should be allowed during run-time.
Task Scheduling : Flexible system will allow task scheduling via events, time
slicing.
Task Priorities : Priority based preemptive scheduling. Priorities must be real time responsive and preferably
dynamic.
11
Tasks States
12
Scheduler
13
14
15
Preemptive Kernel
16
Preemptive Kernel
17
Development Methodology
18
1003.1b - Real time extensions 1003.1c - Multiple threads 1003.1h - High availability 1003.13 - Embedded systems having space/resource limitations
19
Timers Periodic timers, delivery using POSIX signals Priority scheduling Fixed preemptive scheduling with at least 32 priority levels Inter-process communication Message passing Shared memory Memory locking functions to prevent swapping of memory pages Multiple scheduling schemes for same priority level: FIFO, RR, others
20
RTOS Issues
Real-Time POSIX API standard compliance Whether pre-emptive fixed-priority scheduling is supported Support for standard synchronization primitives Support for light weight real-time threads APIs used for task-handling Scalability Footprint of the kernel how huge is the kernel? Can the kernel be scaled down to fit in the ROM of the system?
21
Modularity How does the functionalities like I/O, file system, networking services behave? Can they be added at run-time or can they be changed at run-time? Can a new service be added at run-time? Type of RTOS kernel Monolithic kernel less run-time overhead but not extensible Microkernel high run-time overhead but highly extensible
22
Speed and Efficiency Run-time overhead most of the modern RTOSs are microkernel, but unlike traditional RTOSs they have runtime overhead Run-time overhead is decreased by reducing the unnecessary context switch Important timings such as context switch time, interrupt latency, semaphore latency must be minimum System Calls Non preemptable portions of kernel functions necessary for mutual exclusion are highly optimized and made short and deterministic
23
Interrupt Handling Non preemptable portions of the interrupt handler routines are kept small and deterministic Interrupt handlers are scheduled and executed at appropriate priority
Scheduling Type of scheduling supported Number of priority levels supported 32 to be RT-POSIX compliant; many offer between 128256 Type of scheduling for equal priority threads FIFO or Round-Robin Can thread priorities be changed at run-time?
24
Priority Inversion Control Does it support Priority Inheritance or Ceiling protocols for scheduling? Memory Management Can provide virtual-to-physical address mapping Traditionally does not do paging
Networking Type of networking supported deterministic network stack or not
25
RTOS Application code & RTOS are compiled linked together. Application runs first and calls the OS.
GPOS Application code & OS are and separate. The OS runs first & calls the application. OS is a separate entity than process it runs. Multipurpose, General Purpose
RTOS only runs when called by the the application. Dedicated to single embedded application. Few if any extras.
26
27
LynxOS
Fixed Priority and Preemptiv e
ITRON
Fixed Priority and Preempt ive
QNX
Fixed Priority and Preemp tive
VRTX
Fixed Priority and Preempti ve
VxWork s
Fixed Priority and Preempt ive
Win-CE
Fixed Priority and Preemptive
RR
RR/Quantu m/FCFS
FCFS
RR/Ada ptive
RR
RR
RR(1-7) FCFS(0)
Semaph ores Interrupt locks, preempt ive locks Semaph ores HLP
none
PIP
none
PIP
PIP
PIP
28
ISR
Interrupt Processes
Implem Preemp Preempti entation tible ble Specific interrup Interrupt t handlers handler Special s Context
Special context
Signals
Non-POSIX
POSIX
none
POSIX
Queued POSIX
Queued POSIX
Nested Interrupt s
Yes
Yes
Yes
Yes
Yes
Yes
No
29
Shared Memory
Virtual memory
Segmented
no
Yes
yes
Optional Segmented
Fixed pool
Yes
Yes
Yes
yes
30
31
32
33
34
35
QNX Neutrino
Customer can gain access to the source.
Hard real-time out of the box
SMP inherent in the kernel, but there are scalability issues. Resource requirements ( Cost of Kernel developers Ownership) required. Accountability for Code Quality Who does the customer turn to? GPL prohibits innovative Licensing that protects Intellectual Property business Multi-Processing Capabilities
Hard Real-time capabilities
Distributed inter-process, inter-node communications No kernel development requirements Access to the kernel architects at QNX QNX licensing protects IP
Inherent
Highest priority processes can still be blocked + other issues Cited as a major issue with embedded Linux developers Different implementations
Gnu Toolset , Solaris or Windows. Momentics and Eclipse. Full POSIX compliance.
36
QNX
Full POSIX compliance. Allows OEMs to leverage large UNIX/Linux developer community and minimal port time of the latest software apps.. Microkernel full memory protection using the process model
SMP Built into the Microkernel. Drivers, file systems and applications gain the advantage of SMP without code changes. Any process can run on any CPU. Development can be done on a host (cross development) or directly on the target system (selfhosted). Self-hosted option eliminates timeconsuming process of having to develop one platform and test on another. Built in. Any application can communicate transparently across any number of redundant links, using any combination of network media.
Memory Model
MultiProcessing Capabilities
Developmen t Environment
Redundant networks
GUI Options
Unlike the Zinc and WindML graphics libraries, Photon is a true windowing system that lets multiple applications share screen real estate without interfering with one another. Users can interact with several applications all at once.
37
QNX Neutrino
Proven and Perceived
APIs Processor Independence Scalability Fault Resilience Kernel Stability Distributed Computing Development Model High Availability Development Tools
Dynamic upgradeable built in POSIX Compliance Can move drivers without recoding. 1000 of concurrent processes Process error dont effect the kernel Highly consistent from app to app Qnet. Built-in distributed priority inheritance Self hosted or cross development HA - toolkit Eclipse based Momentics on Windows , Unix or Linux. 38
Drivers must be rewritten for other processors Limited to 32 processes No inherent architecture for fault tolerance Varies with system configuration No inherent support Combination of desktop and embedded development model. None Platform Builder, Visual basic and Visual Studio hosted only on Windows.