%Lab 2 Learning the Development Environment The Next Step Lab Objectives:

This lab is the first phase in the formal development life cycle of a portable data measurement and collection system. The focus of the current phase is on the high-level design and development of the embedded software flow of control within the system as well as on the specification of the driver interfaces for managing the basic system operations, status display, and alarm and warning annunciation functions. The initial deliverables include full specification and design documentation for the portions of the system under current development, the high-level system architecture, the overall flow of control through the system, the ability to perform a subset of the necessary control functions, and portions of the display and annunciation components. Subsequent phases will continue and extend the driver development and incorporate additional capabilities into both the data collection, processing, and management component. The final system must be capable interfacing to a variety of environmental sensors, collecting data from those sensors, performing some local processing of the collected data, displaying the information locally, and also transmitting to a remote station. In addition, low power consumption will be an important aspect of the final product. In developing such a system, we will, 1. uild your bac!ground on pointers, passing of pointers to subroutines, and manipulating them in your subroutines, ". Introduce formal specifications, #. Introduce and wor! with formal design methodologies such as $%& - $se 'ases, (unctional )ecomposition, Sequence )iagrams, State 'harts, and )ata and 'ontrol (low )iagrams, *. (ormulate, design, and verify the top-level flow of control algorithm, +. Introduce simple tas!s and a tas! queue, ,. &earn to stub out or model necessary module functionality prior to full design, -. Share data between tas!s, .. $se software delay/timing functions, 0. $se basic output operations.
Prerequisites:

- 1 of 1. -

(amiliarity with ' programming, the Texas Instruments Stellaris 12I-&%#S.0," implementation of the 34% 'ortex-%# v-% microcomputer, and the I34 Systems 1mbedded 5or!bench integrated ' / 3ssembler development environment.
Background Information:

4elevant chapters from the text6 'hapters +, ,, -, 0, and 11.

Cautions and Warnings:

7ever try to run your system with the power turned off. $nder such circumstances, the results are generally less than satisfying. Since current is dq/dt, if you are running low on current, raise your Stellaris board to about the same level as the $S connection on the 8' and use short leads. This has the effect of reducing the dt in the denominator and giving you more current. 9ou could also hold it out the window hoping that the :&1) is really a solar panel. If the I34 I)1 is downloading your binaries too slowly, lower your Stellaris board so that it is substantially below the $S connection on the 8' and put the I34 I)1 window at the top of the 8' screen. This enables any downloads to get a running start before coming into your board. It will now program much faster. e careful not to get the download process going too fast, or the code will overshoot the Stellaris board and land in a pile of bits on the floor. This can be partially mitigated by downloading over a bit buc!et. ill &ynes has these available in stores;.<ust as! him for one. Throwing your completed but malfunctioning design on the floor, stomping on it, and screaming =why don>t you wor! you stupid fool> is typically not the most effective debugging technique although it is perhaps one of the more satisfying. The debugging commands, step into or step over, is referring to your code, not the system you <ust smashed on the floor. (urther, breakpoint is referring to a point set in your code to stop the high-level flow through your program to allow more detailed debugging;it>s not referencing how many bits you can cram into the Stellaris processor>s memory before you destroy it. 5hen you are debugging your code, writing it, throwing it away, and rewriting again several do?en times does little to fix what is most li!ely a design error. Such an approach is not highly recommended, but can !eep you entertained for hours;.particularly if you can convince your partner to do it.

- " of 1. -

Sometimes - but only in the most dire of situations @ sacrificing small animals to the code elf living in your Stellaris board does occasionally wor!. Aowever, these critters are not included in your lab !it and must be purchased separately from an outside vendor. 3lso, be aware that most of the time, code elves are not affected by such sacrifices. They simply laugh in your face;bwa ha ha; 3lternately, blaming your lab partner can wor! for a short time;until everyone finds out that you are really to blame. 3lways !eep only a single copy of your source code. This ensures that you will always have a maximum amount of dis! space available for games, email, and some interesting pictures. If a code eating gremlin or elf happens to destroy your only copy, not to worry, you can always retype and debug it again. 3lways ma!e certain that the cables connecting the 8' to the Stellaris board are not twisted or have no !nots. If they are twisted or tangled, the compiled instructions might get reversed as they are downloaded into the target and your program will run bac!wards. 3lways practice safe software engineering;don>t leave unused bits laying around the lab.
Laboratory:

5e are using this lab pro<ect as an introduction into the formal development life cycle of an embedded system @ or any system, for that matter. This process generally involves five steps, Identify the requirements. (rom the requirements, put together a specification quantifying those requirements. )o a functional design @ identify the ma<or functional bloc!s that will comprise the system. (ormulate an architecture then map the functional bloc!s onto that architecture. )esign, build, and test a prototype of the system.

3s the development proceeds, we may Band often doC iterate through these steps a number of times as we refine the design and wor! through bugs and design or specification issues. In this lab, we are providing significantly simplified versions of the requirements and the specification for our systemD these can often be fairly substantial documents in practice. There are several parts that you will have to add as a portion of your contribution to the specification and development effort. In this lab, we will utili?e the rapid prototyping approach. Such an approach focuses on the first cut of the functional design and the high-level architecture of the system. 5e will then verify the operation of that architecture by modeling Bsimulating or stubbing outC the behaviour of most of the comprising pieces of functionality. 3s the pro<ect evolves, we will replace the modeled @ stubbed out @ behaviour with the actual hardware and software components that affect that behaviour.

- # of 1. -

3s we begin the development, we will;. $tili?e $%& diagrams to model some of the static and dynamic aspects of your system. Identify the ma<or functional bloc!s. 3rchitect the system as a collection of tas!s. Introduce the concept of Tas! 'ontrol loc!s @ T' . )evelop a simple time based operating system !ernel with scheduler and dispatcher that will schedule and dispatch those tas!s. Stub out or model the desired behaviour of each of the tas!s. &earn and wor! with the Stellaris E8I: subsystem for system I/:, Implement and test the system. Share data using pointers and data structs.

1mpirically determine execution time of each such tas!. (Theo kinh nghim xc nh thi gian lm cc nhim v !" 5e will wor! with the I34 I)1 development tool to edit and build the software then download and debug the executable code in the target environment. This lab, lab report, and program are to be done as a team @ play nice, share the equipment, !eep any viruses Bsoftware or otherwiseC to yourself, and no fighting.
Software Project !eve"o#ing Basic $asks

9ou have <ust been given a once in a lifetime opportunity to participate in the formation an exciting new start up. ecause of the growing concerns over rising temperatures and the associated glacial melt, you and several colleagues have decided to set your own direction and to start a company to develop a multipurpose environmental monitoring and reporting system. ased upon initial discussions with your colleagues, you decide to call the company MonitoringStuffRUs-UnLtd, and have put together a set of preliminary requirements for a small, portable, low power, product based on I8od and smart phone ideas and technologies. The product, CheckItOut, will have the ability to perform many of the basic environmental measurements that people studying and researching factors potentially affecting climate change need to ma!e. 9our team decides that the system must be portable, lightweight, low power, inexpensive, and Internet enabled. (urther, that the prototype unit must have the ability to ma!e such basic measurements as temperature, flow rate, concentration of various pollutants or mixtures, etc., perform simple computations such as trending, and log historical data. The initial deliverables for the system will include the display and alarm portion of the monitoring system as well demonstrated ability to handle temperature, flow rate, and perform carbon and salinity measurements. :ther measurements and capabilities will follow in

- * of 1. -

subsequent phases. B hF thGng hiHn thI ra mJn hKnh vJ cL chuMng bNo OPng OH chQng minh ORSc !hT nUng Oo nhiFt OP,dVng chTy,Oo cacbon vJ OP mWnC 3ll of the sensors that will provide input to the system and any of the peripheral devices with which the system will be able to interact will not be available at present, so, we will model those signals to test the system architecture, flow of control, infrastructure, and internal data sharing#($c b% c&m bi'n v cc thi't b ngo(i vi kh)ng c! s*n hin nay n+n ch,ng ta ph&i m) h-nh h!a cc t.n hiu ! / test ki'n tr,c h th0ng1 lu2ng i3u khi/n1c4u tr,c v chia s5 d6 liu n%i b%" The requirements for the first phase of the pro<ect development life cycle are specified below. System Requirements Specification
1. !eneral Description

3 state of the art environmental monitoring and analysis system is to be designed and developed. The following specification elaborates the requirements for the display and alarm portion of the system. The display and alarm management subsystem must accept inputs from a number of sensors that are used to collect data from various points in a locali7ed geographic area then signal a 8arning if the data falls outside of pre9specified bounds# The area may be either on land or in an ocean or a river# :etailed analysis of the data 8ill be performed by other parts of the system to be added at a subse;uent phase# The outputs of the sensors are measuring a variety of natural phenomenon the values of which comprise a number of different data types such as integers, strings or high precision numbers. The system must be designed to accommodate each of these different types.
". Display an# $larm %anagement Su&system

The display and measurement component of the system in the first prototype must trac! and support the measurement and display of the following signals6
%easurements

Temperature (low 4ate 'oncentration of several different pollutants or other chemical elements The status, alarm, and warning management portion of the system must monitor and annunciate the following signals6
Status

attery state
$larms

Temperature, flow rate or pollutant concentration too high

'arning

Temperature, flow rate, or pollutant concentration out of range

- + of 1. -

)isplayed messages comprise three ma<or categories6 annunciation, status, and warning / alarm. Such information is to be presented on an :&1) display and on a series of lights on the front panel. Sensor signals are to be continuously monitored against predetermined limits. If such limits are exceeded, a visible and aural indication is to be given and shall continue until ac!nowledged. 3c!nowledgement shall terminate the aural indication but the visible indication shall continue until the aberrant value has returned to its proper range. If the signal value remains out of range for a specified time, the aural annunciation shall recommence.
".1 (se )ases

The following use cases express the external view of the system Bsee 'hapter + in the textC, BTo be added @ by engineering ; this would be youC *D+ng (%L v, -.p /ng0

Software !esign S#ecification

1. !eneral Description

3 prototype for a state of the art environmental monitoring and analysis system is to be designed and developed. The high-level architecture is to be modular, comprising a set of tas!s that are executed, in turn, forever. The first phase will focus on the display and alarm management subsystem which must accept inputs from a number of sensors that are used to collect data from various points in a locali?ed geographic area which may be either on land or in the ocean or a river then signal a warning / alarm if the data falls outside of pre-specified bounds. )etailed analysis of the data will be performed by other parts of the system to be incorporated later. The outputs of the sensors are measuring a variety of natural phenomenon the values of which comprise a number of different data types such as integers, strings or high precision numbers. The system must be designed to accommodate each of these different types. The prototype is to be implemented using the 34% 'ortex-%# v-% microcomputer development board. The prototype software must schedule task execution1 model measurements and data processing1 display information on an <=>: display1 and manage peripheral 8arning ? annunciation =>:s#
In addition, the execution time of each task must be empirically determined. (THi gian thc hin m i task do thc nghim x!c "#nh$

The following elaborates the specifications for the display and alarm portion of the system.
". 1unctional Decomposition

The system is to be decomposed into the ma<or functional bloc!s6 Schedule, Measure, Co pute, !isplay, "nnunciate, and Status as given in the following functional decomposition diagram Bsee 'hapter 0 in the textC.

- , of 1. -

$h@c nAn cBa system CDc chia ra thnh cc kh0i ch@c nAngE FGchedule(lch" Fmeasure(o" F$ompute F:isplay F Annunciate(loan bo) +Status BTo be supplied by engineeringC

".1 System Soft2are $rchitecture

The environmental monitoring and collection system is to be architected as a set of tas!s based upon the functional decomposition given above. These tas!s are derived, based upon the functional decomposition, and specified in the following tas!/class diagrams Bsee 'hapter + in the textC. $h@c nAng gim st v thu thHp d6 liu CIc chia thnh cc nhim v nhC J tr+n BTo be supplied by engineeringC

The set of tasks 8ill execute continuously follo8ing po8er <K. They 8ill all have e;ual priority($c task c! Cu ti+n nhC nhau" and will not be pre-emptable. Information within the system will be exchanged utili?ing a number of shared variables.
%&'&' $asks and $ask Contro" B"ocks

The design and implementation of the system software will comprise a number of tas!s. 1ach tas! will be expressed as a T' BTas! 'ontrol loc!C structure. The T$L is implemented as a $ structM there shall be a separate struct for each task# >ach T$L 8ill have t8o membersE i. The first member is a pointer to a function taking an argument of type voidN 8ith a return type of void# ii. The second member is a voidN pointer 8hich is used to reference the shared data for the task# Such a structure allows various tas!s to be handled using function pointers. The following gives a ' declaration for such a T' .
struct %yStruct 3 voi# *4myTas50*voi#406 77 Tr8 t9i h:m v9i tham s; 5i<u voi#4 v9i gi. tr= tr> v? voi#

- - of 1. -

voi#4 tas5Data@tr6 F6

77)on tr8 #+ng -< tham chi?u #A liBu -CDc chia sE

type#ef struct %yStruct T)G6

The following function prototypes are given for the tas!s defined for the application (cc hm Ca ra cho nhim v ;uy nh cho cc @ng d ng1 O struct @ng vPi O @ng d ng c th/" BTo be supplied by engineeringC

%&'&% Intertask !ata ()c*ange and Contro" !ata

3ll of the system>s shared variables will have global scope(T4t c& cc bi'n CIc shared cBa h th0ng sQ c! ph(m vi ton c c"D the remainder will have local scope(phRn cSn l(i sQ c! ph(m vi c c b%". ased upon the 4equirements Specification, the following variables are defined to hold the status and alarm information and command and control information. The initial state of each of the variables is specified as follows6
+easurements

Type unsigned int

!is#"ay

temperature4aw flow4ate4aw carbon&evel4aw salinity&evel4aw

initial value "X initial value #X initial value "+X initial value #X

Type unsigned charY

Status

temp'orrected flow4ate'orrected carbon&evel'orrected salinity&evel'orrected

initial value 7$&& initial value 7$&& initial value 7$&& initial value 7$&&

Type unsigned short

,"arms

batteryGtate

initial value TUU

- . of 1. -

Type unsigned char

'arning

temp<ut<fVange flrt<ut<fVange carbon=evel<utofVange salinity=evel<utofVange

initial value U initial value U initial value U initial value U

Type ool1 tempAigh flrtAigh carbon&evelAigh salinity&evelAigh initial value (3&S1 initial value (3&S1 initial value (3&S1 initial value (3&S1

1. 3lthough an explicit oolean type was added to the 37SI standard in %arch "XXX, the compiler weZre using doesnZt recogni?e it as an intrinsic or native type. BSee http6//en.wi!ipedia.org/wi!i/'[programming[language\'00 if interestedC (:Wng ki/u d6 liu tX nh nghYa / lm hm 8arning" 5e can emulate the oolean type as follows6
enum myBool { FALSE = 0, TRUE = 1 }; typedef enum _myBool Bool;

8ut the code snippet in an include file and include it as necessary.

".1.H Data Structures

The T' member, tas!)ata8tr, will reference a struct containing references to all data utili?ed by tas!.(Task:ZTaptr sQ tham chi3u 'n struct c! ch@a t4t c& data CIc s[ d ng bJi task" 1ach data struct will contain pointers to data required/modified by the target tas! as given in the following representative example1(\]i data struct sQ ch@a pointers / d6 liu cRn thi't?modify bJi task"

where ]data^ would be an integer required by myTas!.

- 0 of 1. -

The data that will be held in the structs associated with each tas! are given as follows. %easureData Aolds pointers to the variables6 temperature4aw flow4ate4aw carbon&evel4aw salinity&evel4aw )omputeData Aolds pointers to the variables6 temperature4aw flow4ate4aw carbon&evel4aw salinity&evel4aw temp'orrected flow4ate'orrected carbon&evel'orrected salinity&evel'orrected DisplayData Aolds pointers to the variables6 temp'orrected flow4ate'orrected carbon&evel'orrected salinity&evel'orrected batteryState 'arning$larmData Aolds pointers to the variables6 temperature4aw flow4ate4aw carbon&evel4aw salinity&evel4aw batteryState Status Aolds pointers to the variables6 batteryState The following data structs are defined for the application, (^i't cc c4u tr,c d6 liu xc nh cho cc @ng d ng" BTo be supplied by engineeringC - 1X of 1. -

%&'&- $ask .ueue

The tas!s comprising the application will be held in a tas! queue. Tas!s will be selected, in sequence, from the head of the queue in round robyn fashion and executed. Tas!s will not be preemptableD each tas! will run to completion. (Task CIc t_ ch@c thnh ngAn x'p1cc task sQ thXc hin t` tr+n xu0ng dCPi1n'u task kh)ng c! nhim v sQ CIc ba ;ua" If a tas! has nothing to do, it will exit immediately. The tas! queue is implemented as an array of - elements that are pointers to variables of type T' . Six of the T' elements in the queue correspond to tas!s, Schedule, Measure, Co pute, !isplay, #arning-"lar , and Status identified and elaborated in Section ".". The seventh element provides space for future capabilities. The tas! function pointer in each T' should be initiali?ed to point to the proper tas!. (or example, T' element ?ero should have its function pointer initiali?ed to point to the tas!X function. The data pointer of each T' should be initiali?ed to point to the proper data structure used by that tas!. (or example, if Measure!ata is the data structure for the tas! Measure, then the data pointer of the T' should point to Measure!ata.
"." Tas5 Definitions an# Gehaviour

The dynamic behaviour of each tas! is given, as appropriate, in the following activity diagrams Bsee 'hapter + in the textC. BTo be supplied @ by engineeringC

Schedule

The schedule tas! manages the execution order and period of the tas!s in the system. Aowever, the tas! is not in the tas! queue. The round robyn task schedule comprises a mabor cycle and a series of minor cycles# The period of the mabor cycle is c seconds# The duration of the minor cycle is specified by the designer#(Thi't k' period lPn l cs1 cSn chu kd nha l tWy nh thi't k'" (ollowing each cycle ma<or cycle through the tas! queue, the scheduler will cause the suspension of all tas! activity, except for the operation of the warning and error annunciation, for five seconds. In between ma<or cycles, there shall be a number of minor cycles to support functionality that must execute on a shorter period. The following bloc! diagram illustrates the design. The Elobal 'ounter is incremented every time the &ocal )elay expires. If the &ocal )elay is 1XX ms, for example, then 1X counts on the Elobal 'ounter represent 1 sec.

- 11 of 1. -

3ll tas!s have access to the System Time ase and, thus, can utili?e it as a reference upon which to base their timing.

7ote, all timing in the system must be derived from the System Time ase. The individual tas!s cannot implement their own delay functions. (urther, the system cannot bloc! for five seconds. The following sequence diagram gives the flow of control algorithm for the system BTo be supplied @ by engineeringC

efgh ij$
Measure

The %easure function shall accept a pointer of type voidY with a return type of void. The pointer in the tas! argument will be re-cast as a pointer to the Measure tas!>s data structure type before it can be dereferenced. The signals expressing the temperature, flow4ate, and pollutant levels must be simulated because the sensors are unavailable.(\@c % ) nhikm ph&i CIc m) phang v- kh)ng c! c&m bi'n c! s*n" To simulate the various parameters, the following operations are to be performed on each of the raw data variables referenced in %easureData& /+0 #*1ng c2c t*am s3 b4ng vi5c t*6c
*i5n c2c 7i8u sau9
tem#erature:aw

Increment the variable by " every even numbered time the function is called and decrement by 1 every odd numbered time the function is called until the value of the variable exceeds #+. The number X is considered to be even. Thereafter, reverse the process until the value of the variable falls below 1+. Then, once again reverse the process#(TAng hm n'u hm ch*n c gli1gi&m O n'u hm lQ CIc gli1cho 'n khi vCIt ;u mcn#"
f"ow:ate:aw

- 1" of 1. -

Increment the variable by # every even numbered time the function is called and decremented by 1 every odd numbered time the function is called until the value of the variable exceeds 1XX. Thereafter, reverse the process until the value of the variable falls below +. Then, once again reverse the process The number X is considered to be even.
carbonLeve":aw

)ecrement the variable by + every even numbered time the function is called and incremented by " every odd numbered time the function is called until the value of the variable drops below *X. Thereafter, reverse the process until the value of the variable rises above *XX. Then, once again reverse the process The number X is considered to be even.

- 1# of 1. -

sa"inityLeve":aw

)ecrement the variable by " every even numbered time the function is called and incremented by 1 every odd numbered time the function is called until the value of the variable drops below "X. Thereafter, reverse the process until the value of the variable rises above *+. Then, once again reverse the process The number X is considered to be even.
Compute

The Co pute function shall accept a pointer of type voidY with a return type of void The pointer in the tas! argument will be re-cast as a pointer to the Co pute tas!>s data structure type before it can be dereferenced. 5hen available, the Co pute tas! will ta!e the data acquired by the Measure tas! and perform any necessary transformations or corrections. The following relationships are defined between the raw data and the converted values. B$huy/n _i gi6a d6 liu th) v d6 liu bi'n _i" 1. Temperature in 'elsius6 temp'orrected _ + ` X..temp4aw ". (low 4ate in lps6 flow4ate'orrected _ 0 `".Xflow4ate4aw #. 'arbon&evel in ppm6 carbon&evel'orrected _ - ` 1." carbon&evel4aw *. Salinity&evel in ppt6 salinity&evel'orrected_ , ` X.- salinity&evel4aw

OLEDdisplay The oled!isplay function shall accept a pointer of type voidY with a return type of void. In the implementation of the function this pointer will be re-cast as a pointer to oled!isplay tas!>s data structure type before it can be dereferenced. The oled!isplay tas! is charged with the responsibility of retrieving the results of the Co pute tas!, formatting / converting the data so that it may be displayed on the instrument front panel display, and finally presenting the information. The oled!isplay tas! is also charged with the responsibility of annunciating the state of the system battery. The 3S'II encoded information shall be displayed on the :&1) display. Temperature1 flo8 rate1 battery status1 and carbon and salinity levels shall be presented as illustrated in the follo8ing front panel diagram1 (To be supplied o by engineering"

- 1* of 1. -

Warning- Alarm

The #arning-"lar function shall accept a pointer of type voidY with a return type of void. The pointer in the tas! argument will be re-cast as a pointer to the #arning-"lar tas!>s data structure type before it can be dereferenced. The normal range for the measurements is specified as follows6 1. Temperature6 "X ( to #X ( ". (low 4ate6 1"X liters per second #. 'arbon&evel6 #.X ppm *. Salinity&evel6 #X ppt attery6 Ereater than "Xa charge remaining

The normal state shall exist under the following conditions6 1. If all measurements are within their specified range, the E4117 &1) on the front panel shall be illuminated and solid#(K'u cc phpp o trong vWng chq nh th- =>: xanh sng va kh)ng nh4p nhy" ". If the state of the battery is within specified limits. (K'u tr(ng thi pin trong giPi h(n ;uy nh"

Z 8arning shall be issued under the following conditions6

1. hf the temperature measurement is out of range, the E4117 &1) on the front panel shall be illuminated and flashing with a one second period.BKh4p nhy vPi chu kd Os" ". hf the flo8 rate measurement are out of range, the E4117 &1) on the front panel shall be illuminated and flashing with a " second period.Bchu !b " gicyC #. hf either the carbon or salinity level is out of range, the 91&&:5 &1) on the front panel shall be illuminated (K'u cacbon horc % mrn ra khai ph(m vi th- isn vng sQ sng"

Zn alarm shall be issued under the following conditions

1. hf either pollutant level measurement is more than TU percent above the specified limit1 the V>: =>: on the front panel shall be illuminated and solid# The aural alarm shall sound with a series of one second tones. (K'u O cacbon horc salinity lPn hDn TUt th- =>: a sng _n nh" ". If "ckno$ledge !ey on the front panel is depressed, the aural alarm shall cease and the 41) &1) on the front panel shall flash with a one second period until the levels return to within 0Xa of normal. The state of the battery display shall flash with a one second period when the state of the battery drops below "Xa remaining.

- 1+ of 1. -

Status

The Status function shall accept a pointer of type voidY with a return type of void. The pointer in the tas! argument will be re-cast as a pointer to the Status tas!>s data structure type before it can be dereferenced. The battery state shall be decremented by 1 each time the Status tas! is entered.
".I @erformance

The execution time of each tas! is to be determined empirically. B9ou need to accurately measure it and document your results.C
".J !eneral

:nce each cycle through the tas! queue, one of the E8I: lines must be toggled. 3ll the structures and variables are declared as globals although they must be accessed as locals. %ote& #e declare the variables as globals to per it their access at run ti e' The flow of control for the system will be implemented using a construct of the form
2hile*10 3 myStuff6 F

The program should wal! through the queue you defined above and call each of the functions in turn. e sure to implement your queue so that when it gets to the last element, it wraps bac! around to the head of the queue. In addition, you will add a timing delay to your loop so that you can associate real time with your annunciation counters. (or example, if the loop were to delay +ms after each tas! was executed, you would !now that it ta!es "+ms for all tas!s to be executed once. 5e can use this fact to create tas! counters that implement the proper flashing rate for each of the annunciation indicators. (or example, imagine a tas! that counted to +X and then started over. If each count lasted "Xms, Bdue to the previous exampleC then the tas! would wait 1 second B+X Y "XmsC between events. To accomplish this, we create the function6 ]delay[msBint time[in[msC^. Thereafter, simply call this function with the delay in milliseconds as its argument. 4emember &ab 1.C)elay cho mdi len thfc hiFn tas!
:equired !esign ,##roac*

This pro<ect involves designing, developing, and integrating a number of software components. :n any such pro<ect, the approach one ta!es can greatly affect the ease at which the pro<ect comes together and the quality of the final product. To this end, 8e strongly encourage you to follo8 these guidelines(TfXc hin theo cc hCPng dun" 1. )evelop all of your $%& diagrams first. This will give you both the static and dynamic structure of the system.

- 1, of 1. -

".

#.

*. +.

,.

loc! out the functionality of each module. This analysis should be based upon your use cases. This will give you a chance thin! through how you want each module to wor! and what you want it to do. )o a preliminary design of the tas!s and associated data structures. This will give you a chance to loo! at the big picture and to thin! about how you want your design to wor! before writing any code. This analysis should be based upon your $%& class/tas! diagrams. 5rite the pseudo code for the system and for each of the constituent modules. )evelop the high-level flow of control in your system. This analysis should be based upon your activity and sequence diagrams. Then code the top-level structure of your system with the bodies of each module stubbed out. This will enable you to verify the flow of control within your system wor!s and that you are able to invo!e each of your procedures and have them return the expected results in the expected place. 5hen you are ready to create the pro<ect in the I34 I)1. It is strongly recommended that you follow these steps6 a. uild your pro<ect. b. $nderstand, and correct if necessary, any compiler warnings. c. 'orrect any compile errors and warnings. d. Test your code. e. 4epeat steps a-d as necessary. f. 5rite your report g. )emo your pro<ect. h. Eo have a beer.

CautionE hnterchanging step h 8ith any other step can significantly affect the successful completion of your design ? probect#

Lab :e#ort

9ou are welcomed and encouraged to use any of the example code on the system either directly or as a guide. (or any such code you use, you must cite the source nyou 8ill be given a failing mark on the lab if you do not cite your sources in your listing 9 this is not something to be hand 8ritten in after the fact1 it must be included in your source coden This is an easy step that you should get in the habit of doing. Do not orget to use proper coding style! including proper comments" #lease see the coding standard on the class $eb page under documentation"

- 1- of 1. -

8lease include in your lab report an estimate of the number of hours you spent wor!ing on each of the following6 )esign 'oding Test / )ebug )ocumentation 8lease include the items listed below in your pro<ect report6 1. Aard copy of your pseudo code ". Aard copy of your source code. #. 1mpirically measured individual tas! execution time. *. Include a high-level bloc! diagram with your report. +. e sure to include all of the items identified as =to be provided by engineering.> ,. If you were not able to get your design to wor!, include a contingency section describing the problem you are having, an explanation of possible causes, a discussion of what you did to try to solve the problem, and why such attempts failed. -. The final report must be signed by team members attesting to the fact that the wor! contained therein is their own and each must identify which portionBsC of the pro<ect she or he wor!ed on. .. If a stealth submersible sin!s, how do they find itg 0. )oes a helium filled balloon fall or rise south of the equatorg 1X. If you fly faster than the speed of sound, do you have to slow down every now and then to let the sound catch upg 11. If you fly really really fast around the world, can you catch up to the sound before it catches up to you and answer a question before you hear itg 1". If you don>t answer a cell phone call, where does it gog Is it <ust sitting there waiting for youg
%&T'( If any of the abo)e re*uirements is not clear, or you ha)e any concerns or *uestions about you+re re*uired to do, please do not hesitate to ask us.

- 1. of 1. -

,##endi) ,: L(! Configuration

The configuration for the &1)s and the connector pins for the various devices on the daughter board are given below.

TGLM1

TGLM"

1 " H L P I J Q

!reen LED Nello2 LED

K"

LED1

LED"

TGLMH R1H HH LEDH KL

Terminal Gloc5 L

Re# LED Onput to Spea5er @ulse Kutput from %otor @'% %otor Onput !roun# RP SD)

R11

KH HH

LED )ircuit

- 10 of 1. -

R1"

HH