Mechatronics Laboratory Assignment #1
Programming a Digital Signal Processor and the TI OMAPL138 DSP/ARM
Recommended Due Date: By your lab time the week of January 29th
Possible Points: If checked off before your lab time the week of Feb.5th … 10points
If checked off after your lab time the week of Feb. 5th and before your lab time the week of Feb. 12th … 7 points
If work not finished before your lab time the week of Feb. 12th … 0 points
Goals for this Lab Assignment:
- Learn about the rules and responsibilities of access to the lab room and its PCs
- Discuss the use of the PCs, location of your data, etc.
- Begin the semester with a quick introduction to the DSP controller and its development software called Code Composer Studio. Specifically:
- Present a quick introduction to “Spr2018OMAPL138ProjCreator”
- Manually step through the process of creating a CCS Project in order to see what Spr2018OMAPL138ProjCreator is doing for you.
- Introduce the “DSP/BIOS” kernel and its Configuration Manager.
- Learn how to manage compiler errors and to debug your source code with Breakpoints and the Expressions Window.
DSP/BIOS Objects Used:
PRD object
Daughter Card Library Functions Used:
MACROS SETLED1-5, CLRLED1-5, GETSWITCH1-2
Matlab Functions Used:
None
Prelab: You may wish to install the demonstration version of Code Composer Studio v7 (CCS) provided by TI. There are a few different free licenses for CCS. The one you will be most interested in is for your HW and allows you to develop programs for your MSP430 chip. There is also a 90-day trial license that allows you to use all the features of CCS. You can download CCS v7at . By installing CCS v7 you will have access to the help files referenced in lab and homework assignments and be able to program your microcontroller on your home PC.
Laboratory Exercise 1Read the handout on rules of the lab.
Laboratory Exercise 2Disk space and file management.
Recommended Drive Usage:
C: DriveUse a temporary directory on this drive to develop and debug code. Save the results at the end of lab to the U: drive.
N: DriveThis drive is a read only share where many of your lab and homework files are located. There is a “scratch” directory on the N:\ drive that does give you write permissions. Use N:\scratch only to transfer files from one account to another and not to save work because it is flushed periodically.
U: DriveWhen you login onto the stations in the Mechatronics Lab, the computer will automatically map to your own personal drive labeled “U:”. This directory is only accessible by your login name, and is your personal space to store your DSP projects and other files related to the class. Every individual’s U: drive will be backed up regularly, so make sure to copy your code off your C: drive at the end of class to this drive because we cannot insure the safety of your data on the lab PCs.
Laboratory Exercise 3
- For your lab assignments all the given code is stored in an SVN repository. You will be periodically “checking out” code from this repository. Your Instructor/TA will explain the check-out procedures.
- Spr2018OMAPL138ProjCreator.exe is found in the “Spr2018OMAPL138ProjCreatorFiles” directory of the repository. Your instructor/TA will step you through creating and running your first project in Part a.
Part (a): Building a Project with Spr2018OMAPL138ProjCreator.exe.
For the first part of the Lab Exercise, your Instructor/TA is going to walk you through the creation of your first DSP project for the semester. This includes creating a project, building the DSP code, and finally running the code on the DSP.
Part (b): Explore a little bit how you could make you own DSP project for the OMAPL138 processor.
There are quite a number of details that go into creating a Code Composer project for a specific DSP platform. This is why we will be using a number of different “Project Creators” throughout the semester to give you a good starting point for the source code you will be developing. With this exercise I want you to explore your projects properties to see all the possible options that can be set/modified to build your source code appropriately for this DSP system. Right click on your project’s name that you created in part (a) above and select “Properties.” Take a few minutes and browse through the different property settings. As you become more experienced with embedded system software design you will understand these properties better. Towards the end of the semester when you understand CCS and the source code build process much better you may want to come back to these properties and try to make better sense of them.
Also as another resource we have defined the steps to create a Code Composer Studio project manually. The procedure to perform the manual project creation is located in the directory Spr2018OMAPL138ProjCreatorFiles\manualProject” of your repository. In that directory open the “howto.txt” file and find the steps needed to create your own project. Do not perform all these steps, but do take a few minutes to read through this file to get an idea of what the project creator is generating automatically for you.
Part (c): DSP Bios Kernel and Configuration Manager Example: The Period Object
In this section you will create a new application that uses the PRD (Period) object in DSP/BIOS. First use Spr2018OMAPL138ProjCreator.exe to generate a new project (do NOT go through the steps of part (b)). Give the project a name that describes it and also identifies you and your partner’s group. Say something like “dblocklab1c”. As the project creator states, you must place your new projects in the bottom most directory of your repository. Then in CCS v7 select menu Project->Import Existing CCS/CCE Eclipse Project. In the import dialog select “Select search-directory” and Browse for your project directory just created with the project creator.
- Open your project inside CCS and find the configuration (*.tcf) file for your project. Double click on the TCF file and the Configuration Tool will open. The Configuration Tool shows the DSP/BIOS kernel setup for your project. Modify your DSP/BIOS configuration to add a period object by selecting the tab: SchedulingPRD. Right click over the PRD tab, and select Insert PRD. You should see a new PRD object created. Give the period a name other than PRD0. While the name can be anything, the Texas Instruments convention is that period objects should begin with ‘PRD_’. Thus, one good name for the period object might be PRD_checkswitches.
- Set the period object to call a function every second. To set the PRD object properties, right click over the name and select Properties. A menu will appear with the following options:
- Comments: can be anything descriptive
- Period (ticks): The number of clock ticks to wait before executing the function. A “tick” is equal to 1 millisecond. FYI: A “tick’s” default value is 1 ms but in the DSP/BIOS CLK properties you can change the “tick” resolution. We will be using a tick=1ms throughout the entire semester more than likely.
- Mode: Select ‘Continuous’ so that the function will be repeatedly called.
- Function: The name of your c-function (see Step 12) that will be executed each period, with the function name prefaced with an underscore. For example, if your function is called “CheckMe”, then the entry should be “_CheckMe” (this is how assembly code accesses C-functions).
- Arg1/Arg2: Leave these set to 0x00000000. These are used to pass constant arguments to the function if needed. We don’t use this option.
- Write a global function in the project’s C file (i.e. if your project name was “danlab1c” than this file would be called user_danlab1c.c) to read the status of the 2 LCD push buttons and echo their state to two of the LEDS. The name of this function should be the same name you selected in part iv above, minus the beginning “_”. (i.e. if you used the suggested function name above “_CheckMe” than you would write a function “void CheckMe(void)”.) (IMPORTANT: Your DSP/BIOS objects (PRD, SWI, TSK etc) CANNOT have the same name as the function the object calls!) Use the MACRO’s GETSWITCH1 and GETSWITCH2 to read the switch state and SETLED1, SETLED2, CLRLED1, CLRLED2 to turn on an off the LEDs. Compile and download your code to the DSP, and when finished demonstrate your application to your TA.
If you are working with a partner on this exercise, trade places and give the other person a chance to do the coding for this next project.
- To give you some more practice, create another new project with Spr2018OMAPL138ProjCreator.exe. As above, import this new project into your workspace and open it.
- Again add a PRD object to the DSP/BIOS configuration, and have the period object call a global function every second. You could call this function void countit(void). Note that the function called by a PRD must have void parameters and void return. Have this function increment a global integer variable by one each time it is called. NOTE: When you setup a PRD object in DSP/BIOS, whatever function you specify to be called by the PRD is automatically called by the scheduler. You will come back to this function after the next step.
- Write a second global function that is passed an integer (int) and returns void; i.e. void set5LEDS(int cnt). This function should check the state of the first 5 bits of the passed integer and turn on or off the corresponding LED 1 – 5. For example if the value 18 (0x12, 10010b) is passed to this function then LED5 =on, LED4=off, LED3=off, LED2=on, LED1=off. Use bit masking to determine the state of each individual bit. For example to check if bit 3 is 1 or 0:
void myfunction(int cnt) {
if ((cnt & 0x8) == 0x8) {
turn LED4 on;
} else {
turn LED4 off;
}
- Now that you created the above function that displays to the five LEDS the state of the last five bits of a number, call it inside your PRD function, i.e. countit(), and pass it your global count variable. Build and run your code and see that the LEDS start counting in binary. Show your instructor/TA.
- As a final step, add one more feature to your program. If switch 1 is pressed do not increment the count. Build and run this code and show it to your instructor/TA.
Part (d):: Breakpoints and Expressions Window. Using the code you just finished, we want you to experiment with adding breakpoints to your code and using the “Expressions Window” to edit the values of your variables.
- In your previous code and with the DSP halted, put your cursor over the integer variable that you are incrementing. You should see a value appear corresponding to the value of the variable. Run your code, halt it again. Put your cursor over the same variable to confirm that it changes.
- An easier method than using the cursor repeatedly is to add the variable to the expressions window. When the DSP is halted, the expressions window displays the current values of each variable in the expressions window. To add your counting integer variable to the expressions window, highlight the variable and then right-click, then select Add WatchExpression. The variable will appear in a window with the current value of the variable listed alongside. The Expressions Window dialog is also found under the View menu.
- IMPORTANT! BREAKPOINTS! IMPORTANT! Breakpoints (along with the Expressions Window) make debugging source code so much easier. In fact as a general rule for your lab assignments, you will need to set a few breakpoints and try to figure out your source code errors before asking an instructor for help. A large part of this mechatronics course is teaching you how to debug an embedded control system.
A breakpoint is a location where the program will literally halt during execution. This allows you to check the values of your variables midway during operation. Have your instructor/TA come to your computer and show you how to set breakpoints and step through your code. It is much less confusing to show you then describe the process. After halted at a breakpoint, you can single step through your code using the (F6) key and watch the variables update as different calculations are performed. You remove breakpoints by double clicking on the blue breakpoint circle that is created.
Note: The DSP compiler is very advanced and is optimized to produce assembly code that has a speed, on average, of approximately 70% of that of hand-coded assembly, i.e. the theoretical maximum usage of the DSP. If your code contains simple loop instructions or if statements, then the C compiler may optimize your code to a point that seems to eliminate portions of your code, thus making it impossible to set breakpoints at each line. To get around this, you can turn off optimizations in the compiler options or you can declare the variables of interest as “volatile.” This will allow you to single step through your code in the sections you are debugging. You will learn more about this “volatile” variable type in upcoming labs.
- As a final step, if you have been lucky and have not yet received any compiler errors during any of the above exercises, you should intentionally add some errors to your code so that you will see how CCS will alert you during the build process.
Lab Check Off:
- Demonstrate you have completed Parts A and B.
- Demonstrate your first application, the one that continually checks the status of the two push buttons and displays their current state on two of the LEDs. (First half of Part C)
- Demonstrate your second application, the one that updates a counter every second and outputs the last five bits of the count to the five LEDs. The count should stop if button 1 is pressed and resume when it is released. (Second half of Part C)
- Demonstrate that you know how to use Breakpoints and the Expressions Window to debug your source code. (Part D)
GE423, Mechatronic SystemsLab 1, Page 1 of 5