introduction to embedded systemscs5780/lectures/09_5780_l6_2up.pdfintroduction to embedded systems...
TRANSCRIPT
Page 1
1 CS 5780 School of Computing University of Utah
Introduction to Embedded Systems
CS/ECE 6780/5780
Al Davis
Today’s topics:
• logistics – minor
• more software development issues
2 CS 5780 School of Computing University of Utah
Software Update Problem
• Lab machines work let us know if they don’t
• Personal machines have update issues Torrey & William have been trying to find a fix
» so far the solution has been elusive
• Labs next lab will be assembly oriented
hopefully posted by tomorrow
Page 2
3 CS 5780 School of Computing University of Utah
Modular SW Development
• Modular programming breaks SW into distinct and independent modules
provides: » functional abstraction to support reuse
» complexity abstraction • divide and conquer approach
» portability
4 CS 5780 School of Computing University of Utah
Global Variables
• Global information shared by more than one module
use them to pass data between main() and interrupts data is permanent and not deallocated
• Can use absolute addressing to access globals
• I/O ports and registers are considered global values it would be silly to view them as locally scoped
Page 3
5 CS 5780 School of Computing University of Utah
Local Variables
• Temporary information used by only one module typically allocated, used, and deallocated
» hence information is not permanent
• Stored on stack or registers dynamic allocation/release allows memory reuse
limited scope provides data protection
since interrupt saves registers and uses it’s own stack » code may still be re-entrant
code is relocatable
number of local variables » only limited by stack size
6 CS 5780 School of Computing University of Utah
Two Local 16-bit Variables: Take 1
*X sum and *X+2 n (stack grows down) n and sum are now X relative offsets
Page 4
7 CS 5780 School of Computing University of Utah
Take 1 continued
8 CS 5780 School of Computing University of Utah
Two Local 16-bit Variables: Take 2
• 6812 allows negative offset addressing
X now points inside the stack frame leas: load effective address SP
Page 5
9 CS 5780 School of Computing University of Utah
Take 2 continued
deallocation phase now 1 instruction shorter than in Take 1
10 CS 5780 School of Computing University of Utah
Take 2 Execution
Page 6
11 CS 5780 School of Computing University of Utah
Take 2 Execution
SP decrements by 2
12 CS 5780 School of Computing University of Utah
Take 2 Execution
Page 7
13 CS 5780 School of Computing University of Utah
Take 2 Execution
n sum
14 CS 5780 School of Computing University of Utah
Take 2 Execution
Page 8
15 CS 5780 School of Computing University of Utah
Take 2 Execution
16 CS 5780 School of Computing University of Utah
Take 2 Execution
Page 9
17 CS 5780 School of Computing University of Utah
Take 2 Execution
18 CS 5780 School of Computing University of Utah
Take 2 Execution
Page 10
19 CS 5780 School of Computing University of Utah
Take 2 Execution
20 CS 5780 School of Computing University of Utah
Take 2 Execution
Page 11
21 CS 5780 School of Computing University of Utah
Take 2 Execution
22 CS 5780 School of Computing University of Utah
End of loop
Page 12
23 CS 5780 School of Computing University of Utah
Put Sum in D register
24 CS 5780 School of Computing University of Utah
Restore Stack Pointer & Dellocate
Page 13
25 CS 5780 School of Computing University of Utah
Restore X Register & Voila done
26 CS 5780 School of Computing University of Utah
Returning Multiple Parameters: Registers
Page 14
27 CS 5780 School of Computing University of Utah
Returning Multiple Values: stack
28 CS 5780 School of Computing University of Utah
More Issues
• All assembly exit points must balance the stack
» call and return sequences are mirrored
• Performing unnecessary I/O in a subroutine limits reuse
• I/O devices must be considered global restrict the number of modules that access them
• Information hiding expose only the necessary information at the interfaces
» promotes understanding and reduces conceptual complexity
» e.g. hide inner workings of the black box from the user
Page 15
29 CS 5780 School of Computing University of Utah
Module Decomposition
• Coupling influence a module’s behavior has on another module
• Task decomposition goals make the SW organization easier to understand
increase the number of modules » this may increase code footprint and/or increase run time
• due to extra subroutine linkages
» but start properly and then optimize if you have to
» minimize coupling as much as possible
• Develop, connect and test modules in a hierarchy top-down – “write no software until every detail is
specified”
bottom-up – “one brick at a time”
• Initial design is best done top-down • Implementation is best done bottom-up
namely you have something to test
30 CS 5780 School of Computing University of Utah
Layered Software Systems
• Note SW continually changes as better HW or algorithms become
available
• Layered SW facilitates these changes top layer is the main program
lowest layer is the HW abstraction layer » modules that access the I/O HW
• Hierarchy should be strict each layer can only call lower layers
» ideal is to only call the next lower layer
gate or API » defines the interface at the next lower layer
if this happens » each layer can be replaced without affecting other layers
» possible downside: code bloat • optimize last policy is a good one
• easier to optimize correctly based on measurements of working code
Page 16
31 CS 5780 School of Computing University of Utah
Layered Parallel Port Example
32 CS 5780 School of Computing University of Utah
Layered SW Rules
• Modules may make calls to modules in the same layer
• Modules may call lower layer only using gate • Module has no access to any function or variable in
another layer except via gate
• Modules can’t call upper layers
• Ideal yet optional module calls only next layer down
all I/O access is at the lowest layer
user interface is at the highest level
Page 17
33 CS 5780 School of Computing University of Utah
Device Driver Concepts
• Purpose SW interface to physical I/O devices
» interface API for upper layers
» low-level routines to configure and perform actual I/O
• Separation of policy and mechanism is important e.g. interface may include routines to open, read, and write
files » but it shouldn’t care about what device the files reside on
• HAL provide a good hardware abstraction layer
34 CS 5780 School of Computing University of Utah
Low-Level Device Drivers
• Normally found in BIOS ROM basic I/O system
• Good low-level drivers allow: new hardware to be installed
new algorithms to be implemented » synchronization w/ completion flags/interrupts
» error detection and recovery methods
higher-level features built on top of low-level » OS features like blocking semaphores
» driver features like automatic compression/decompression
Page 18
35 CS 5780 School of Computing University of Utah
Encapsulated Objects in ANSI C
• Choose names to reflect the module in which they are defined Example
36 CS 5780 School of Computing University of Utah
Reentrancy
• Reentrant if it can be conurrently executed by 2 or more threads
or by main and one or more interrupts
• Rules for reentrant functions must not call a non-reentrant function
must not touch global variables w/o proper locking
Page 19
37 CS 5780 School of Computing University of Utah
Coding Guidelines
• Guidelines that cannot be checked by a smart compiler are less effective
• Too many guidelines are worthless too hard to remember or enforce
• Following is a 10 rule list by Gerard Holzman
» leads NASA/JPL’s Lab for Reliable Software • needless to say it’s hard to debug things in outer space
note » these are good things to know
» even though some of the implied tools aren’t available to you at the moment
38 CS 5780 School of Computing University of Utah
Rule 1
Page 20
39 CS 5780 School of Computing University of Utah
Rule 2
40 CS 5780 School of Computing University of Utah
Rule 3
Page 21
41 CS 5780 School of Computing University of Utah
Rule 4
42 CS 5780 School of Computing University of Utah
Rule 5
Page 22
43 CS 5780 School of Computing University of Utah
Rule 6
44 CS 5780 School of Computing University of Utah
Rule 7
Page 23
45 CS 5780 School of Computing University of Utah
Rule 8
46 CS 5780 School of Computing University of Utah
Rule 9
Page 24
47 CS 5780 School of Computing University of Utah
Rule 10
48 CS 5780 School of Computing University of Utah
Debugging Theory
• Process of testing, stabilizing, localizing, and correcting errors
• Research in program monitoring & debugging has not kept up gdb has been around for 30+ years
so has printf alas the Symbolics 3600 system has been left behind
» it shouldn’t have
• ES debugging is even more complicated by concurrency and real-time requirements
printf is a problem because they are slow
Page 25
49 CS 5780 School of Computing University of Utah
HW Debugging
50 CS 5780 School of Computing University of Utah
Debugging w/ SW
• Debugging instrument » code added to a program to improve visibility of internals
» extra visibility aids debugging
» printf is the common example
• Printf instrument policy (use one or more) place printf statements in a unique column define instruments with a specific naming pattern
define all instruments to test a run-time global flag
use conditional compilation (assembly) to turn on/off
Page 26
51 CS 5780 School of Computing University of Utah
Functional/Static Debugging
• Functional check that the right computation is done Inputs supplied
run system check outputs
• Several methods single step
tracing
breakpoints w/o filtering
conditional breakpoints
instrumentation: printf’s to a trace file » with or without filtering
• you only want values within a specific range
monitor with a fast display
52 CS 5780 School of Computing University of Utah
Performance Debugging
• Verification of timing behavior run system and check dynamic I/O behavior
» count bus cycles using the assembly listing
» instrumentation – measure with a counter
Page 27
53 CS 5780 School of Computing University of Utah
Instrumentation via Output Port
How would you improve on this?
54 CS 5780 School of Computing University of Utah
Concluding Remarks
• As Arlo says “you can’t always do what you’re supposed to do”
• But keeping these coding tips in mind will make you a better
programmer
and reduce hair pulling panic attacks
in later professional life » these types of things will be mandated by your company
• albeit in a slightly different form
• So might as well develop good habits early
» some of you already have