Case Study Es

8/12/2019 Case Study Es

1/21

ALARM CLOCK

1. Requirements

The basic functions of an alarm clock are well understood and easy to enumerate.Figure

4.34 illustrates the front panel design for the alarm clock. The time is shown as four

digits in 12-h format; we use a light to distinguish between ! and "!. #e use se$eral

buttons to set the clock time and alarm time. #hen setting the time% we must hold down

the set time button while we hit the hour and minute buttons; the set alarm button

works in a similar fashion. #e turnthe alarm on and o& with the alarm on and alarm of

buttons. #hen the alarm is acti$ated% the alarm ready light is on. separate speaker

pro$ides the audiblealarm.


2/21

2. Specifcation

The basic function of the clock is simple% but we do need to create some classes

and associated beha$iors to clarify e'actly how the user interface works. Figure

4.3( shows the basic classes for the alarm clock. )orrowing a term from

mechanical watches% we call the class that handles the basic clock operation the

Mechanism class.

#e ha$e three classes that represent physical elements* Lights+ for all the digits

and lights% Buttons+ for all the buttons% and Speaker+ for the sound output. The

Buttons+ class can easily be used directly by Mechanism.

The details of the low-le$el user interface classes are shown in Figure 4.3,. The

Buzzer+ class allows the buer to be turned o&; we will use analog electronics to

generate the bu tone for the speaker. The Buttons+ class pro$ides read-only


3/21

access to the current state of the buttons. The Lights+ class allows us to dri$e the

lights.

#e generate the display by scanning the digits periodically. That function is

performed by the Display class% which makes the display appear as an unscanned%

continuous display to the rest of the system. The Mechanism class is described in

Figure 4.3. This class keeps track of the current time% the current alarm time%

whether the alarm has been turned on% and whether it is currently buing. The clock

shows the time only to the minute% but it keeps internal time to the second. The time is kept as discrete digits rather than a single integer to simplify transferring

the time to the display. Figure 4.3/ shows the state diagram for update-time. This

beha$ior is straightforward% but it must do se$eral things. 0t is acti$ated once per

second and must update the seconds clock. 0f it has counted , s% it must then


4/21

update the displayed time; when it does so% it must roll o$er between digits and keep

track of !-to-"! and "!-to-! transitions. 0t sends the updated time to the display

obect. 0t also

compares the time with the alarm setting and sets the alarm buing under proper

conditions. The state diagram for scan-keyboard is shown in Figure 4.3.

nce computing the acti$ation $alues for all the buttons% it looks at the acti$ation

combinations and takes the appropriate actions. )efore e'iting% it sa$es the current button

$alues for computing acti$ations the ne't time this beha$ior is e'ecuted.

System Architecture

The software and hardware architectures of a system are always hard to completely

separate% but let5s 6rst consider the software architecture and then its implications on

the hardware. The system has both periodic and aperiodic components7the current time

must ob$iously be updated periodically% and the button commands occur occasionally. 0tseems reasonable to ha$e the following two maor software components*

n interrupt-dri$en routine can update the current time. The current time will be kept in

a $ariable in memory. timer can be used to interrupt periodically and update the time.

s seen in the subse8uent discussion of the hardware


5/21

architecture% the display must be sent the new $alue when the minute $alue changes.This routine can also maintain the "! indicator.

foreground program can poll the buttons and e'ecute their commands. 9ince

buttons are changed at a relati$ely slow rate% it makes no sense to add the hardware

re8uired to connect the buttons to interrupts. 0nstead% the foreground program will

read the button $alues and then use simple conditional tests to implement the

commands% including setting the current time% setting


6/21

the alarm% and turning o& the alarm. nother routine called by the foreground

program will turn the buer on and o& based on the alarm time. n important

8uestion for the interrupt-dri$en current time handler is how often the timer

interrupts occur. 1-min inter$al would be $ery con$enient for the software% but a

one-minute timer would re8uire a large number of counter bits. 0t is more realistic to

use a one-second timer and to use a program $ariable to count the seconds in a

minute.

The foreground code will be implemented as a while loop*

while (TRUE) {

read_buttons(button_values);/* read inputs */

process_command(button_values);/* do commands */

check_alarm();/* decide whether to turn on the alarm */

The loop 6rst reads the buttons using read_ buttons (). 0n addition to reading the

current button $alues from the input de$ice% this routine must preprocess the button

$alues so that the user interface code will respond properly. The buttons will remain

depressed for many sample periods since the sample rate is much faster than any

person can push and release buttons. #e want to make sure that the clock responds

to this as a single depression of the button% not one depression per sample inter$al.

s shown in Figure 4.4% this can be done by performing a simple edge detection on

the button input7the button e$ent $alue is 1 for one sample period when the button


7/21

is depressed and then goes back to and does not return to 1 until the button is

depressed and then released.

The 6nal step before starting to write code and build hardware is to draw the state

transition graph for the clock5s commands. That diagram will be used to guide the

implementation of the software components.

3. Component Design an !esting The two maor software components% the interrupt handler and the foreground code%

can be implemented relati$ely straightforwardly. 9ince most of the functionality of

the interrupt handler is in the interruption process itself% that code is best tested on

the microprocessor platform. The foreground code can be more easily tested on the

": or workstation used for code de$elopment. better testing strategy is to add testing code that updates the clock% perhaps once

per four iterations of the foreground while loop. The timer will probably be a stock

component% so we would then focus on implementing logic to interface to the

buttons% display% and buer. The buttons will re8uire debouncing logic. The displaywill re8uire a register to hold the current display $alue in order to dri$e the display

elements.

". System #ntegration an !esting

)ecause this system has a small number of components% system integration is relati$ely

easy. The software must be checked to ensure that debugging code has been turned o&.

Three types of tests can be performed. First% the clock5s accuracy can be checked against

a reference clock. 9econd% the commands can be e'ercised from the buttons. Finally% the

buer5s functionality should be $eri6ed.


8/21

D#$#!AL S!#LL CAM%RAS

The digital still camera bears some resemblance to the film camera but is fundamentally different

in many respects. The digital still camera not only captures images, italso performs a substantial

amount of image processing that formerly was done byphotofinishers.Digital image processing

allows us to fundamentally rethink the camera. A simpleexample is digital zoom, which is usedto extend or replace optical zoom.Many cell phones include digital cameras, creating a hybrid

imaging/communicationdeice.

Digital still cameras must perform many functions!

" #t must determine the proper exposure for the photo.

" #t must display a preiew of the picture for framing.

" #t must capture the image from the image sensor.

" #t must transform the image into usable form.

" #t must conert the image into a usable format, such as $%&', and store the image in a file

system.

A typical hardware architecture for a digital still camera is shown in (igure ).*+. Most cameras

use two processors. The controller seuences operations on the camera and performs operations

like file system management. The D-% concentrates on image processing. The D-% may be

either a programmable processor or a set of hardwired accelerators. Accelerators are often used

to minimize power consumption.

The picture taking process can be diided into three main phases! composition, capture, and

storage. e can better understand the ariety of functions that must be performed by the camera

through a seuence diagram. (igure ).* shows a


9/21

seuence diagram for taking a picture using a point0and0shoot digital still camera. As we walk

through this seuence diagram, we can introduce some concepts in digital photography. hen

the camera is turned on, it must start to display the image on the camera1s screen. That imagery

comes from the camera1s image sensor. To proide a reasonable image, itmust ad2ust the image

exposure. The camera mechanism proides two basic exposure controls! shutter speed andaperture. The camera also displays what is seen through the lens on the camera1s display. #n

general, the display has fewer pixels than does the image sensor3 the image processor must

generate a smaller ersion of the image.

4irtually all still cameras use a single image sensor to capture a color image. 5olor is captured

using microscopic color filters, each the size of a pixel, oer the image sensor. -ince each pixel

can capture only one color, the color filters must be arranged in a pattern across the image sensor.

A commonly used pattern is the 6ayer pattern 76ay)89 shown in (igure ).*8. This pattern uses

two greens for eery red and blue pixel since the human eye is most sensitie to green. The

camera must interpolate colors so that eery pixel has red, green, and blue alues.


10/21

After this image processing is complete, the image must be compressed and saed. #mages are

often compressed in $%&' format, but other formats, such as '#(, may also be used. The &:#(

standard ;http!//www.exif.org< defines a file format for data interchange. -tandard compressed

image formats such as $%&' are components of an &:#( image file3 the &:#( file may also

contain a thumbnail image for preiew, metadata about the picture such as when it was taken,

etc.


11/21

AUDIO PLAYERS

Audio players are often called MP3 players after the popular audio data format. The earliest

portable M%+ players were based on compact disc mechanisms. Modern M%+ players use either

flash memory or disk dries to store music. An M%+ player performs three basic functions! audio

storage, audio decompression, and user interface. Although audio compression is

computationally intensie, audio decompression is relatiely lightweight. The incoming bit

stream has been encoded using a =uffman0style code, which must be decoded. The audio data

itself is applied to a reconstruction filter, along with a few other parameters. M%+ decoding can,

for example, be executed using only >?@ of an AM) 5%B. The user interface of an M%+ player

is usually kept simple to minimize both the physical size and power consumption of the deice.

Many players proide only a simple display and a few buttons.

#mage compression need not be performed strictly in real time. =oweer, many cameras allow

users to take a burst of images, in which case the images must be compressed uickly to make

room in the image processing pipeline for the next image. 6uffering is ery important in digital

still cameras. #mage processing often takes longer than capturing an image. Bsers often want to

take a burst of seeral pictures, for example during sports eents.


12/21

The file system of the player generally must be compatible with %5s. 5D/M%+ players used

compact discs that had been created on %5s. Today1s players can be plugged into B-6 ports andtreated as disk dries on the host processor.

The memory controller can be interfaced to seeral different types of memory! flash memory can

be used for data or code storage3 DAM can be used as a buffer to handle temporary disruptions

of the 5D data stream. The audio interface unit puts out audio in formats that can be used by A/D

conerters.

DATA COMPRESSOR

Cur design example for this chapter is a data compressor that takes in data with a constant

number of bits per data element and puts out a compressed data stream in which the data is

encoded in ariable0length symbols. 6ecause this chapter concentrates on 5%Bs, we focus on the

data compression routine itself.

.!." Re#uirements and A$gorit%m

e use the Huffman coding techniue, which is introduced in Application &xample +.. e

reuire some understanding of how our compression code fits into a larger system. (igure +.*?

shows a collaboration diagram for the data compression process. The data compressor takes in a

seuence of input symbols and then produces a stream of output symbols. Assume for simplicity

that the input symbols are one byte in length. The output symbols are ariable length, so we hae

to choose a format in which to delier the output data. Deliering each coded symbol separately


13/21

is tedious, since we would hae to supply the length of each symbol and use external code to

pack them into words. Cn the other hand, bit0by0bit deliery is almost certainly too slow.

Therefore, we will rely on the data compressor to pack the coded symbols into an array. There is

not a one0to0one relationship between the input and output symbols, and we may hae to wait for

seeral input symbols before a packed output word comes out.

Speci&ication

et1s refine the description of (igure +.*? to come up with a more complete specification for our

data compression module. That collaboration diagram concentrates on the steady0state behaior

of the system. (or a fully functional system, we hae to proide the following additional

behaior.

" e hae to be able to proide the compressor with a new symbol table.

" e should be able to flush the symbol buffer to cause the system to release all pending

symbols that hae been partially packed. A class description for this refined understanding of the

reuirements on the module is shown in (igure +.*>. The class1s buffer and current-bitbehaiors

keep track of the state of the encoding, and the table attribute proides the current symbol table.

The class has three methods as follows!

" Encodeperforms the basic encoding function. #t takes in a >0byte input symbol and returns

two alues! a boolean showing whether it is returning a full buffer and, if the boolean is true, the

full buffer itself.


14/21

New-symbol-table installs a new symbol table into the ob2ect and throws away the current

contents of the internal buffer.

" Flush returns the current state of the buffer, including the number of alid bits in the buffer.

e also need to define classes for the data buffer and the symbol table. These classes are shown

in (igure +.**.The data-buffer will be used to hold both packed symbols and unpacked ones

;such as in the symbol table


15/21

shows a state diagram for insert. #t shows that we must consider two casesEthe new symbol

does not fill the current buffer or it does.

.!. Program Design

-ince we are only building an encoder, the program is fairly simple. e will use this as an

opportunity to compare ob2ect0oriented and non0CC implementations by coding the design in

both 5FF and 5.

OO design in C

(irst is the ob2ect0oriented design using 5FF,since this implementation most closely mirrors the

specification. The first step is to design the data buffer. The data buffer needs to be as long as the

longest symbol.e also need to implement a function that lets us merge in another

dataGbuffer,shifting the incoming buffer by the proper amount.


16/21

const int databuflen H I3 /J as long in bytes as longest symbol J/

const int bitsperbyte H I3 /J definition of byte J/

const int bytemask H ?xff3 /J use to mask to I bits for safety J/

const char lowbitsmask 7bitsperbyte9 H K ?, >, +, ), >8, +>, L+, >*)3 /J used to keep low bits in a

byte J/typedef char boolean3 /J for clarity J/

Ndefine TB& >

Ndefine (A-& ?

class dataGbuffer K

char databuf7databuflen93

int len3

int lengthGinGchars;< K return len/bitsperbyte3

/J length in bytes rounded down0used in implementation J/

public!

oid insert;dataGbuffer, dataGbufferO


17/21

or by writing a small program to generate it ourseles. e should test seeral different symbol

tables. e also want to test enough symbols for each symbol table. Cne way to help automate

testing is to write a =uffman decoder.

As illustrated in (igure +.*L, we can run a set of symbols through the encoder, and then through

the decoder, and simply make sure that the input and output are the same. #f they are not, we

hae to check both the encoder and decoder to locate the problem, but since most practical

systems will reuire both in any case, this is a minor concern.

Another way to test the code is to examine the code itself and try to identify potential problem

areas. hen we read the code,we should look for places where data operations take place to see

that they are performed properly.

e also want to look at the conditionals to identify different cases that need to be exercised.

-ome ideas of things to look out for are listed below.

" #s it possible to run past the end of the symbol tableP

" hat happens when the next symbol does not fill up the bufferP

" hat happens when the next symbol exactly fills up the bufferP

" hat happens when the next symbol oerflows the bufferP

" Do ery long encoded symbols work properlyP =ow about ery short onesP

" Does flush; < work properlyP

Testing the internals of code often reuires building scaffolding code. (or example, we may

want to test the insert method separately, which would reuire building a program that calls the

method with the proper alues. #f our programming language comes with an interpreter, building

such scaffolding is easier because we do not hae to create a complete executable, but we often

want to automate such tests een with interpreters because we will usually execute them seeral

times


18/21


19/21

the audio input into a bit stream is illustrated in (igure 8.+*.The analog input is sampled and the

resulting stream is sent to two digital filters ;such as an (# filter0band freuencies, and the other filter does the

conerse. The outputs of the filters are sent to detectors, which compute the aerage alue of the

signal oer the past n samples. hen the energy goes aboe a threshold alue, the appropriate bitis detected.

e will send data in units of I0bit bytes. The receiing modem does not know when the

transmitter has started to send a byte. (urthermore, een when the receier does detect a

transmission, the clock rates of the transmitter and receier may ary somewhat, causing them to

fall out of sync. #n both cases, we can reduce the chances for error by sending the waeforms for

a longer time.

The receiing process is illustrated in (igure 8.++. The receier will detect the start of a byte by

looking for a start bit, which is always ?. 6y measuring the length of the start bit,the receier

knows where to look for the start of the first bit. =oweer, since the receier may hae slightly

mis2udged the start of the bit, it does not immediately try to detect the bit. #nstead, it runs the

detection algorithm at the predicted middle of the bit.

The modem will not implement a hardware interface to a telephone line or software for dialing a

phone number. e will assume that we hae analog audio inputs and outputs for sending and

receiing. e will also run at a much slower bit rate than >*?? baud to simplify the

implementation. Rext, we will not implement a serial interface to a host, but rather put the

transmitter1s message in memory and sae the receier1s result in memory as well. 'ien those

understandings, let1s fill out the reuirements table.


20/21

Speci&ication

The basic classes for the modem are shown in (igure 8.+.

)."". S*stem Arc%itecture

The modem consists of one small subsystem ;the interrupt handlers for the samples< and two

ma2or subsystems ;transmitter and receier


21/21

The best way to generate waeforms that retain the proper shape oer long interals is table

loo"up. -oftware oscillators can be used to generate periodic signals, but numerical problems

limit their accuracy. (igure 8.+8 shows an analog waeform with sample points and the 5 code

for these samples.The filters and detectors of (igure 8.++ can be implemented with circular buffers. 6ut that

module must feed a state machine that recognizes the bits. The recognizer state machine must

use a timer to determine when to start and stop computing the filter output aerage based on the

starting point of the bit. #t must then determine the nature of the bit at the proper interal. #t must

also detect the start bit and measure it using the counter.

The receier sample interrupt handler is a natural candidate to double as the receier timer since

the receier1s time points are relatie to samples. The hardware architecture is relatiely simple.

#n addition to the analog/digital and digital/analog conerters, a timer is reuired. The amount of

memory reuired to implement the algorithms is relatiely small.

)."".+ Component Design and Testing

The transmitter and receier can be tested relatiely thoroughly on the host platform since the

timing0critical code only deliers data samples. The transmitter1s output is relatiely easy to

erify, particularly if the data are plotted. A test bench can be constructed to feed the receier

code sinusoidal inputs and test its bit recognition rate. #t is a good idea to test the bit detectors

first before testing the complete receier operation.

5are must be taken to ensure that the receier does not run too long and miss its deadline. -ince

the bulk of the computation is in the filters, it is relatiely simple to estimate the total

computation time early in the implementation process.

)."".) S*stem Integration and Testing

There are two ways to test the modem system! by haing the modem1s transmitter sends bits to

its receier, and or by connecting two different modems. The ultimate test is to connect two

different modems, particularly modems designed by different people to be sure that incompatible

assumption or errors were not made. 6ut single0unit testing, called loop-bac" testing in the

telecommunications industry, is simpler and a good first step.

Case Study Es

Documents

Transcript of Case Study Es