Laboratory 1 Manual V1.2 1 st September 2007 Developing a Blackfin GPIO interface using an automated embedded testing environment

Transcription

1 Laboratory 1 Manual V1.2 1 st 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. 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

2 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

3 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.

4 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 / 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.

5 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 Switch SW2 is connected to GPIO programmable flag bit PF9 -- bit pattern 0x0200 when FIO_FLAG_D register is read Switch SW3 is connected to GPIO programmable flag bit PF10 -- bit pattern 0x0400 when FIO_FLAG_D register is read Switch SW4 is connected to GPIO programmable flag bit PF11 -- bit pattern 0x0800 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 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 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 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

6 PIO_Interface.htm Lab 1 Task 4 -- Automated testing procedure for the code 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 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

7 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.

8 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.

9 Remember to check the cable and logic lab. settings Common Errors experienced in the Labs. 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 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. 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 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.

10 %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

11 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?????

12 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.

13 Also look at the details in class notes Lab 1 Task 7 -- Echo switches to the LEDs 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 void Initialize_GPIOFlagsASM(void); unsigned short int ReadGPIOFlagsASM(void); #define SWITCHES_MASK 0x0F00 // Only GPIO bits 8, 9, 10 and 11 considered #define SW1_PRESSED 0x0100 #define SW2_PRESSED 0x0200 #define SW3_PRESSED 0x0400 // NOTE 0x0400 and not 0x0300 #define SW4_PRESSED 0x0800 // NOTE 0x0800 and not 0x0400 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

14 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.

15 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 void Initialize_GPIOFlagsASM(void); unsigned short int ReadGPIOFlagsASM(void); #define SWITCHES_MASK 0x0F00 // Only GPIO bits 8, 9, 10 and 11 considered #define SW1_PRESSED 0x0100 #define SW2_PRESSED 0x0200 #define SW3_PRESSED 0x0400 // NOTE 0x0400 and not 0x0300 #define SW4_PRESSED 0x0800 // NOTE 0x0800 and not 0x0400 void InitFlashASM(void); void InitFlashPortASM(void); void WriteFlashLEDASM( int value); int ReadFlashLEDASM(void); InitFlashASM( ); InitFlashPortASM( ); 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 InitFlashPortASM( ); 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

16 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 :-)