Anda di halaman 1dari 44

EE 445L – Embedded System Design Lab

Interrupts
Software style guidelines
Debugging

EE 445L – Bard, Valvano 1


Device Enable
• Nested Vectored Interrupt Controller (NVIC)
– Device must be enabled in the NVIC and its
priority set
– BASEPRI register sets priority of interrupts that
are permitted to occur
• if BASEPRI = 3, interrupts with priority
– 0 – 2 can occur, suspending this interrupt
– 3-7 will be postponed until this interrupt is finished

EE 445L – Bard, Valvano 2


Arm
• Each potential interrupt source has a
separate arm bit.
– Set arm bits for those devices from which it
wishes to accept interrupts,
– Deactivate arm bits in those devices from
which interrupts are not allowed

EE 445L – Bard, Valvano 3


Flag
• Each potential interrupt source has a
separate flag bit.
– hardware sets the flag when it wishes to
request an interrupt
– software clears the flag in ISR to signify it is
processing the request

EE 445L – Bard, Valvano 4


Enable
• Interrupt enable bit, I, (bit 0 of PRIMASK)
which is in the condition code register.
– enable all armed interrupts by setting I=0
– disable all interrupts by setting I=1
– I=1 does not dismiss the interrupt requests,
rather it postpones them

EE 445L – Bard, Valvano 5


Interrupt Enable/Disable
;*********** DisableInterrupts ***************
; disable interrupts
; inputs: none
; outputs: none
DisableInterrupts
CPSID I
BX LR
;*********** EnableInterrupts ***************
; disable interrupts
; inputs: none
; outputs: none
EnableInterrupts
CPSIE I
BX LR

EE 445L – Bard, Valvano 6


Interrupt Requirements
• 1) Enable device in the NVIC
• 2)Initialization software will set the arm bit
– individual control bit for each possible flag that can
interrupt
• 3) When it is convenient, the software will
enable, I=0
– allow all interrupts now
• 4) Hardware action (busy to done) sets a flag
– e.g., new input data ready, output device idle,
periodic, alarm

EE 445L – Bard, Valvano 7


Latency
• input device
– latency is the time between new input data ready
and the software reading the data
• output device
– latency is the time between output device idle and
the software giving the device new data to output.
• periodic events (sampling ADC, outputting to
DAC).
– latency is the time between when it is supposed to
be run and when it is actually run.
EE 445L – Bard, Valvano 8
Latency
• A real time system is one that can guarantee a
worst case software latency.
– it guarantees an upper bound on the software
response time

EE 445L – Bard, Valvano 9


Latency
• hardware or device latency is the time between
when an I/O device is given a command, and the time
when command is completed
• bandwidth is maximum data flow that can be
processed
– bandwidth can limited by the I/O device or software
– can be reported as an overall average or a short-term
maximum.
• priority determines the order of service when two or
more requests are made simultaneously.
– a "soft-real-time" system supports priority

EE 445L – Bard, Valvano 10


Bandwidth Limits
• I/O bound is defined as
– bandwidth is limited by speed of I/O device
– making the I/O device faster will increase
bandwidth
– making the software run faster will not increase
bandwidth
– software often waits for the I/O device

EE 445L – Bard, Valvano 11


Bandwidth Limits
• CPU bound is defined as
– bandwidth is limited by speed of executing
software
– making the I/O device faster will not increase
bandwidth
– making the software run faster will increase
bandwidth
– software does not have to wait for the I/O device
For more information read Sections 5.1, 5.2 in the book

EE 445L – Bard, Valvano 12


Multiple Devices
busy-wait synchronization
• overall system Ready
Status1
bandwidth can be
Busy Input/Output
improved by data1
establishing concurrent Ready
Status2
I/O operations
Busy Input/Output
data2

Ready
Status3
Busy Input/Output
data3
Other
functions
EE 445L – Bard, Valvano 13
Dynamic Efficiency
• Bandwidth
– calculations performed per second
– data transferred per second
• Latency or response time (real time means
bounded latency)
– time from a request to the time action satisfies
request
– time new input ready to time data is read
– time output device is idle to time new data is
written
EE 445L – Bard, Valvano 14
Static Efficiency
• Size of RAM (variables, stack)
– TM4C123, 32 KiB RAM
– TM4C1294, 256 KiB RAM
– MSP430F2013, 128 bytes RAM
• Size of ROM (constants, program)
– TM4C123, 256 KiB EEPROM
– TM4C1294, 1 MiB EEPROM
– MSP430F2013, 2 KiB EEPROM

EE 445L – Bard, Valvano 15


System Specifications
(what must be done)
• bandwidth, latency
• accuracy (difference between measured and truth)
• resolution (smallest change that can be detected)
• repeatability (standard deviation of multiple
observations)
– same operator, conditions, day, machine
• reproducibility (standard deviation of multiple
observations)
– different operator, conditions, day, machine

EE 445L – Bard, Valvano 16


Constraints
(what must NOT be done)
• power, size, weight
– must not stop running for within 24 hours on +9V
– must not be bigger than 5 by 3 by 1 inch
– must not weight more than 1 lbs
• software development costs,
– must not cost more than $100,000
• memory available,
– must not need more than 2 KiB RAM or 32 KiB ROM
• time-table.
– must not take more than 1 month to produce

EE 445L – Bard, Valvano 17


Thinking Forth - Brodie
EE 445L – Bard, Valvano 18
Software Maintenance
• Important embedded system requirement:
– verification of proper operation
– updates
– fixing bugs
– adding features
– extending to new applications
– change user configurations

EE 445L – Bard, Valvano 19


Self-Documenting Code
Naming Conventions
• Names should have meaning.
• Avoid ambiguities.
• Give hints about the type.
• Use the same name to refer to the same type of
object.
• Use a prefix to identify public objects.
• Use upper and lower case to specify the scope
of an object.
• Use capitalization to delimit words.
EE 445L – Bard, Valvano 20
Self-Documenting Code
Naming Conventions

An object's properties (public/private,


local/global, constant/variable) are always
perfectly clear at the place where the object is
defined. The importance of the naming policy
is to extend that clarity also to the places
where the object is used.

EE 445L – Bard, Valvano 21


Self-Documenting Code
Naming Conventions
Type examples
Constants SAFE_TO_RUN
START_OF_RAM
PORTA
local variables maxTemperature
lastCharTyped
errorCnt
private global variable MaxTemperature
LastCharTyped
ErrorCnt
public global variable DAC_MaxTemperature
Key_LastCharTyped
Network_ErrorCnt
private function ClearTime
wrapPointer
InChar
public function Timer_ClearTime
RxFifo_Put
Key_InChar

EE 445L – Bard, Valvano 22


Code (*.c) File
• Opening comments in the code file.
– intended to be read by co-worker
– first line should contain the file name
– the overall purpose of the software module
– the names of the programmers
– the creation (optional) and last update dates
– the hardware/software configuration required to
use the module
– any copyright information
EE 445L – Bard, Valvano 23
Header (*.h) Files
• assist in drawing a call-graph
• avoid having one header file include other
header files
• only those files that are absolutely necessary

EE 445L – Bard, Valvano 24


Comments
• Good ones:
– how it works
– why it is done this way
– how to change
• Bad ones:
– what it is doing (n = n + 1)

EE 445L – Bard, Valvano 25


Debugging
it’s in the news
“Most throttle systems on modern vehicles are electronic.
Typically, the driver steps on the accelerator and gets
resistance back from a spring. The movement activates
components in the pedal assembly that send an
electronic signal to the engine-control computer, and a
signal from the computer feeds more fuel to the engine.”

-www.msnbc.msn.com/id/35110966/ns/business-autos/
1/28/10

EE 445L – Bard, Valvano 26


Relevant Aphorisms
• The turtle wins the race!
– It is better to have a software system that runs slow
than one that does run at all.
• There are two ways of constructing a software
design:
– one way is to make it so simple that there are
obviously no deficiencies
– make it so complicated that there are no obvious
deficiencies. -Hoare, "The Emperor's Old
Clothes," CACM Feb. 1981.
EE 445L – Bard, Valvano 27
Golden Rule of Software Development

Write software for others as you wish they


would write for you.

For more information read Section 3.3 in the book

EE 445L – Bard, Valvano 28


Developer’s Attitude
• embarrassed to deliver poorly written software
• modules that are easy to change
• expect our code will be modified
• reward good behavior
• punish bad behavior
• test it now, fix it now
• plan for testing

EE 445L – Bard, Valvano 29


Constituents
• client
– programmers who will use our software
– develops software that will call our functions
• coworkers
– programmers who will debug and upgrade our
software
– develops, tests, and modifies our software

EE 445L – Bard, Valvano 30


High Quality Programming
• Characteristics
– easy to debug (fix mistakes)
– easy to verify (prove correctness)
– easy to maintain (add features)

EE 445L – Bard, Valvano 31


Debugging
• Types
– performance debugging (timing)
– functional debugging (data)
• Goal of debugging
– maintain and improve software
– remedy faults or to correct errors in a program
– role of a debugger is to support this endeavor
• The debugging process
– testing,
– stabilizing,
– localizing, and
– correcting errors.
EE 445L – Bard, Valvano 32
Manual Methods
• desk-checking
– Hand execute the program and think about it a lot
• Write down intermediate results
– Then execute program and compare
• What you thought it should do
• What is actually is doing
• dumps,
– save important data into an array, look at it later
• print statements
– print important during execution
EE 445L – Bard, Valvano 33
Hardware debugging tools
• Logic analyzer LM3S Logic Analyzer
or
Digital
– Multiple channel, digital, TM4C
Interface
storage scope Digital
– Flexible method of Interface
PB1
triggering PB0

EE 445L – Bard, Valvano 34


TI’s Debug Module (Spy Bi-ware)

EE 445L – Bard, Valvano 35


Joint Test Action Group (JTAG)
Industry Standard Debug Module

EE 445L – Bard, Valvano 36


Software Debugging Tools
• A debugging instrument
– software that is added to the program for the
purpose of debugging, e.g., print statement
– instrument added using editor/assembler/loader

EE 445L – Bard, Valvano 37


Software Debugging Tools
• Dump without filter
#define SIZE 100
uint32_t Debug_Buffer[SIZE][2];
uint32_t Debug_Cnt=0;
// dump Happy and Sad
void Debug_Dump(void){
if(Debug_Cnt < SIZE){
Debug_Buffer[Debug_Cnt][0] = Happy;
Debug_Buffer[Debug_Cnt][1] = Sad;
Debug_Cnt ++;
}
}
EE 445L – Bard, Valvano 38
Software Debugging Tools
• Choose one of the following techniques
– Place all instruments in the first column, they are easy to see
– Define instruments with specific pattern in their names
– Use instruments that test a run time global flag
– leaves a permanent copy of the debugging code
– will cause it to suffer runtime overhead when activated
– simplifies “on-site” customer support.
– Use conditional compilation (or conditional assembly)

– Easy to remove all instruments


– But, Leave the instruments
• Because this is the way it was proven to work
• May need more testing

EE 445L – Bard, Valvano 39


Software Debugging Tools
• Add a LED monitor
– Serves as Heart beat
– Question: Is my program running?
– Method: Add instruments, assemble, download, run
– Initialization
• Clock, data enable, direction register
– Debugging Instrument
• #define PF2 (*((volatile uint32_t *) 0x40025010))
• #define Debug_HeartBeat() (PF2 ^= 0x04)
– Results: No it is not running?
– Action: Fix the bug, assemble, download, run

EE 445L – Bard, Valvano 40


Software Debugging Tools
• Dump into array with filtering
– A filter is a software/hardware condition that must be
true in order to place data into the array
#define SIZE 100
uint32_t Debug_Buffer[SIZE][2];
uint32_t Debug_Cnt=0;
// dump Happy and Sad
void Debug_FilteredDump(void){
if((Sad > 100)&&(Debug_Cnt < SIZE)){
Debug_Buffer[Debug_Cnt][0] = Happy;
Debug_Buffer[Debug_Cnt][1] = Sad;
Debug_Cnt ++;
}

EE 445L – Bard, Valvano 41


Intrusiveness
– degree of perturbation caused by the debugging itself
(Heisenberg)
– how much the debugging slows down execution
• Nonintrusive
– characteristic or quality of a debugger
– allows system to operate as if debugger did not exist
– e.g., logic analyzer, ICE
• Minimally intrusive
– negligible effect on the system being debugged
– e.g., dumps (ScanPoint) and monitors, BDM
• Highly instrusive
– print statements, breakpoints and single-stepping
EE 445L – Bard, Valvano 42
Software Debugging Tools
• Performance Debugging
– Verification of timing behavior of our system
– Dynamic process
• system is run
• dynamic behavior compared to expected results

EE 445L – Bard, Valvano 43


Debugging Summary
• Intrusiveness
• Stabilization
• Acceleration
• Near the extremes and in the middle
• Variability • Most typical of how our clients will properly use it
• Most typical of how our clients will improperly use it
• Stress • That differ by one
• You know your system will find difficult
• Coverage • Using a random number generator

For more information read Section 3.9 in the book

EE 445L – Bard, Valvano 44

Anda mungkin juga menyukai