Des Design gn and De Developme ment t Me Metho thodo dology 01204322 Embedded System Chaiporn J Chaipo n Jaik aikae aeo De Department of f Computer Engineering Kasetsart Unive versity Revised 2019-12-15 Materials from Computers as Components 3e, Marilyn Wolf, Morgan Kaufman
Ou Outline • Embedded system design methodology • Embedded system development • Hands-on: developing and debugging embedded system using STM32CubeIDE 2
De Design gn Method odol ology ogy • A procedure for designing a system • Understanding your methodology helps you ensure you didn’t skip anything • Compilers, software engineering tools, computer-aided design (CAD) tools, etc., can be used to: ◦ Help automate methodology steps ◦ Keep track of the methodology itself 3
De Design gn Goa oals • Performance ◦ Overall speed, deadlines • Functionality and user interface • Manufacturing cost • Power consumption • Other requirements (physical size, etc.) 4
Le Levels ls o of ab f abstrac actio ion top-down design requirements specification architecture component development system integration bottom-up design 5
To Top-Do Down vs. . Bot ottom om-Up Up • Top-down design: ◦ Start from most abstract description ◦ Work to most detailed • Bottom-up design: ◦ Work from small components to big system • Real design uses both techniques and often iterative 6
Re Requirements • Plain language description of what the user wants and expects to get • May be developed in several ways: ◦ talking directly to customers ◦ talking to marketing representatives ◦ providing prototypes to users for comment 7
Func Functiona nal v vs. s. N Non-Func Functiona nal R Req. eq. • Functional requirements: ◦ output as a function of input • Non-functional requirements: ◦ time required to compute output ◦ size, weight, etc. ◦ power consumption ◦ reliability ◦ etc. 8
Ex Example o ample of R f Requir equiremen ements F s Form Name Purpose Inputs Outputs Functions Performance Manufacturing cost Power Physical size/weight 9
Example: Ex ample: GP GPS M Moving ing M Map ap • Moving map obtains position from GPS, requirements paints map from local database. specification I-78 architecture Scotch Road component development system integration user’s current location lat: 40.13 lon: 32.19 user’s lat/lon position 10
GP GPS M Map N ap Needs eeds • Functionality: For automotive use. Show major roads and landmarks. • User interface: At least 400 x 600 pixel screen. Three buttons max. Pop-up menu. • Performance: Map should scroll smoothly. No more than 1 sec power-up. Lock onto GPS within 15 seconds. • Cost: $120 street price. $40 cost of goods sold. 11
GP GPS M Map N ap Needs (C eeds (Cont’d) d) • Physical size/weight: Should fit in hand • Power consumption: Should run for 8 hours on four AA batteries 12
GP GPS M Map: ap: R Requir equiremen ements F s Form Name GPS moving map Purpose consumer-grade moving map for driving Inputs power button, two control buttons Outputs back-lit LCD 400x600 Functions 5-receiver GPS; three resolutions; display current lat/lon Performance screen update within 0.25 sec of movement Manufacturing cost $40 Power 100 mW Physical size/weight no more than 2” x 6”, 350g 13
Specific Sp ification ion • A more precise description of the system: requirements ◦ Should not imply a particular architecture ◦ Provides input to the architecture design process specification • May include functional and non- functional elements architecture • Should be understandable enough so that it can be verified against the requirements component development ◦ May be executable or may be in mathematical form for proofs ◦ UML (Unified Modeling Language) may be used system integration 14
GP GPS M Map: ap: S Spec pecific ificatio ion • Should include: ◦ What is received from GPS ◦ Map data ◦ User interface ◦ Operations required to satisfy user requests ◦ Background operations needed to keep the system running 15
Arch Ar chitect cture Design • What major components go satisfying requirements the specification? • Hardware components: specification ◦ CPUs, peripherals, etc • Software components: architecture ◦ Major programs and their operations • Must take into account functional and component non-functional specifications development system integration 16
GPS M GP Map: ap: B Blo lock D Diag iagram am GPS search display renderer receiver engine user interface storage 17
GP GPS M Map: ap: Har Hardw dwar are A e Archit hitec ectur ure • Clear hardware interface definition ◦ E.g., communication protocols CPU frame display buffer GPS receiver storage panel I/O Bus 18
GPS M GP Map: ap: S Soft ftwar are A e Archit hitec ectur ure • Clear software interface definition ◦ E.g., APIs to be used among components database renderer pixels position search user timer interface 19
Component Development Co • Actual implementation of individual requirements hardware and software components • Must spend time architecting the system specification before you start coding • Some components are ready-made architecture • Some can be modified from existing designs component development • Others must be designed from scratch • Good surveys help! system integration 20
Sy System Integration • Put together the components requirements ◦ Many bugs appear only at this stage • Have a plan for integrating components to specification uncover bugs quickly ◦ Test as much functionality as early as possible architecture component development system integration 21
Embedded S Embedded System D em Develo elopmen pment • Let’s focus on how to develop the requirements components and integrate the system • Real hardware? specification • Programming environment? architecture component development system integration 22
Develop De opment Envi viron onment host system Source ce code (C (C/Assembly) Cross Compiler/Assembler target system Firmware code Fi 010101 U U debugging 011101 (binary) (b S S 110110 software B B chip programmer/debugger 23
De Develop opment Boa oards • Before real hardware is built, software can be developed and tested using development boards ◦ Also known as evaluation boards debugger ◦ Designed by CPU manufacturer or others ◦ Includes CPU, memory, some I/O devices, or even on-board debugger ◦ May include prototyping section ◦ CPU manufacturer often gives out reference design , which can be used as starting point for your custom board design target 24
De Debuggi ging g Embedded Systems • Challenges: ◦ Target system may be hard to observe ◦ Target may be hard to control ◦ May be hard to generate realistic inputs ◦ Bugs may be timing-dependent 25
De Debuggi ging g Techniques • LEDs • Serial output (e.g., printf) • In-circuit emulator • On-chip debugger + host-based cross debugger • Oscilloscope, logic analyzer • Simulator https://store.digilentinc.com/analog-discovery-2-100msps- usb-oscilloscope-logic-analyzer-and-variable-power-supply/ https://www.instructables.com/id/How-to-Install- WaveForms-2015-in-Linux/ 26
Co Conclusi sion • Development of a system usually involves: ◦ Requirement, specification, architecture design, component development, system integration, test and validation • Development environment of an embedded system often includes ◦ Development host with toolchain: cross compiler, linker/loader, library, debugger ◦ Development board 27
Recommend
More recommend
