ARM Cortex-A Family (V7-A): General Purpose Processors - Applications Processors for Full OS and 3Rd Party Applications

Total Page:16

File Type:pdf, Size:1020Kb

ARM Cortex-A Family (V7-A): General Purpose Processors - Applications Processors for Full OS and 3Rd Party Applications ARM architecture Computer architecture M 1 History • Acorn computer: an english company Cambridge spin-off (UK) which had developed a 8 bit microprocessor for the BBC on 6502 architecture (Synertek e Rockwell) • In 1982 Acorn engineers looked for a new microprocessor per more sophisticated applications but decided against CISC solutions because too slow for the specific requirements and interrupt latency time • They decided to design a totally new architecture. At the same time Stanford RISC I and II and MIPS (Microprocessor without Interlocked Pipeline Stages) of Berkley appeared on the market Berkley and they decided to follow that philosophy • ARM (Advanced RISC Machine) whose three stages is still now used • ARM is now a true industry (from 1990) and a «brand» with multiple implementations and is used by many processor companies (Intel too) in multiple environments in tailored versions (Intellectual Property – IP - cores) • Design software can be bought (Verilog) – soft core 2 ARM • T: Thumb • D: On-chip debug support • M: Enhanced multiplier • I: Embedded ICE hardware • T2: Thumb-2 • S: Synthesizable code • E: Enhanced DSP instruction set • J: JAVA support • Z: TrustZone • F: Floating point unit • H: Handshake, clockless design for synchronous or asynchronous design 3 ARM- base concepts • Arm is a family of Risc processors conceptually similar to DLX • There are several versions from a very simple to a very sophisticated one • Multiple environments (i.e. mobile phones) Apple iPod Photo e iPod Video 5th gen (2X, @80MHz) Roomba 500 Lego Mindstorm 4 ARM – first version • LOAD/STORE architecture very simple since the designers had no full-custom previous experience • 32 bit fixed length instructions • Three addresses instructions RISC type (with some exceptions CISC type) • Fixed register bank. Obviously in addition to programmer visible registers there are the machine registers • Single cycle instructions but potentially multiple cycle since the no Harvard architecture is implemented. When more that a single memory access is required (i.e. a LOAD) the extra cycles are used for useful microoperations (i.e. autoindex address) 5 Tthree stages ARM • 16 32-bit general-purpose registers (r0 - r15) • Three ports register bank (two for reading and one for writing) An additional port for read and write register 15 (PC) • N-positions barrel shifter • 32 bit ALU • The address register is provided with an incrementer (for sequential accesses) – In practice it is a programmable counter • Two buffer registers for data to and from the memory (invisible to the programmer). Single bank memory • Instructions decoder and control logic • Status register (CSPR) • Two interrupts: fast and standard 6 ARM register set r0 fiq: fast interrupt r1 r0-r7-are common to svc: software interrupt r2 user and system mode abt: memory faults (abort) irq: standard interrupt r3 und:undefined instructions r4 r5 r6 r7 System mode only r8_fiq r8 r9-fiq r9 r10_fiq r10 r11_fiq r13_und r11 r13_irq r12_fiq r13_abt r14_und r12 r13_svc r14_irq r13_fiq r14_abt r13 (MSP) r14_svc r14_fiq r14 (LR) SPSR_und r15 (PC) SPSR_irq SPSR_abt SPSR_svc SPSR_fiq CPSR User mode fiq mode svc mode abort mode irq mode undef. mode CPSR Current Program Status Register SPSR Saved Processor Status Register MSP Master Stack Pointer LR Link Register (return register for subroutines) 7 Current Program Status Register CPSR (similar to flag register) 31 28 27 8 7 6 5 4 0 N Z C V Unused I F T Mode Condition codes N negative Z zero I,F interrupt masks C carry T Thumb Instr. Set V oVerflow CPSR [4:0] mode Use Used Register Set 10000 User Normal user code user 10001 FIQ Processing Fast interrupt fiq 10010 IRQ Processing standard interrupts irq 10011 SVC Processing software interrupts svc 10111 Abort Processing memory faults abt 11011 Undef Handling undefined instructions trap und 11111 System Running privileged operating system tasks user Each privileged mode has a Saved Program Status Register SPSR where the current CPSR is saved and a specific r14 (Link Register) NB Thumb Instruction Set: higly encoded instructions for memory save 8 Exceptions When an exception occurs: 1) The corresponding mode is activated 2) The PC (r15) is saved in r14 (link register) of the new mode 3) The old CSPR is saved in the SPSR of the new mode 4) IRQ is disabled setting bit 7 of CSPR and if the exception corresponds to the Fast Interrupt CSPR bit6 is set 5) PC assumes the value of the following table (fixed addresses) Exception Mode Address Reset SVC 00000000 Undef. Instr. UND 00000004 Soft. Int. (SWI) SVC 00000008 Prefetch Abort ( Instr.Mem. Fault) Abort 0000000C Data Abort (Data Mem. Fault) Abort 00000010 IRQ IRQ 00000018 FIQ FIQ 0000001C 00000014 cannot be used (old ARMs compatibility) 9 ARM three stages pipeline Write Read Read 10 Organisation • Register bank (=Register File): two ports (read) and one port (write) - as in DLX – for the normal data traffic plus two accesses (read e write) for r15 (PC) • Memory access register has an incrementer for sequential accesses which is used for incrementing the PC too • One extra register for 32 bit multiplication (when multiplying 32 bit data the result can be longer that 32 bits) • Two transit register for the memory (Datain and Dataout - no harvard architecture initially) • No forwarding unit (not needed because the following instruction finds the updated value already in the RF - three stages pipelines – see next slide) 11 Three stages pipeline Single cycle instructions fetch decode exec.add add r3,r1,r5 sub r2,r3,r6 fetch decode exec. sub cmp r2,#3 fetch decode exec.cmp 1 2 3 time • A single execution clock instruction accesses during the execute stage two operands; the datum on bus B shifted (if required), combined in the ALU with bus A datum. The result is written back in the register bank. The PC is incremented by the incrementer and the result is stored back in r15 AND in the address register for next instruction access • Fetch stage: the instruction is read from the memory into the data-in register for decoding • Decode stage: the instruction in the data-in register (it doesn’t use the datapath) and in the meantime the next instruction is read from the memory and is «clocked» at the end of the fetch stage • Exec stage the instruction uses the datapath. In an arithmetic instruction two operands are read, that on the bus B shifted (combinatorially) if needed and combined with datum on bus A. The result is written back in the RF in the same clock period NB The datum required by an instruction (exec stage) finds the datum already available in the RF. No forwarding unit !!!! 12 Three stages pipeline Multiple cycles instructions Here no fetch because the 1 fetchADD decode execute memory is busy with the WB 2(memory fetch STR decode calc. addr. data xfer Store) 3 fetchADD bubble decode execute The address computation 4 prevents the decoding because fetchADD bubble decode execute the registers towards the ALU cannot be opened 5 Decoder busy No fetch fetchADD decode execute instruction Memory busy time • Multi-cycles instructions are executed more irregularly. In this example an ADD followed by a STORE and three ADDs • The greyed stages are those where the memory is accessed • The datapath is used by the STORE for the address computation • Since the PC(r15) is incremented in the first stage the programmer must be aware that it was already twice incremented (two instructions – 8 bytes) if it has to be used in the exec stage 13 Three stages pipeline Multiple cycles instructions «register based» load with autoincrement ldmia r0!,{r2,r3} fetch decode ex ld r2 ex ld r3 sub r2,r3,r6 fetch decode ex sub cmp r2,#3 fetch decode ex cmp time Ldmia -> Load multiple registers increment address • This instruction loads two registers (in this case r2 and r3) with data starting from the address in r0 (in this case). No need for address computation (value already present in r0). The address is incremented by 4 each load (incrementer) 14 Branch Decision on the third clock bne foo fetch decodexecute linkret adjust sub r2,r3,r6 fetch decod ex add add r13,r14,r2 fetch decod ex add fetch decod ex add foo add r0,r1,r2 time The branch can be with return and the PC value is saved in the linkret stage. The adjust stage adjusts its value which has been already incremented by 8 15 Register/Register instructions Datapath address register incrementer Rd PC(r15) Instruction Reg-Reg registers Rd <= Rn op Rm Rn Rm R15 (PC) <= AR + 4 AR <= AR + 4 multiplier Barrel AR: Address Register as per ins. PC value incremented by 4 as per instruction The same incremented value in the AR data out data in instr. pipe 16 Register/Immediate instructions Datapath address register incrementer Reg-Imm Rd <= Rn op Imm Rd PC(r15) R15(PC) <= AR + 4 registers AR <= AR + 4 Rn In this case the operand is in the instruction multiplier as per ins. As per instruction [7:0] data out data in instr. pipe 17 Store instruction Datapath address register address register Compute address AR <= Rn op Disp increment increment R15 (PC)<= AR + 4 PC Rn PC(r15) registers registers Rn Rd Store data AR <= R15 (PC) mem[AR] <= Rd If autoindexing lsl #0 shifter Rn <= Rn +/- 4 = A / A + B / A - B = A + B / A - B [11:0] data out data in i. pipe byte? data in i. pipe (a) 1st cycle – The STORE address is computed and stored in the AR. In the meantime r15(PC) is incremented and the value stored in the RF ONLY for the next instruction (a) 2nd cycle – r15 (PC) is copied into the AR while the datum is written into the memory and an autoincrement (if required) is executed.
Recommended publications
  • Sistemi Operativi Real-Time Marco Cesati Lezione R13 Sistemi Operativi Real-Time – II Schema Della Lezione
    Sistemi operativi real-time Marco Cesati Lezione R13 Sistemi operativi real-time – II Schema della lezione Caratteristiche comuni VxWorks LynxOS Sistemi embedded e real-time QNX eCos Windows Linux come RTOS 15 gennaio 2013 Marco Cesati Dipartimento di Ingegneria Civile e Ingegneria Informatica Università degli Studi di Roma Tor Vergata SERT’13 R13.1 Sistemi operativi Di cosa parliamo in questa lezione? real-time Marco Cesati In questa lezione descriviamo brevemente alcuni dei più diffusi sistemi operativi real-time Schema della lezione Caratteristiche comuni VxWorks LynxOS 1 Caratteristiche comuni degli RTOS QNX 2 VxWorks eCos 3 LynxOS Windows Linux come RTOS 4 QNX Neutrino 5 eCos 6 Windows Embedded CE 7 Linux come RTOS SERT’13 R13.2 Sistemi operativi Caratteristiche comuni dei principali RTOS real-time Marco Cesati Corrispondenza agli standard: generalmente le API sono proprietarie, ma gli RTOS offrono anche compatibilità (compliancy) o conformità (conformancy) allo standard Real-Time POSIX Modularità e Scalabilità: il kernel ha una dimensione Schema della lezione Caratteristiche comuni (footprint) ridotta e le sue funzionalità sono configurabili VxWorks Dimensione del codice: spesso basati su microkernel LynxOS QNX Velocità e Efficienza: basso overhead per cambi di eCos contesto, latenza delle interruzioni e primitive di Windows sincronizzazione Linux come RTOS Porzioni di codice non interrompibile: generalmente molto corte e di durata predicibile Gestione delle interruzioni “separata”: interrupt handler corto e predicibile, ISR lunga
    [Show full text]
  • POLITECNICO DI MILANO DEPARTMENT of CIVIL and ENVIRONMENTAL ENGINEERING – Environmental Section
    POLITECNICO DI MILANO DEPARTMENT OF CIVIL AND ENVIRONMENTAL ENGINEERING – Environmental Section AWARE – Assessment on Waste and Resources – Research group LITERATURE REVIEW ON THE ASSESSMENT OF THE CARBONATION POTENTIAL OF LIME IN DIFFERENT MARKETS AND BEYOND Customer: EuLA – the European Lime Association Authors: Prof. Mario Grosso (Principal Investigator) Eng. Laura Biganzoli, Francesco Pietro Campo, Sara Pantini, Camilla Tua July 2020 Report n. 845.0202.70.02 To refer to this report, please use the following reference: Grosso M., Biganzoli L., Campo F. P., Pantini S., Tua C. 2020. Literature review on the assessment of the carbonation potential of lime in different markets and beyond. Report prepared by Assessment on Waste and Resources (AWARE) Research Group at Politecnico di Milano (PoliMI), for the European Lime Association (EuLA). Pp. 333. CHAPTER AUTHORS 1 EXECUTIVE SUMMARY F. P. Campo, C. Tua, M. Grosso 2 METHODOLOGY AND SCOPE OF THE WORK F. P. Campo, M. Grosso 3 INTRODUCTION: LIME USE AND APPLICATIONS F. P. Campo, M. Grosso 3.1 USE OF LIME IN IRON AND STEEL INDUSTRY L. Biganzoli, M. Grosso 3.2.1 USE OF LIME IN SAND LIME BRICK C. Tua, M. Grosso APPLICATION 3.2.2 USE OF LIME IN LIGHT-WEIGHT LIME C. Tua, M. Grosso CONCRETE 3.2.3 USE OF LIME IN MORTARS F. P. Campo, M. Grosso 3.2.4 USE OF LIME IN HEMP LIME F. P. Campo, M. Grosso 3.2.5 USE OF LIME IN OTHER CONSTRUCTION F. P. Campo, M. Grosso MATERIALS 3.3.1 USE OF LIME IN SOIL STABILISATION F. P. Campo, C.
    [Show full text]
  • Soft Tools for Robotics and Controls Implementations
    Soft Tools for Robotics and Controls Implementations A Thesis Submitted to the Faculty of Drexel University by Robert M. Sherbert in partial fulfillment of the requirements for the degree of Master of Science in Electrical Engineering June 2011 c Copyright 2011 Robert M. Sherbert. All rights reserved. ii Dedications To the parents who placed me on my path, to the mentors who guided me along its many turns, and to the friends who made the long journey swift. iii Acknowledgments There are a number of people to whom I owe a great deal of thanks in completing this document. While the labor has been my own, the inspiration for it and the support to finish it have come from the community around me. In creating this work I have taken on the role of toolsmith and, as tools are worthless without their users, it is to these individuals that I am especially indebted. I would like to thank Dr. Oh for lending his vision of robotics testing and prototyping which inspired this work. You have taught me more than I realized there was to know about the modern practice of science. I would also like to thank Dr. Chmielewski for lending his experience, insight, and enthusiasm to the project. Having these ideas weighed against and improved by your practical knowledge has provided a very important validation for me. Above all I would like to thank my friends at DASL, without whom the entirety of this project would have been consigned to the dust bin long ago. You have given me not only critical feedback and suggestions but also the support and encouragement that has helped me carry this to completion.
    [Show full text]
  • CSE I Sem Question Bank
    M.Tech (Computer Science and Engineering) R-15 MALLA REDDY COLLEGE OF ENGINEERING & TECHNOLOGY (Autonomous Institution – UGC, Govt. of India) Sponsored by CMR Educational Society (Affiliated to JNTU, Hyderabad, Approved by AICTE - Accredited by NBA & NAAC – ‘A’ Grade - ISO 9001:2008 Certified) Maisammaguda, Dhulapally (Post Via Hakimpet), Secunderabad – 500100, Telangana State, India. Contact Number: 040-23792146/64634237, E-Mail ID: [email protected], website: www.mrcet.ac.in MASTER OF TECHNOLOGY COMPUTER SCIENCE AND ENGINEERING DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING ACADEMIC REGULATIONS COURSE STRUCTURE AND SYLLABUS (Batches admitted from the academic year 2016 - 2017) Note: The regulations hereunder are subject to amendments as may be made by the Academic Council of the College from time to time. Any or all such amendments will be effective from such date and to such batches of candidates (including those already pursuing the program) as may be decided by the Academic Council. Malla Reddy College of Engineering & Technology Page 0 M.Tech (Computer Science and Engineering) R-15 CONTENTS S.No Name of the Subject Page no 1 Advanced Data Structures and Algorithms 7 2 Course Coverage 9 3 Question Bank 10 4 Advanced Operating System 19 5 Course Coverage 20 6 Question Bank 21 7 Computer System Design 31 8 Course Coverage 33 9 Question Bank 34 10 Software Process And Project Management 39 11 Course Coverage 41 12 Question Bank 42 13 Natural Language Processing 49 14 Internet of Things 51 15 Machine Learning 52 16 Software Architecture
    [Show full text]
  • Firmware Pro Robotické Vozítko
    VYSOKÉ UČENÍ TECHNICKÉ V BRNĚ BRNO UNIVERSITY OF TECHNOLOGY FAKULTA ELEKTROTECHNIKY A KOMUNIKAČNÍCH TECHNOLOGIÍ ÚSTAV AUTOMATIZACE A MĚŘICÍ TECHNIKY FACULTY OF ELECTRICAL ENGINEERING AND COMMUNICATION DEPARTMENT OF CONTROL AND INSTRUMENTATION FIRMWARE PRO ROBOTICKÉ VOZÍTKO FIRMWARE FOR THE ROBOTIC VEHICLE DIPLOMOVÁ PRÁCE MASTER'S THESIS AUTOR PRÁCE Bc. LUKÁŠ OTAVA AUTHOR VEDOUCÍ PRÁCE Ing. PAVEL KUČERA, Ph.D. SUPERVISOR BRNO 2013 ABSTRAKT Tato práce je zaměřena na vytvoření firmware pro robotické vozítko, založené na ar- chitektuře ARM Cortex-M3, který využívá operační systém reálného času. Úvodní část obsahuje informace o dostupných operačních systémech reálného času pro malé vestavné systémy, popis architektury ARM Cortex-M3 a hardwarového řešení řídicího systému. Praktická část se zabývá výběrem a měřením zvolených operačních systémů reálného času. Výsledkem práce je firmware složený z programových modulů, které slouží kovlá- dání jednotlivých HW prvků. Je vytvořena také ukázková aplikace, která umožňuje na dálku ovládat pohyb robota a ukládat provozní data robota. KLÍČOVÁ SLOVA ARM, Cortex M3, LM3S8962, reálný čas, RTOS, FreeRTOS, CooCox, CoOS, uC/OSIII, absolutní časování, přepnutí kontextu, DC motor, akcelerometr, FreeRTOS+TRACE, synchronizace, regulátor, SLIP, diagnostika RTOS ABSTRACT This thesis is focused on a firmware for robotic vehicle based on the ARM Cortex- M3 architecture that is running a real-time operating system (RTOS). Theoretical part describes available solutions of embedded RTOS and concrete HW implementation of the robotic vehicle. There is also comparison of the three selected RTOS with their measurements. Result of this thesis is base firmware compounded by a program modules that controls HW parts. There is also a sample PC and firmware application that extends base firmware.
    [Show full text]
  • Järjestelmä Multikopterin Lennonohjaustietokoneessa
    REAALIAIKAKÄYTTÖ- JÄRJESTELMÄ MULTIKOPTERIN LENNONOHJAUSTIETOKONEESSA Olli Paloniemi Opinnäytetyö Toukokuu 2015 Tietotekniikka Sulautetut järjestelmät ja elektroniikka TIIVISTELMÄ Tampereen ammattikorkeakoulu Tietotekniikka Sulautetut järjestelmät ja elektroniikka PALONIEMI, OLLI: Reaaliaikakäyttöjärjestelmä multikopterin lennonohjaustietokoneessa Opinnäytetyö 48 sivua, joista liitteitä 9 sivua Toukokuu 2015 Tämän opinnäytetyön tarkoituksena oli tarkastella multikopterin lennonohjaustietoko- neelle tehdyn laiteohjelmiston suunnitteluun liittyviä asioita. Laiteohjelmiston pohjana toimi avoimen lähdekoodin FreeRTOS-reaaliaikakäyttöjärjestelmä. Laiteohjelmiston testaus tapahtui tarkoitusta varten rakennetussa lennonohjaustietokoneessa, joka asen- nettiin neliroottoriseen multikopteriin. Työssä tutkittiin multikopterien ohjausmenetelmiä. Radio-ohjauselektroniikasta tuttua pulssinleveyden modulaatioon perustuvaa signaalia käytettiin yhdistämään lennonoh- jaustietokone multikopterin muihin komponentteihin. Lennonohjaustietokoneen anturei- ta ja radiovastaanottimelta tulevaa ohjausta hyödynnettiin PID-säätimissä, joiden on tarkoitus vakauttaa multikopterin lento. Antureiden mittaustulokset yhdistettiin anturi- fuusiolla käyttäen Complementary-suodinta. Säätimiä ja anturifuusiota käytettiin eri ohjaustiloissa, jotka määrittävät sen, miten multikopterin lennonohjausjärjestelmä toi- mii. Lennonohjausjärjestelmän toiminnan reaaliaikaisuus todettiin mittaamalla käyttö- järjestelmän suoritus- ja vasteajat. Opinnäytetyön avulla saatiin tietoa muun
    [Show full text]
  • PAN/TILT System Implementation in the Powerleaf to Use This System in Your Project, It Would Require That a Form of Tracking Was Developed
    BSc in Engineering (Robot Systems) University of Southern Denmark July 27 2017 PAN/TILT System Implementation in the PowerLeaf To use this system in your project, it would require that a form of tracking was developed. This could be achieved through a sensor, though rather inefficient. The reason being, that a light sensor functions like a sensitive solar panel, meaning that the sun would be detected for a long time, without even being directly above the pan/tilt system. Another and more practical solution, would be to just store data of the suns position in the system, and then adjust the angle of the pan/tilt system so that it is perpendicular with the sun’s rays. Below, I included the abstract and conclusion of our pan/tilt system project translated to English. Abstract The purpose of this project is to develop a user-friendly system for the regulation and control of a pan/tilt system. Programmable hardware has been designed and implemented for controlling and decoding of the system. The interaction between the user and the hardware is achieved using a microcontroller. Considerations for design, implementation, and user-friendliness have been made. Conclusion A control system for the pan/tilt system has been designed and then implemented. A pan/tilt system can be controlled by the means of a closed-loop controller, in the form of a proportional regulator with speed- control and position-control. Although simulation and testing do not match with each other, the controller functions as intended and provides a satisfactory result if there only the position control is observed.
    [Show full text]
  • Open Interconnect Consortium
    Open Interconnect Consortium Martin Hsu/徐茂容 Intel Open Source Technology Center Content • IoT Opportunities and Challenges • Open Interconnect Consortium Vision • Goals & Strategy • Open Interconnect Consortium – Members & Structure – Standards – Compliance – Marketing – Open Source Project – Roadmap • Technology 2 The Internet of Things is… 50B Intelligence Everywhere 44 DEVICES* ZETTABYTES** Sensors Home/ Gateway Industrial Network DC/Cloud Mobile *** COST OF COST OF COST OF SENSORS 2X BANDWIDTH 40X PROCESSING 60X PAST 10 YEARS PAST 10 YEARS PAST 10 YEARS * IDC ** IMC/EDC: The Digital Universe of Opportunities *** Goldman Sachs Fragmentation Solutions today OIC makes it all work together … Eclipse Foundati Pidora on Microsoft RedHat Azure Google Brillo Vertical Google Debian Android Linux RISC OS Raspbian Cybervisi Micrium on KAA μC-OSII/III Arduino BeRTOS Riot OS Software Wind River freeRTOS VxWorks 2013 Maker Boards Market Share, by Unit Green eCOS Hills U- velOSity Others Nuttx DIY Boards ThreadX Galileo NutOS Platforms Beagle Bone Arduino Raspberry Pi Open Interconnect Vision • Enable IoT – Secure and reliable device discovery and connectivity across multiple OSs, platforms, and technologies • Enable scale – Industry consolidation around a common interoperable approach, across all vertical markets 5 Organization Goals and Strategy Why Open Interconnect Consortium? • Current IoT connectivity difficulties… – Technical issues – Intellectual property rights issues – Organizational/structural issues • Open Interconnect Consortium (OIC)
    [Show full text]
  • Harald Szeemann Artist Files
    http://oac.cdlib.org/findaid/ark:/13030/c86978bx No online items Harald Szeemann artist files Alexis Adkins, Heather Courtney, Judy Chou, Holly Deakyne, Maggie Hughes, B. Karenina Karyadi, Medria Martin, Emmabeth Nanol, Alice Poulalion, Pietro Rigolo, Elena Salza, Laura Schroffel, Lindsey Sommer, Melanie Tran, Sue Tyson, Xiaoda Wang, and Isabella Zuralski. Harald Szeemann artist files 2011.M.30.S2 1 Descriptive Summary Title: Harald Szeemann artist files Date (inclusive): 1836-2010, bulk 1957-2005 Number: 2011.M.30.S2 Creator/Collector: Szeemann, Harald Physical Description: 1400 Linear Feet Repository: The Getty Research Institute Special Collections 1200 Getty Center Drive, Suite 1100 Los Angeles 90049-1688 [email protected] URL: http://hdl.handle.net/10020/askref (310) 440-7390 Abstract: Series II of the Harald Szeemann papers contains artist files on more than 24,000 artists. In addition to fine arts artists, Harald Szeemann created artist files for architects, composers, musicians, film directors, authors and philosphers. The contents of the artist files vary widely from artist to artist, but may include artist statements; artist proposals; biographies; correspondence; exhibition announcements; news clippings; notes; photographs of works of art, exhibitions of the artist; posters; resumes; and original works of art. Due to its size, Series II is described in a separate finding aid. The main finding aid for the Harald Szeemann papers is available here: http://hdl.handle.net/10020/cifa2011m30 Request Materials: Request access to the physical materials described in this inventory through the catalog record for this collection. Click here for the access policy . Language: Collection material is primarily in German with some material in Italian, French, English and other languages.
    [Show full text]
  • Download (8MB)
    New Nonlinear Machine Learning Algorithms with Applications to Biomedical Data Science by Xiaoqian Wang BS, Zhejiang University, 2013 Submitted to the Graduate Faculty of the Swanson School of Engineering in partial fulfillment of the requirements for the degree of Doctor of Philosophy University of Pittsburgh 2019 UNIVERSITY OF PITTSBURGH SWANSON SCHOOL OF ENGINEERING This dissertation was presented by Xiaoqian Wang It was defended on May 31, 2019 and approved by Heng Huang, PhD, John A. Jurenko Endowed Professor, Department of Electrical and Computer Engineering Zhi-Hong Mao, PhD, Professor, Department of Electrical and Computer Engineering Wei Gao, PhD, Associate Professor, Department of Electrical and Computer Engineering Jingtong Hu, PhD, Assistant Professor, Department of Electrical and Computer Engineering Jian Ma, PhD, Associate Professor, Computational Biology Department, Carnegie Mellon University Dissertation Director: Heng Huang, PhD, John A. Jurenko Endowed Professor, Department of Electrical and Computer Engineering ii Copyright c by Xiaoqian Wang 2019 iii New Nonlinear Machine Learning Algorithms with Applications to Biomedical Data Science Xiaoqian Wang, PhD University of Pittsburgh, 2019 Recent advances in machine learning have spawned innovation and prosperity in various fields. In machine learning models, nonlinearity facilitates more flexibility and ability to better fit the data. However, the improved model flexibility is often accompanied by challenges such as overfitting, higher computational complexity, and less interpretability. Thus, it is an important problem of how to design new feasible nonlinear machine learning models to address the above different challenges posed by various data scales, and bringing new discoveries in both theory and applications. In this thesis, we propose several newly designed nonlinear machine learning algorithms, such as additive models and deep learning methods, to address these challenges and validate the new models via the emerging biomedical applications.
    [Show full text]
  • Hard Real-Time Linux for Off-The-Shelf Multicore Architectures
    Universität Bremen Fachbereich 3 Hard Real-Time Linux for Off-The-Shelf Multicore Architectures Dissertation zur Erlangung des Grades eines Doktors der Ingenieurwissenschaften – Dr.-Ing. – vorgelegt von Dirk Radder im Fachbereich 3 der Universität Bremen am 19. Mai 2015 Datum des Promotionskolloquiums: 10.11.2015 Gutachter: Prof. Dr. Jan Peleska (Universität Bremen) Prof. Dr.-Ing. Görschwin Fey (Universität Bremen) Zusammenfassung In dieser Dissertation werden die Forschungsergebnisse bezüglich der Entwicklung einer Echtzeiterweiterung für das Linux Betriebssystem vorgestellt. Die Arbeit beschreibt eine vollständige Erweiterung das Kernels, welche hartes Echtzeitverhalten auf einer 64 Bit x86 Architektur ermöglicht. Im ersten Teil dieser Arbeit werden Echtzeit-Systeme kategorisiert und Konzepte von Echtzeit-Betriebssystemen eingeführt. Im Weiteren werden zahlreiche bekannte Echtzeit-Betriebssysteme betrachtet. QNX Neutrino, RT_PREEMPT Linux Patch sowie HLRT Linux Patch werden detailiert analysiert und deren Kernkonzepte ausführlich diskutiert. Darüber hinaus wird eine Test-Suite erarbeitet, mit der aussagekrätige Benchmarks der analysierten Systeme erstellt werden. Die Systeme werden anhand dieser Benchmarks evaluiert und mit der in dieser Arbeit entwickelten Echtzeit- Erweiterung verglichen. Anhand der vorausgegangenen Analysen der genannten Systeme wird ein Katalog von Anforderungen definiert, den die entwickelte Echtzeit-Erweiterung umsetzen wird. Basierend auf diesem Anforderungs-Katalog und den identifizierten Kernkonzepten der analysierten
    [Show full text]
  • Desarrollo De Drivers Y Aplicaciones Para Freertos Con AT91SAM7S
    Desarrollo de drivers y aplicaciones para FreeRtos Marzo 2010 Ing. Marcelo Lorenzati http://sistemasembebidos.com.ar Agenda Sistemas de tiempo Real y Sistemas embebidos Introducción a los RTOS embebidos y a FreeRTOS Ports, manejo de Memoria y configuración Control del Kernel y de la Tarea Sincronización y Comunicación entre tareas El por qué del Driver Partes de un Driver Desarrollo de un Driver Tipos de Drivers Drivers desarrollados Ejemplo de uso – audio player con FreeRTOS Conclusiones Bibliografía Preguntas Sistemas de tiempo Real y Sistemas embebidos /1 Patriot F16 SistemasMars Climate Orbiteren tiempo real Sistemas embebidosAriane-5 Therac-25 Complejos Tuvieron fallas Sistemas de tiempo Real y Sistemas embebidos /2 Problemas específicos de los sistemas de tiempo real Tiempos de respuesta estrictos Impredictibilidad del comportamiento del entorno Necesidad de acción rápida ante errores Problemas específicos de los sistemas de software Atomicidad Estancamiento Sincronización Concurrencia Condiciones de carrera Secciones críticas Desbordes de memoria Paralelismo Tiempos de desarrollo del sistema Mantenimiento del sistema Problema específicos de los sistemas embebidos Parte integral de un sistema mas grande Heterogeneidad de dispositivos Memoria de datos y de programa reducida Alto acoplamiento del código con el Hardware Baja potencia de computo Monolíticos Introducción a los RTOS embebidos /1 Variante de un sistema operativo, donde se asegura un resultado computacional en un periodo predecible de tiempo. RTOS para sistemas embebidos! No sistemas complejos de tiempo real * Dominio total del algoritmo de scheduling Acceso rápido al hardware Tiempos reducidos de reacción (ms vs ns) Capacidad de priorización Generalmente diseñados para funcionar con memoria reducida y baja potencia de computo.
    [Show full text]