I/O Interfacing Techniques

BCSE305L – EMBEDDED SYSTEMS SYSTEMS

I/O Interfacing Techniques

MODULE 4
PROGRAMMING TOOLS

Dr. Sridhar Chandrasekaran

Assistant Professor (Senior)
VIT University, Chennai

BCSE305L, Dr. C. Sridhar Page 1

TOPICS IN MODULE 4
EVOLUTION OF EMBEDDED PROGRAMMING TOOLS, MODELLING
PROGRAMS, CODE OPTIMIZATION, LOGIC ANALYZERS, PROGRAMMING
ENVIRONMENT

Weightage

INTERNALS (PROJECTS WITH 3 REVIEWS) – 3 MEMBERS IN A TEAM

EXTERNAL (2- CAT, AND FAT)
CAT 2 – MODULE 3, MODULE 4 & 5

BCSE305L Page 2
BUILDING PROCESS FOR EMBEDDED SYSTEMS

BCSE305L Page 3
BUILDING PROCESS FOR EMBEDDED SYSTEMS

Edit-Test-Debug Cycle implementation phase of the

development process

BCSE305L Page 4
 BUILDING PROCESS FOR EMBEDDED SYSTEMS

q Embedded systems programming is not substantially different

from the programming you've done before.

q The only thing that has really changed is that you need to have
an understanding of the target hardware platform. Furthermore,
each target hardware platform is unique.

q Unfortunately, this uniqueness among hardware platforms leads

to a lot of additional software complexity, and it's also the
reason you'll need to be more aware of the software build
process than ever before.
BCSE305L Page 5
 BUILDING PROCESS FOR EMBEDDED SYSTEMS

q When build tools run on the same system as the program they
produce, they can make a lot of assumptions about the system.

q This is typically not the case in embedded software development,

where the build tools run on a host computer that differs from the
target hardware platform.

q Embedded software development tools, can rarely make

assumptions about the target platform.

q Instead, the user must provide some knowledge of the system to the
tools by giving them more explicit instructions.
BCSE305L Page 6
 BUILDING PROCESS FOR EMBEDDED SYSTEMS

q Software Development is performed on a Host computer

Ø Compiler, Assembler, Linker, Locator, Debugger
Ø Produces executable binary image that will run on Target Embedded
System

BCSE305L Page 7
 BUILDING PROCESS FOR EMBEDDED SYSTEMS

q Software Tools
1. Software Development Kit (SDK)
2. Source-code Engineering Software
3. RTOS
4. Integrated Development Environment (IDE)
5. Emulator
6. Editor
7. Interpreter
8. Compiler
9. Assembler
10. Cross Assembler
11. Locator
12. Testing and debugging tools
BCSE305L Page 8
 PROCESS FOR DEVELOPING EMBEDDED SOFTWARE
q To develop software for a General Purpose Computer
Ø Create source file
Ø Type in C code
Ø Build: compile and link
Ø Execute: load and run

q To develop software for an embedded system

Ø Create source file (on Host)
Ø Type in C code (on Host)
Ø Compile/Assemble: translate into machine code (on Host)
Ø Link: combine all object files and libraries, resolve all symbols (on Host)
Ø Locate: assign memory addresses to code and data (on Host)
Ø Download: copy executable image into Target processor memory
Ø Execute: reset Target processor
BCSE305L Page 9
PROCESS FOR DEVELOPING EMBEDDED SOFTWARE

The Embedded Software Development Process

BCSE305L Page 10
 PROCESS FOR DEVELOPING EMBEDDED SOFTWARE

SOURCE CODE INTO EXECUTABLE BINARY IMAGE

Each of the source files must be compiled or assembled into an object file

All of the object files that result from the first step must be linked together
to produce a single object file, called the re-locatable program.

Physical memory addresses must be assigned to the relative offsets within

the re-locatable program in a process called relocation.

BCSE305L Page 11
 PREPROCESSING

q Pre-processing is not a part of the compiler, but is a separate step

in the compilation process

q Pre-processing is a process of running a set of instructions provided

by the programmer explicitly as code before the program
compiles.

q The pre-processor provides the ability for the inclusion of header

files, macro expansions, conditional compilation, and line control.

q Pre-processor instructions are called pre-processor directives, and

they all start with a hash symbol (#). Few examples: "#include",
"#define", "#line", and many more.
BCSE305L Page 12
 COMPILING
q Compiler translate programs written in some human-readable
language into an equivalent set of op-codes (or machine
language) for a particular processor.

q Compiler performs conversion of Source Code --> Object file

q Object file is binary file that contains set of machine-language

instructions (opcodes) and data resulting from language translation
Process

q Each processor has its own unique machine language, so you

need to choose a compiler that produces programs for your
specific target processor.
BCSE305L Page 13
 CROSS COMPILING

q In the embedded systems case, compiler almost always runs

on the host computer.

q A Native-compiler runs on a computer platform and produces

code for that same computer platform

q A Cross-compiler runs on one computer platform and

produces code for another computer/target platform

q The use of a cross-compiler is one of the defining features of

embedded software development.
BCSE305L Page 14
 COMPILER - EXAMPLE

q The GNU C compiler (gcc) and assembler (as) can be

configured as either native compilers or cross-compilers.

q These tools support an impressive set of host-target

combinations.

q The gcc compiler will run on all common PC and Mac

operating systems.

q The target processor support is extensive, including AVR, Intel

x86, MIPS, PowerPC, ARM, and SPARC.
BCSE305L Page 15
 COMPILER – OBJECT FILE FORMAT

q Regardless of the input language (C, C++, assembly, or any

other), the output of the cross-compiler will be an object file.

q Although parts of this file contain executable code, the object

file cannot be executed directly.

q The contents of an object file can be thought of as a very

large, flexible data structure.

q The structure of the file is often defined by a standard format

such as the Common Object File Format (COFF) or Executable
and Linkable Format (ELF).
BCSE305L Page 16
 COMPILER – OBJECT FILE

q Most object files begin with a header that describes the sections
that follow.

q Each of these sections contains one or more blocks of code or

data that originated within the source file you created.

q However, the compiler has regrouped these blocks into related

sections.

q For example, in gcc

Ø text - all of the code blocks are collected into this section,
Ø data - initialized global variables (and their initial values) into this section
Ø bss - uninitialized global variables into this section.
BCSE305L Page 17
 COMPILER – SYMBOL TABLE

q There is also usually a symbol table somewhere in the object file

that contains the names and locations of all the variables and
functions referenced within the source file.

q Parts of this table may be incomplete, however, because not all of

the variables and functions are always defined in the same file.

q These are the symbols that refer to variables and functions defined
in other source files.

q And it is up to the linker to resolve such unresolved references.

BCSE305L Page 18
 LINKER

q All of the object files resulting from the compilation in step one must
be combined.

q The object files themselves are individually incomplete, some of

the internal variable and function references not yet been resolved.

q The job of the linker is to combine these object files and, in the
process, to resolve all of the unresolved symbols

q By merging the text, data, and bss sections of the input object files,
the linker creates a new object file that contains all of the code
and data from the input object files.
BCSE305L Page 19
 LINKER

q When the linker is finished executing, all of the machine language

code from all input object files will be in text section of the new file.

q And all of the initialized and uninitialized variables will reside in the
new data and bss sections, respectively.

q After merging all of the code and data sections and resolving all of
the symbol references, the linker produces an object file that is a
special “relocatable” copy of the program.

q In other words, the program is complete except for one thing: no

memory addresses have yet been assigned to the code and data
sections within. BCSE305L Page 20
 LOCATOR
q The tool that performs the conversion from relocatable program to
executable binary image is called a locator.

q You have to do most of the work in this step yourself, by providing

information about the memory on the target board as input to the
locator.

q The locator uses this information to assign physical memory

addresses to each of the code and data sections within the
relocatable program.

q It then produces an output file that contains a binary memory

image that can be loaded into the target.
BCSE305L Page 21
 LOCATOR
q The output of this final step of the build process is a binary image
containing physical addresses for the specific embedded system.

q This executable binary image can be downloaded to the

embedded system or programmed into a memory chip.

q There is a separate development tool, called a locator, to assign

addresses. However, in the of GNU tools, this feature is built into the
linker (ld).

q The memory information required by the GNU linker can be passed

to it in the form of a linker script.
BCSE305L Page 22
 LOCATOR - EXAMPLE
example of a linker script

BCSE305L Page 23
 LOCATOR - EXAMPLE
q The first executable instruction is ENTRY command, which appears
on the first line and the entry point is the function main.

q This script informs the GNU linker’s built-in locator about the
memory on the target board, which contains 64 MB of RAM and 16
MB of flash ROM.

q The linker script file instructs the GNU linker to locate the data, bss,
and text sections in RAM starting at address 0x00400000.

q Names in the linker command file that begin with an underscore

(e.g., _DataStart) can be referenced similarly to ordinary variables
from source code. BCSE305L Page 24
 LOCATOR - EXAMPLE
q The linker will use these symbols to resolve references in the input
object files.

q So, for example, there might be a part of the embedded software

(usually within the startup code) that copies the initial values of the
initialized variables from ROM to the data section in RAM.

q The start and stop addresses for this operation can be established
symbolically by referring to the addresses as _DataStart and
_DataEnd.

BCSE305L Page 25
 BUILD PROCEDURE FOR THE ARCOM VIPER-LITE DEVELOPMENT BOARD

q In this section, we show an example build procedure for the Arcom

VIPER-Lite development board.

q If another hardware platform is used, a similar process should be

followed using the tools and conventions that accompany that
hardware.

q Once the tools are installed, the commands covered in the

following sections are entered into a command shell.

q For Windows users, the command shell is a Cygwin bash shell

(Cygwin is a Unix environment for Windows); for Linux users, it is a
regular command shell.
BCSE305L Page 26
 BUILD PROCEDURE FOR THE ARCOM VIPER-LITE DEVELOPMENT BOARD

COMPILE

q First we look at the individual commands in order to manually

perform the three separate tasks (compiling, linking, and locating)

q Later, we will learn how to automate the build procedure with

makefiles.

q The Blinking LED example consists of two source modules: led.c

and blink.c.

q The first step in the build process is to compile these two files.
BCSE305L Page 27
 BUILD PROCEDURE FOR THE ARCOM VIPER-LITE DEVELOPMENT BOARD

COMPILE
q The basic structure for the gcc compiler command is:

q The command-line options we’ll need are:

-g To generate debugging info in default format
-c To compile and assemble but not link
-Wall To enable most warning messages
-I../include To look in the directory include for header files

q Here are the actual commands for compiling:

BCSE305L Page 28
 BUILD PROCEDURE FOR THE ARCOM VIPER-LITE DEVELOPMENT BOARD

COMPILE
q We broke up the compilation step into two separate commands,
but you can compile the two files with one command.

q To use a single command, just put both of the source files after the
options. If you wanted different options for one of the source files,
you would need to compile it separately as just shown.

q The result of each of these commands is the creation of an object

file that has the same prefix as the .c file, and the extension .o.

q So if all goes well, there will now be two additional files—led.o and
blink.o—in the working directory.
BCSE305L Page 29
 BUILD PROCEDURE FOR THE ARCOM VIPER-LITE DEVELOPMENT BOARD

LINK AND LOCATE

q We now have the two object files—led.o and blink.o—that we need

in order to perform the second step in the build process.

q As we discussed earlier, the GNU linker performs the linking and

locating of the object files.

q For the third step, locating, there is a linker script file named
viperlite.ld that we input to ld in order to establish the location of
each section in the Arcom board’s memory.

BCSE305L Page 30
 BUILD PROCEDURE FOR THE ARCOM VIPER-LITE DEVELOPMENT BOARD

LINK AND LOCATE

q The structure for the linker and locater ld command is:

q The command-line options we’ll need for this step are:

-Map blink.map To generate a map file and use the given filename
-T viperlite.ld To read the linker script
-N To set the text and data sections to be readable and writable
-o blink.exe To set the output filename (if this option is not included, ld will
use the default output filename a.out)

q The actual command for linking and locating is:

 BUILD PROCEDURE FOR THE ARCOM VIPER-LITE DEVELOPMENT BOARD

LINK AND LOCATE

q The order of the object files determines their placement in memory.
Because we are not linking in any startup code, the order of the
object files is irrelevant.

q If startup code were included, you would want that object file to be
located at the proper address.

q The linker script file can be used to specify where you want the
startup routine (and other code) to reside in memory.

q Furthermore, you can also use the linker script file to specify exact
addresses for code or data, should you find it necessary to do so.
 BUILD PROCEDURE FOR THE ARCOM VIPER-LITE DEVELOPMENT BOARD

LINK AND LOCATE

q As you can see in this command, the two
object files—led.o and blink.o—are the last
arguments on the command line for linking.

q The linker script file, viperlite.ld, is also

passed in for locating the data and code in
the Arcom board’s memory.

q The result of this command is the creation of

two files—blink.map and blink.exe—in the
working directory.
 BUILD PROCEDURE FOR THE ARCOM VIPER-LITE DEVELOPMENT BOARD

LINK AND LOCATE

q The .map file gives a complete listing of all code and data
addresses for the final software image.

q It provides information similar to the contents of the linker script

described earlier.

q However, these are results rather than instructions and therefore

include the actual lengths of the sections and the names and
locations of the public symbols found in the relocatable program.
 LINKER MAP FILES
q The linker map file provides valuable information that can help you
understand and optimize memory.

q The map file is a symbol table for the whole program.

q The most straightforward pieces of information in the map file are the
actual memory regions, with location, size and access rights granted to
those regions
 LINKER MAP FILES
q Linker script and memory map section contains a breakdown of the
memory contribution of each and every file that was linked into the final
image.
 LOADING ON THE TARGET

q Previously, we saw how the code or software to be executed on

the embedded system (target board) is written on a computer.

q The resulting code created after subjecting it to be build process is

called the binary executable image or simply hex code.

q This topic explains how the hex code is loaded on the target board
which is referred as downloading

q And what are the various possible ways of debugging a code

meant to run on a embedded system.
LOADING ON THE TARGET

q There are two ways of

downloading the binary image
on the embedded system:

1. Using a Device Programmer

2. In-system programming (ISP)

 LOADING ON THE TARGET
1. Using a Device Programmer:
Ø Step 1: Once the binary image is ready on the computer, the device
programmer is connected to the computer.

Ø Step 2: The uP/uC or memory chip, usually the ROM which is

supposed to contain the binary image is placed on the proper socket
on the device programmer.

Ø Step 3: The device programmer contains a software interface through

which the user selects the target uP/uC for which the binary image
has to be downloaded.

Ø Step 4: The Device programmer then transfers the binary image bit by
bit to the chip.
MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN
 LOADING ON THE TARGET
1. Using a Device Programmer:
uP/uC/Memory Chip

Host Computer
Device Programmer
 LOADING ON THE TARGET
2. Using In System Programmer(ISP):
Ø Certain Target embedded platforms uses a piece of hardware called
ISP that have a hardware interface to both the computer as well the
target board’s chip where the code is to be downloaded.

Ø ISP is also called in-circuit serial programming (ICSP), is the ability of

programming the embedded processor/controller while it is installed
in a complete system, rather than requiring the chip to be
programmed prior to installing it into the system.

Ø It also allows firmware updates to be delivered to the on-chip

memory of microcontrollers and related processors without requiring
specialist programming circuitry on the circuit board, and simplifies
design work
MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN
 LOADING ON THE TARGET
2. Using In System Programmer(ISP):
Ø The user through the ISP’s software interface sends the binary image
to the target board. This avoids the requirement of frequently
removing the microprocessor / microcontroller or ROM for
downloading the code if a device programmer had to be used.

MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN

 DEBUGGING TOOLS

MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN

 DEBUGGING TOOLS
SIMULATOR

q Simulator is a host-based program that simulates functionality and

instruction set of target processor.

q The front-end has text or GUI-based windows for source code,

register contents, etc.

q Simulators are valuable during early stages of development.

q Disadvantage of this method is that, it only simulates the processor,

and not the peripherals.

MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN

 DEBUGGING TOOLS
REMOTE DEBUGGER
q Remote debuggers are one of the commonly used downloading
and testing tools during development of embedded software

q It is used to monitor/control embedded SW. It is used to download,

execute and debug embedded software over a comm. link.

q The program running on the host of a remote debugger has a user

interface (GUI/Command-line) that looks just like other debugger

q The front-end of the GUI debuggers contain several windows to

show the active part of the source code, current register contents,
and other relevant information about the executing program.
MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN
 DEBUGGING TOOLS
REMOTE DEBUGGER
q Backend provides low-level control of target processor, runs on
target processor and communicates to the front-end over a
communication link.

q Debugger and software being debugged are executing on two

different computer systems.
-Start/restart/kill, and stepping through program.
- Software breakpoints.
- Reading/writing registers or data at specified address.

q Disadvantage: inability to debug startup Code, code must execute from

RAM, requires a target processor to run the final software package
MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN
 DEBUGGING TOOLS
IN-CIRCUIT EMULATOR (ICE)
q Emulation refers to the ability of a computer program or electronic
device to imitate another program or device.

q An emulator is a piece of hardware/software that enables one

computer system to run programs that are written for another
computer system.
q An in-circuit emulator (ICE) provides a lot more functionality than a
remote debugger.
q In addition to providing the features available with a remote
debugger, an ICE allows you to debug startup code and programs
running from ROM, etc.,
MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN
 DEBUGGING TOOLS
IN-CIRCUIT EMULATOR (ICE)
 DEBUGGING TOOLS
IN-CIRCUIT EMULATOR (ICE)
q In-Circuit Emulator (ICE) takes the place of the target processor. It
contains a copy of target processor, plus RAM, ROM, and its own
embedded software.

q It allows you to examine the state of the processor while the

program is running. It uses the remote debugger for human
interface.

q ICE provides greater flexibility, ease for developing various

applications on a single system in place of testing that multiple
targeted systems. Disadvantage of this method is that, it is
expensive.
 Petri net
model

Modelling
embedded
Unified
systems Data
model Flow
language Graph

50
 Modelling Programs
Representation of a program

q Modelling the programs in Embedded systems.

q Program has basic blocks, conditional statements etc.

q Can be represented by
q Data Flow graph (DFG)
q Control Data Flow Graph (CDFG)

MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN

 Modelling Programs
Representation of a program

q Model a program that has no conditionals

q Basic blocks - having one entry and exit point.
q Before go for DFG represent the program in single assignment form
q Single assignment form
Ø Having statement in a program, where the assignment variables (in left)appears
only one.
Ø It verifies no cyclic form in the statements or blocks.
Ø It identifies the unique location of variables in the code
Ø Any use of repeated assignment to single variable need to be rewrite and assigns
the latest assigned variable if it is used further.

MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN

 Modelling Programs
Representation of a program
q Two types of nodes
q Round nodes - represents or denotes operators.
q Square nodes - represents values.
Single assignment form

MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN

 Modelling Programs
Advantages of DFG

q It orders the way operations can be performed in a program.

q Determines the feasible reordering's of the operations, this will
reduce the pipeline or cache conflicts

MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN

 Modelling Programs
Control DFG

q Constructs a model for decision flow and data flow of a program.

q Data flow nodes represented by basic block (set of statements).

q Control flow of a sequential program is represented by decision

nodes

MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN

 Modelling Programs
Control DFG

q Basic block nodes

q Decision nodes

q Edges labelled with possible outcomes

MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN

 Modelling Programs
Building loop in CDFG

while (a < b)
{
a = proc1(a,b);
b= proc2(a,b);
}

MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN

 Modelling Programs
Condition blocks using CDFG

if (cond1)
basic_block_1( );
else
basic_block_2();
basic_block_3( );
switch (test1) {
case c1: basic_block_4( ); break;
case c2: basic_block_5( ); break;
case c3: basic_block_6( ): break;
}

MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN

 Modelling Programs
Control DFG

q CDFG is a hierarchical representation.

q Each block in CDFG is expanded using Data flow graph.

MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN

60
 PETRI NET MODEL

q Petri net can also called as Place/Transition net

q It is used for describing and analyzing concurrent process
q Petri net is also a graphical tool
q Petri Net(PN) is Very similar to State Transition Diagrams which
model the system behavior
q It is an abstract model to show the interaction between
asynchronous processes
q In asynchronous process, start and sequence of processes
may vary during the execution

MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN

 PETRINET MODEL
COMPONENTS OF PETRINET MODEL
q Petri net Model consists of four types of components - places
(circles), transitions (rectangles) and arcs (arrows),
tokens(black dot):
q Places represent possible states of the system;
q Transitions are events which cause the change of state
q Every arc simply connects a place with a transition or a
transition with a place.
q Change of state is denoted by a movement of token(s)
from place(s) to place(s)

MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN

 PETRINET MODEL

COMPONENTS OF PETRINET MODEL

MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN

 PETRINET MODEL
q Change of state is caused by the firing of a transition

q Firing refers to the occurrent of a event

q The firing is based on the input conditions, denoted by token

availability

q A transition is enabled when sufficient tokens are available in

input places

q Once firing is initiated, tokens will be transferred from input to

output places
MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN
 PETRINET MODEL

COMPONENTS OF PETRINET

q Below is an example Petri net with two places and one

transaction.

- p1: input place

p1 t1 p2 - p2: output place

MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN

 PETRINET MODEL

PROPERTIES
q Sequential Execution: Transition t2 can
take place only after t1. Here a
constraint is imposed “t2 after t1”

q Concurrency: This property is used in

Modelling distributed control system. t1
and t2 are concurrent process

MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN

 PETRINET MODEL

PROPERTIES

q Merging: When several tokens are

arrived at same transition merging will
take place

q Synchronization: Transition t1 will be

enabled only when at least one token is
available at each of its input places

MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN

 PETRINET MODEL

EXAMPLE-1 POINT OF SALE (POS) MACHINE

q A point of sale terminal (POS terminal) is an electronic device
used to process card payments at retail locations. A POS
terminal generally does the following:
§ Reads the information off a customer’s credit or debit card
§ Validate the user using 4-digit PIN number
§ Checks whether the funds in a customer’s bank account are sufficient
§ Transfers the funds from the customer’s account to the seller’s account
§ Records the transaction and prints a receipt

MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN

 PETRINET MODEL

EXAMPLE-1 POINT OF SALE (POS) MACHINE

qScenario 1: Normal
§ Enters all 4 digits and
press OK.

qScenario 2: Exceptional
§ Enters only 3 digits
and press OK.

MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN

 PETRINET MODEL

EXAMPLE-2 VENDING MACHINE

q The machine dispenses two kinds of snack bars 20c and 15c.
Constraint: 10c and 5c coins can only be used
q Scenario 1:
§ Deposit four 5c, take 20c snack bar.
q Scenario 2:
§ Deposit 10 + 5c, take 15c snack bar.
q Scenario 3:
§ Deposit 5 + 10 + 5c, take 20c snack bar.

MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN

 PETRINET MODEL

EXAMPLE-2 VENDING MACHINE

MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN

 PETRINET MODEL
EXAMPLE-3 ORDER MANAGEMENT IN A RESTAURANT
q In the real world, many events are concurrent in nature. Many
applications have global state formed from local state.
q Scenario 1:
q Waiter takes order from customer 1
q Serves customer 1
q Takes order from customer 2
q Serves customer 2.
q Scenario 2:
q Waiter takes order from customer 1
q Takes order from customer 2
q Serves customer 2
q Serves customer 1
MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN
 PETRINET MODEL

EXAMPLE-3 ORDER MANAGEMENT IN A RESTAURANT

MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN

74
 UNIFIED Modelling LANGUAGE (UML)

q What is Modelling Language?

A Modelling language is a graphical/textual computer language
explains design and construction of any model or structure
following a set of guidelines.

q Importance of Modelling : Visualization, reduced complexity,

documentation

q To effectively model a system, you need a language with

which the model can be described and here's where UML
comes in.

MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN

 UNIFIED Modelling LANGUAGE (UML)

INTRODUCTION

q UML - general purpose visual Modelling language

q It is used to visualize, specify, construct, and document
q Using tools codes can be generated with UML diagrams in
various languages
q It is a pictorial language
q It can be used for both Modelling the software system and
non-software systems
q For example, modelling a process flow in automated systems,
etc.

MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN

 UNIFIED Modelling LANGUAGE (UML)

INTRODUCTION
q UML is used in many applications by many people like
business users, common people to make the system simple,
clear and understandable

q It is a simple modelling mechanism to model most of the

practical systems

q It is a object-oriented analysis based method

MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN

 UNIFIED Modelling LANGUAGE (UML)
INTRODUCTION
UML Uses:
q Forecast systems
q To estimate the reusability.
q Lower costs
q Plan and analyze system behavior
q Easier maintenance/modification

MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN

 UNIFIED Modelling LANGUAGE (UML)
INTRODUCTION
There are two types of diagram in UML
1. Structure diagram: explains static structure of a system
Ø Class diagram
Ø Object diagram
Ø Deployment diagram
Ø Package diagram
2. Behavior diagram : used to model dynamic changes
Ø Use case diagram
Ø Interaction diagram
Ø Activity diagram
Ø State diagram
MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN
 UNIFIED Modelling LANGUAGE (UML)

q Principles of UML Modelling

System Requirement Use case diagrams

System Structure Class diagram

System Sequence, state and

characteristics activity diagram

Implementation Component diagram

MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN

81
 UNIFIED Modelling LANGUAGE (UML)

USE CASE DIAGRAM

q The use case diagram shows different ways a user can interact
with the system
q It can be used in scenarios like when system interact with
people or any other external systems
q It contains “use-cases” and ‘’actors’’
q Use case diagram depicts how the actor interacts with use
cases
q It describes the relationship between functionalities and their
controllers

MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN

 UNIFIED Modelling LANGUAGE (UML)

USE CASE DIAGRAM

System

Actors

Use Cases

Relationships

MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN 9

 UNIFIED Modelling LANGUAGE (UML)
UML NOTATIONS
q Notations are very important in any modelling language

q Efficient use of notations play a major role in making any

model meaningful

q Use case diagram: Notations of things and relationships

q Extensibility makes UML more powerful and flexible.

MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN

 UNIFIED Modelling LANGUAGE (UML)
USE CASE NOTATIONS
q Use case - high level functionalities of a system.
q Use case is represented as an eclipse

MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN

 UNIFIED Modelling LANGUAGE (UML)
USE CASE NOTATIONS - ACTOR
q An actor - the internal or external entities.

MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN

 UNIFIED Modelling LANGUAGE (UML)
USE CASE NOTATIONS - DEPENDENCY
q Dependency - relationship between two elements of a system
q Dependency - dotted arrow
q Arrow head represents - independent element
q Other end - dependent element

MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN

 UNIFIED Modelling LANGUAGE (UML)
USE CASE NOTATIONS - ASSOCIATION
q Association - relationship between two elements
q Association describes how the elements are associated.
q Association is represented by a dotted line with (without)
arrows on both sides
q The multiplicity (1, *, etc.) to show how many objects are
associated

MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN

 UNIFIED Modelling LANGUAGE (UML)
USE CASE NOTATIONS - GENERALIZATION
q Generalization - parent-child relationship
q Generalization - inheritance relationship of the object-oriented
concept
q Generalization - arrow with a hollow arrow head

MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN

 UNIFIED Modelling LANGUAGE (UML)
USE CASE NOTATIONS - <<include>> and <<extend>>

q ‘Extend’ and ‘Include’ – between use cases

q Include: invocation of one use case by the other

q Extend: extending use case will work exactly like the base use
case

MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN

 UNIFIED Modelling LANGUAGE (UML)
Banking Application

Verify
Primary actor – Initiates the process
<<Include>> Password
Log in
Secondary actor – Responds
<<Extend>>
Error
Check Use case – Action
Balance
Customer
Association
Transfer
fund
Bank Exclude
Make
Include
Payment
Generalization

New Old
customer customer

MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN

 UNIFIED Modelling LANGUAGE (UML)

MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN

 UNIFIED Modelling LANGUAGE (UML)
USE CASE DIAGRAM EXAMPLE- ATM SYSTEM

MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN 24

 UNIFIED Modelling LANGUAGE (UML)
USE CASE DIAGRAM EXAMPLE WASHING MACHINE LAUNDRY

MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN 25

 UNIFIED Modelling LANGUAGE (UML)
USE CASE DIAGRAM EXAMPLE ELEVATOR SYSTEM

MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN 26

 UNIFIED Modelling LANGUAGE (UML)
USE CASE DIAGRAM EXAMPLE ELEVATOR SYSTEM

MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN 26

97
 UNIFIED Modelling LANGUAGE (UML)

CLASS DIAGRAM
q Class diagram- use to document software architecture

q It is used to refine the use case diagram

q Set of interrelated classes

q It contains methods and attributes for classes

q Classes can be "is-a" or "has-a" relationship

MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN

 UNIFIED Modelling LANGUAGE (UML)

CLASS DIAGRAM
q Class diagram - Static diagram, Structural diagram

q Class diagram - attributes and operations of a class

q It explains the constraints on the system

q It is a collection of classes, interfaces, associations,

collaborations and constraints

MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN

 UNIFIED Modelling LANGUAGE (UML)

CLASS DIAGRAM
q The purpose of the class diagram can be summarized as −

Ø Analysis and design of system

Ø Describe responsibilities of a system

Ø Conceptual modelling

Ø Forward and reverse engineering

MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN

 UNIFIED Modelling LANGUAGE (UML)
UML NOTATIONS - CLASS
q Classes are used to represent objects

q UML class diagram is divided into four parts.

Ø Top section - name the class.
Ø Second - attributes of the class.
Ø Third - operations or methods performed by the class.
Ø Fourth - any additional components.

MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN

 UNIFIED Modelling LANGUAGE (UML)

Class

Relationships
Attributes

Methods

MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN

 UNIFIED Modelling LANGUAGE (UML)
Student Information-Class Diagram
Class Student
Visibility
+ name: String + Public
#Roll: Int - Private
Attributes
-Section: String # protected
~ Package/default
+ display ()
Methods -Add () Inheritance
-Edit ()
# Delete ()
Association

Anil Aggregation
Sunil

MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN

 UNIFIED Modelling LANGUAGE (UML)

Classroom
Multiplicity
N
0…*
0…1
1…*
m…n

1…* 1
Tables Projector

Composition

MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN

 UNIFIED Modelling LANGUAGE (UML)
CLASS DIAGRAM EXAMPLE- ATM SYSTEM

MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN 43

 UNIFIED Modelling LANGUAGE (UML)
CLASS DIAGRAM EXAMPLE ELEVATOR SYSTEM

Simplified Class Diagram Detailed Class Diagram

MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN 45
 UNIFIED Modelling LANGUAGE (UML)
CLASS DIAGRAM EXAMPLE WASHING MACHINE

MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN 46

108
 UNIFIED Modelling LANGUAGE (UML)
SEQUENCE DIAGRAM
q Sequence diagram - interactions among the different
elements in the model

q It describes the dynamic behavior of the system

q They explain the interaction between objects and

collaborations

q It emphasizes on the time sequence of messages and

structural organizations of the objects

MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN

 UNIFIED Modelling LANGUAGE (UML)
SEQUENCE DIAGRAM
q Sequence diagram shows the details of the use cases

q It shows the complete flow of information, function and

operations of the system

q It is used in planning and understanding the functionality of

existing and future scenario

q Time – vertical direction

q Header elements – Horizontal direction

MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN
 UNIFIED Modelling LANGUAGE (UML)

SEQUENCE DIAGRAM
q Sequence Diagrams are suitable for following scenarios:
q Usage scenario – to determine how the system could be
used
q Method logic – to explore logic of any function, procedure
or complex process
q Service logic – ideal way to explain high level methods
used by clients

MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN

 UNIFIED Modelling LANGUAGE (UML)

Actor Object Activation

Bar Synchronous message
Lifeline
Notation Comment
Return message

Alternate frame
Alt
If it is valid

Else

MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN

 UNIFIED Modelling LANGUAGE (UML)

SEQUENCE DIAGRAM EXAMPLE PRODUCT PURCHASE SYSTEM

q In this sequence diagram we have four objects
Ø Customer
Ø Product
Ø Stock
Ø Payment
q The message starts from the top and flows to the bottom (waterfall
manner)
q Dashed lines - duration for object
q Horizontal rectangles - activation of the object
q Messages sent - dark arrow and dark arrow head
q Return message - dotted arrow

MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN

 UNIFIED Modelling LANGUAGE (UML)

SEQUENCE DIAGRAM EXAMPLE - PRODUCT PURCHASE SYSTEM

Ø Customer object - to the product object
Ø Product object -to the stock object
Ø Stock object - saying yes or No.
Ø Product object sends - customer object.
Ø Customer object -payment object to pay money.
Ø Payment object - receipt to the customer object.

MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN

 UNIFIED Modelling LANGUAGE (UML)
PRODUCT PURCHASE SYSTEM
Customer
Product Stock Payment
Request Product
In stock?

Yes/No
Yes/No

Payment

Receipt

MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN

 UNIFIED Modelling LANGUAGE (UML)
SEQUENCE DIAGRAM EXAMPLE ELEVATOR SYSTEM

Sequence Diagram for Serving Elevator Button

MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN 58
 UNIFIED Modelling LANGUAGE (UML)
SEQUENCE DIAGRAM EXAMPLE VENDING MACHINE

MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN 59

118
 UNIFIED Modelling LANGUAGE (UML)

STATE DIAGRAM

q State diagram stores the status of object

q It shows the condition of system over a finite instance of time
q It’s a behavioral diagram
q It also referred to as State machines and State-chart Diagrams.
q It explains the dynamic behavior of a class
q State diagrams an be used to understand the reaction of
objects on receiving external stimuli

MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN

 UNIFIED Modelling LANGUAGE (UML)

STATE DIAGRAM
q Uses of state chart diagram:
Ø We use it to depict event driven objects
Ø We use it for showing use cases in business context
Ø Shows the overall behavior of state machine
Ø We use it to model the dynamic behavior of the system .
q Steps to draw a state diagram:
Ø Identify the initial state and the final states.
Ø Identify the possible states in which the object can exist
Ø Label the events which trigger these transitions.
MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN
 UNIFIED Modelling LANGUAGE (UML)
STATE DIAGRAM SYMBOL NOTATIONS

Initial state Transition Symbol

State
Composite State

Final state
Self Transition

MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN

 UNIFIED Modelling LANGUAGE (UML)
ONLINE ORDER MANAGEMENT Transition

Send Special or
Idle order Normal
request order v
v
Initial Abnormal
state exit state
Order
Final confirmation
state v

Dispatch
order v

MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN

 UNIFIED Modelling LANGUAGE (UML)
STATE DIAGRAM EXAMPLE ATM MACHINE

MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN 59

 UNIFIED Modelling LANGUAGE (UML)
STATE DIAGRAM EXAMPLE ELEVATOR SYSTEM

Statechart
Statechart for for
"User" “Elevator
Behavior Control
System"

MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN 59

125
 UNIFIED Modelling LANGUAGE (UML)

ACTIVITY DIAGRAM
q An activity diagram - behavioral diagram

q It shows the control flow from start to finish point including

other decisions paths that is being executed

q It can explain both sequential and concurrent processing

MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN

 UNIFIED Modelling LANGUAGE (UML)

ACTIVITY DIAGRAM

q Uses of Activity chart diagram:

Ø Modelling work flow by using activities
Ø Modelling the logic of algorithm
Ø Shows the workflow process between users and system
Ø Understanding system's functionalities.
Ø Investigating business requirements at a later stage.

MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN

 UNIFIED Modelling LANGUAGE (UML)

ACTIVITY DIAGRAM
q Steps to draw a activity diagram:
Ø Identify the initial state and the final states.
Ø Identify the intermediate activities needed to reach the final
state from he initial state.
Ø Identify the conditions or constraints which cause the
system to change control flow.
Ø Draw the diagram with appropriate notations.
MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN
 UNIFIED Modelling LANGUAGE (UML)
ACTIVITY DIAGRAM SYMBOL NOTATIONS

Action Control flow Object flow

Activity

Initial node Final node Object node Decision node Merge node

Fork node
Join node

MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN

 UNIFIED Modelling LANGUAGE (UML)
Activity Diagram of an Order Management System

Customer Order request system

sends an confirms the order Condition
order request check
Start of [No]
process
[Yes]

[Yes]
Confirm order
[No]
Termination

Dispatch order

MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN

 UNIFIED Modelling LANGUAGE (UML)
ACTIVITY DIAGRAM EXAMPLE ELEVATOR SYSTEM

ELC – Elevator Logic Control

ERS – Elevator Request Service

Request Elevator Activity

MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN 59
 UNIFIED Modelling LANGUAGE (UML)
ACTIVITY DIAGRAM EXAMPLE VENDING MACHINE

MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN 59

CODE OPTMIZATION
PROGRAM DESIGN AND ANALYSIS

• Program-level performance analysis.

• Optimizing for:
• Execution time.
• Energy/power.
• Program size.
• Program validation and testing.
• Safety and security.
 PROGRAM-LEVEL PERFORMANCE ANALYSIS
• Need to understand performance in
detail:
• Real-time behavior, not just typical.
• On complex platforms.
• Program performance ¹ CPU
performance:
• Pipeline, cache are windows into
program.
• We must analyze the entire program.
HOW TO MEASURE PROGRAM PERFORMANCE

• Simulate execution of the CPU.

• Makes CPU state visible.
• Measure on real CPU using timer.
• Requires modifying the program to control the timer.
• Measure on real CPU using logic analyzer.
• Requires events visible on the pins.
ELEMENTS OF PROGRAM PERFORMANCE

• Basic program execution time formula:

• execution time = program path + instruction timing
• Solving these problems independently helps simplify analysis.
• Easier to separate on simpler CPUs.
• Accurate performance analysis requires:
• Assembly/binary code.
• Execution platform.
DATA-DEPENDENT PATHS IN AN IF STATEMENT

if (a || b) { /* T1 */ a b c path
if ( c ) /* T2 */ 0 0 0 T1=F, T3=F: no assignments
x = r*s+t; /* A1 */
0 0 1 T1=F, T3=T: A4
else y=r+s; /* A2 */
z = r+s+u; /* A3 */ 0 1 0 T1=T, T2=F: A2, A3

} 0 1 1 T1=T, T2=T: A1, A3

else {
1 0 0 T1=T, T2=F: A2, A3
if ( c ) /* T3 */
y = r-t; /* A4 */ 1 0 1 T1=T, T2=T: A1, A3

} 1 1 0 T1=T, T2=F: A2, A3

1 1 1 T1=T, T2=T: A1, A3

PATHS IN A LOOP
i=0
f=0

N
i=N
for (i=0, f=0; i<N; i++)
Y
f = f + c[i] * x[i];
f = f + c[i] * x[i]

i=i+1
PATHS IN A LOOP WITH CONDITIONS
i=0;
executed 1 time
f=0;

T executed N+1 times

i<N
for (i=0, f=0; i<N; i++) { F
if (x[i] > 0) F
x[i] > 0 executed N times
f = f + c[i] * x[i];
T
}
f =f + c[i] * x[i]; executed 0, 𝑁 times

i++; executed N times

Computers as Components 5e © 2022 Marilyn Wolf
INSTRUCTION TIMING
• Not all instructions take the same amount of time.
• Multi-cycle instructions.
• Fetches.
• Execution times of instructions are not independent.
• Pipeline interlocks.
• Cache effects.
• Execution times may vary with operand value.
• Floating-point operations.
• Some multi-cycle integer operations.
MESAUREMENT-DRIVEN PERFORMANCE ANALYSIS

• Not so easy as it sounds:

• Must actually have access to the CPU.
• Must know data inputs that give worst/best case performance.
• Must make state visible.
• Still an important method for performance analysis.
FEEDING THE PROGRAM

• Need to know the desired input values.

• May need to write software scaffolding to generate
the input values.
• Software scaffolding may also need to examine
outputs to generate feedback-driven inputs.
TRACE-DRIVEN MEASUREMENT

• Trace-driven:
• Instrument the program.
• Save information about the path.
• Requires modifying the program.
• Trace files are large.
• Widely used for cache analysis.
PHYSICAL MEASUREMENT
• In-circuit emulator allows tracing.
• Affects execution timing.
• Logic analyzer can measure behavior at pins.
• Address bus can be analyzed to look for events.
• Code can be modified to make events visible.
• Particularly important for real-world input streams.
CPU SIMULATION

• Some simulators are less accurate.

• Cycle-accurate simulator provides accurate clock-
cycle timing.
• Simulator models CPU internals.
• Simulator writer must know how CPU works.
SIMPLESCALAR FIR FILTER SIMULATION

int x[N] = {8, 17, … };

COUNT total sim sim cycles per
int c[N] = {1, 2, … }; cycles filter execution
main() { 100 25854 259

int i, k, f; 1,000 155759 156

for (k=0; k<COUNT; k++) 1,0000 1451840 145

for (i=0; i<N; i++)

f += c[i]*x[i];
}
PERFORMANCE OPTIMIZATION MOTIVATION

• Embedded systems must often meet deadlines.

• Faster may not be fast enough.
• Need to be able to analyze execution time.
• Worst-case, not typical.
• Need techniques for reliably improving execution time.
PROGRAMS AND PERFORMANCE ANALYSIS

• Best results come from analyzing optimized instructions, not high-

level language code:
• non-obvious translations of HLL statements into instructions;
• code may move;
• cache effects are hard to predict.
LOOP OPTIMIZATIONS

• Loops are good targets for optimization.

• Basic loop optimizations:
• code motion;
• induction-variable elimination;
• strength reduction (x*2 -> x<<1).
CODE MOTION
i=0; Xi=0;
= N*M

N
i<N*M
i<X
Y
for (i=0; i<N*M; i++)
z[i] = a[i] + b[i]; z[i] = a[i] + b[i];

i = i+1;
 INDUCTION VARIABLE ELIMINATION

• Induction variable: loop index.

• Consider loop:
for (i=0; i<N; i++)
for (j=0; j<M; j++)
z[i,j] = b[i,j];
• Rather than recompute i*M+j for each array in each iteration,
share induction variable between arrays, increment at end of loop
body.
CACHE ANALYSIS

• Loop nest: set of loops, one inside other.

• Perfect loop nest: no conditionals in nest.
• Because loops use large quantities of data, cache
conflicts are common.
ARRAY CONFLICTS IN CACHE

a[0,0]
1024
1024 4099

b[0,0] ...
4099

main memory cache

ARRAY CONFLICTS, CONT’D.

• Array elements conflict because they are in the same line, even if
not mapped to same location.
• Solutions:
• move one array;
• pad array to change alignment.
ARRAY PADDING

• Add array elements to change mapping into cache:

a[0,0] a[0,1] a[0,2] a[0,0] a[0,1] a[0,2] a[0,2]

a[1,0] a[1,1] a[1,2] a[1,0] a[1,1] a[1,2] a[1,2]

before after
LOOP TILING EXAMPLE
• Breaks one loop into a nest of loops.
• Changes order of accesses within array.
• Changes cache behavior.
for (j=0; j < N; j += TILE) {
for (i=0; i<N; i++) {
for (i=0; i<N; i++) {
for (j=0; j<N; j++) {
for (jj=0; j<TILE; jj++) {
z[i][j] = x[i] * y[j];
z[i][j + jj] = x[i] * y[j + jj];
}
}
}
}
}
x[0] x[] x[0] x[1] x[]

y[N-
y[0] y[1] y[] y[0] y[1] y[]
1]
PERFORMANCE OPTIMIZATION HINTS

• Use registers efficiently.

• Use page mode memory accesses.
• Analyze cache behavior:
• instruction conflicts can be handled by rewriting code, rescheudling;
• conflicting scalar data can easily be moved;
• conflicting array data can be moved, padded.

Computers as Components 5e © 2022 Marilyn Wolf

 LOGIC ANALYZER
LOGIC ANALYZER
• A logic analyzer is an electronic measurement device that
captures and displays multiple signals from a digital
design
• It is an excellent tool for checking and debugging ICs,
digital systems, circuits such as embedded systems,
electronic control units, computers, etc.
• A modern logic analyzer can convert the captured data
into timing diagrams, protocol decodes, state machine
traces, and assembly language.
Computers as Components 5e © 2022 Marilyn Wolf
 LOGIC ANALYZER

Computers as Components 5e © 2022 Marilyn Wolf

 LOGIC ANALYZER
• The logic analyzer allows different types of standard interfaces to be
automatically decoded.
• Depending on the analyzer these can include UART, SPI, I2C, CAN and
many more.
Characteristics:
• Multiple channels
• Provide a time display of logic states
• Displays logic states
• Does not display analog information
Computers as Components 5e © 2022 Marilyn Wolf
 PROGRAMMING ENVIRONMENT
Embedded Software Development Tools:
Ø Editor
Ø Compiler
Ø Assembler
Ø Debugger
Ø Linker
Ø Emulator

Computers as Components 5e © 2022 Marilyn Wolf

 EMBEDDED SOFTWARE DEVELOPMENT TOOLS LIST
Ø PyCharm
Ø WebStorm
Ø Qt Creator
Ø MPLAB X
Ø Eclipse
Ø Visual Studio
Ø NetBeans
Ø MATLAB
Ø Arduino IDE
Ø ARM Keil
Computers as Components 5e © 2022 Marilyn Wolf
THANK YOU…

164