DOCSLIB.ORG

RTEMS User Manual Release 5.E733a39-Modified (12Th March 2020) © 1988, 2020 RTEMS Project and Contributors

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
RTEMS User Manual Release 5.E733a39-Modified (12Th March 2020) © 1988, 2020 RTEMS Project and Contributors RTEMS User Manual Release 5.e733a39-modified (12th March 2020) © 1988, 2020 RTEMS Project and contributors CONTENTS 1 Introduction 3 1.1 Overview........................................4 1.2 Features.........................................5 1.3 Ecosystem.......................................8 1.3.1 Rational....................................8 1.3.2 Open Source..................................8 1.3.3 Deployment..................................9 1.4 Real-time Application Systems............................ 10 1.5 Real-time Executive.................................. 11 2 Quick Start 13 2.1 Preparation....................................... 14 2.1.1 Host Computer................................ 14 2.1.2 Selecting a BSP................................ 14 2.2 Choose an Installation Prefix............................. 15 2.3 Obtain the Sources................................... 16 2.3.1 Releases.................................... 16 2.3.2 Git....................................... 16 2.3.3 Offline Download............................... 17 2.4 Install the Tool Suite.................................. 18 2.5 Bootstrap the RTEMS Sources............................. 20 2.6 Build a Board Support Package (BSP)........................ 21 2.6.1 RSB BSP Build................................. 21 2.6.2 Manual BSP Build............................... 22 2.7 Test a Board Support Package (BSP)......................... 25 2.8 Build Your Application................................. 26 2.9 Build an RSB Package................................. 30 2.9.1 RTEMS Packages............................... 30 2.9.2 BSP Stack Build................................ 30 2.9.3 Package Build................................. 31 3 Support and Contributing 33 3.1 RTEMS Project Support................................ 34 3.1.1 Users Mailing List............................... 34 3.1.2 Documentation................................ 34 3.1.3 All Mailing Lists................................ 34 3.1.4 IRC....................................... 34 3.2 Report Bugs...................................... 35 i 3.2.1 Search for Existing Bugs........................... 35 3.2.2 Not RTEMS Bugs............................... 35 3.2.3 Good Bug Reports............................... 36 3.2.4 Nobody Fixes my Bug............................. 37 3.3 Contributing...................................... 38 3.3.1 How to Contribute?.............................. 38 3.3.2 Preparing and Sending Patches....................... 38 3.3.3 Checklist for Patches............................. 38 3.3.4 Patch Review Process............................. 39 3.3.5 Why Contribute?............................... 39 3.3.6 Common Questions and Answers...................... 41 3.4 Commercial Support Services............................. 43 4 Host Computer 45 4.1 Host Operating Systems................................ 46 4.2 POSIX Hosts...................................... 48 4.2.1 Root Access.................................. 48 4.2.2 Linux...................................... 48 4.2.2.1 ArchLinux.............................. 48 4.2.2.2 CentOS................................ 49 4.2.2.3 Fedora................................ 49 4.2.2.4 Raspbian............................... 49 4.2.2.5 Ubuntu................................ 49 4.2.2.6 Linux Mint.............................. 50 4.2.2.7 openSUSE.............................. 50 4.2.3 FreeBSD.................................... 50 4.2.4 NetBSD.................................... 50 4.3 Apple macOS...................................... 51 4.3.1 Catalina.................................... 51 4.3.2 Sierra..................................... 51 4.3.3 Mavericks................................... 51 4.4 Microsoft Windows.................................. 52 4.4.1 Windows Path Length............................. 52 4.4.2 Windows Spaces In Paths........................... 52 4.4.3 Parallel Builds with Make.......................... 53 4.4.4 POSIX Support................................ 53 4.4.5 Python..................................... 53 4.4.6 MSYS2..................................... 53 4.4.7 Cygwin..................................... 55 5 Installation 59 5.1 Releases......................................... 60 5.1.1 RTEMS Tools and Kernel........................... 60 5.2 Developer (Unstable)................................. 67 5.2.1 POSIX and OS X Host Tools Chain...................... 67 5.2.2 Windows Host Tool Chain.......................... 72 5.2.2.1 RTEMS Windows Tools....................... 72 5.2.2.2 Building the Kernel......................... 75 5.3 RTEMS Kernel..................................... 81 5.3.1 Development Sources............................. 81 5.3.2 Tools Path Set Up............................... 81 5.3.3 Bootstrapping................................. 81 ii 5.3.4 Building a BSP................................ 82 5.3.5 Installing A BSP................................ 85 5.3.6 Contributing Patches............................. 86 5.4 Project Sandboxing.................................. 88 6 Target Hardware 91 6.1 Targets......................................... 92 6.2 Architectures...................................... 93 6.3 Tiers.......................................... 95 7 Board Support Packages 97 7.1 aarch64 (AArch64).................................. 98 7.2 arm (ARM)....................................... 99 7.2.1 altera-cyclone-v (Intel Cyclone V)...................... 99 7.2.1.1 Boot via U-Boot........................... 99 7.2.1.2 Clock Driver............................. 99 7.2.1.3 Console Driver............................ 99 7.2.1.4 I2C Driver.............................. 99 7.2.1.5 Network Interface Driver...................... 99 7.2.1.6 MMC/SDCard Driver........................ 100 7.2.1.7 USB Host Driver........................... 100 7.2.1.8 Caveats................................ 100 7.2.2 atsam..................................... 100 7.2.3 beagle..................................... 100 7.2.3.1 Boot via U-Boot........................... 100 7.2.3.2 Getting the Device Tree Blob.................... 101 7.2.3.3 Writing the uEnv.txt file....................... 101 7.2.3.4 I2C Driver.............................. 101 7.2.3.5 SPI Driver............................... 101 7.2.4 csb336..................................... 102 7.2.5 edb7312.................................... 102 7.2.6 gdbarmsim.................................. 102 7.2.7 gumstix.................................... 102 7.2.8 imx (NXP i.MX)................................ 102 7.2.8.1 Build Configuration Options.................... 102 7.2.8.2 Boot via U-Boot........................... 103 7.2.8.3 Clock Driver............................. 103 7.2.8.4 Console Driver............................ 103 7.2.8.5 I2C Driver.............................. 103 7.2.8.6 SPI Driver............................... 103 7.2.8.7 Network Interface Driver...................... 104 7.2.8.8 MMC/SDCard Driver........................ 104 7.2.8.9 Caveats................................ 104 7.2.9 lm3s69xx................................... 104 7.2.10 lpc176x.................................... 104 7.2.11 imx (NXP i.MX)................................ 105 7.2.11.1 Build Configuration Options.................... 105 7.2.11.2 Boot via U-Boot........................... 105 7.2.11.3 Clock Driver............................. 106 7.2.11.4 Console Driver............................ 106 7.2.11.5 I2C Driver.............................. 106 7.2.11.6 SPI Driver............................... 106 iii 7.2.11.7 Network Interface Driver...................... 106 7.2.11.8 MMC/SDCard Driver........................ 107 7.2.11.9 Caveats................................ 107 7.2.12 raspberrypi.................................. 107 7.2.12.1 Setup SD card............................ 107 7.2.12.2 Kernel image............................. 107 7.2.12.3 Testing using QEMU......................... 108 7.2.13 realview-pbx-a9................................ 109 7.2.14 rtl22xx..................................... 109 7.2.15 smdk2410................................... 109 7.2.16 tms570..................................... 109 7.2.17 xen (Xen on ARM).............................. 109 7.2.17.1 Execution............................... 109 7.2.17.2 Additional Information....................... 110 7.2.18 xilinx-zynq................................... 110 7.2.19 xilinx-zynqmp................................. 110 7.3 bfin (Blackfin)..................................... 111 7.3.1 bf537Stamp.................................. 111 7.3.2 eZKit533.................................... 111 7.3.3 TLL6527M................................... 111 7.4 epiphany (Epiphany)................................. 112 7.4.1 epiphany_sim................................. 112 7.5 i386........................................... 113 7.5.1 pc386..................................... 113 7.6 lm32 (LatticeMicro32)................................. 114 7.6.1 lm32_evr................................... 114 7.6.2 milkymist................................... 114 7.7 m68k (Motorola 68000 / ColdFire)......................... 115 7.7.1 av5282..................................... 115 7.7.2 csb360..................................... 115 7.7.3 gen68340................................... 115 7.7.4 gen68360................................... 115 7.7.5 genmcf548x.................................. 115 7.7.6 mcf5206elite................................. 115 7.7.7 mcf52235................................... 115 7.7.8 mcf5225x................................... 115 7.7.9 mcf5235...................................
Load more

Recommended publications
  • Buildbot: a Continuous Integration System
    Buildbot: A continuous integration system Krzysztof Voss January, 2013 Outline • Testing and Continuous Integration • Introduction to Buildbot • BuildMaster • BuildMaster components • BuildSlave • Installation and Usage 1 Testing and continuous integration Tests: • the best specification • safety-net for refactoring • bug identification Tests are the most effective if we: • run them often • run them on different machines/environments • can easily see their results 2 The most straightforward approach would entail: • logging in to different machines • fetching the newest source code • running tests • analyzing their output In case we want to test a few environments, repeating the above steps is tedious. Developers do not focus on the code, instead they run tests. A continuous integration system performs all of these steps for us, so developers can focus on their code. 3 Introduction to Buildbot: Features • run builds on a variety of BuildSlave platforms • arbitrary build process: handles projects using C, Python, . • minimal host requirements: python and Twisted • BuildSlave can be behind a firewall if they can still do checkout • status delivery through web page, email, IRC, other protocols • track builds in progress, provide estimated completion time • flexible configuration by subclassing generic build process classes 4 • debug tools to force a new build, submit fake Changes, query BuildSlave status • released under the GPL source: http://buildbot.net/buildbot/docs/current/manual/introduction.html 5 Introduction to Buildbot: Overview system overview source: http://buildbot.net/buildbot/docs/0.8.1/full.html 6 BuildMaster BuildMaster components source: http://buildbot.net/buildbot/docs/0.8.1/full.html 7 BuildMaster BuildMaster: • holds the configuration of the entire system.
    [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]
  • Analysis of Devops Tools to Predict an Optimized Pipeline by Adding Weightage for Parameters
    International Journal of Computer Applications (0975 – 8887) Volume 181 – No. 33, December 2018 Analysis of DevOps Tools to Predict an Optimized Pipeline by Adding Weightage for Parameters R. Vaasanthi V. Prasanna Kumari, PhD S. Philip Kingston Research Scholar, HOD, MCA Project Manager SCSVMV University Rajalakshmi Engineering Infosys, Mahindra City, Kanchipuram College, Chennai Chennai ABSTRACT cloud. Now-a-days more than ever, DevOps [Development + Operations] has gained a tremendous amount of attention in 2. SCM software industry. Selecting the tools for building the DevOps Source code management (SCM) is a software tool used for pipeline is not a trivial exercise as there are plethora’s of tools development, versioning and enables team working in available in market. It requires thought, planning, and multiple locations to work together more effectively. This preferably enough time to investigate and consult other plays a vital role in increasing team’s productivity. Some of people. Unfortunately, there isn’t enough time in the day to the SCM tools, considered for this study are GIT, SVN, CVS, dig for top-rated DevOps tools and its compatibility with ClearCase, Mercurial, TFS, Monotone, Bitkeeper, Code co- other tools. Each tool has its own pros/cons and compatibility op, Darcs, Endevor, Fossil, Perforce, Rational Synergy, of integrating with other tools. The objective of this paper is Source Safe, and GNU Bazaar. Table1 consists of SCM tools to propose an approach by adding weightage to each with weightage. parameter for the curated list of the DevOps tools. 3. BUILD Keywords Build is a process that enables source code to be automatically DevOps, SCM, dependencies, compatibility and pipeline compiled into binaries including code level unit testing to ensure individual pieces of code behave as expected [4].
    [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]
  • OPERATING SYSTEMS.Ai
    Introduction Aeroflex Gaisler provides LEON and ERC32 users with a wide range of popular embedded operating systems. Ranging from very small footprint task handlers to full featured Real-Time Operating System (RTOS). A summary of available operating systems and their characteristics is outlined below. VxWorks The VxWorks SPARC port supports LEON3/4 and LEON2. Drivers for standard on-chip peripherals are included. The port supports both non-MMU and MMU systems allowing users to program fast and secure applications. Along with the graphical Eclipse based workbench comes the extensive VxWorks documentation. • MMU and non-MMU system support • SMP support (in 6.7 and later) • Networking support (Ethernet 10/100/1000) • UART, Timer, and interrupt controller support • PCI, SpaceWire, CAN, MIL-STD-1553B, I2C and USB host controller support • Eclipse based Workbench • Commercial license ThreadX The ThreadX SPARC port supports LEON3/4 and its standard on-chip peripherals. ThreadX is an easy to learn and understand advanced pico-kernel real-time operating system designed specifically for deeply embedded applications. ThreadX has a rich set of system services for memory allocation and threading. • Non-MMU system support • Bundled with newlib C library • Support for NetX, and USBX ® • Very small footprint • Commercial license Nucleus Nucleus is a real time operating system which offers a rich set of features in a scalable and configurable manner. • UART, Timer, Interrupt controller, Ethernet (10/100/1000) • TCP offloading and zero copy TCP/IP stack (using GRETH GBIT MAC) • USB 2.0 host controller and function controller driver • Small footprint • Commercial license LynxOS LynxOS is an advanced RTOS suitable for high reliability environments.
    [Show full text]
  • Final Report
    Parallel Programming Models for Space Systems BSC - Evidence ESA Contract No. 4000114391/15/NL/Cbi/GM Final Report Parallel Programming Models for Space Systems (ESA Contract No. 4000114391/15/NL/Cbi/GM) Main contractor Subcontractor Barcelona Supercomputing Center (BSC) Evidence Srl. Eduardo Quiñones, Paolo Gai, [email protected] [email protected] Dissemination level: All information contained in this document is puBlic June 2016 1 Parallel Programming Models for Space Systems BSC - Evidence ESA Contract No. 4000114391/15/NL/Cbi/GM Table of Contents 1 Introduction ..................................................................................................... 3 2 Future work: Next development activities to reach higher TRL (5/6) ................ 4 Annex I - D1.1. Report on parallelisation experiences for the space application .... 5 Annex II - D2.1. Report on the evaluation of current implementations of OpenMP ............................................................................................................................ 23 Annex III - D3.1. Report on the applicability of OpenMP4 on multi-core space platforms ............................................................................................................ 36 2 Parallel Programming Models for Space Systems BSC - Evidence ESA Contract No. 4000114391/15/NL/Cbi/GM 1 Introduction High-performance parallel architectures are becoming a reality in the critical real-time embedded systems in general, and in the space domain in particular. This is the case of the
    [Show full text]
  • KINTSUGI Identifying & Addressing Challenges in Embedded Binary
    KINTSUGI Identifying & addressing challenges in embedded binary security jos wetzels Supervisors: Prof. dr. Sandro Etalle Ali Abbasi, MSc. Department of Mathematics and Computer Science Eindhoven University of Technology (TU/e) June 2017 Jos Wetzels: Kintsugi, Identifying & addressing challenges in embed- ded binary security, © June 2017 To my family Kintsugi ("golden joinery"), is the Japanese art of repairing broken pottery with lacquer dusted or mixed with powdered gold, silver, or platinum. As a philosophy, it treats breakage and repair as part of the history of an object, rather than something to disguise. —[254] ABSTRACT Embedded systems are found everywhere from consumer electron- ics to critical infrastructure. And with the growth of the Internet of Things (IoT), these systems are increasingly interconnected. As a re- sult, embedded security is an area of growing concern. Yet a stream of offensive security research, as well as real-world incidents, contin- ues to demonstrate how vulnerable embedded systems actually are. This thesis focuses on binary security, the exploitation and miti- gation of memory corruption vulnerabilities. We look at the state of embedded binary security by means of quantitative and qualitative analysis and identify several gap areas and show embedded binary security to lag behind the general purpose world significantly. We then describe the challenges and limitations faced by embedded exploit mitigations and identify a clear open problem area that war- rants attention: deeply embedded systems. Next, we outline the cri- teria for a deeply embedded exploit mitigation baseline. Finally, as a first step to addressing this problem area, we designed, implemented and evaluated µArmor : an exploit mitigation baseline for deeply em- bedded systems.
    [Show full text]
  • Studying Routing Issues in Vanets by Using NS-3 Bachelor Thesis on Informatics
    Studying Routing Issues in VANETs by Using NS-3 Bachelor Thesis on Informatics by Christos Profentzas Thesis supervisor Dr. Periklis Chatzimisios Alexander Technological Educational Institute of Thessaloniki Department of Informatics A.T.E.I. of Thessaloniki P.O. Box 141 GR -547 00 Thessaloniki, Macedonia, Greece November 2012 i Acknowledgements This research project would not have been possible without the sup- port of many people. The author wishes to express his gratitude to his supervisor, Assistant Professor Periklis Chatzimisios (Alexan- der TEI of Thessaloniki, Greece) and Assistant Professor Gennaro Boggia (Politecnico di Bari, Italy) who was abundantly helpful and offered invaluable assistance, support and guidance. Deepest grati- tude are also due to the members of the supervisory committee, Assis- tant Professor Luigi Alfredo Grieco and Ph.D Student Giuseppe Piro without whose knowledge and assistance this study would not have been successful. Special thanks also to all group members of Telematics Lab at the Electrical & Electronics Engineering Depart- ment of Politecnico di Bari, for sharing the literature, invaluable assis- tance and laboratory facilities. The author would also like to convey thanks to the Office of Erasmus Program and Faculty of Alexander Technological Educational Institution of Thessaloniki for providing the financial means. Abstract A Vehicular Ad-hoc Network (VANET) is a system of nodes (vehi- cles) that are being connected with each other by wireless technolo- gies. Usually the nodes are moving with very high speeds and, thus, the topology is unpredictable and frequently changing. Such networks can be stand alone and making paths along vehicles or may be con- nected by an infrastructure internet.
    [Show full text]
  • Flight Software Workshop 2007 ( FSW-07)
    Flight Software Workshop 2007 ( FSW-07) Current and Future Flight Operating Systems Alan Cudmore Flight Software Branch NASAIGSFC November 2007 Page I Outline Types of Real Time Operating Systems - Classic Real Time Operating Systems - Hybrid Real Time Operating Systems - Process Model Real Time Operating Systems - Partitioned Real Time Operating Systems Is the Classic RTOS Showing it's Age? Process Model RTOS for Flight Systems Challenges of Migrating to a Process Model RTOS Which RTOS Solution is Best? Conclusion November 2007 Page 2 GSFC Satellites with COTS Real (waiting for launch) (launched 8/92) (launched 12/98) (launched 3/98) (launched 2/99) (12/04) XTE (launched 12/95) TRMM (launched 11/97) JWST lSlM (201 1) Icesat GLAS f01/03) MAP (launched 06/01) LRO HST 386 4llH -%Y ST-5 (5/06) November 2007 Page 3 Classic Real Time OS What is a "Classic" RTOS? - Developed for easy COTS development on common 16 and 32 bit CPUs. - Designed for systems with single address space, and low resources - Literally Dozens of choices with a wide array of features. November 2007 Page 4 Classic RTOS - VRTX Ready Systems VRTX Size: Small - 8KB RTOS Kernel Provides: Very basic RTOS services Used on: - Small Explorer Missions Used from 1992 to 1999 8086 and 80386 Processors - Medium Explorer Missions XTE (1995) TRMM (1997) 80386 Processors - Hubble Space Telescope 80386 Processors Advantages: - Small, fast - Uses 80386 memory protection -- A feature we have missed since we stopped using it! Current use: - Only being maintained, not used for new development
    [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]
  • This Book Doesn't Tell You How to Write Faster Code, Or How to Write Code with Fewer Memory Leaks, Or Even How to Debug Code at All
    Practical Development Environments By Matthew B. Doar ............................................... Publisher: O'Reilly Pub Date: September 2005 ISBN: 0-596-00796-5 Pages: 328 Table of Contents | Index This book doesn't tell you how to write faster code, or how to write code with fewer memory leaks, or even how to debug code at all. What it does tell you is how to build your product in better ways, how to keep track of the code that you write, and how to track the bugs in your code. Plus some more things you'll wish you had known before starting a project. Practical Development Environments is a guide, a collection of advice about real development environments for small to medium-sized projects and groups. Each of the chapters considers a different kind of tool - tools for tracking versions of files, build tools, testing tools, bug-tracking tools, tools for creating documentation, and tools for creating packaged releases. Each chapter discusses what you should look for in that kind of tool and what to avoid, and also describes some good ideas, bad ideas, and annoying experiences for each area. Specific instances of each type of tool are described in enough detail so that you can decide which ones you want to investigate further. Developers want to write code, not maintain makefiles. Writers want to write content instead of manage templates. IT provides machines, but doesn't have time to maintain all the different tools. Managers want the product to move smoothly from development to release, and are interested in tools to help this happen more often.
    [Show full text]
  • Timing Comparison of the Real-Time Operating Systems for Small Microcontrollers
    S S symmetry Article Timing Comparison of the Real-Time Operating Systems for Small Microcontrollers Ioan Ungurean 1,2 1 Faculty of Electrical Engineering and Computer Science; Stefan cel Mare University of Suceava, 720229 Suceava, Romania; [email protected] 2 MANSiD Integrated Center, Stefan cel Mare University, 720229 Suceava, Romania Received: 9 March 2020; Accepted: 1 April 2020; Published: 8 April 2020 Abstract: In automatic systems used in the control and monitoring of industrial processes, fieldbuses with specific real-time requirements are used. Often, the sensors are connected to these fieldbuses through embedded systems, which also have real-time features specific to the industrial environment in which it operates. The embedded operating systems are very important in the design and development of embedded systems. A distinct class of these operating systems is real-time operating systems (RTOSs) that can be used to develop embedded systems, which have hard and/or soft real-time requirements on small microcontrollers (MCUs). RTOSs offer the basic support for developing embedded systems with applicability in a wide range of fields such as data acquisition, internet of things, data compression, pattern recognition, diversity, similarity, symmetry, and so on. The RTOSs provide basic services for multitasking applications with deterministic behavior on MCUs. The services provided by the RTOSs are task management and inter-task synchronization and communication. The selection of the RTOS is very important in the development of the embedded system with real-time requirements and it must be based on the latency in the handling of the critical operations triggered by internal or external events, predictability/determinism in the execution of the RTOS primitives, license costs, and memory footprint.
    [Show full text]