DOCSLIB.ORG

Reconfigurable Embedded Control Systems: Problems and Solutions

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text

Load more

RECONFIGURABLE EMBEDDED CONTROL SYSTEMS: PROBLEMS AND SOLUTIONS By Dr.rer.nat.Habil. Mohamed Khalgui ⃝c Copyright by Dr.rer.nat.Habil. Mohamed Khalgui, 2012 v Martin Luther University, Germany Research Manuscript for Habilitation Diploma in Computer Science 1. Reviewer: Prof.Dr. Hans-Michael Hanisch, Martin Luther University, Germany, 2. Reviewer: Prof.Dr. Georg Frey, Saarland University, Germany, 3. Reviewer: Prof.Dr. Wolf Zimmermann, Martin Luther University, Germany, Day of the defense: Monday January 23rd 2012, Table of Contents Table of Contents vi English Abstract x German Abstract xi English Keywords xii German Keywords xiii Acknowledgements xiv Dedicate xv 1 General Introduction 1 2 Embedded Architectures: Overview on Hardware and Operating Systems 3 2.1 Embedded Hardware Components . 3 2.1.1 Microcontrollers . 3 2.1.2 Digital Signal Processors (DSP): . 4 2.1.3 System on Chip (SoC): . 5 2.1.4 Programmable Logic Controllers (PLC): . 6 2.2 Real-Time Embedded Operating Systems (RTOS) . 8 2.2.1 QNX . 9 2.2.2 RTLinux . 9 2.2.3 VxWorks . 9 2.2.4 Windows CE . 10 2.3 Known Embedded Software Solutions . 11 2.3.1 Simple Control Loop . 12 2.3.2 Interrupt Controlled System . 12 2.3.3 Cooperative Multitasking . 12 2.3.4 Preemptive Multitasking or Multi-Threading . 12 2.3.5 Microkernels . 13 2.3.6 Monolithic Kernels . 13 2.3.7 Additional Software Components: . 13 2.4 Conclusion . 14 3 Embedded Systems: Overview on Software Components 15 3.1 Basic Concepts of Components . 15 3.2 Architecture Description Languages . 17 3.2.1 Acme Language . 17 3.2.2 Rapide Language . 17 vi vii 3.2.3 Wright Language . 18 3.2.4 Aesop Language . 18 3.2.5 Metah Language . 18 3.2.6 Architecture Analysis and Design Language . 18 3.2.7 Unicon Language . 19 3.2.8 Darwin Language . 19 3.3 Component-based Technologies . 19 3.3.1 Industrial Technology IEC61131 . 19 3.3.2 Industrial Technology IEC61499 . 20 3.3.3 Port Based Object Technology . 21 3.3.4 Koala Technology . 23 3.3.5 Pecos Technology . 23 3.3.6 Rubus Technology . 24 3.4 Conclusion . 25 4 Formalisms for Modelling and Verification of Embedded Systems 26 4.1 Petri nets . 26 4.2 NCES Formalism: Extension of Petri Net . 27 4.3 Temporal Logic . 28 4.3.1 Computation Tree Logic . 28 4.3.2 Extended Computation Tree Logic . 29 4.3.3 Timed Computation Tree Logic . 30 4.4 Conclusion . 30 5 Problems and Contributions 31 6 Reconfigurable Component-based Embedded Systems: New Motivations 33 6.1 Plant Formalization . 34 6.2 Control Components . 34 6.2.1 Formalization . 35 6.2.2 Specification . 35 6.3 Reconfigurable Systems: State of the Art . 35 6.4 New Reconfiguration Semantic . 36 6.5 Industrial Case Studies: Reconfiguration of Benchmark Production Systems FESTO and EnAS . 37 6.5.1 FESTO Manufacturing System . 37 6.5.2 EnAS Manufacturing System . 38 6.6 Reconfiguration Forms . 43 6.7 Conclusion . 45 7 Safety Multi-Agent Reconfigurable Architectures: Modelling And Verifi- cation 47 7.1 Introduction . 47 7.2 State of the Art . 48 7.2.1 Model Checking . 48 7.2.2 Multi-Agent Systems . 49 7.3 Contribution: Multi-Agent Architecture for Reconfigurable Embedded Con- trol Systems . 50 7.3.1 Reconfiguration in a Device . 51 7.3.2 Reconfiguration in a Distributed Architecture . 54 7.3.3 Implementation . 63 7.4 Contribution: NCES-based Modelling and SESA-Based Model Checking of Distributed Reconfigurable Embedded Systems . 64 7.4.1 NCES-Based Specification of a Reconfiguration Agent . 65 7.4.2 SESA-Based Model Checking in a Device . 66 7.4.3 SESA-Based Model Checking of the Coordination Agent . 69 viii 7.5 Contribution: Hierarchical Verification of Control Components . 73 7.5.1 Refinement-based Specification and Verification of a Network of Con- trol Components . 73 7.5.2 Generalization: Refinement-based Specification and Verification of a Reconfigurable System . 79 7.6 Application: Implementation of Multi-Agent Reconfigurable IEC61499 Systems 81 7.6.1 Implementation of Reconfiguration Agents . 83 7.6.2 Agent Interpreter . 83 7.6.3 Reconfiguration Engine . 85 7.6.4 Agent Converter . 85 7.6.5 Implementation of The Coordination Agent . 87 7.7 Conclusion . 89 7.8 References of the Chapter's Contributions . 90 8 Feasible Execution Models for Reconfigurable Real-Time Embedded Con- trol Systems 91 8.1 Introduction . 91 8.2 State of the Art . 92 8.3 Temporal Properties of Reconfigurable Embedded Control Systems . 93 8.4 Contribution: Formalization of Reconfigurable Embedded Control Systems 93 8.4.1 Action of Control Component . 94 8.4.2 Trace of Control Component . 95 8.5 Contribution: Verification and Assignment of Control Components to OS Tasks . 95 8.5.1 Verification and Pre-scheduling of a Container . 96 8.5.2 Verification of OS tasks for a Reconfiguration Scenario . 101 8.6 Generalization: Verification and Assignment of Reconfigurable Embedded Control Systems . 102 8.6.1 Algorithm . 103 8.6.2 Discussion . 104 8.7 conclusion . 104 8.8 References of the Chapter's Contributions . 105 9 Dynamic Low Power Reconfigurations of Real-Time Embedded Systems106 9.1 Introduction . 106 9.2 Related Works . 107 9.2.1 Reconfigurations of Embedded Systems . 107 9.2.2 Real-Time Scheduling . 108 9.2.3 Low Power Scheduling . 109 9.3 Formalization of Reconfigurable Real-Time Systems . 110 9.4 Power Consumption of Reconfigurable Embedded Real-Time Systems . 111 9.5 Contribution: Agent-based Architecture for Low Power Reconfigurations of Embedded Systems . 112 9.5.1 Modification of periods and deadlines . 113 9.5.2 Modification of WCETs . 113 9.5.3 Removal of Tasks . 114 9.6 Experimentation . 115 9.6.1 Implementation of the Reconfiguration Agent . 115 9.6.2 Simulations . 117 9.6.3 Analysis . 119 9.6.4 Advantages of the First Solution . 119 9.6.5 Application and Advantages of the Third Solution . 120 9.7 Conclusion . 121 9.8 References of the Chapter's Contributions . 121 ix 10 Simulation of Control Components implementing a Reconfiguration Sce- nario 126 10.1 Introduction . 126 10.2 Industrial Case Study . ..
Recommended publications
  • Fill Your Boots: Enhanced Embedded Bootloader Exploits Via Fault Injection and Binary Analysis

    Fill Your Boots: Enhanced Embedded Bootloader Exploits Via Fault Injection and Binary Analysis

    IACR Transactions on Cryptographic Hardware and Embedded Systems ISSN 2569-2925, Vol. 2021, No. 1, pp. 56–81. DOI:10.46586/tches.v2021.i1.56-81 Fill your Boots: Enhanced Embedded Bootloader Exploits via Fault Injection and Binary Analysis Jan Van den Herrewegen1, David Oswald1, Flavio D. Garcia1 and Qais Temeiza2 1 School of Computer Science, University of Birmingham, UK, {jxv572,d.f.oswald,f.garcia}@cs.bham.ac.uk 2 Independent Researcher, [email protected] Abstract. The bootloader of an embedded microcontroller is responsible for guarding the device’s internal (flash) memory, enforcing read/write protection mechanisms. Fault injection techniques such as voltage or clock glitching have been proven successful in bypassing such protection for specific microcontrollers, but this often requires expensive equipment and/or exhaustive search of the fault parameters. When multiple glitches are required (e.g., when countermeasures are in place) this search becomes of exponential complexity and thus infeasible. Another challenge which makes embedded bootloaders notoriously hard to analyse is their lack of debugging capabilities. This paper proposes a grey-box approach that leverages binary analysis and advanced software exploitation techniques combined with voltage glitching to develop a powerful attack methodology against embedded bootloaders. We showcase our techniques with three real-world microcontrollers as case studies: 1) we combine static and on-chip dynamic analysis to enable a Return-Oriented Programming exploit on the bootloader of the NXP LPC microcontrollers; 2) we leverage on-chip dynamic analysis on the bootloader of the popular STM8 microcontrollers to constrain the glitch parameter search, achieving the first fully-documented multi-glitch attack on a real-world target; 3) we apply symbolic execution to precisely aim voltage glitches at target instructions based on the execution path in the bootloader of the Renesas 78K0 automotive microcontroller.
  • STM32-P103 User's Manual

    STM32-P103 User's Manual

    STM-P103 development board User's manual Document revision C, August 2016 Copyright(c) 2014, OLIMEX Ltd, All rights reserved INTRODUCTION STM32-P103 board is development board which allows you to explore thee features of the ARM Cortex M3 STM32F103RBT6 microcontroller produced by ST Microelectronics Inc. The board has SD/MMC card connector and allows USB Mass storage device demo to be evaluated. The RS232 driver and connector allows USB to Virtual COM port demo to be evaluated. The CAN port and driver allows CAN applications to be developed. The UEXT connector allows access to all other UEXT modules produced by OLIMEX (like MOD-MP3, MOD-NRF24LR, MOD-NOKIA6610, etc) to be connected easily. In the prototype area the customer can solder his own custom circuits and interface them to USB, CAN, RS232 etc. STM32-P103 is almost identical in hardware design to STM32-P405. The major difference is the microcontroller used (STM32F103 vs STM32F405). Another board with STM32F103 and a display is STM32-103STK. A smaller (and cheaper board) with STM32F103 is the STM32-H103. Both boards mentioned also have a version with the newer microcontroller STM32F405 used. The names are respectively STM32-405STK and STM32-H405. BOARD FEATURES STM32-P103 board features: - CPU: STM32F103RBT6 ARM 32 bit CORTEX M3™ - JTAG connector with ARM 2×10 pin layout for programming/debugging with ARM-JTAG, ARM-USB- OCD, ARM-USB-TINY - USB connector - CAN driver and connector - RS232 driver and connector - UEXT connector which allow different modules to be connected (as MOD-MP3,
  • Elementary Functions: Towards Automatically Generated, Efficient

    Elementary Functions: Towards Automatically Generated, Efficient

    Elementary functions : towards automatically generated, efficient, and vectorizable implementations Hugues De Lassus Saint-Genies To cite this version: Hugues De Lassus Saint-Genies. Elementary functions : towards automatically generated, efficient, and vectorizable implementations. Other [cs.OH]. Université de Perpignan, 2018. English. NNT : 2018PERP0010. tel-01841424 HAL Id: tel-01841424 https://tel.archives-ouvertes.fr/tel-01841424 Submitted on 17 Jul 2018 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. Délivré par l’Université de Perpignan Via Domitia Préparée au sein de l’école doctorale 305 – Énergie et Environnement Et de l’unité de recherche DALI – LIRMM – CNRS UMR 5506 Spécialité: Informatique Présentée par Hugues de Lassus Saint-Geniès [email protected] Elementary functions: towards automatically generated, efficient, and vectorizable implementations Version soumise aux rapporteurs. Jury composé de : M. Florent de Dinechin Pr. INSA Lyon Rapporteur Mme Fabienne Jézéquel MC, HDR UParis 2 Rapporteur M. Marc Daumas Pr. UPVD Examinateur M. Lionel Lacassagne Pr. UParis 6 Examinateur M. Daniel Menard Pr. INSA Rennes Examinateur M. Éric Petit Ph.D. Intel Examinateur M. David Defour MC, HDR UPVD Directeur M. Guillaume Revy MC UPVD Codirecteur À la mémoire de ma grand-mère Françoise Lapergue et de Jos Perrot, marin-pêcheur bigouden.
  • Schedule 14A Employee Slides Supertex Sunnyvale

    Schedule 14A Employee Slides Supertex Sunnyvale

    UNITED STATES SECURITIES AND EXCHANGE COMMISSION Washington, D.C. 20549 SCHEDULE 14A Proxy Statement Pursuant to Section 14(a) of the Securities Exchange Act of 1934 Filed by the Registrant Filed by a Party other than the Registrant Check the appropriate box: Preliminary Proxy Statement Confidential, for Use of the Commission Only (as permitted by Rule 14a-6(e)(2)) Definitive Proxy Statement Definitive Additional Materials Soliciting Material Pursuant to §240.14a-12 Supertex, Inc. (Name of Registrant as Specified In Its Charter) Microchip Technology Incorporated (Name of Person(s) Filing Proxy Statement, if other than the Registrant) Payment of Filing Fee (Check the appropriate box): No fee required. Fee computed on table below per Exchange Act Rules 14a-6(i)(1) and 0-11. (1) Title of each class of securities to which transaction applies: (2) Aggregate number of securities to which transaction applies: (3) Per unit price or other underlying value of transaction computed pursuant to Exchange Act Rule 0-11 (set forth the amount on which the filing fee is calculated and state how it was determined): (4) Proposed maximum aggregate value of transaction: (5) Total fee paid: Fee paid previously with preliminary materials. Check box if any part of the fee is offset as provided by Exchange Act Rule 0-11(a)(2) and identify the filing for which the offsetting fee was paid previously. Identify the previous filing by registration statement number, or the Form or Schedule and the date of its filing. (1) Amount Previously Paid: (2) Form, Schedule or Registration Statement No.: (3) Filing Party: (4) Date Filed: Filed by Microchip Technology Incorporated Pursuant to Rule 14a-12 of the Securities Exchange Act of 1934 Subject Company: Supertex, Inc.
  • YANLI: a Powerful Natural Language Front-End Tool

    YANLI: a Powerful Natural Language Front-End Tool

    AI Magazine Volume 8 Number 1 (1987) (© AAAI) John C. Glasgow I1 YANLI: A Powerful Natural Language Front-End Tool An important issue in achieving acceptance of computer sys- Since first proposed by Woods (1970), ATNs have be- tems used by the nonprogramming community is the ability come a popular method of defining grammars for natural to communicate with these systems in natural language. Of- language parsing programs. This popularity is due to the ten, a great deal of time in the design of any such system is flexibility with which ATNs can be applied to hierarchically devoted to the natural language front end. An obvious way to describable phenomenon and to their power, which is that of simplify this task is to provide a portable natural language a universal Turing machine. As discussed later, a grammar front-end tool or facility that is sophisticated enough to allow in the form of an ATN (written in LISP) is more informative for a reasonable variety of input; allows modification; and, than a grammar in Backus-Naur notation. As an example, yet, is easy to use. This paper describes such a tool that is the first few lines of a grammar for an English sentence writ- based on augmented transition networks (ATNs). It allows ten in Backus-Naur notation might look like the following: for user input to be in sentence or nonsentence form or both, provides a detailed parse tree that the user can access, and sentence : := [subject] predicate also provides the facility to generate responses and save in- subject ::= noun-group formation.
  • Insider's Guide STM32

    Insider's Guide STM32

    The Insider’s Guide To The STM32 ARM®Based Microcontroller An Engineer’s Introduction To The STM32 Series www.hitex.com Published by Hitex (UK) Ltd. ISBN: 0-9549988 8 First Published February 2008 Hitex (UK) Ltd. Sir William Lyons Road University Of Warwick Science Park Coventry, CV4 7EZ United Kingdom Credits Author: Trevor Martin Illustrator: Sarah Latchford Editors: Michael Beach, Alison Wenlock Cover: Wolfgang Fuller Acknowledgements The author would like to thank M a t t Saunders and David Lamb of ST Microelectronics for their assistance in preparing this book. © Hitex (UK) Ltd., 21/04/2008 All rights reserved. No part of this publication may be reproduced, stored in a retrieval system or transmitted in any form or by any means, electronic, mechanical or photocopying, recording or otherwise without the prior written permission of the Publisher. Contents Contents 1. Introduction 4 1.1 So What Is Cortex?..................................................................................... 4 1.2 A Look At The STM32 ................................................................................ 5 1.2.1 Sophistication ............................................................................................. 5 1.2.2 Safety ......................................................................................................... 6 1.2.3 Security ....................................................................................................... 6 1.2.4 Software Development ..............................................................................
  • Turing's Influence on Programming — Book Extract from “The Dawn of Software Engineering: from Turing to Dijkstra”

    Turing's Influence on Programming — Book Extract from “The Dawn of Software Engineering: from Turing to Dijkstra”

    Turing's Influence on Programming | Book extract from \The Dawn of Software Engineering: from Turing to Dijkstra" Edgar G. Daylight∗ Eindhoven University of Technology, The Netherlands [email protected] Abstract Turing's involvement with computer building was popularized in the 1970s and later. Most notable are the books by Brian Randell (1973), Andrew Hodges (1983), and Martin Davis (2000). A central question is whether John von Neumann was influenced by Turing's 1936 paper when he helped build the EDVAC machine, even though he never cited Turing's work. This question remains unsettled up till this day. As remarked by Charles Petzold, one standard history barely mentions Turing, while the other, written by a logician, makes Turing a key player. Contrast these observations then with the fact that Turing's 1936 paper was cited and heavily discussed in 1959 among computer programmers. In 1966, the first Turing award was given to a programmer, not a computer builder, as were several subsequent Turing awards. An historical investigation of Turing's influence on computing, presented here, shows that Turing's 1936 notion of universality became increasingly relevant among programmers during the 1950s. The central thesis of this paper states that Turing's in- fluence was felt more in programming after his death than in computer building during the 1940s. 1 Introduction Many people today are led to believe that Turing is the father of the computer, the father of our digital society, as also the following praise for Martin Davis's bestseller The Universal Computer: The Road from Leibniz to Turing1 suggests: At last, a book about the origin of the computer that goes to the heart of the story: the human struggle for logic and truth.
  • Instrumentation Control Using the Rabbit 2000 Embedded Microcontroller

    Instrumentation Control Using the Rabbit 2000 Embedded Microcontroller

    Instrumentation Control Using the Rabbit 2000 Embedded Microcontroller Ian S. Schofield*, David A. Naylor Astronomical Instrumentation Group, Department of Physics, University of Lethbridge, 4401 University Drive West, Lethbridge, Alberta, T1K 3M4, Canada ABSTRACT Embedded microcontroller modules offer many advantages over the standard PC such as low cost, small size, low power consumption, direct access to hardware, and if available, access to an efficient preemptive real-time multitasking kernel. Typical difficulties associated with an embedded solution include long development times, limited memory resources, and restricted memory management capabilities. This paper presents a case study on the successes and challenges in developing a control system for a remotely controlled, Alt-Az steerable, water vapour detector using the Rabbit 2000 family of 8-bit microcontroller modules in conjunction with the MicroC/OS-II multitasking real-time kernel. Keywords: Embedded processor, Rabbit, instrument control, MicroC/OS-II 1. INTRODUCTION The Astronomical Instrumentation Group (AIG) of the University of Lethbridge’s Department of Physics has been designing instruments for use in infrared and (sub)millimetre astronomy for over twenty years, with an emphasis on Fourier transform spectroscopy. Historically, these instruments have been driven by control software hosted on standard desktop personal computers (PCs). This approach has been highly successful, allowing for rapid and inexpensive system development using widely available software development tools and low cost, commercial off-the- shelf hardware. In the fall of 2001, the AIG began work on a remotely controlled atmospheric water vapour detector called IRMA (Infrared Radiometer for Millimetre Astronomy). IRMA mechanically consists of a shoebox-size detector system attached to an Alt-Az motorized fork mount, which allows it to point to any position in the sky, and is attached to the end of an umbilical cable, through which it receives its power and network connection.
  • Church-Turing Thesis: Every Function F: {0,1}* -> {0,1}* Which Is "Effectively Computable" Is Computable by a Turing Machine

    Church-Turing Thesis: Every Function F: {0,1}* -> {0,1}* Which Is "Effectively Computable" Is Computable by a Turing Machine

    Church-Turing Thesis: Every function f: {0,1}* -> {0,1}* which is "effectively computable" is computable by a Turing Machine. Observation: Every Turing Machine (equivalently, every python program, or evey program in your favorite language) M can be encoded by a finite binary string #M. Moreover, our encoding guarantees #M != #M' whenever M and M' are different Turing Machines (different programs). Recall: Every finite binary string can be thought of as a natural number written in binary, and vice versa. Therefore, we can think of #M as a natural number. E.g. If #M = 1057, then we are talking about the 1057th Turing Machine, or 1057th python program. Intuitive takeaway: At most, there are as many different Turing Machines (Programs) as there are natural numbers. We will now show that some (in fact most) decision problems f: {0,1}* -> {0,1} are not computable by a TM (python program). If a decision problem is not comptuable a TM/program then we say it is "undecidable". Theorem: There are functions from {0,1}* to {0,1} which are not computable by a Turing Machine (We say, undecidable). Corollary: Assuming the CT thesis, there are functions which are not "effectively computable". Proof of Theorem: - Recall that we can think of instead of of {0,1}* - "How many" functions f: -> {0,1} are there? - We can think of each each such function f as an infinite binary string - For each x in (0,1), we can write its binary expansion as an infinite binary string to the right of a decimal point - The string to the right of the decimal point can be interpreted as a function f_x from natural numbers to {0,1} -- f_x(i) = ith bit of x to the right of the decimal point - In other words: for each x in (0,1) we get a different function f_x from natural numbers to {0,1}, so there are at least as many decision problems as there are numbers in (0,1).
  • Embedded Market Study, 2013

    Embedded Market Study, 2013

    2013 EMBEDDED MARKET STUDY Essential to Engineers DATASHEETS.COM | DESIGNCON | DESIGN EAST & DESIGN WEST | EBN | EDN | EE TIMES | EMBEDDED | PLANET ANALOG | TECHONLINE | TEST & MEASUREMENT WORLD 2013 Embedded Market Study 2 UBM Tech Electronics’ Brands Unparalleled Reach & Experience UBM Tech Electronics is the media and marketing services solution for the design engineering and electronics industry. Our audience of over 2,358,928 (as of March 5, 2013) are the executives and engineers worldwide who design, develop, and commercialize technology. We provide them with the essentials they need to succeed: news and analysis, design and technology, product data, education, and fun. Copyright © 2013 by UBM. All rights reserved. 2013 Embedded Market Study 5 Purpose and Methodology • Purpose: To profile the findings of the 2013 results of EE Times Group annual comprehensive survey of the embedded systems markets worldwide. Findings include types of technology used, all aspects of the embedded development process, tools used, work environment, applications, methods and processes, operating systems used, reasons for using and not using chips and technology, and brands and chips currently used by or being considered by embedded developers. Many questions in this survey have been trended over two to five years. • Methodology: A web-based online survey instrument based on the previous year’s survey was developed and implemented by independent research company Wilson Research Group from January 18, 2013 to February 13, 2013 by email invitation • Sample: E-mail invitations were sent to subscribers to UBM/EE Times Group Embedded Brands with one reminder invitation. Each invitation included a link to the survey. • Returns: 2,098 valid respondents for an overall confidence of 95% +/- 2.13%.
  • Architecture of 8051 & Their Pin Details

    Architecture of 8051 & Their Pin Details

    SESHASAYEE INSTITUTE OF TECHNOLOGY ARIYAMANGALAM , TRICHY – 620 010 ARCHITECTURE OF 8051 & THEIR PIN DETAILS UNIT I WELCOME ARCHITECTURE OF 8051 & THEIR PIN DETAILS U1.1 : Introduction to microprocessor & microcontroller : Architecture of 8085 -Functions of each block. Comparison of Microprocessor & Microcontroller - Features of microcontroller -Advantages of microcontroller -Applications Of microcontroller -Manufactures of microcontroller. U1.2 : Architecture of 8051 : Block diagram of Microcontroller – Functions of each block. Pin details of 8051 -Oscillator and Clock -Clock Cycle -State - Machine Cycle -Instruction cycle –Reset - Power on Reset - Special function registers :Program Counter -PSW register -Stack - I/O Ports . U1.3 : Memory Organisation & I/O port configuration: ROM RAM - Memory Organization of 8051,Interfacing external memory to 8051 Microcontroller vs. Microprocessors 1. CPU for Computers 1. A smaller computer 2. No RAM, ROM, I/O on CPU chip 2. On-chip RAM, ROM, I/O itself ports... 3. Example：Intel’s x86, Motorola’s 3. Example：Motorola’s 6811, 680x0 Intel’s 8051, Zilog’s Z8 and PIC Microcontroller vs. Microprocessors Microprocessor Microcontroller 1. CPU is stand-alone, RAM, ROM, I/O, timer are separate 1. CPU, RAM, ROM, I/O and timer are all on a single 2. designer can decide on the chip amount of ROM, RAM and I/O ports. 2. fix amount of on-chip ROM, RAM, I/O ports 3. expansive 3. for applications in which 4. versatility cost, power and space are 5. general-purpose critical 4. single-purpose uP vs. uC – cont. Applications – uCs are suitable to control of I/O devices in designs requiring a minimum component – uPs are suitable to processing information in computer systems.
  • Μc/OS-II™ Real-Time Operating System

    Μc/OS-II™ Real-Time Operating System

    μC/OS-II™ Real-Time Operating System DESCRIPTION APPLICATIONS μC/OS-II is a portable, ROMable, scalable, preemptive, real-time ■ Avionics deterministic multitasking kernel for microprocessors, ■ Medical equipment/devices microcontrollers and DSPs. Offering unprecedented ease-of-use, ■ Data communications equipment μC/OS-II is delivered with complete 100% ANSI C source code and in-depth documentation. μC/OS-II runs on the largest number of ■ White goods (appliances) processor architectures, with ports available for download from the ■ Mobile Phones, PDAs, MIDs Micrium Web site. ■ Industrial controls μC/OS-II manages up to 250 application tasks. μC/OS-II includes: ■ Consumer electronics semaphores; event flags; mutual-exclusion semaphores that eliminate ■ Automotive unbounded priority inversions; message mailboxes and queues; task, time and timer management; and fixed sized memory block ■ A wide-range of embedded applications management. FEATURES μC/OS-II’s footprint can be scaled (between 5 Kbytes to 24 Kbytes) to only contain the features required for a specific application. The ■ Unprecedented ease-of-use combined with an extremely short execution time for most services provided by μC/OS-II is both learning curve enables rapid time-to-market advantage. constant and deterministic; execution times do not depend on the number of tasks running in the application. ■ Runs on the largest number of processor architectures with ports easily downloaded. A validation suite provides all documentation necessary to support the use of μC/OS-II in safety-critical systems. Specifically, μC/OS-II is ■ Scalability – Between 5 Kbytes to 24 Kbytes currently implemented in a wide array of high level of safety-critical ■ Max interrupt disable time: 200 clock cycles (typical devices, including: configuration, ARM9, no wait states).