EE Embedded Systems Design

Transcription

1 EE Embedded Systems Design Lesson 2 Structured Design, Documentation, and Laboratory Notebooks 1 Overview - Structured Design The divide-and-conquer technique Requirements Partitioning - The Black Box Structure Chart Pseudo (Fake) Code Implementation Techniques Testing Techniques Documentation Unified Modeling Language (UML) 2

2 Challenges in Embedded System Design Hw much hardware do we need: too little H/W and the system may fail to meet requirements, too much leads to expensive system How do we meet the deadline: Brute force (get the fastest H/W) leads to expensive system, Better design How to minimize power consumption: reduce the speed, that is guaranteed to reduce power. Better careful design to identify the noncritical parts for power consumption 3 Challenges in Embedded System Design How to design for upgradeability: Several different version of the product could be designed (different prices). Can we use the same H/W? S/W? Does it really work? How to be sure that it works as requested If workstation programming is like assembling a machine on a bench, embedded system design is like working in a car, cramped, and difficult 4

3 Challenges in Embedded System Design Testing: More difficult than traditional computing system We may have to run the machine the system is embedded in Timing plays a very important role Limited observability and controllability No keyboard or CRT Restricted development environments 5 The divide-and-conquer technique Paper writing/book writing Solid outline allows big picture view Write a paragraph at a time Use same technique in SW/HW design divide project into understandable, doable pieces A.K.A.: top-down-design, bottom-upimplementation... 6

4 Requirements Overall goal of structured design is to provide tools to transform system requirements into a plan to implement a system Your responsibility to ensure you understand requirements iterative process with customer More difficult if the customer is not an engineer 7 Requirements Requirements may be functional or nonfunctional (performance, cost, physical size and weight) Validating requirements: very difficult, may require to build a mock-up. For example a small program running on a PC with the required user interface so the customer may test drive it 8

5 Simple Requirements Form Name: Purpose Inputs Outputs Functions Performance Cost Power Physical size and weight 9 Requirements In a large project, a more thorough requirements analysis is done. The previous form may act as a summary of a much longer requirements documents. After you finish the requirements, check for inconsistency? Any unrealistic features in a cheap product, large power consumption in a portable product? 10

6 Partitioning - The Black Box Break a large, complex system into a hierarchical description of black boxes black box : small definable pieces know inputs, outputs, general details of function define relationship between black boxes use a graphical tools relationship Structure Chart provides big picture 11 Structure Chart 12

7 Modeling Structured chart describe the big picture. Not very useful for small systems. Unified Modeling language UML activity chart Flow chart is used to model flow of control Pseudocade 13 Pseudo (Fake) Code Once hierarchy is defined begin working out details of black box. Develop functional relationship between the boxes inputs and outputs Use pseudocode to defer details not trying to avoid details defer until higher level details worked out 14

8 Implementation Techniques Incremental Approach - get a little bit working at a time Top-down: implement top module lower level code simulated with stubs (empty modules) Bottom-up: implement module at lowest level. Higher level code simulated with drivers Hybrid: use of mixture of both techniques and meet in the middle 15 Testing Techniques Compile time errors Run Time errors Everything is O.K. except project completed to incorrect requirements!!! Test Plan Test each subpart separately Test after integration 16

9 Documentation External documentation - support information Structure Chart Internal documentation Comments Self-documenting code - wise choice of variable, function names Program Formatting - pretty printing - use blank spaces to help illustrate the control structure of the program 17 Unified Modeling Language (UML) Standardized set of graphical tools to model a complex system prior to implementation Used in structural description, behavioral description, and specification Used to describe object-oriented design Activity Diagram -- UML-compliant flow chart 18

10 Unified Modeling Language (UML) 19 Laboratory Notebooks Legal document - may be used in court to establish ownership of an idea Mechanics Use ink, must be bound Number each page consecutively, use both sides Sign and date each page Glue additional figures into notebook - sign and date Z out unused space Do not remove incorrect material - X it out 20

11 Cont. Laboratory Notebooks What to include? Everything Flowcharts of any non trivial procedures Program listing, printout and glued. A narrative of what you did, including mistakes New page for every day 21 Flowchart main Count=0 Count=count+1 <10 pulse pulse PORTB=1 PORTB=0 return void pulse(void) { PORTB=1 PORTB=0 } void main(void) { int counter; while(1) { count=0; do{ count++; } while(count<10) pulse(); } } 22

12 Requirements New requirements Product Development Cycle Analyze the problem Specifications Constraints High-level Design Block diagram Data flow graphs Not Done Engineering Design Testing Implementation Done Hardware Software Call graphs Data structure I/O Interface 23 High-level-design: Thermometer Build a conceptual model of the hardware/software system Mainly abstraction, no details Divide the system into modules and subcomponent Dataflow graphs are a good tool to use in this stage 24

13 Thermometer Temperature Temperature sensor voltage Analog amplifier voltage ADC Timer Fixed-point temperature Digital samples LCD Display LCD Routines Temp calculation Fixed-point voltage ADC Routines F or C Table lookup Switch 25 Engineering Design HW/SW Division The basic I/O signals Data structure Flowchart for the software part. Call graph The mechanical part design 26

14 Call Graph ADC Timer H/W Main program ADC Routines LCD Routines ADC H/W LCD H/W Switch I/P 27 Implementation Start writing the code and designing the circuits Test every component separately, and again when combined with another component Same for Software Golden rule for S/W: Write software for others as you wish they would write for you You are a good programmer if you can read your code 12 months later and understand it AND others can make changes to your code 28

15 Another Design Process Requirement Specification Architecture Testing and verification at every stage Iterative process Usually top-down design, bottom-up implementation Components Integration 29 GPS Moving Map System is designed for highway driving not aviation use. The system should have the major roads and landmarks The user interface have at least 400x600 pixel resolution. No more than 3 buttons. Menus are used for selection Production cost is $100 Works on battery, and hand-held 30

16 Name: Purpose: Inputs: Outputs: Functions: Requirements Form GPS moving map Consumer-grade moving map for drivers Power button, 2 control buttons back-lit LCD display 400x600 Uses 5-receiver GPS system three user selectable resolution, always display current latitude and longitude Performance Updates screen within 0.25 sec upon movement Cost $100 Power 100 mw Shape&weight No more than 2 x6, 12 ounces 31 Specifications Specifications is more precise, it is the contract between the designer and the customer. Should be understandable enough so that someone can verify that it meets the requirements. Should be unambiguous enough so the designers know what they need to build 32

17 Specifications UML is used to describe objects and classes Each class has a name, attributes and operations. UML is useful at many level of abstractions Successive refinements instead of starting over at each abstraction level. More in the next example. 33 Specifications Display pixels elements menu_items mouse_click() draw_box() A class in UML notations d1: Display Pixels:array[]of pixels Elements menu_items An object in UML notations 34

18 State Machine Specifications mouse_click(x,y,button) find_region(region) region=menu/ Start Which_menu(i) Region Got menu item call_menue(i) Called menu item Stop found region=drawing/ find_object(objid) Found object Object highlighted highlight(objid) 35 Architecture Design 36

19 Hardware Architecture Display Frame buffer Memory CPU GPS receiver Bus I/O Panel 37 Software Architecture Database search Renderer position User interface Timer 38