Survey
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
ELN5622 Embedded Systems Class 1 Spring, 2003 Kent Orthner [email protected] Course Description This course introduces students to the hardware and software tools available for the design and debug of microcontrollers (RISC and Fixed instruction set)based circuit packs. The generic concepts of embedded systems are discussed with an emphasis on the Motorola HC11 and Intel series 8052(2) families. Control techniques of peripherals (stepper motors and displays) round out the course. This course has a lab component. Course Objectives Develop an in-depth understanding of the operation and design of embedded systems, including – Hardware – Software – System Architecture Develop a thorough understanding of the Motorola 68HC11 microcontroller – Apply the knowledge to the labs and the design project What is an Embedded System? What is an Embedded System? A computing system embedded within a device. A system intended for a single purpose, which includes a general purpose processor. Hard to define. Nearly any computing system other than a desktop computer What is an Embedded System? Billions of units produced yearly, versus millions of desktop units Perhaps 50 per household and per automobile Often used for – providing user control over a product – to observe or control something in the “real world” (i.e. analog) Computer Systems are common. PC’s PDA’s Laptops Mainframes Servers Embedded Systems are everywhere. Anti-lock brakes Auto-focus cameras Automatic teller machines Automatic toll systems Automatic transmission Avionic systems Battery chargers Camcorders Cell phones Cell-phone base stations Cordless phones Cruise control Curbside check-in systems Digital cameras Disk drives Electronic card readers Electronic instruments Electronic toys/games Factory control Fax machines Fingerprint identifiers Home security systems Life-support systems Medical testing systems Modems MPEG decoders Network cards Network switches/routers On-board navigation Pagers Photocopiers Point-of-sale systems Portable video games Printers Satellite phones Scanners Smart ovens/dishwashers Speech recognizers Stereo systems Teleconferencing systems Televisions Temperature controllers Theft tracking systems TV set-top boxes VCR’s, DVD players Video game consoles Video phones Washers and dryers Characteristics of Embedded Systems Processor Based Application-specific functionality – specialized for one or one class of applications Interact with their environment Characteristics of Embedded Systems Tight Design Constraints – Power, Size, Timing, Cost to manufacture Tight Economic Constraints – Low design costs (NRE) , faster time to market, flexible product lines – Not User Programmable Stable / Reliable / Correct Real-time Operation Must finish processing by a deadline. – Hard Real-time • Missing deadlines causes a failure • Eg. Aircraft navigation system, ABS – Soft Real-time • Missing deadlines causes degraded performance • Eg. Network routers, cell phones – Multi-rate • Different operations have different priorities & deadlines – Not all embedded systems are real-time systems Why use processors? Easy to design with. Area & Cost Efficient : Can use the same logic for multiple functions or tasks. Tools are widely available. Upgradeable Code is reuseable. Cheap! Why use processors? Alternatives: – Custom Silicon • Very expensive NRE • Very long design cycle • Complex design – Pure Hardware Design • Design seldom re-useable • Debugging may require board re-spin. • Longer design cycle – FPGA • • • • Complex Design Expensive parts Design seldom reuseable High performance is not often required Embedded System Design Embedded System Design Requirements Specification Architecture Implementation System Integration Verification Hand-off to Manufacturing Requirements What the system is intended to do, what needs it meets, what features it will include. May be developed in several ways: – talking directly to customers – talking to marketing representatives – providing prototypes to users for comment Often takes the form of a ‘feature sheet’ of ‘requirements document’ Functional Requirements – – – – – – What will it do What won’t it do Performance Flexibility Testability Upgradeability – Power – Size – Unit Cost (Cost to manufacture) – Reliability – Correctness Non-functional Requirements – NRE (Non Recurring Engineering) cost • Cost to design – Time to prototype – Time to Market – Maintainability Specification Detailed explanation of what the system will do. – The users / customers will get a variation of this document, – Includes how the user will interact with the system. – Eg: User interface, power consumption, response times. The feature list often included as the first part of the specification. Architecture Description Detailed explanation of how the system will work. – The users / customers usually do not get this information. – Includes data flow descriptions, block diagrams, etc. – Eg. Software tasks, interfaces to components, etc. Specification should not dictate an architecture. The specification stage and the architecture stage tend to overlap significantly. Often, the System Specification and the Architecture description are parts of the same document. Implementation Capture the schematic, write the software, write the RTL. – Writing the software, doing the schematc & PCB layout, writing and verifying the RTL, etc. This is what most people associate with “design”. Different components may be done by different people or teams. Each person or team ‘unit tests’ his or her own design. Caution: It is very tempting, and very common, for designers to implement a system, and then document it. This commonly leads to design problem because of the system not being well thought out. – Eg. Doesn’t meet power & response requirements, code size is too big, etc. Top Down vs. Bottom Up Top down – Begin at the most abstract layer, and design successively detailed components until the design is complete. Bottom up – Begin with small components and put them together to build up the system. Real System design mixes both – You can’t do a proper abstract design if you don’t know what the components are going to be, and you can’t design proper components if you don’t know how the system will be put together, System Integration Putting the different parts of the system together. All the design teams have to work together to get the overall system to run. Often requires going back to the implementation. Involves a considerable amount of testing to make sure the product works correctly. Verification Making sure the product meets the requirements & specification. Verification Team – The people verifying the design should be different from the designers, and preferably, should not be too familiar with the architecture. – The designer knows the system intimately; it is natural for him or her to avoid errors, or to simply not see them. Verification Hand-off – This should not be done in parallel with integration. Instead there should be a formal ‘hand-off’ from the system integration team to the verification team. – If the design fails verification and has to return to a previous stage, the design needs to be re-verified to prevent new bugs from being introduced. Hand-off to Manufacturing The designer has finished the design, and it is time for it to be produced in numbers, and sold. Hand-off documents consist of: – – – – Bill of Materials Assembly Instructions Troubleshooting information Test plan / test checklist Embedded System Design: Case Study System Design Case Study Digital Camera Anti-lock brakes Cruise Control VCR Controller Microwave Requirements Functionality Performance Size Cost Testability Upgradeability Reliability NRE Time to Market Specification Inputs Outputs Operations Interfaces Development Tools Cost breakdown Architecture Processor Hardware Components Software Components Software Processes Implementation Capture Schematic Write & compile code System Integration Verification Meet all requirements? – Does it do what it’s supposed to? – Does it meet stability / reliability requirements? Microprocessor Technology Computer System Architecture Input Device Output Device Processor Processing Subsystems Memory Busses Output Device Processor Input Device Processing Subsystems Memory Input Devices Keyboard Mouse Button Touch Sensors / Touch Pad Microphone Camera Scanner Communications Receiver Voltage Sensor Output Devices Display (Monitor, LCD Display) LED Motor Speaker / Sound Card Printer Voltage output Communications Transmitter Peripheral Subsystems Math coprocessor DSP Coprocessor Timer Subsystem Watchdog Memory Volatile Memory – Cache – RAM Non-volatile Memory – ROM – EEPROM, Flash Mass Storage – Hard drive – Compact Flash – CD / DVD Memory Addressing 0x0002 Inst 1 Inst 2 0x0003 Inst 3 0x10F7 Inst n Data 1 Data 2 0x0001 0x10F8 0x10F9 Memory Mapped I/O 0x0001 0x0002 0x003 Inst 1 Inst 2 Inst 3 0x10F7 0x10F8 0x10F9 Inst n Data 1 Data 2 0x2000 0x2001 0x2002 Config Data_In Data_Out 4 Registers UART 0x2000 to 0x2003 2 Address bits 0x2800 0x2801 0x2802 Config 1 Config 2 Data_Out 256 Registers Display 0x2800 to 0x28FF 8 Address Bits Memory 8 kBytes 0x0000 to 0x1FFF 13 Address bits Memory Maps 0x3FFF 0x3000 0x2FFF Display (CS2) Total Memory Space: = 0x0000 to 0x3FFF = 16383 = 16kByte 0x2800 0x27FF 14 Address Lines 0x2004 0x2003 0x2000 UART (CS1) 0x1FFF Memory (CS0) 0x0000 Address Decoding & Chip selects A[1:0] UART A[13:0] Processor CS1 CS2 CS0 A[7:0] A[12:0] Display Memory A[15:0] Processor ‘Heart’ of the system – where the intelligence and decision making lies. Processor Characteristics: – – – – Architecture (Harvard vs. Von Neumann) Instruction Set (CISC, RISC, VLIW) Pipelining Programmer’s Model (accumulator based, general purpose registers, stack based) Instruction Execution 2 Basic Functions: – – Move data from one location to another Perform data transformation Steps 1. IF: Fetch the next instruction from memory pointed to by PC. Increment PC. 2. ID: Decode the instruction. 3. EX: Instruction Execution or Address Calculation 4. MEM: Data Memory Access 5. WB: Write Back Instruction Execution Not all instructions require all stages. – Eg. ‘Jump’ instructions don’t read or write memory. Different instructions can take a different number of clock cycles to complete. Pipelining The different instruction execution steps are (mostly) independent. Different steps can be done in parallel. Non-Pipelined Execution: Inst 1 IF ID EX MEM WB Inst 2 t|inst IF ID EX MEM WB t|inst Pipelining Inst 1 Pipelined Execution: IF ID EX MEM WB Inst 2 IF ID EX MEM WB Inst 3 IF ID EX MEM WB Inst 4 IF ID EX MEM WB Inst 5 IF ID EX MEM WB Inst 6 IF ID t|inst EX MEM WB t|inst Von Neumann Architecture Output Device Processor Input Device Processing Subsystems Memory Von Neumann Architecture The architecture used for all general purpose computers. Characteristics: – Single Read-write memory space for data & instructions – The memory is addressable by location, and the addressing scheme is not affected by the contents. Harvard Architecture Instruction Memory Output Device Processor Input Device Data Memory Harvard Architecture Separate Instruction & Data Memories Individual busses for each I/O is mapped into the Data Memory Space More efficient – Avoids the memory bus bandwidth problem Instruction Set CISC – Complex Instruction Set Computer – Many different instructions, different addressing modes. • Eg: Can read operations from memory, perform an operation, and write back to memory with one operation. – Can take many clock cycles per instruction. Instruction Set RISC – Reduced Instruction Set Computer – Very few instructions, only. • Eg: Load from memory is one instruction, do an operation is a second operation, and write back to memory is a third operation. – Usually only one clock cycle per instruction. – Can support higher clock frequencies. Microprocessors vs. Microcontrollers Microprocessor – – – – – – Used in general-purpose systems Optimized for performance Does just the processing No on-chip peripherals Minimal On-chip memories Eg. Pentium Microprocessors vs. Microcontrollers Microcontroller – – – – – Used in special-purpose systems Optimized for cost On-chip peripherals & I/O components Includes on-chip RAM, ROM, etc. Motorola 68HC11 Microprocessors vs. Microcontrollers