DOCSLIB.ORG

Real Time Operating Systems

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Real Time Operating Systems School of Electrical and Computer Engineering N.T.U.A. Embedded System Design Real Time Alex Bartzas Operating Systems Microlab/NTUA Άδεια Χρήσης Το παρόν εκπαιδευτικό υλικό υπόκειται σε άδειες χρήσης Creative Commons. Για εκπαιδευτικό υλικό, όπως εικόνες, που υπόκειται σε άδεια χρήσης άλλου τύπου, αυτή πρέπει να αναφέρεται ρητώς. What is an Embedded OS? An "embedded system" is any computer system or computing device that performs a dedicated function or is designed for use with a specific embedded software applica tion. Embedded systems may use a ROM-based operating system or they may use a disk-based system, like a PC. But an embdddbedded sys tem is no t usa ble as a commercillially v ibliable substitute for general purpose computers or devices. 3 Aspects of embedded system design 4 Metrics •Performance can be measured in multiple ways –Latency vs. throughput –Average vs. worst-case vs. best-case –Peak vs. sustained •Power/energy –Power consumption is important for heat generation –Energy consumption is important for battery life –ItIntegra tdted me titrics suc h as Energy-De lay Pro duc t (EDP) •Cost –Des ign time vs. life time •Reliability –Avail a bility, depen da bility, performabilit y 5 Hardware/software codesign •Goals –Optimizing design process –Oppggtimizing design •Tasks –Cospecificationand comodeling –Codesign –Cosynthesis, optimization, interfacing –Verification 6 Codesign flow 7 What makes a good Embedded OS? Modular Scalable Configurable Small footprint CPU support Device drivers etc,,, etc, etc... 8 What is Real Time? “A real time system is one in which the correctness of the computations not only depends upon the logical correctness of the computation but also upon the time at which the result iddIfthtiititfthtis produced. If the timing constraints of the system are no t met, system failure is said to have occurred.” 9 What is Real Time? “Real time in operating systems: The ability of the operating system to provide a required llfiibddlevel of service in a bounded response ti”time.” 10 Hard vs. Soft Real Time Hard guaranteed worst-case response times absol ut el y, positiv el y, fir st tim e ev er y tim e Soft Kinda, sorta, usually 11 What makes a good RTOS? Multi-threaded Thread ppyriority has to exist because no deadline driven OS exists Must support predictable thread synchronization mechanisms A system of priority inheritance must exist 12 Embedded operating systems - Requirement: Configurability - Configurability No single RTOS will fit all needs, no overhead for unused functions tolerated ) configurability needed. simplest form: remove unused functions (by linker ?). Conditional compilation (using #if and #ifdef commands). Dynamic data might be replaced by static data. Advanced compile-time evaluation useful. Object-orientation could lead to a derivation subclasses. Verification a potential problem of systems with a large number of derived OSs: Each derived OS must be tested thoroughly; potential problem for eCos (open source RTOS from Red Hat), inclu ding 100 to 200 configuration points [Takada, 01]. 13 Example: Configuration of VxWorks © Windriver http://www.windriver.com/products/development_tools/ide/tornado2/tornado_2_ds.pdf 14 Embedded operating systems -Requirement: Disc and network handled by tasks - Disc & network handled by tasks instead of integrated drivers Many ES without disc, a keyboard, a screen or a mouse. Effectively no device that needs to be supported by all versions of the OS, except maybe the system timer. Relatively slow discs & networks can be handled by tasks. RTOS Standard OS 15 Example: WindRiver Platform Industrial Automation © Windriver 16 Embedded operating systems - Requirement: Protection is optional- Protection mechanisms not alwayyys necessary: ES typically designed for a single purpose, untested programs rarely loaded, SW considered reliable. (However, protection mechanisms may be needed for safety and security reasons). 17 Embedded operating systems - Requirement: Interrupts not restricted to OS - Interrupts can be employed by any process For standard OS: serious source of unreliability. Since embdddbedded programs can be cons idere d to be teste d, since protection is not necessary and since effi ci ent cont rol over a vari et y of d evi ces i s requi red , it is possible to let interrupts directly start or stop tasks (by storing the tasks start address in the interrupt table). More efficient than going through OS services. However, composability suffers: if a specific task is connected to some interrupt, it may be difficult to add another task which also needs to be started by an event. 18 Embedded operating systems - Requirement: Real -time capability- Many embedded systems are real-time (RT) systems and, hence, the OS used in these systems must be real-time operating systems (RTOSes). 19 Real-time operating systems - Real-time OS (1) - Def.: (A) real-time operating system is an operating system that supports the construction of real-time systems The followinggy are the three key requirements 1. The timing behavior of the OS must be predictable. ∀ services of the OS: Upper bound on the execution time! RTOSs must be deterministic: unlike standard Java, short times during which interrupts are disabled, contiguous files to avoid unpredictable head movements. [Takada, 2001] 20 Real-time operating systems - Real-time OS (2) - 2. OS must managgge the timing and scheduling OS possibly has to be aware of task deadlines; (unless scheduling is done off-line). OS must provide precise time services with high resolution. [Takada, 2001] 21 Time services Time plays a central role in “real-time” systems. Actual time is described by real numbers. Two discrete standards are used in real-time eqqpuipment: • International atomic time TAI (french: temps atomic internationale) Free of any artificial artifacts. • Universal Time Coordinated (UTC) UTC is de fine d by as tronom ica l s tan dar ds UTC and TAI were identical on Jan. 1st, 1958. In the meantime, 30 seconds had to be added. Not without problems: New Year may start twice per night. 22 Internal synchronization Synchronization with one master clock Typically used in startup-phases Distributed synchronization: 1. Collect information from neighbors 2. Compute correction value 3. Set correction value. Precision of steppp 1 depends on how information is collected: Application level: ~500 µs to 5 ms Operation system kernel: 10 µs to 100 µs Communication hardware: < 10 µs 23 Byzantine Error Erroneous local clocks can have an impact on the computed local time. Advanced algorithms are fault-tolerant with respect to Byzantine errors. Excluding k erroneous clocks is possible with 3k+1 clocks (largest and smallest values will be excluded. Many publications in this area. k=1 t 24 External synchronization External synchronization guarantees consistency with actual physical time. Recent trend is to use GPS for ext. synchronization GPS offers TAI and UTC time information. Resolution is about 100 ns. 25 Problems with external synchronization Problematic from the perspective of fault tolerance: Erroneous values are copied to all stations. Consequence: Accepting only small changes to local time. Many time formats too restricted; e.g.: NTP protocol includes only years up to 2036 For time services and global synchronization of clocks synchronization see Kopetz, 1997. 26 Real-time operating systems - Real-time OS (3) - 3. The OS must be fast Practically important. [Takada, 2001] 27 RTOS-Kernels Distinction between • real-time kernels and modified kernels of standard OSes. Distinction between • general RTOSes and RTOSes for specific domains, • standard APIs (e.g. POSIX RT-Extension of Unix, ITRON, OSEK) or proprietary APIs. 28 Functionality of RTOS-Kernels Incl udes • processor management, • memory management, resource management • and timer management; • task management (resume, wait etc), • inter-task communication and synchronization. 29 Classes of RTOSes according to R. Gupta 1. Fast proprietary kernels Fast proprietary kernels For complex systems, these kernels are inadequate, because they are designed to be fast, rather than to be predictable in every respect [R. Gupta, UCI/UCSD] Examples include QNX, PDOS , VCOS, VTRX32, VxWORKS. 30 Classes of RTOSes according to R. Gupta 2. Real-time extensions to standard OSs Real-time extensions to standard OSes: Attempt to exploit comfortable main stream OSes. RT-kernel running all RT-tasks. Stan dar d-OS execu te d as one tas k. + Crash of standard-OS does not affect RT-tasks; - RT-tasks cannot use Standard-OS services; less comfortable than expected 31 Example: RT-Linux RT-tasks cannot use Init BhBash Moz illa standard OS calls. Commercially available from flb(fsmlabs (www. flbfsmlabs.com ) scheduler Linux-Kernel RT-TkTask RT-TkTask driver interrupts RT-Scheduler RT-Linux interrupts I/O interrupts Hardware 32 Example: Posix 1.b RT-extensions to Linux Standard scheduler can be replaced by POSIX scheduler implementing priorities for RT tasks RT-Task RT-Task Init Bash Mozilla Special RT-calls and POSIX 1.b scheduler standard OS calls available. Linux-Kernel Easy programming, driver no guarantee for I/O, i n terrup ts meeting d eadli ne Hardware 33 Evaluation (Gupta) According to Gupta, trying to use a version of a standard OS: nottht the correc t approac hbh because too many bas ic an d inappropriate underlying assumptions still exist such as optimizing for the average case (rather than the worst case), ... ignoring most if not all semantic information, and indeppgendent CPU scheduling and resource allocation. Dependences between tasks not frequent for most applications of std. OSs & therefore frequently ignored. Situation different for ES since dependences between tasks are quite common. 34 Classes of RTOSes according to R. Gupta 3. Research systems trying to avoid limitations Research systems trying to avoid limitations. Include MARS, Spring, MARUTI, Arts, Hartos, DARK, and Melody RhiResearch issues [Ta ka da, 2001]: low overhead memory protection, tlttiftitemporal protection of computing resources RTOSes for on-chip multiprocessors supportft for con tinuous me dia quality of service (QoS) control. CtitibtCompetition between traditional vendors (e.g.
Load more

Recommended publications
  • Application Note: QP/C MISRA-C:2004 Compliance Matrix
    QP/C MISRA Compliance Matrix Application Note QP/C™ MISRA-C:2004 Compliance Matrix Document Revision D February 2013 Copyright © Quantum Leaps, LLC [email protected] www.state-machine.com MISRA”, “MISRA C”, and the triangle logo are registered trademarks of MISRA Limited Table of Contents 1 Introduction ..................................................................................................................................................... 1 1.1 About MISRA-C:2004 ............................................................................................................................... 1 1.2 About QP™ ............................................................................................................................................... 1 2 Checking MISRA Compliance with PC-Lint/FlexeLint .................................................................................. 2 2.1 Structure of PC-Lint Options for QP/C ...................................................................................................... 2 2.2 QS Software Tracing and the Spy (Q_SPY) Configuration ....................................................................... 6 2.3 Checking MISRA Compliance of a QP/C Source Code ............................................................................ 6 2.4 Checking MISRA Compliance of a QP/C Application Code ...................................................................... 7 2.5 Testing Rule Coverage Against the MISRA-C Exemplar Suite ................................................................
    [Show full text]
  • Embedded Operating Systems
    7 Embedded Operating Systems Claudio Scordino1, Errico Guidieri1, Bruno Morelli1, Andrea Marongiu2,3, Giuseppe Tagliavini3 and Paolo Gai1 1Evidence SRL, Italy 2Swiss Federal Institute of Technology in Zurich (ETHZ), Switzerland 3University of Bologna, Italy In this chapter, we will provide a description of existing open-source operating systems (OSs) which have been analyzed with the objective of providing a porting for the reference architecture described in Chapter 2. Among the various possibilities, the ERIKA Enterprise RTOS (Real-Time Operating System) and Linux with preemption patches have been selected. A description of the porting effort on the reference architecture has also been provided. 7.1 Introduction In the past, OSs for high-performance computing (HPC) were based on custom-tailored solutions to fully exploit all performance opportunities of supercomputers. Nowadays, instead, HPC systems are being moved away from in-house OSs to more generic OS solutions like Linux. Such a trend can be observed in the TOP500 list [1] that includes the 500 most powerful supercomputers in the world, in which Linux dominates the competition. In fact, in around 20 years, Linux has been capable of conquering all the TOP500 list from scratch (for the first time in November 2017). Each manufacturer, however, still implements specific changes to the Linux OS to better exploit specific computer hardware features. This is especially true in the case of computing nodes in which lightweight kernels are used to speed up the computation. 173 174 Embedded Operating Systems Figure 7.1 Number of Linux-based supercomputers in the TOP500 list. Linux is a full-featured OS, originally designed to be used in server or desktop environments.
    [Show full text]
  • AN QP™/QM™ and the Qt™ GUI Framework
    QP state machine frameworks for Arduino Application Note QP/C++™ and the Qt™ GUI Framework Document Revision K May 2014 Copyright © Quantum Leaps, LLC [email protected] www.state-machine.com Table of Contents 1 Introduction ..................................................................................................................................................... 1 1.1 About Qt .................................................................................................................................................. 1 1.2 About QP/C++™ ...................................................................................................................................... 1 1.3 About QM™ ............................................................................................................................................. 2 1.4 Licensing QP™ ........................................................................................................................................ 3 1.5 Licensing QM™ ....................................................................................................................................... 3 2 Getting Started ................................................................................................................................................ 4 2.1 Installing Qt .............................................................................................................................................. 4 2.2 Installing QP/C++ Baseline Code ...........................................................................................................
    [Show full text]
  • Getting Started with QP/C
    Application Note: Getting Started with QP Getting Started with QP™ Real-Time Embedded Frameworks Document Revision G October 2019 Copyright © Quantum Leaps, LLC www.state-machine.com [email protected] Table of Contents 1 Introduction.................................................................................................................................................... 1 2 Downloading and Installing QP and QTools................................................................................................2 2.1 Downloading QP and QTools...................................................................................................................2 2.2 Installing QP............................................................................................................................................. 3 2.3 Downloading QTools................................................................................................................................ 4 2.4 Installing QTools...................................................................................................................................... 5 3 Building and Running the Blinky Example..................................................................................................6 3.1 Blinky on Windows with MinGW (GNU C/C++ for Windows)...................................................................7 3.2 Blinky on Tiva LauchPad with GNU-ARM (command-line)......................................................................8 3.3 Blinky on Tiva LauchPad
    [Show full text]
  • AN QP and ARM7/9 With
    QP state machine frameworks for ARM7/ARM9 with GNU Application Note QP™ and ARM7/9 with GNU Document Revision I March 2014 Copyright © Quantum Leaps, LLC www.quantum-leaps.com www.state-machine.com Table of Contents 1 Introduction ..................................................................................................................................................... 2 1.1 About the ARM Port ................................................................................................................................... 3 1.2 What’s Included in the Accompanying Code .............................................................................................. 4 1.3 About QP™ ................................................................................................................................................ 4 1.4 About QM™ ............................................................................................................................................... 5 1.5 Licensing QP .............................................................................................................................................. 6 1.6 Licensing QM™ .......................................................................................................................................... 6 2 Directories and Files ....................................................................................................................................... 7 2.1 Building the QP Libraries ...........................................................................................................................
    [Show full text]
  • Application Note: QP and Threadx®
    QP state machine frameworks for ThreadX Application Note QP and ThreadX Document Revision D May 2014 Copyright © Quantum Leaps, LLC www.quantum-leaps.com www.state-machine.com Table of Contents 1 Introduction..................................................................................................................................................... 1 1.1 About QP™................................................................................................................................................ 1 1.2 About QM™............................................................................................................................................... 2 1.3 About the QP-ThreadX Integration.............................................................................................................3 1.4 Licensing QP.............................................................................................................................................. 4 1.5 Licensing QM™.......................................................................................................................................... 4 2 Directories and Files....................................................................................................................................... 5 2.1 Installation.................................................................................................................................................. 5 3 Executing the Examples................................................................................................................................
    [Show full text]
  • QP-Embedded Software Engineer
    QUALIFICATIONS PACK - OCCUPATIONAL STANDARDS FOR ELECTRONICS INDUSTRY Contents 1. Introduction and Contacts.…….P1 2. Qualifications Pack……….….......P2 What are 3. OS Units……………..………….....….P3 Occupational 4. Glossary of Key Terms.……….…P12 Standards(OS)? 5. Nomenclature for QP & OS…..P14 OS describe what individuals need to do, know and understand in Introduction order to carry out a particular job Qualifications Pack- Embedded Software Engineer role or function SECTOR: ELECTRONICS OS are SUB-SECTOR: Semiconductor Design and Active Components performance standards that OCCUPATION: System software development individuals must REFERENCE ID: ELE/Q1501 achieve when carrying out ALIGNED TO: NCO-2004/NIL functions in the workplace, Embedded Software Engineer: Also called ‘Embedded Software together with Developer’, the Embedded Software Engineer is responsible for developing specifications of software module for the embedded system. the underpinning knowledge and Brief Job Description: The individual at work assesses the embedded understanding systems’ specification requirement, develops software, tests and validates the software in coordination with design engineers for system integration. Contact Us: ESSCI, New Delhi Personal Attributes: The job requires the individual to have: attention to Electronics Sector Skills details, good communication skills, logical thinking, and ability to work for Council of India long hours on computer. 422, Okhla Industrial Estate, Phase-III, New Delhi-110020 E-mail: 1 [email protected] Qualifications Pack
    [Show full text]
  • Application Note: QP and SEGGER Embos
    QP state machine frameworks for embOS Application Note QP™ and SEGGER embOS Document Revision A June 2014 Copyright © Quantum Leaps, LLC www.quantum-leaps.com www.state-machine.com Table of Contents 1 Introduction..................................................................................................................................................... 1 1.1 About QP™................................................................................................................................................ 2 1.2 About QM™............................................................................................................................................... 3 1.3 About the QP-embOS Integration...............................................................................................................4 1.4 Licensing QP.............................................................................................................................................. 4 1.5 Licensing QM™.......................................................................................................................................... 4 2 Directories and Files....................................................................................................................................... 5 2.1 Installation.................................................................................................................................................. 5 3 Building the DPP Example............................................................................................................................
    [Show full text]
  • Comparing Windows NT, Linux, and QNX As the Basis for Cluster Systems
    Comparing Windows NT, Linux, and QNX as the Basis for Cluster Systems Avi Kavas Dror G. Feitelson School of Computer Science and Engineering The Hebrew University, 91904 Jerusalem, Israel Abstract Clusters use commodity hardware and software components to provide an environment for parallel processing. A major issue in the development of a cluster system is the choice of the operating system that will run on each node. We compare three alternatives: Windows NT, Linux, and QNX — a real-time microkernel. The comparison is based on expressive power, performance, and ease-of-use metrics. The result is that none of these systems has a clear advantage over the others in all the metrics, but that each has its strong and weak points. Thus any choice of a base system will involve some technical compromises, but not major ones. 1 Introduction Rapid improvements in network and processor performance are causing clustered commodity workstations and PCs to become an increasingly popular platform for executing parallel applica- tions. In the past, Unix was used as the platform for almost all parallel systems implementations. Recently, however, it is becoming more common to use Windows NT as the base platform. The decision which operating system to use involves many considerations, including the oper- ating system’s cost and personal experience with the different systems. But there are also technical implications. Our goal is to illuminate these technical issues, by providing a broad comparison of the capabilities and characteristics of the different systems. Throughput, the emphasis is on those features deemed to be important for the implementation of computational clusters.
    [Show full text]
  • QP and ARM Cortex-M with IAR
    QP state machine frameworks for ARM Cortex-M Application Note QP™ and ARM Cortex-M with IAR Document Revision L February 2013 Copyright © Quantum Leaps, LLC www.quantum-leaps.com www.state-machine.com Table of Contents 1 Introduction ..................................................................................................................................................... 1 1.1 About the QP Port to ARM Cortex-M ........................................................................................................ 2 1.2 The Use of the FPU (Cortex-M4F) ............................................................................................................ 2 1.3 Cortex Microcontroller Software Interface Standard (CMSIS) ................................................................... 2 1.4 About QP™ ............................................................................................................................................... 3 1.5 About QM™ .............................................................................................................................................. 4 1.6 Licensing QP ............................................................................................................................................. 5 1.7 Licensing QM™ ........................................................................................................................................ 5 2 Directories and Files ......................................................................................................................................
    [Show full text]
  • QP and POSIX
    QP state machine frameworks for POSIX Application Note QP™ and POSIX Document Revision E November 2012 Copyright © Quantum Leaps, LLC www.quantum-leaps.com www.state-machine.com Table of Contents 1 Introduction ..................................................................................................................................................... 1 1.1 About QP™ .................................................................................................................................................... 1 1.2 About QM™ ................................................................................................................................................... 2 1.3 About the QP™ Port to POSIX ....................................................................................................................... 3 1.4 Licensing QP™ and QP port to POSIX .......................................................................................................... 4 1.5 Licensing QM™ .............................................................................................................................................. 4 2 Directories and Files ....................................................................................................................................... 5 2.1 Building the QP Libraries ............................................................................................................................... 6 2.2 Building the QP Applications .........................................................................................................................
    [Show full text]
  • Third Party License Terms List
    QNX® THIRD PARTY LICENSE TERMS LIST Version 2.14a Includes: Supplement for Screen Graphics Subsystem for QNX Software Development Platform 6.5 Service Pack 1 (“Screen”) (See Publication History for version details) Table of Contents 1. Introduction 2. Tables 2.1 Condensed Version of File Mapping Tables (Summarized by License Family) 2.2 Complete Version of File Mapping Tables (Includes Full Legal ID Codes) 3. Licenses 3.1 License Types and Codes 3.2 License Texts © 2015 QNX Software Systems Limited, a subsidiary of BlackBerry Limited. All rights reserved. QNX, QNX CAR, Momentics, Neutrino and Aviage are trademarks of BlackBerry Limited, which are registered and/or used in certain jurisdictions, and are used under license by QNX Software Systems Limited. All other trademarks belong to their respective owners. 1. Introduction This version 2.14a of the QNX Third Party License Terms List (“TPLTL”) is the companion document to version 2.14a of the QNX License Guide (“License Guide”) (see http://licensing.qnx.com/document-archive/). As explained in the License Guide, QNX Software Systems Limited (“QSS”) incorporates certain third-party software in our products. The license terms associated with some of the third-party software requires that we provide the recipient with additional information such as attributions, copies of licenses, or source code (“Compliance”). This document encapsulates Compliance for Screen. This TPLTL is divided into two sections as follows: 1. The summary tables in section 2.1 provide an overview of types of licenses (“Legal ID Codes”) for third-party software that QSS has reused and that have Compliance requirements.
    [Show full text]