Real-Time & Embedded Operating Systems

Transcription

1 Real-Time & Embedded Operating Systems VO Embedded Systems Engineering (Astrit ADEMAJ) Real-Time Operating Systems Scheduling Embedded Operating Systems Power Consumption Embedded Real-Time Operating Systems 2 Real-Time Operating Systems Operating System (OS): abstracts from hardware provides access to I/O, memory management,... has application programming interface (API) with system calls Real-Time Operating Systems (2) Real-Time (RT) requirements for OS + features for timing constrains guaranteed max. execution time of system calls guaranteed OS response time to external events guaranteed max. execution time of OS functions (ISRs, drivers, context switches,...) Determinism/predictability Efficiency Fast context switch Minimize intervals during which the interrupts are disabled 3 4 RTOS taxonomy and architecture (1) Smal, fast, proprietary kernels Highly specialized to an application Real-Time extensions to commercial operating systems (RT-Linux, RT-Posix, RT-MACH, RT-WinNT) Compliant kernels Existing OS is modified such that linux binaries run without modification Dual kernels Thin RT-kernel stay below the native OS Core kernel modification Changes are made in the core of OS The resource kernel approach Kernel is extended to provide support for resource reservation RTOS taxonomy and architecture (2) Component based kernles (OS-kit, Coyote, PURE, MMLite, ) OS components can be selectively included to compose an RTOS Selection depends on the target and application Construction of OS through composition PURE - embedded applications MMLite replacing components while components are in use (dynamic reconfiguration) Components (0.5 3 KB) 5 6 1

2 RTOS taxonomy and architecture (3) QoS based kernels Applied to soft real-time systems Research kernels (MARS, SPRING, HARTOS, TTOS) Developed at university research projects to study new RT-process models RT-synchronization primitives (supporting priority inheritance and priority ceiling protocols) support for fault tolerance RTOS paradigms (1) Hard and soft real-time guarantees Task admission control For soft real-time systems Spring adds this concept in the hard real-time domain 7 8 RTOS paradigms (2) Resource reservation Static resource reservation to a task Reflection Use meta data about the systems to build more flexible systems To achieve better performance (supporting QoS for multimedia) Resource kernels Dynamic resource reservation Real-time Operating Systems Scheduling 9 10 Scheduling Scheduling Decision: which of tasks in RDY-state gets CPU? Fixed priorities, dynamic priorities, round-robin (time-slicing), rate monotonic, cooperative How does scheduler get CPU? system calls system timer interrupt Is Scheduler Necessary? No, you can meet deadlines without any RTOS (generate offline schedule, implement it): inefficient (regularly poll infrequent events, reserve max. time for interrupts) long schedule cycle time (least common multiple of all task periods) or unnecessary overhead (shorten task periods) hard to change and maintain (use tools!)

3 Assigning Task Priorities Tasks have periods or deadlines derived from periods: rate monotonic algorithm derived from deadlines: deadline monotonic Schedulability analysis possible tasks must obey some restrictions (no disabling of interrupts, no suspension in middle of task,...) context switch in zero-time need task execution times Task Execution Time Interrupts interrupts of the OS (w.c. time is specified) interrupts of the application Code execution time system calls (w.c. time is specified) remaining code Real-time Operating Systems Scheduling Design Decisions How many tasks? Poll events or use interrupts? If interrupt, handle event in ISR or in a task? Number of Tasks Few tasks: small OS overhead (not much scheduling) not much inter-task communication easy to understand complete system Many tasks: good and consequent functional partitioning modularization easy to maintain/change modules high parallelism Polling vs. Interrupts Polling: easier to understand regular, hence easier to estimate average times under the control of the scheduler Interrupt: only called when event occurs always called as soon as possible

4 Event Handling in ISR or in Task? In ISR: + fastest possible reaction long ISR not all system calls allowed in ISR (printf, blocking operations) In Task: + considers execution time needs of other tasks handling time harder to compute Event Reaction Time (1) Reaction in ISR: interrupt latency longest time the interrupt may be masked (by application; OS is included in latency) sum of ISR execution times for all interrupts with higher priority Event Reaction Time (2) Reaction in Task: scheduling strategy total execution times of tasks which may preempt total execution time of all OS-specific things (drivers,...) sum of reaction times for all unmasked interrupts Real-time Operating Systems Embedded Operating Systems Power Consumption Embedded Real-time Operating Systems Embedded Operating Systems Strip OS features not used in embedded systems (GUI, CD-ROM support, harddisk support,...) Often specifically developed for a given hardware/system -> modular for easy customizations Network support is important Resource constraints (memory, power, processor speed) EOS Design Objectives Small memory usage (no virtual memory, no memory management) Low power consumption Simplicity (low overhead)

5 EOS Examples Linux: RTLinux, Embedded Linux and derivatives LynxOS QNX VxWorks Windows CE EOS Memory Comparison Embedded Linux: KB QNX: 12 KB Windows CE: 350 KB EOS Features Monolithic kernel define a high-level virtual interface over the hardware with a set of system calls Execute in the kernel mode Micro-kernel - modular kernel Core function in the user mode Less essential run in the user mode Possibly no virtual memory/address translation (small CPUs do not have MMUs) linear addressing space Support for power management Power Consumption (1) Very important! Sleep, idle modes regulating the power consumption in static modes such as sleep and suspend. Power reduction many architectures provide the equivalent of a halt instruction that reduces CPU power during idle periods. The operating system and device drivers may also manage power of peripheral devices, for example spinning down disks during periods of inactivity Power Consumption (2) Power reduction cont. The memory subsystem also provides a profitable area for dynamic power management, either through the memory controller implementation or through software-based schemes. Processor speed reduction CPU power consumption typically scale linearly with frequencies, Processors such as the Transmeta Crusoe, Intel StrongARM and XScale processors, and the recently announced IBM PowerPC 405LP Programming Considerations Keep program short Keep memory usage down Be careful not to overwrite system memory (buffer overflow) Consider power consumption use CPU as seldom as possible (no busy wait, no idle loop!) on a distributed system, try to minimize consumption (but take care not to completely drain one node...)

6 Combination EOS & RTOS RTOS properties must be fulfilled (time guarantees) OS is small enough to fit on a small CPU Programming Considerations Those of RTOS and EOS Try to achieve best power consumption under given restrictions (reduce processor speed and/or voltage if laxity allows it) VxWorks Most widely adopted embedded (realtime) OS Hard real-time Wide range of supported CPUs/platforms and network protocols VxWorks is deployed in: NASA/JPL: Pathfinder, Mars Exploration Rover, Stardust Telecommunications (Apple, Motorola, Siemens, Sony,...) Home entertainment: TV sets, satellite receivers,... Printers (Xerox) LynxOS Provides hard real-time POSIX-conformant Unix-compatible APIs Linux ABI (Application Binary Interface): Linux binaries can be executed in LynxWork LynxOSis used in: NASA Satellite Ranging Systems Boeing 777 Cabin Services System US Army: various military applications USPS Mail Processing Plants Telecommunications: modems, switches HP and Xerox printers Embedded Linux Mainstream Linux is usually not suitable for embedded systems => special patches or dedicated derived implementations are used, e.g.: uclinux ( you-see-linux ): Open Source Linux derivative for CPUs without MMU (microcontrollers) Bluecat, Embedix, Montavista, TimeSys, RTLinux Embedded Linux (2) Low cost, high reliability Extensive know-how and support in Free Software community Numerous derivatives from various vendors -> commercial support & consulting available Open Source if necessary, debug tracing can extend into the OS system can be tailored to project requirements

7 Selecting an OS Supported processors? Memory requirements (OS + appl <= Target memory; don't forget RAM requirements) Features (scheduling strategies, IPC mechanisms,...) Execution time (if real-time requirements) Support! (hotline, documentation, sources?,...) Check newsgroups & magazines for reports Summary RTOS For time-critical applications timeliness is important Guaranteed system response times Application programmer must be aware of system characteristics (scheduling strategy, behaviour of environment, other applications) Careful development of application necessary to guarantee timeliness Summary EOS For resource-constrained applications minimal resource usage is important Small memory requirements Low power consumption Programmer must choose application implementations accordingly The End 39 7