DOCSLIB.ORG

RTEMS C User Documentation Release 4.11.2 ©Copyright 2016, RTEMS Project (Built 10Th July 2017)

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
RTEMS C User Documentation Release 4.11.2 ©Copyright 2016, RTEMS Project (Built 10Th July 2017) RTEMS C User Documentation Release 4.11.2 ©Copyright 2016, RTEMS Project (built 10th July 2017) CONTENTS I RTEMS C User’s Guide1 1 Preface 3 2 Overview 7 2.1 Introduction......................................8 2.2 Real-time Application Systems............................9 2.3 Real-time Executive.................................. 10 2.4 RTEMS Application Architecture........................... 11 2.5 RTEMS Internal Architecture............................. 12 2.6 User Customization and Extensibility......................... 14 2.7 Portability....................................... 15 2.8 Memory Requirements................................. 16 2.9 Audience........................................ 17 2.10 Conventions...................................... 18 2.11 Manual Organization................................. 19 3 Key Concepts 23 3.1 Introduction...................................... 24 3.2 Objects......................................... 25 3.2.1 Object Names................................. 25 3.2.2 Object IDs................................... 25 3.2.2.1 Thirty-Two Object ID Format.................... 26 3.2.2.2 Sixteen Bit Object ID Format.................... 26 3.2.3 Object ID Description............................. 26 3.3 Communication and Synchronization........................ 28 3.4 Time.......................................... 29 3.5 Memory Management................................. 30 4 RTEMS Data Types 31 4.1 Introduction...................................... 32 4.2 List of Data Types................................... 33 5 Scheduling Concepts 37 5.1 Introduction...................................... 38 5.2 Scheduling Algorithms................................ 39 5.2.1 Priority Scheduling.............................. 39 5.2.2 Deterministic Priority Scheduler....................... 40 5.2.3 Simple Priority Scheduler.......................... 40 i 5.2.4 Simple SMP Priority Scheduler....................... 40 5.2.5 Earliest Deadline First Scheduler...................... 40 5.2.6 Constant Bandwidth Server Scheduling (CBS)............... 41 5.3 Scheduling Modification Mechanisms........................ 42 5.3.1 Task Priority and Scheduling......................... 42 5.3.2 Preemption.................................. 42 5.3.3 Timeslicing.................................. 42 5.3.4 Manual Round-Robin............................. 43 5.4 Dispatching Tasks................................... 44 5.5 Task State Transitions................................. 45 6 Initialization Manager 49 6.1 Introduction...................................... 50 6.2 Background....................................... 51 6.2.1 Initialization Tasks.............................. 51 6.2.2 System Initialization............................. 51 6.2.3 The Idle Task................................. 51 6.2.4 Initialization Manager Failure........................ 51 6.3 Operations....................................... 53 6.3.1 Initializing RTEMS.............................. 53 6.3.2 Shutting Down RTEMS............................ 54 6.4 Directives........................................ 55 6.4.1 INITIALIZE_EXECUTIVE - Initialize RTEMS................. 56 6.4.2 SHUTDOWN_EXECUTIVE - Shutdown RTEMS............... 57 7 Task Manager 59 7.1 Introduction...................................... 60 7.2 Background....................................... 61 7.2.1 Task Definition................................ 61 7.2.2 Task Control Block.............................. 61 7.2.3 Task States................................... 61 7.2.4 Task Priority.................................. 62 7.2.5 Task Mode................................... 62 7.2.6 Accessing Task Arguments.......................... 63 7.2.7 Floating Point Considerations........................ 63 7.2.8 Per Task Variables............................... 64 7.2.9 Building a Task Attribute Set......................... 64 7.2.10 Building a Mode and Mask.......................... 65 7.3 Operations....................................... 66 7.3.1 Creating Tasks................................. 66 7.3.2 Obtaining Task IDs.............................. 66 7.3.3 Starting and Restarting Tasks........................ 66 7.3.4 Suspending and Resuming Tasks....................... 66 7.3.5 Delaying the Currently Executing Task................... 67 7.3.6 Changing Task Priority............................ 67 7.3.7 Changing Task Mode............................. 67 7.3.8 Notepad Locations.............................. 67 7.3.9 Task Deletion................................. 67 7.3.10 Transition Advice for Obsolete Directives.................. 68 7.3.10.1 Notepads............................... 68 7.4 Directives........................................ 69 7.4.1 TASK_CREATE - Create a task........................ 70 ii 7.4.2 TASK_IDENT - Get ID of a task........................ 72 7.4.3 TASK_SELF - Obtain ID of caller....................... 73 7.4.4 TASK_START - Start a task.......................... 74 7.4.5 TASK_RESTART - Restart a task....................... 75 7.4.6 TASK_DELETE - Delete a task........................ 76 7.4.7 TASK_SUSPEND - Suspend a task...................... 77 7.4.8 TASK_RESUME - Resume a task....................... 78 7.4.9 TASK_IS_SUSPENDED - Determine if a task is Suspended......... 79 7.4.10 TASK_SET_PRIORITY - Set task priority................... 80 7.4.11 TASK_MODE - Change the current task mode............... 81 7.4.12 TASK_GET_NOTE - Get task notepad entry................. 82 7.4.13 TASK_SET_NOTE - Set task notepad entry................. 83 7.4.14 TASK_WAKE_AFTER - Wake up after interval................ 84 7.4.15 TASK_WAKE_WHEN - Wake up when specified............... 85 7.4.16 ITERATE_OVER_ALL_THREADS - Iterate Over Tasks............ 86 7.4.17 TASK_VARIABLE_ADD - Associate per task variable............ 87 7.4.18 TASK_VARIABLE_GET - Obtain value of a per task variable........ 88 7.4.19 TASK_VARIABLE_DELETE - Remove per task variable........... 89 8 Interrupt Manager 91 8.1 Introduction...................................... 92 8.2 Background....................................... 93 8.2.1 Processing an Interrupt............................ 93 8.2.2 RTEMS Interrupt Levels........................... 94 8.2.3 Disabling of Interrupts by RTEMS...................... 94 8.3 Operations....................................... 95 8.3.1 Establishing an ISR.............................. 95 8.3.2 Directives Allowed from an ISR....................... 95 8.4 Directives........................................ 98 8.4.1 INTERRUPT_CATCH - Establish an ISR................... 99 8.4.2 INTERRUPT_DISABLE - Disable Interrupts................. 100 8.4.3 INTERRUPT_ENABLE - Enable Interrupts.................. 101 8.4.4 INTERRUPT_FLASH - Flash Interrupts................... 102 8.4.5 INTERRUPT_LOCAL_DISABLE - Disable Interrupts on Current Processor 103 8.4.6 INTERRUPT_LOCAL_ENABLE - Enable Interrupts on Current Processor. 104 8.4.7 INTERRUPT_LOCK_INITIALIZE - Initialize an ISR Lock.......... 105 8.4.8 INTERRUPT_LOCK_ACQUIRE - Acquire an ISR Lock........... 106 8.4.9 INTERRUPT_LOCK_RELEASE - Release an ISR Lock............ 107 8.4.10 INTERRUPT_LOCK_ACQUIRE_ISR - Acquire an ISR Lock from ISR.... 108 8.4.11 INTERRUPT_LOCK_RELEASE_ISR - Release an ISR Lock from ISR.... 109 8.4.12 INTERRUPT_IS_IN_PROGRESS - Is an ISR in Progress.......... 110 9 Clock Manager 111 9.1 Introduction...................................... 112 9.2 Background....................................... 113 9.2.1 Required Support............................... 113 9.2.2 Time and Date Data Structures....................... 113 9.2.3 Clock Tick and Timeslicing.......................... 113 9.2.4 Delays..................................... 114 9.2.5 Timeouts.................................... 114 9.3 Operations....................................... 115 9.3.1 Announcing a Tick.............................. 115 iii 9.3.2 Setting the Time............................... 115 9.3.3 Obtaining the Time.............................. 115 9.4 Directives........................................ 116 9.4.1 CLOCK_SET - Set date and time....................... 117 9.4.2 CLOCK_GET - Get date and time information............... 118 9.4.3 CLOCK_GET_TOD - Get date and time in TOD format........... 119 9.4.4 CLOCK_GET_TOD_TIMEVAL - Get date and time in timeval format... 120 9.4.5 CLOCK_GET_SECONDS_SINCE_EPOCH - Get seconds since epoch.... 121 9.4.6 CLOCK_GET_TICKS_PER_SECOND - Get ticks per second......... 122 9.4.7 CLOCK_GET_TICKS_SINCE_BOOT - Get current ticks counter value... 123 9.4.8 CLOCK_TICK_LATER - Get tick value in the future............. 124 9.4.9 CLOCK_TICK_LATER_USEC - Get tick value in the future in microseconds 125 9.4.10 CLOCK_TICK_BEFORE - Is tick value is before a point in time...... 126 9.4.11 CLOCK_GET_UPTIME - Get the time since boot.............. 127 9.4.12 CLOCK_GET_UPTIME_TIMEVAL - Get the time since boot in timeval for- mat....................................... 128 9.4.13 CLOCK_GET_UPTIME_SECONDS - Get the seconds since boot...... 129 9.4.14 CLOCK_GET_UPTIME_NANOSECONDS - Get the nanoseconds since boot 130 10 Timer Manager 131 10.1 Introduction...................................... 132 10.2 Background....................................... 133 10.2.1 Required Support............................... 133 10.2.2 Timers..................................... 133 10.2.3 Timer Server................................. 133 10.2.4 Timer Service Routines............................ 133 10.3 Operations....................................... 134 10.3.1 Creating a Timer..............................
Load more

Recommended publications
  • The Design and Implementation of Multiprocessor Support for an Industrial Operating System Kernel
    Blekinge Institute of Technology Research Report 2005:06 The Design and Implementation of Multiprocessor Support for an Industrial Operating System Kernel Simon Kågström Håkan Grahn Lars Lundberg Department of Systems and Software School of Engineering Blekinge Institute of Technology The Design and Implementation of Multiprocessor Support for an Industrial Operating System Kernel Simon Kågström, Håkan Grahn, and Lars Lundberg Department of Systems and Software Engineering School of Engineering Blekinge Institute of Technology P.O. Box 520, SE-372 25 Ronneby, Sweden {ska, hgr, llu}@bth.se Abstract The ongoing transition from uniprocessor to multiprocessor computers requires support from the op- erating system kernel. Although many general-purpose multiprocessor operating systems exist, there is a large number of specialized operating systems which require porting in order to work on multipro- cessors. In this paper we describe the multiprocessor port of a cluster operating system kernel from a producer of industrial systems. Our initial implementation uses a giant locking scheme that serializes kernel execution. We also employed a method in which CPU-local variables are placed in a special sec- tion mapped to per-CPU physical memory pages. The giant lock and CPU-local section allowed us to implement an initial working version with only minor changes to the original code, although the giant lock and kernel-bound applications limit the performance of our multiprocessor port. Finally, we also discuss experiences from the implementation. 1 Introduction A current trend in the computer industry is the transition from uniprocessors to various kinds of multipro- cessors, also for desktop and embeddedsystems. Apart from traditional SMP systems, many manufacturers are now presenting chip multiprocessors or simultaneous multithreaded CPUs [9, 15, 16] which allow more efficient use of chip area.
    [Show full text]
  • Linux Scheduler Documentation
    Linux Scheduler Documentation The kernel development community Jul 14, 2020 CONTENTS i ii CHAPTER ONE COMPLETIONS - “WAIT FOR COMPLETION”BARRIER APIS 1.1 Introduction: If you have one or more threads that must wait for some kernel activity to have reached a point or a specific state, completions can provide a race-free solution to this problem. Semantically they are somewhat like a pthread_barrier() and have similar use-cases. Completions are a code synchronization mechanism which is preferable to any misuse of locks/semaphores and busy-loops. Any time you think of using yield() or some quirky msleep(1) loop to allow something else to proceed, you probably want to look into using one of the wait_for_completion*() calls and complete() instead. The advantage of using completions is that they have a well defined, focused pur- pose which makes it very easy to see the intent of the code, but they also result in more efficient code as all threads can continue execution until the result isactually needed, and both the waiting and the signalling is highly efficient using low level scheduler sleep/wakeup facilities. Completions are built on top of the waitqueue and wakeup infrastructure of the Linux scheduler. The event the threads on the waitqueue are waiting for is reduced to a simple flag in ‘struct completion’, appropriately called “done”. As completions are scheduling related, the code can be found in ker- nel/sched/completion.c. 1.2 Usage: There are three main parts to using completions: • the initialization of the ‘struct completion’synchronization object • the waiting part through a call to one of the variants of wait_for_completion(), • the signaling side through a call to complete() or complete_all().
    [Show full text]
  • Computer Organization and Architecture Designing for Performance Ninth Edition
    COMPUTER ORGANIZATION AND ARCHITECTURE DESIGNING FOR PERFORMANCE NINTH EDITION William Stallings Boston Columbus Indianapolis New York San Francisco Upper Saddle River Amsterdam Cape Town Dubai London Madrid Milan Munich Paris Montréal Toronto Delhi Mexico City São Paulo Sydney Hong Kong Seoul Singapore Taipei Tokyo Editorial Director: Marcia Horton Designer: Bruce Kenselaar Executive Editor: Tracy Dunkelberger Manager, Visual Research: Karen Sanatar Associate Editor: Carole Snyder Manager, Rights and Permissions: Mike Joyce Director of Marketing: Patrice Jones Text Permission Coordinator: Jen Roach Marketing Manager: Yez Alayan Cover Art: Charles Bowman/Robert Harding Marketing Coordinator: Kathryn Ferranti Lead Media Project Manager: Daniel Sandin Marketing Assistant: Emma Snider Full-Service Project Management: Shiny Rajesh/ Director of Production: Vince O’Brien Integra Software Services Pvt. Ltd. Managing Editor: Jeff Holcomb Composition: Integra Software Services Pvt. Ltd. Production Project Manager: Kayla Smith-Tarbox Printer/Binder: Edward Brothers Production Editor: Pat Brown Cover Printer: Lehigh-Phoenix Color/Hagerstown Manufacturing Buyer: Pat Brown Text Font: Times Ten-Roman Creative Director: Jayne Conte Credits: Figure 2.14: reprinted with permission from The Computer Language Company, Inc. Figure 17.10: Buyya, Rajkumar, High-Performance Cluster Computing: Architectures and Systems, Vol I, 1st edition, ©1999. Reprinted and Electronically reproduced by permission of Pearson Education, Inc. Upper Saddle River, New Jersey, Figure 17.11: Reprinted with permission from Ethernet Alliance. Credits and acknowledgments borrowed from other sources and reproduced, with permission, in this textbook appear on the appropriate page within text. Copyright © 2013, 2010, 2006 by Pearson Education, Inc., publishing as Prentice Hall. All rights reserved. Manufactured in the United States of America.
    [Show full text]
  • Introduction to the Intel® Nios® II Soft Processor
    Introduction to the Intel® Nios® II Soft Processor For Quartus® Prime 18.1 1 Introduction This tutorial presents an introduction the Intel® Nios® II processor, which is a soft processor that can be instantiated on an Intel FPGA device. It describes the basic architecture of Nios II and its instruction set. The Nios II processor and its associated memory and peripheral components are easily instantiated by using Intel’s SOPC Builder or Platform Designer tool in conjunction with the Quartus® Prime software. A full description of the Nios II processor is provided in the Nios II Processor Reference Handbook, which is available in the literature section of the Intel web site. Introductions to the SOPC Builder and Platform Designer tools are given in the tutorials Introduction to the Intel SOPC Builder and Introduction to the Intel Platform Designer Tool, respectively. Both can be found in the University Program section of the web site. Contents: • Nios II System • Overview of Nios II Processor Features • Register Structure • Accessing Memory and I/O Devices • Addressing • Instruction Set • Assembler Directives • Example Program • Exception Processing • Cache Memory • Tightly Coupled Memory Intel Corporation - FPGA University Program 1 March 2019 ® ® INTRODUCTION TO THE INTEL NIOS II SOFT PROCESSOR For Quartus® Prime 18.1 2 Background Intel’s Nios II is a soft processor, defined in a hardware description language, which can be implemented in Intel’s FPGA devices by using the Quartus Prime CAD system. This tutorial provides a basic introduction to the Nios II processor, intended for a user who wishes to implement a Nios II based system on an Intel Development and Education board.
    [Show full text]
  • Overrun Handling for Mixed-Criticality Support in RTEMS Kuan-Hsun Chen, Georg Von Der Brüggen, Jian-Jia Chen
    Overrun Handling for Mixed-Criticality Support in RTEMS Kuan-Hsun Chen, Georg von der Brüggen, Jian-Jia Chen To cite this version: Kuan-Hsun Chen, Georg von der Brüggen, Jian-Jia Chen. Overrun Handling for Mixed-Criticality Support in RTEMS. WMC 2016, Nov 2016, Porto, Portugal. hal-01438843 HAL Id: hal-01438843 https://hal.archives-ouvertes.fr/hal-01438843 Submitted on 25 Jan 2017 HAL is a multi-disciplinary open access L’archive ouverte pluridisciplinaire HAL, est archive for the deposit and dissemination of sci- destinée au dépôt et à la diffusion de documents entific research documents, whether they are pub- scientifiques de niveau recherche, publiés ou non, lished or not. The documents may come from émanant des établissements d’enseignement et de teaching and research institutions in France or recherche français ou étrangers, des laboratoires abroad, or from public or private research centers. publics ou privés. Overrun Handling for Mixed-Criticality Support in RTEMS Kuan-Hsun Chen, Georg von der Bruggen,¨ and Jian-Jia Chen Department of Informatics, TU Dortmund University, Germany Email: fkuan-hsun.chen, georg.von-der-brueggen, [email protected] Abstract—Real-time operating systems are not only used in of real-time operation systems is sufficient. However, some embedded real-time systems but also useful for the simulation and applications also have tasks with arbitrary deadlines, i.e., for validation of those systems. During the evaluation of our paper some tasks D > T . If the tasks are strictly periodic, this about Systems with Dynamic Real-Time Guarantees that appears i i in RTSS 2016 we discovered certain unexpected system behavior leads to a situation where two or more instances of the same in the open-source real-time operating system RTEMS.
    [Show full text]
  • Computer Organization & Architecture Eie
    COMPUTER ORGANIZATION & ARCHITECTURE EIE 411 Course Lecturer: Engr Banji Adedayo. Reg COREN. The characteristics of different computers vary considerably from category to category. Computers for data processing activities have different features than those with scientific features. Even computers configured within the same application area have variations in design. Computer architecture is the science of integrating those components to achieve a level of functionality and performance. It is logical organization or designs of the hardware that make up the computer system. The internal organization of a digital system is defined by the sequence of micro operations it performs on the data stored in its registers. The internal structure of a MICRO-PROCESSOR is called its architecture and includes the number lay out and functionality of registers, memory cell, decoders, controllers and clocks. HISTORY OF COMPUTER HARDWARE The first use of the word ‘Computer’ was recorded in 1613, referring to a person who carried out calculation or computation. A brief History: Computer as we all know 2day had its beginning with 19th century English Mathematics Professor named Chales Babage. He designed the analytical engine and it was this design that the basic frame work of the computer of today are based on. 1st Generation 1937-1946 The first electronic digital computer was built by Dr John V. Atanasoff & Berry Cliford (ABC). In 1943 an electronic computer named colossus was built for military. 1946 – The first general purpose digital computer- the Electronic Numerical Integrator and computer (ENIAC) was built. This computer weighed 30 tons and had 18,000 vacuum tubes which were used for processing.
    [Show full text]
  • Advances in Mobile Cloud Computing and Big Data in the 5G Era Studies in Big Data
    Studies in Big Data 22 Constandinos X. Mavromoustakis George Mastorakis Ciprian Dobre Editors Advances in Mobile Cloud Computing and Big Data in the 5G Era Studies in Big Data Volume 22 Series editor Janusz Kacprzyk, Polish Academy of Sciences, Warsaw, Poland e-mail: [email protected] About this Series The series “Studies in Big Data” (SBD) publishes new developments and advances in the various areas of Big Data-quickly and with a high quality. The intent is to cover the theory, research, development, and applications of Big Data, as embedded in the fields of engineering, computer science, physics, economics and life sciences. The books of the series refer to the analysis and understanding of large, complex, and/or distributed data sets generated from recent digital sources coming from sensors or other physical instruments as well as simulations, crowd sourcing, social networks or other internet transactions, such as emails or video click streams and other. The series contains monographs, lecture notes and edited volumes in Big Data spanning the areas of computational intelligence incl. neural networks, evolutionary computation, soft computing, fuzzy systems, as well as artificial intelligence, data mining, modern statistics and Operations research, as well as self-organizing systems. Of particular value to both the contributors and the readership are the short publication timeframe and the world-wide distribution, which enable both wide and rapid dissemination of research output. More information about this series at http://www.springer.com/series/11970 Constandinos X. Mavromoustakis George Mastorakis ⋅ Ciprian Dobre Editors Advances in Mobile Cloud Computing and Big Data in the 5G Era 123 Editors Constandinos X.
    [Show full text]
  • Filesystem Performance on Freebsd
    Filesystem Performance on FreeBSD Kris Kennaway [email protected] BSDCan 2006, Ottawa, May 12 Introduction ● Filesystem performance has many aspects ● No single metric for quantifying it ● I will focus on aspects that are relevant for my workloads (concurrent package building) ● The main relevant filesystem workloads seem to be – Concurrent tarball extraction – Recursive filesystem traversals ● Aim: determine relative performance of FreeBSD 4.x, 5.x and 6.x on these workloads – Overall performance and SMP scaling – Evaluate results of multi-year kernel locking strategy as it relates to these workloads Outline ● SMP architectural differences between 4/5/6.x ● Test methodology ● Hardware used ● Parallel tarball extraction test – Disk array and memory disk ● Scaling beyond 4 CPUs ● Recursive filesystem traversal test ● Conclusions & future work SMP Architectural Overview ● FreeBSD 4.x; rudimentary SMP support – Giant kernel lock restricts kernel access to one process at a time – SPL model; interrupts may still be processed in parallel ● FreeBSD 5.x; aim towards greater scalability – Giant-locked to begin with; then finer-grained locking pushdown ● FreeBSD 5.3; VM Giant-free ● FreeBSD 5.4; network stack Giant-free (mostly) ● Many other subsystems/drivers also locked – Interrupts as kernel threads; compete for common locks (if any) with everything else ● FreeBSD 6.x; – Consolidation; further pushdown; payoff! – VFS subsystem, UFS filesystem Giant-free FreeBSD versions ● FreeBSD 4.11-STABLE (11/2005) – Needed for amr driver fixes after 4.11-RELEASE ● FreeBSD 5.4-STABLE (11/05) – No patches needed ● FreeBSD 6.0-STABLE (11/05) – patches: ● Locking reworked in amr driver by Scott Long for better performance ● All relevant changes merged into FreeBSD 6.1 – A kernel panic was encountered at very high I/O loads ● Also fixed in 6.1 Test aims and Methodology ● Want to measure – overall performance difference between FreeBSD branches under varying (concurrent process I/O) loads – scaling to multiple CPUs ● Avoid saturating hardware resources (e.g.
    [Show full text]
  • On the Defectiveness of SCHED DEADLINE W.R.T. Tardiness and Afinities, and a Partial Fix Stephen Tang Luca Abeni James H
    On the Defectiveness of SCHED_DEADLINE w.r.t. Tardiness and Afinities, and a Partial Fix Stephen Tang Luca Abeni James H. Anderson [email protected] {sytang,anderson}@cs.unc.edu Scuola Superiore Sant’Anna University of North Carolina at Chapel Hill Pisa, Italy Chapel Hill, USA ABSTRACT create new DL tasks until existing DL tasks reduce their bandwidth SCHED_DEADLINE (DL for short) is an Earliest-Deadline-First consumption. Note that preventing over-utilization is only a neces- sary condition for guaranteeing that tasks meet deadlines. (EDF) scheduler included in the Linux kernel. A question motivated Instead of guaranteeing that deadlines will be met, AC satisfes by DL is how EDF should be implemented in the presence of CPU afnities to maintain optimal bounded tardiness guarantees. Recent two goals [3]. The frst goal is to provide performance guarantees. works have shown that under arbitrary afnities, DL does not main- Specifcally, AC guarantees to each DL task that its long-run con- tain such guarantees. Such works have also shown that repairing sumption of CPU bandwidth remains within a bounded margin DL to maintain these guarantees would likely require an impractical of error from a requested rate. The second goal is to avoid the overhaul of the existing code. In this work, we show that for the starvation of lower-priority non-DL workloads. Specifcally, AC special case where afnities are semi-partitioned, DL can be modi- guarantees that some user-specifed amount of CPU bandwidth fed to maintain tardiness guarantees with minor changes. We also will remain for the execution of non-DL workloads.
    [Show full text]
  • The Many Approaches to Real-Time and Safety Critical Linux Systems
    Corporate Technology The Many Approaches to Real-Time and Safety-Critical Linux Open Source Summit Japan 2017 Prof. Dr. Wolfgang Mauerer Siemens AG, Corporate Research and Technologies Smart Embedded Systems Corporate Competence Centre Embedded Linux Copyright c 2017, Siemens AG. All rights reserved. Page 1 31. Mai 2017 W. Mauerer Siemens Corporate Technology Corporate Technology The Many Approaches to Real-Time and Safety-Critical Linux Open Source Summit Japan 2017 Prof. Dr. Wolfgang Mauerer, Ralf Ramsauer, Andreas Kolbl¨ Siemens AG, Corporate Research and Technologies Smart Embedded Systems Corporate Competence Centre Embedded Linux Copyright c 2017, Siemens AG. All rights reserved. Page 1 31. Mai 2017 W. Mauerer Siemens Corporate Technology Overview 1 Real-Time and Safety 2 Approaches to Real-Time Architectural Possibilities Practical Approaches 3 Approaches to Linux-Safety 4 Guidelines and Outlook Page 2 31. Mai 2017 W. Mauerer Siemens Corporate Technology Introduction & Overview About Siemens Corporate Technology: Corporate Competence Centre Embedded Linux Technical University of Applied Science Regensburg Theoretical Computer Science Head of Digitalisation Laboratory Target Audience Assumptions System Builders & Architects, Software Architects Linux Experience available Not necessarily RT-Linux and Safety-Critical Linux experts Page 3 31. Mai 2017 W. Mauerer Siemens Corporate Technology A journey through the worlds of real-time and safety Page 4 31. Mai 2017 W. Mauerer Siemens Corporate Technology Outline 1 Real-Time and Safety 2 Approaches to Real-Time Architectural Possibilities Practical Approaches 3 Approaches to Linux-Safety 4 Guidelines and Outlook Page 5 31. Mai 2017 W. Mauerer Siemens Corporate Technology Real-Time: What and Why? I Real Time Real Fast Deterministic responses to stimuli Caches, TLB, Lookahead Bounded latencies (not too late, not too Pipelines early) Optimise average case Repeatable results Optimise/quantify worst case Page 6 31.
    [Show full text]
  • A Modular Soft Processor Core in VHDL
    A Modular Soft Processor Core in VHDL Jack Whitham 2002-2003 This is a Third Year project submitted for the degree of MEng in the Department of Computer Science at the University of York. The project will attempt to demonstrate that a modular soft processor core can be designed and implemented on an FPGA, and that the core can be optimised to run a particular embedded application using a minimal amount of FPGA space. The word count of this project (as counted by the Unix wc command after detex was run on the LaTeX source) is 33647 words. This includes all text in the main report and Appendices A, B and C. Excluding source code, the project is 70 pages in length. i Contents I. Introduction 1 1. Background and Literature 1 1.1. Soft Processor Cores . 1 1.2. A Field Programmable Gate Array . 1 1.3. VHSIC Hardware Definition Language (VHDL) . 2 1.4. The Motorola 68020 . 2 II. High-level Project Decisions 3 2. Should the design be based on an existing one? 3 3. Which processor should the soft core be based upon? 3 4. Which processor should be chosen? 3 5. Restating the aims of the project in terms of the chosen processor 4 III. Modular Processor Design Decisions 4 6. Processor Design 4 6.1. Alternatives to a complete processor implementation . 4 6.2. A real processor . 5 6.3. Instruction Decoder and Control Logic . 5 6.4. Arithmetic and Logic Unit (ALU) . 7 6.5. Register File . 7 6.6. Links between Components .
    [Show full text]
  • USENIX October Proof 3
    FOR THE PAST COUPLE OF MONTHS, I have become absorbed in operating sys- RIK FARROW tems. My quest began with some consult- ing regarding security features of the cur- rent Linux kernel, including SELinux, then plunged even deeper during the HotOS workshop. I do not pretend to be a kernel hacker, but I am very interested in what musings goes on with the design and implementa- Rik Farrow provides UNIX and Internet security con- tion of operating system software. sulting and training. He is the author of UNIX System Security and System Administrator’s Guide to System V and editor of the SAGE Short Topics in System Like some others, I had wondered what had hap- Administration series. pened to FreeBSD 4’s stellar performance when Free- [email protected] BSD 5 appeared. Instead of getting faster, FreeBSD was slower. If I had bothered digging deeper, I would have learned that this was the result of far-reaching changes in the FreeBSD kernel. Michael W. Lucas ex- plains these changes in his article, which in turn is based on a talk given by Robert Watson about modify- ing the kernel to support SMP (symmetric multipro- cessing). And perhaps by the time you read this col- umn, FreeBSD 6 will have appeared, ready to utilize the new multiprocessor cores that are popping up. Lucas explains just why the transition from single- threaded to multi-threaded kernel takes so long and is so hard to do right. I first understood the importance of the Big Giant Lock when I was reviewing an early multiprocessing server that used SPARC processors.
    [Show full text]