laboratory 1 manual v1.2 – 1st september 2007 developing...

Laboratory 1 Manual V1.2 – 1st September 2007

Developing a Blackfin GPIO interface using

an automated embedded testing environment

These pages are cut-and-paste from the Lab. 1 web-pages. I have not spent a lot of time reformatting them.

I have not checked that the links work correctly from this document – if there are problems in following the links

to download code segments, then go to the ENCM415 web site and follow the links there.

http://www.enel.ucalgary.ca/People/Smith/2007webs/encm415_07/07LaboratorySchedule.htm

You should have already completed the familiarization exercises:

Familiarization Exercise for the Blackfin BF533 Board Follow the video links for more details

1. Check that the Lab. station can talk to the Blackfin Evaluation Board across the HPCC-ICE

interface Check HPPCI Link To Blackfin ADSP-BF533 Evaluation Board.swf

2. Activate a VDSP Blackfin Session -- Activate a VDSP Blackfin Session.swf

3. Build a Blackfin Project and add a main( ) -- Build a Blackfin Project .swf

4. Add the Blackfin Hello World function -- Add the Blackfin Hello World function.swf 5. Add Blackfin CPP Stubs Then Coding -- Add CPP Stubs Then Coding.swf

6. Add a Blackfin Assembly language stub -- Assembly code Stub.swf

7. Complete the Blackfin assembly code example -- Completing the assembly code example.swf

http://www.enel.ucalgary.ca/People/Smith/2007webs/encm415_07/07Labs/L1TasksToComplete.htm

Laboratory 1 Tasks

Minimum requirements – For many of the tasks associated with the Laboratory, code examples are

provided to cut down the amount of typing you have to perform during the Laboratory time. You should

downloaded any code needed for Laboratory 1 into your ENCM415 directory before coming into the

Laboratory. Plan to complete Tasks 1 to 2 (preferably Tasks 1 to 3 or 4) before coming into the

Laboratory. You are unlikely to complete the laboratory in 3 hours otherwise.

1. Testing the development environment -- Check that the audio talk-through program works on your

laboratory station T1 - Test CPPTalkthrough

2. See the impact of using "debug print" statements on the operation of an embedded system T2 - Debug impact

Test last development - TLD

3. Using your standard coding process, develop and test the GPIO interface functions

void Initialize_GPIOFlagsASM(void) and unsigned short int ReadGPIOFlagsASM(void); T3 - GPIO Interface.

Links are provided to detailed help information on developing the GPIO code..3 Hints - GPIO Interface

4. Use the E-Unit testing frame work to more thoroughly test the GPIO interface functions (TLD -- Test last

development approach). Test code can be downloaded from the web. T4 -- GPIO Interface tests

Test driven development - TDD

5. Using a test first development approach (TDD), add tests for the Flash Memory interface void

InitFlashASM(void), void InitFlashPortASM(void), void WriteFlashLEDASM( int value), int

ReadFlashLEDASM(void). Test code can be downloaded from the web. T5 - Flash Memory Tests

6. Develop the code for the Flash Memory interface InitFlashASM( ), InitFlashPortASM( ),

WriteFlashLEDASM( int value), int ReadFlashLEDASM( ) using a TDD approach. Links to hints are

provided.T6 - Flash Memory Interface Hints

Functional Testing of Lab. 1 Code -- Demonstrate to T.A. or instructor

7. Echoing the switch positions to the LEDs T7 - Echo switches to LED. Developed in CPP. (80% -- A- grade in

the Laboratory to this point)

8. Laboratory design components -- Developing Morse code functionality in CPP using a TDD approach T8

Morse Code. (additional 15% with possible Laboratory bonuses)

9. Does your code really work -- Download and run this audio project which automatically calls all of your

Lab. 1 code. Will you have to "recall" your project'? T9 - Does your code really work (additional 5% )

Optional voice-activated robotic car project -- download the VARC project. This will automatically link to

your Lab. 1 code. TO COME

http://www.enel.ucalgary.ca/People/Smith/2007webs/encm415_07/07Labs/07Lab1Details/L1task1_TestTalkThr

ough.htm

Lab. 1 Task 1 -- Test CPP talk-through Code

Analog Devices provides a series of example code for their evaluation boards so that people can "quickly get something working". The

"Talk-through" example we are going to use in this laboratory is a modified version of the code that is found at

C:\Program Files\Analog Devices\VisualDSP 4.5\Blackfin\EZ-KITs\ADSP-BF533\Examples\Audio codec talkthrough\C\TDM

This talk through example shows the programmer how to set-up the audio codecs (A/D and D/A) to capture an audio signal and then

play the signal back (or talk-through) without changing it. In addition the example shows the programmer how to make use of audio

interrupt service routines.

None of this is going to be of a concern for us in this laboratory. We are going to leave all the Analog code alone, and just

assume that it works as stated.

We are going to use this code to test that the Blackfin Evaluation board works as expected.

You will not have to write any code for this task -- just down load code (C++ and asm) and link into a project.

The first thing we need to do is to check that the C++-version of the talk-through code works on our lab-station.

• If you have not already done so, download and expand the

2007LabStructure30Aug2007.7z file into your ENCM415 directory on your

home drive. That way you will have the correct common directory structure

and test driven development environment needed for Assignment 1 and

Laboratory 1.

Your directory structure should look similar to the picture on the right

• Activate the VDSP development environment and switch to directory

CPP_Talkthrough_Lab1Task1Task2 inside VDSP. Activate the

CPP_Talkthrough_Lab1Task1Task2 project in that directory .

• Build the code and download the executable to the evaluation board

• Hook up your CD or IPOD output to the CJ2 stereo input.

• Hook up your ear-phones to the CJ3 stereo output.

• Run the CPP_Talkthrough_Lab1Task1Task2.dxe executable and check that

the talk through program is working.

http://www.enel.ucalgary.ca/People/Smith/2007webs/encm415_07/07Labs/07Lab1Details/L1task2_ImpactDebu

gStatements.htm

Lab. 1 Task 2

Impact of Debug operations using standard I/O

on the performance of an embedded system

In the class, we have discussed the impact of using "printf( )" or "cout" statements as part of a code debugging process on real-time

embedded system.

The Blackfin audio talk-through program is an example of a real time system -- if the "next" audio sample is not available within 1 /

44000 s, the audio signal becomes distorted.

Remove the comment markers (//) from the if and printf( ) in the code for the main.cpp in the project

CPP_Talkthrough_Lab1Task1Task2 to include a very simple debug check via a print statement.

Recompile the code and run. The impact on sound quality of a debug operation via a print statement is very obvious. You can try

modifying the code to use "cout" operations. By changing the maximum "count" in the SpinWheels( ) code you can cause the debug

print statement to execute less often.

Basically, the conclusion I would expect you to reach from this task is – it is necessary to be able to debug embedded code in a way

that takes no use of print statements. You must find a different debugging approach that does not impact on the performance of your

code and use a different automated approach that does not require that you manually look at the test results.

In your laboratory write-up, explain the details of why using a print statement for debugging (or any other purpose) is so slow

and disruptive to a real-time embedded system. What is happening to an embedded system when you use printf( ) statements?

Get another group to sign off in your laboratory report that you have completed these two tasks.

http://www.enel.ucalgary.ca/People/Smith/2007webs/encm415_07/07Labs/07Lab1Details/L1task3_GPIO_Flags

ASM.htm

Lab 1 Task 3 -- General Purpose Input Output interface

void Initialize_GPIOFlagsASM(void);

unsigned short int ReadGPIOFlagsASM(void);

WARNING -- SMOKE CAUSING AREA

MIS-PROGRAMMING OR MIS-CONNECTION OF WIRES

HAS A REAL POSSIBILITY OF LEADING TO PERMANENT BLACKFIN PROCESSOR DAMAGE

DISCUSION In the next couple of tasks we need to be able to read the switches on the front panel of the BF533 board

• Switch SW1 is connected to GPIO programmable flag bit PF8 -- bit pattern 0x0100 when FIO_FLAG_D register is read




We need to generate the function void Initialize_GPIOFlagsASM(void) to configure the GPIO interface.

After we initialize the registers for the PF (programmable flag) interface, then information in the FIO_FLAG_D register will tell us

which button (or buttons -- 16 combinations) is being pressed (using the unsigned short int ReadGPIOFlagsASM(void) function)

Look at the details in Activating the Blackfin GPIO pins -- Lab. 1.ppt on how to set up the logic Lab and the Blackfin Cables

Laboratory Requirements NOTE: Important -- Certain laboratory requirements must be followed.

If the laboratory notes say Build Function Fred( ) and place in file X.cpp in directory XYZ, then those instructions must be

followed "absolutely".

To save time typing in the laboratory, you have been provided with files and project directories to down load. The code in these files

and project directories expects that the function will be called Fred( ) and not fred( ) and that it can be found in file X.cpp in

directory XYZ to work. I have shown you in the lecture notes that it is easy to save files into the wrong directory by accident (I know,

I do it all the time).

1. Close the talkthrough project, you will noit need that again till task 9.

2. Develop a project called Lab1 in your ENCM415/Lab1 directory

3. Use your normal coding process to write, debug and demonstrate the code for activating the Blackfin GPIO interface.

Remember that you are sharing the GPIO interface with other processor threads, so don't change settings other than for pins 8,

9, 10 and 11

4. Using the course lecture notes and information from the Blackfin Hardware manual build the routine void

Initialize_GPIOFlagsASM(void) to configure the GPIO interface. Place this "C++" compatible assembly language function in

the file InitializeGPIOFlagsASM.asm in your Lab1directory.

5. Using the course lecture notes and information from the Blackfin Hardware manual build the routine unsigned short int

ReadGPIOFlagsASM(void) to read the GPIO interface setting. Place this "C++" compatible assembly language function in the

file ReadGPIOFlagsASM.asm in your Lab1directory. When completed your testing, get the T.A. or instructor to sign off

that your code is working. Since this is early in the laboratory, you can get another laboratory group (not your closest friends)

to sign off this section, meaning, you don't have to wait for a T.A. or instructor.

Try to finish Task 3 according to the class notes using your normal code development process. If you need some help to get started --

then follow this link T3 Hints - GPIO Interface available from the web only. Before spending a lot of time debugging, I suggest you try Task 4 -- Automated TLD testing of the GPIO interface code.

Look at the details in Activating the Blackfin GPIO pins -- Lab. 1.ppt on how to set up the logic Lab and the Blackfin Cables

http://www.enel.ucalgary.ca/People/Smith/2007webs/encm415_07/07Labs/07Lab1Details/L1task4_Test+Init_G

PIO_Interface.htm

Lab 1 Task 4 -- Automated testing procedure for the code



WARNING -- SMOKE CAUSING AREA

MIS-PROGRAMMING OR MIS-CONNECTION OF WIRES

HAS A REAL POSSIBILITY OF LEADING TO PERMANENT BLACKFIN PROCESSOR DAMAGE

By using tests that examine the condition (state) of the Blackfin hardware after we have programmed it, we can try to minimize

problems. One of the problems is that damage may be done (because of incorrect code) we are doing the tests.

• Before proceeding with Task 4, YOU NEED TO ENSURE that your code you developed in Task 3 uses the correct named

functions, placed in the correct files in Lab. 1

o Develop a project called Lab1 in your ENCM415/Lab1 directory

o Using the course lecture notes and information from the Blackfin Hardware manual build the routine void

Initialize_GPIOFlagsASM(void) to configure the GPIO interface. Place this "C++" compatible assembly language

function in the file InitializeGPIOFlagsASM.asm in your Lab1directory.

o Using the course lecture notes and information from the Blackfin Hardware manual build the routine unsigned short

int ReadGPIOFlagsASM(void) to read the GPIO interface setting. Place this "C++" compatible assembly language

function in the file ReadGPIOFlagsASM.asm in your Lab1directory.

To provide the automated testing you need to download certain files to the Lab1Test directory

1. Lab1Tests.dpj

2. Lab1Testmain.cpp

3. Lab1GPIOTests.cpp

4. Lab1GPIOTestsLowLevel.cpp

Once you have downloaded the files, open? the Lab1Test project, recompile and run your code. The Lab1Tests.dpj will hunt out and

link to the Task 3 files in directory Lab. 1 automatically if the Lab 1 task 3 files have been placed in the Lab. 1 directory as expected.

The provided test simply checks that the 50-pin cable is plugged in (SAY WITH ME -- "Insert the cable the correct way (not upside

down), push hard till the 'click' is heard – now do it for the other end of the cable") and the logic lab. is witched on and no fuses have

blown

You can modify the tests you used during task3 (from Lab1main.cpp) to run in the E-UNIT testing environment.

Click on the thumb-nail picture for more details.

With the E-UNIT testing framework you can do some more detailed testing -- even at the level of "did you perform the number of

expected read and write operations within a routine”

• Useful for testing loops in C++ (did you go around the loop the correct number of times, not once too many times or once too

few).

• For interfacing problems, did you read and write to the GPIO register values the correct number of times.

Here are the steps for activating the low level set of tests. Lab1GPIOTestsLowLevel.cpp

1. Right click on Lab1GPIOTestsLowLevel.cpp to change the compile options.

2. Remove the "tick" from "exclude from build" box and select okay

3. Activate the E-Unit GUI from the E-UnitIncludes Directory.

4. Select "Always on top" from the GUI "view menu"

5. Select "Refresh test connection" from the new E-UNIT VDSP menu options

You should now be able to build the Lab1Test -- you should expect to have no compile or link errors if your code files, names and

location from Task 3 are correct.

6. You can get the E-UNIT GUI to "compile", "load" and "run" the code

automatically, saving some steps over using the VDSP interface correctly.

Notice that the tests run faster as the communication between the processor and

the PC is handled by a GUI "background communication channel (BTC)"

which is much faster than normal prints to the screen

If you get a failure message (in red), simply click on the failure message and

you will get additional information on the test you failed.

Fix your code to pass the tests.

Don't fix the tests to pass the code, unless you are VERY sure that the test

is wrong.

• Provide copies of the working code for Task 3 in your laboratory

write-up. Follow the coding conventions required for this course

Click on the thumb-nail image to see my code failing

as I did not respond to the requests to press switches.

You don't get the "click to jump to failure" capability

without having the E-UNIT GIU running. This "jump

to failure" mode is very useful when you take a "test

driven development (TDD) approach to developing

your code.

If you want to see just the test failures (and not the test successes), go into the file ActivateTests.cpp and change the line

volatile int output_mode = SCREEN_OUTPUT | BTC_CONNECTION

| SHOW_FAILURES | SHOW_EXPECTED_FAILURES

| SHOW_SUCCESSES;

to

volatile int output_mode = SCREEN_OUTPUT | BTC_CONNECTION

| SHOW_FAILURES | SHOW_EXPECTED_FAILURES

; //| SHOW_SUCCESSES;

to comment out the request to show test successes. Recompile, reload and run the tests again

NOTE: Under some circumstances you can rebuild the project and then run the code but then get the VDSP message "project is out of

date -- do you want to rebuild". Say yes to this message. However if, after you rebuild, you get the same message "project is out of

date -- do you want to rebuild" again. Just say NO. This problem has been reported to Analog Devices.

http://www.enel.ucalgary.ca/People/Smith/2007webs/encm415_07/07Labs/07Lab1Details/L1CommonErrors.htm

Common Errors experienced in the Labs.

Remember to check the cable and logic lab. settings

An issue sometimes found when debugging code in any processor development system

The first couple of times, I ran the test, the code stopped unexpectedly at a "ghost breakpoint" before completing. Ghost breakpoints

are breakpoints left over from a previous debug session

If this happens to you -- select DEBUG | RUN again, to cause the code to continue.

Sometimes there seem to be an "infinite" number of ghost breakpoints to clear, especially after you have found many errors in your

code.

In this case you need to "clean" the environment.

• (A) Close the GUI;

• (B) Exit from VDSP entirely.

• (C) Power down the evaluation board

• (D) Power up the evaluation board

• (E) Reactivate VDSP

• (F) Reactivate the GUI

Common error messages from VDSP

(especially when starting up)

Unspecified error: Normally, for me, it means

that I have activated 2 VDSP sessions rather

than 1.

Solution 1: Close down the second

accidentally opened VDSP Blackfin session.

Click on the thumb-nail see a typical screen

Notice that there is both a "Analog Devices" and a "VisualDSP" icon in Fig. 1, only

the "Analog Devices" in Fig. 2, and multiple icons later in the process

Solution 2: Sometimes you get this message

and there is only one VDSP session "present",

especially after horribly crashing the system. In

this case, there is a "hidden" VDSP session

running.

You need to close the VDSP session you have

just started, and then kill the hidden VDSP

session via the task manager. Kill the Blackfin

"IDDE.EXE" process

NOTE: Under some circumstances you can rebuild the project and then run the code but then get the VDSP message "project is out of

date -- do you want to rebuild". Say yes to this message. However if, after you rebuild, you get the same message "project is out of

date -- do you want to rebuild" again. Just say NO. This problem has been reported to Analog Devices.

http://www.enel.ucalgary.ca/People/Smith/2007webs/encm415_07/07Labs/07Lab1Details/L1task5_Tests%20for

%20flash%20memory.htm

Lab 1 Task 5 -- Automated testing procedure for the code InitFlashASM( ), InitFlashPortASM( ), WriteFlashLEDASM( int value), int ReadFlashLEDASM( ).

Using a test first development approach (TDD), we need to add tests for the Flash Memory interface void InitFlashASM(void ), void

InitFlashPortASM(void ), void WriteFlashLEDASM( int value), int ReadFlashLEDASM(void).

Add the following files to your Lab1Tests Directory and then into the Lab1Tests project

• Lab1FlashTests.cpp

• Lab1FlashTests_EUNITFunctionality.cpp // You might want to "exclude this file from the build" when you start testing. Bring

it back when all the simple tests are working.

Select "Refresh test connection" from the new E-UNIT VDSP menu options

Build the tests. The compiler will tell you the name of the functions you need to construct.

Build the ASM stubs for those functions and place into your Lab1 directory

• InitFlashASM( ) in InitFlashASM.asm

• InitFlashPortASM( ) in InitFlashPortASM.asm

• WriteFlashLEDASM( int value) in WriteFlashLEDASM.asm

• int ReadFlashLEDASM( ) in ReadFlashLEDASM.asm

Add these files to the Lab1Tests Project -- don't copy them into the Lab1Tests directory (making a second copy); you only want one

version of any code.

The screen should now look like this.

Build and run the code. The tests should run, with many failures expected as no code is present. In fact, it is a sign of a "bad" test suite

and "bad" stubs if any of the tests pass at this point in time.

In Task 6, I will provide you with some hints for writing the Flash Memory Interface Code

http://www.enel.ucalgary.ca/People/Smith/2007webs/encm415_07/07Labs/07Lab1Details/L1task6_FlashMemoryHints.htm

Lab 1 Task 6 -- Automated testing procedure for the code InitFlashASM( ), InitFlashPortASM( ), WriteFlashLEDASM( int value), int ReadFlashLEDASM( ).

Using a test first development approach (TDD) , we have added the tests for the Flash Memory interface

void InitFlashASM(void ), void InitFlashPortASM(void ), void WriteFlashLEDASM( int value), int ReadFlashLEDASM(void).

Now we need to add the code. Here are some screen dumps to provide some hints if you want them

InitFlashASM( ) hint

Link to InitFlashASM( ) code

InitFlashPortASM( ) hint -- fill in the lines marked ?????

WriteFlashLEDASM( int value)

hint

-- fill in the lines marked ?????

Remember that this routine uses

a passed in parameter

int ReadFlashLEDASM( ) hint

-- fill in the lines marked ?????

Code one function at a time, get the tests to work. Obviously some code must be written correctly (InitFlashASM( ) ) before other code

will work. However the E-UNIT low level tests will give you confidence that you have written the code in the way you planned, and in

a way that meets the Laboratory requirements.

Provide copies of the working code for Task 6 in your laboratory write-up.

Follow the coding conventions required for this course

There is one, and only one, test that is incorrect in the tests I have provided. It is incorrect because of a bad coding practice --

defining the same constant in two different files rather than defining the constant in an "include file" and placing that include

file in the other files

In your laboratory write-up, report on this incorrect test -- why was it wrong and how did you fix it.

• Provide a screen dump of the code and tests results before fixing the error.

• Provide a screen dump of the code and tests results after fixing the error.

http://www.enel.ucalgary.ca/People/Smith/2007webs/encm415_07/07Labs/07Lab1Details/L1task7_Switch_to_LED.htm

Lab 1 Task 7 -- Echo switches to the LEDs

Also look at the details in class notes

1. Close the Lab1Tests project, we have finished with that for now.

2. Open your Lab1 project

3. Edit Lab1main.cpp to use the new routines you have developed -- the following code can be cut and pasted. Do a code review

so that you understand what the code does and be able to generate similar code for quizzes and exams. There are a couple of

typos in the code which can be found by doing the code review.

// Prototypes etc



#define SWITCHES_MASK 0x0F00 // Only GPIO bits 8, 9, 10 and 11 considered

#define SW1_PRESSED 0x0100


#define SW3_PRESSED 0x0400 // NOTE 0x0400 and not 0x0300


void InitFlashASM(void);

void InitFlashPortASM(void);

void WriteFlashLEDASM( int value);

int ReadFlashLEDASM(void);

InitFlashASM( );

InitFlashPortASM( );

// The "C++" and "C" keyword volatile will be explained in class

volatile unsigned short int switch_result = 0;

while (1) {

switch_result = ReadGPIOFlagsASM & SWITCHES_MASK; // Read the switches

switch_result = switch_result >> 8;

// Why do we need to "down-shift by 8" and not by 24?

WriteFlashLEDASM(switch_result);

}

4. Once the code in 3 is working, modify the code so that you continue echoing the switches to the lights, but can quit the loop,

and exit the program properly, when you press all switches at once (about 2 lines of code need to be changed).

Completing this laboratory task is a major milestone

Get a T. A., L. A. or instructor to sign off that you have completed and demonstrated this milestone -- 80% (A- grade) of the

laboratory is complete

http://www.enel.ucalgary.ca/People/Smith/2007webs/encm415_07/07Labs/07Lab1Details/L1task8MorseCode.ht

m

Lab 1 Task 8 -- Morse code

This is your design component -- you do it the way you think best. When I wrote up the laboratories, I was thinking of something along

these lines --

Might not be the best approach

char message[ ] = "SOS - My ENCM415 Laboratory is sinking";

char *letterPointer = message

char morseCode[15];

while (*letterPointer != '\0') { // Find end of string value and then quit

GetMorseValueCPP(*letterPointer , morseCode);

// Array for coding the letter S looks like 'S', 'S', 'S', '\0'

// Array for coding the letter O looks like 'L', 'L', 'L', '\0'

// I was going to use a lookup table built from an array of arrays

char *morseCodePointer = morseCode;

while (*morseCodePointer != '\0') {

if (*morseCodePointer == 'L') { // Long morse code flash

WriteFlashLEDASM(0x3F);

WaitForLongTimeCPP( );

WriteFlashLEDASM(0x0); // Turn light off for a reasonable time

WaitForReasonableTime(CPP );

}

else {

WriteFlashLEDASM(0x7); // SHort morse code flash

WaitForShortTimeCPP( );

WriteFlashLEDASM(0x0); // Turn light off for a reasonable time

WaitForReasonableTimeCPP( );

}

morseCodePointer++;

}

letterPointer ++; Next letter

}

This is a major milestone -- get a T. A., L. A. or instructor to sign off that you have completed and demonstrated this milestone

-- 15% of remaining 20% (totally A+ grade) of the laboratory is complete.

Provide a copy of your code for this task in your laboratory report.

BONUS 20% on the Laboratory marks -- use a TDD approach for developing the CPP functions associated with this task.

Demonstrate the tests.

http://www.enel.ucalgary.ca/People/Smith/2007webs/encm415_07/07Labs/07Lab1Details/L1task9Does%20you

r%20code%20really%20work.htm

Lab. 1 Task 9 -- Does your code really work

This is a 5 minute job. Yes, we have done all the tests, but the real test is "does the code work when you add it to existing code” --

integration testing

Go to the directory TalkThroughCode - Lab1Tasks1and2 used in Task 1 T1 - Test CPPTalkthrough. Check the code "still" works --

meaning you can hear the sound.

Close the project and open the DoesYourCodeReallyWork.dpj project in the same TalkThroughCode - Lab1Tasks1and2

directory.

The difference between the two projects is that in TalkThroughCode - Lab1Tasks1and2.dpj the main.cpp file looks like this

while (1) ;

and in DoesYourCodeReallyWork.dpj the while-loop is replaced with the code from T7 - Echo switches to LED



#define SWITCHES_MASK 0x0F00 // Only GPIO bits 8, 9, 10 and 11 considered





void InitFlashASM(void);

void InitFlashPortASM(void);

void WriteFlashLEDASM( int value);

int ReadFlashLEDASM(void);

InitFlashASM( );


volatile unsigned short int switch_result = 0;

while (1) {

switch_result = ReadGPIOFlagsASM & SWITCHES_MASK; // Read the switches

switch_result = switch_result >> 8; // Why do we need to "down-shift by 8" and not by 24?

WriteFlashLEDASM(switch_result);

}

The compiler, by using the details provided by the project,, will pick up all the necessary files from Lab. 1 directory. Rebuild and run

the code.

IF YOU CAN RUN THE CODE without making any changes to your Lab. 1 code, and hear the sound while pressing the switches and

make the lights operate at the same time, I am impressed.

If you can't hear the sound, then try commenting out the line InitFlashASM( );, and if that does not work comment out the line


Often the problem is that the sound interface and the LED interface are both operating using the Flash memory interface screwing up

each other's settings. Alternatively, a common problem is that when you merge to setes of code -- you forgot one piece of the code

Write a short paragraph in your laboratory report explaining your findings and how you fixed your code to work 5%. (Note, the T.A.'s

know what the error is, 1 line of code, so don't fake it :-)

laboratory 1 manual v1.2 – 1st september 2007 developing...

Documents