Des Design gn and De Developme ment t Me Metho thodo dology - - PowerPoint PPT Presentation

Des Design gn and De Developme ment t Me Metho thodo dology

Chaipo Chaiporn J n Jaik aikae aeo De Department of f Computer Engineering Kasetsart Unive versity

01204322 Embedded System

Revised 2019-12-15

Materials from Computers as Components 3e, Marilyn Wolf, Morgan Kaufman

2

Ou Outline

• Embedded system design methodology
• Embedded system development
• Hands-on: developing and debugging embedded system

using STM32CubeIDE

3

De Design gn Method

• dol
• logy
• gy
• 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

4

De Design gn Goa

• als
• Performance
• Overall speed, deadlines
• Functionality and user interface
• Manufacturing cost
• Power consumption
• Other requirements (physical size, etc.)

5

Le Levels ls o

• f ab

f abstrac actio ion

requirements specification architecture component development system integration

top-down design bottom-up design

6

To Top-Do Down vs. . Bot

• ttom
• m-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

7

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

8

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.

9

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

10

Ex Example: ample: GP GPS M Moving ing M Map ap

• Moving map obtains position from GPS,

paints map from local database.

lat: 40.13 lon: 32.19

I-78 Scotch Road user’s current location user’s lat/lon position

requirements specification architecture component development system integration

11

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.

12

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

13

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

14

Sp Specific ification ion

• A more precise description of the system:
• Should not imply a particular architecture
• Provides input to the architecture design

process

• May include functional and non-

functional elements

• Should be understandable enough so that

it can be verified against the requirements

• May be executable or may be in mathematical

form for proofs

• UML (Unified Modeling Language) may be used

requirements specification architecture component development system integration

15

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

16

Ar Arch chitect cture Design

• What major components go satisfying

the specification?

• Hardware components:
• CPUs, peripherals, etc
• Software components:
• Major programs and their operations
• Must take into account functional and

non-functional specifications

requirements specification architecture component development system integration

17

GP GPS M Map: ap: B Blo lock D Diag iagram am

GPS receiver search engine renderer user interface storage display

18

GP GPS M Map: ap: Har Hardw dwar are A e Archit hitec ectur ure

• Clear hardware interface definition
• E.g., communication protocols

GPS receiver CPU panel I/O display frame buffer storage Bus

19

GP GPS M Map: ap: S Soft ftwar are A e Archit hitec ectur ure

• Clear software interface definition
• E.g., APIs to be used among components

position

database search renderer timer user interface pixels

20

Co Component Development

• Actual implementation of individual

hardware and software components

• Must spend time architecting the system

before you start coding

• Some components are ready-made
• Some can be modified from existing

designs

• Others must be designed from scratch
• Good surveys help!

requirements specification architecture component development system integration

21

Sy System Integration

• Put together the components
• Many bugs appear only at this stage
• Have a plan for integrating components to

uncover bugs quickly

• Test as much functionality as early as possible

requirements specification architecture

component development

system integration

22

Embedded S Embedded System D em Develo elopmen pment

• Let’s focus on how to develop the

components and integrate the system

• Real hardware?
• Programming environment?

requirements specification architecture component development system integration

23

Source ce code (C (C/Assembly) Cross Compiler/Assembler Fi Firmware code (b (binary)

010101 011101 110110

target system chip programmer/debugger

debugging software

U S B U S B

host system

De Develop

• pment Envi

viron

• nment

24

De Develop

• pment Boa
• ards
• Before real hardware is built,

software can be developed and tested using development boards

• Also known as evaluation boards
• Designed by CPU manufacturer or others
• Includes CPU, memory, some I/O devices,
• r 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 debugger

25

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

26

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/

27

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