1 / 58

ELN5622 Embedded Systems Class 1 Spring, 2003

ELN5622 Embedded Systems Class 1 Spring, 2003. Kent Orthner korthner@hotmail.com. Course Description.

vea
Download Presentation

ELN5622 Embedded Systems Class 1 Spring, 2003

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. ELN5622Embedded SystemsClass 1Spring, 2003 Kent Orthnerkorthner@hotmail.com

  2. 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.

  3. 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

  4. What is an Embedded System?

  5. 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

  6. 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)

  7. Computer Systems are common. • PC’s • PDA’s • Laptops • Mainframes • Servers

  8. Embedded Systems are everywhere. 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 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

  9. Characteristics of Embedded Systems • Processor Based • Application-specific functionality • specialized for one or one class of applications • Interact with their environment

  10. 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

  11. 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

  12. 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!

  13. 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

  14. Embedded System Design

  15. Embedded System Design • Requirements • Specification • Architecture • Implementation • System Integration • Verification • Hand-off to Manufacturing

  16. 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’

  17. Functional Requirements • Power • Size • Unit Cost (Cost to manufacture) • Reliability • Correctness • What will it do • What won’t it do • Performance • Flexibility • Testability • Upgradeability

  18. Non-functional Requirements • NRE (Non Recurring Engineering) cost • Cost to design • Time to prototype • Time to Market • Maintainability

  19. 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.

  20. 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.

  21. 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.

  22. 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,

  23. 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.

  24. 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.

  25. 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

  26. Embedded System Design:Case Study

  27. System Design Case Study • Digital Camera • Anti-lock brakes • Cruise Control • VCR Controller • Microwave

  28. Requirements • Functionality • Performance • Size • Cost • Testability • Upgradeability • Reliability • NRE • Time to Market

  29. Specification • Inputs • Outputs • Operations • Interfaces • Development Tools • Cost breakdown

  30. Architecture • Processor • Hardware Components • Software Components • Software Processes

  31. Implementation • Capture Schematic • Write & compile code

  32. System Integration

  33. Verification • Meet all requirements? • Does it do what it’s supposed to? • Does it meet stability / reliability requirements?

  34. Microprocessor Technology

  35. Computer System Architecture Input Device Processor Output Device Processing Subsystems Memory

  36. Busses Address Bus Data Bus Processor Output Device Input Device Processing Subsystems Memory

  37. Input Devices • Keyboard • Mouse • Button • Touch Sensors / Touch Pad • Microphone • Camera • Scanner • Communications Receiver • Voltage Sensor

  38. Output Devices • Display (Monitor, LCD Display) • LED • Motor • Speaker / Sound Card • Printer • Voltage output • Communications Transmitter

  39. Peripheral Subsystems • Math coprocessor • DSP Coprocessor • Timer Subsystem • Watchdog

  40. Memory • Volatile Memory • Cache • RAM • Non-volatile Memory • ROM • EEPROM, Flash • Mass Storage • Hard drive • Compact Flash • CD / DVD

  41. Memory Addressing 0x0001 0x0002 0x0003 0x10F7 0x10F8 0x10F9 Inst 1 Inst 2 Inst 3 Inst n Data 1 Data 2

  42. Memory Mapped I/O 0x0001 Inst 1 0x0002 Inst 2 0x003 Inst 3 0x10F7 Inst n 0x10F8 Data 1 0x10F9 Data 2 0x2000 Config UART 0x2001 Data_In 0x2002 Data_Out 0x2800 Config 1 Display 0x2801 Config 2 0x2802 Data_Out Memory 8 kBytes 0x0000 to 0x1FFF 13 Address bits 4 Registers 0x2000 to 0x2003 2 Address bits 256 Registers 0x2800 to 0x28FF 8 Address Bits

  43. Memory Maps Total Memory Space: = 0x0000 to 0x3FFF = 16383 = 16kByte 14 Address Lines

  44. Address Decoding & Chip selects A[1:0] Processor UART A[13:0] CS1 CS2 CS0 Display A[7:0] Memory A[12:0] A[15:0]

  45. 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)

  46. Instruction Execution • 2 Basic Functions: • Move data from one location to another • Perform data transformation • Steps • IF: Fetch the next instruction from memory pointed to by PC. Increment PC. • ID: Decode the instruction. • EX: Instruction Execution or Address Calculation • MEM: Data Memory Access • WB: Write Back

  47. 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.

  48. Pipelining IF ID EX MEM WB IF ID EX MEM WB • The different instruction execution steps are (mostly) independent. • Different steps can be done in parallel. • Non-Pipelined Execution: Inst 1 Inst 2 t|inst t|inst

  49. Pipelining IF ID EX MEM WB Inst 1 IF ID EX MEM WB Inst 2 IF ID EX MEM WB Inst 3 Inst 4 IF ID EX MEM WB Inst 5 IF ID EX MEM WB Inst 6 IF ID EX MEM WB • Pipelined Execution: t|inst t|inst

  50. Von Neumann Architecture Processor Output Device Input Device Processing Subsystems Memory

More Related