Lab 5: Pointers, Subroutines

This lab has you convert a C program that uses pointers and subroutines into PIC24 assembly language. You will also use debugging techniques to examine the workings of a C program.

Basics

1. • Download the ZIP archive which contains the lab files. It is located in Canvas > Files > Labs S2025 > Lab 5, and is called lab5.zip. Extract it directly into C:\ece3724. You should now have a folder called C:\ece3724\lab5.

   • Inside this folder, there are three different projects, called case7, case8, and case9. You will only be completing one of these.

   • If you are in lab section...

     • 07 or 05, then you will be doing case7.

     • 03 or 06, then you will be doing case8.

     • 04, then you will be doing case9.

Be sure you do the correct project, or you won't get credit for the lab.

1. • There is also a sample project, called sample, which includes two programs, upcase, and swap.

   • For your case, there are two source files, case#.c, and case#.s, which are C and PIC24 assembly programs, respectively. For the sample project, there are C and assembly versions of both upcase, and swap.

• upcase is a program that makes a string all uppercase. Examine  upcase.c, then run it. (Before running it, or any program in this lab, make sure its project is set as the main project, and it is the only source file included in the current configuration.)

• The UART1 window should show two strings being printed, first in regular case, then in all uppercase. If you don't have a UART window, you can try the steps on the Troubleshooting page. If they don't work, or you don't feel like it, don't worry - you do not need a UART window to complete the lab. Examine data memory. Set a breakpoint and single step through it. Examine how the strings change letter by letter. Set watches on the variables in the program. If you can't remember how to do any of this, refer to Lab 2 or read the MPLAB docs.

• Now, check out upcase.s. It's an assembly translation of upcase.c. You're going to be doing an assembly translation of a similar program for Task 1, so this will be helpful to show you how it should be done. You can pretty much ignore everything outside the /*****/ lines, as you won't have to translate that stuff.

• Run upcase.s, set a breakpoint, step through it, examine memory, and etc. upcase.s and the other assembly programs in this lab do not print anything in the UART window.

• swap is a program that swaps two strings. Investigate swap.c and swap.s like you did with upcase.

Prelab

• In one of the sample files provided, there is a label prelab:. Beneath it is some code that puts the ASCII characters spelling "Prelab" into data memory, so after you run the program, you'll find this somewhere in data memory:

• Change "Prelab" to your first name*. Use the following table to help:

*Your first name is whatever Canvas says your first name is, spelled and capitalized the same way. For example, if your name is "Lawrence", that is what the TA  should see on your screen. "Larry", "lawrecnE", "L", or "Prelab" would not receive credit, even if all your friends call you that.

Prelab Checkoff

• You are running the correct program, have data memory open to the correct address, and your first name is visible in the ASCII column, spelled and capitalized correctly. (20)

• You misspelled your name slightly, or didn't capitalize it. (10)

• You can't find the lines of code, can't locate the appropriate area in data memory, couldn't figure out how to do this, or waited until the last minute and only get a letter or two in there before the TA came around to check you off. (0)

Task 1 (40)

• Your job is to manually convert your assigned C program, case#.c into PIC24 assembly language, in the file case#.s.

• Fill out the header on top of the program with your name and etc. before you forget.

• Replace the ??? with a brief description of what your program does e.g. "Takes string 1 and reverses it, then makes string 2 uppercase."

• Below the header is the C code all in one place, which will be useful for your lab report.

• Then there's some initialization code. There's some at the bottom, too. Don't mess with any of it.

• In the middle is the C code you need to translate. It's already been commented out for your convenience.

• Keep things neat. You need to use register assignments, but not Input, Process, Output. Follow the example of upcase.s and swap.s:

;     [W0]    W2    (register assignments, above the correct variables)

;; C code = C code++;

assembly W2, [W0]

(blank line)

          ; [W1]  W3  etc...

• The case# subroutines take two parameters, like swap. (upcase only takes one.) You call them the same way, by moving the addresses of the strings into W0 and W1, then rcall case#.

• Each of the case# subroutines uses a local variable. (case9 uses two. ) Do not make a new variable(s). Just fill in the blank in the comments with the register(s) you will be using. Look at swap.s for an example. Use register(s) between W3-W7 for temporary variables. Use the same register for that variable throughout the program. Do not use W0 or W1 for temporary variables.

• psz_1 and psz_2 are pointers. (They are the addresses of what character in the string that we are looking at.) Translate them as W0 and W1. Like all addresses, they are 16 bits.

• When you see *psz_1 and *psz_2 in the code, it means the pointers are dereferenced, meaning this refers to a char in C, which is 8 bits. Use .b operations with them. Translate them as [W0] and [W1] and note this in the register assignments.

• You shouldn't need to move [W0] and [W1] into new registers to use them. But if you do, note this in the register assignments like [W0]>W4. There is an example in upcase.s.

• Don't forget a return and of course, labels where you need them.

• There are no printf statements in the assembly code to test if your program is working, so you cannot rely on the UART window. (main has been modified accordingly, to run an endless loop.)To see your program's output, examine the data memory (File Registers) at the addresses where  the sz_1 and sz_2 variables are stored.

• You may also use the Watches window to monitor sz_1 and sz_2.  To make reading the strings possible, right-click the variables and select Display Value Column As > Character. You may also need to increase User Defined Size if the entire string is not visible. However, the strings may appear to be backwards because they are stored in memory with their first letters in the least significant bytes. Thus it is probably easiest to look at data memory.

• Your PIC24 assembly program should have the same values for the strings after it runs as the values printed (or stored in data memory) by the original C program. This must be achieved by proper line-by-line translation of the C code, not, for example, by:

  • somehow avoiding using pointers/indirect addressing

  • editing the string constants

  • moving things directly into memory like you did in the prelab 

TA Checkoff

• Your program correctly transforms the two strings (as verified by file registers window).

• You have both screenshots and they look decent.

• Code looks good.

Report Requirements

• Take a screenshot of the Files Register window showing sz_1 and sz_2 with format set to Hex in the dropdown at the bottom. 

• Now open the Program Memory window (Window > Target Memory View > Program Memory). Set Format to Code in the dropdown at the bottom. Right click in the window and check Symbolic Mode and Verbose Labels.  Take a screenshot of your case# subroutine.  Expand the window so you can get all of it.

Task 2 (10)

• Your job is to find the point where the program puts the first "H" into sz_1: in the C program, upcase.c:

• You can set breakpoints in program memory as well as in your code. Set one on the first line of program memory:

• With Program Memory settings of Format>Code and Symbolic Mode, step through the program. Go back to the Watches window so you don't miss when the H appears.

• You will need to choose judiciously between Step Into (F7) and Step Over (F8), Step Over is faster, but will jump right through whole subroutines. 

• You need to know the exact line and state it in your report, and it needs to be in the screenshot, but you don't need to have stopped the program counter exactly on it. In fact, the program counter (green arrow) points to the line that is about to execute.

TA Checkoff

• You can show the TA which instruction "put the H in sz_1".

Report Requirements

• Note the line, address, opcode, and (dis)assembly code of the instruction that caused the "H" to appear. Take a screenshot of the Program Memory that includes this line. 

Task 3 (10)

• Still using upcase.c, remove the breakpoint. Stop and rerun the program. 

• Switch the Program Memory view format to Hex, which will display ASCII values (and make text strings readable). 

• Locate the area in program memory which contains the constant strings used to initialize sz_1 and sz_2 . You can use the MPLAB search, filter, or goto functions, but I would just scroll down and look for the word "Hello" in the ASCII.

•  Change Hex Display Width to One Byte by right clicking in the memory.

• Determine the address where the "H" is stored. 

How to read MPLAB Program Memory in Hex Format

Let's say instead of the "H" in "Hello", we are looking for the "B" in "Before". We find it here (ASCII 42):

The addresses on the left are the starting addresses for the whole row. So the addresses are laid out like this:

Thus, 00D10 contains "426500--"*, and the answer would be 00D10.

The "fo" is at 00D12, and the "re" is at 00D14. Hopefully this helps you determine the address of your H.

*The PIC24 family (which includes the dsPIC33EP128GP502 that we use in lab) has a 24-bit instruction. So the MSB of the MSW is called the "phantom byte". There is nothing there, hence the dashes/gray boxes.

TA Checkoff

• You can show the TA where the constant strings used to initialize sz_1 and sz_2 are located. You know the address of the "H".

Report Requirements

• Take a screenshot and note the address where the H is stored.

Report

• Your report must have a title page.

• Briefly (in 1-3 sentences) describe the overall activities of the lab.

• Distance students only:

  • Make a section called Prelab. Briefly mention what you did.

  • Include a screenshot or monospace paste of the code you wrote.

  • Include a screenshot of your data memory showing your first name.

• Label the next section Task 1. 

  • Briefly describe what you did for Task 1. Mention things like what language(s) you used, and what your program did.

  • Include a screenshot of the code you translated or paste it in a monospaced font like Courier New. Fit it all on one page.

  • Include the screenshot of program memory along with a brief explanation of what it is and what it signifies.

  • Include the screenshot of data memory along with a brief explanation of what it is and what it signifies.

  • Be sure to give addresses and other required information in the text and tell the reader what they are supposed to be looking at.

• Label the next section Task 2.

  • Briefly describe what you did for Task 2.

  • Include the screenshot of program memory along with a brief explanation of what it is and what it signifies. Be sure to give the line, address, opcode, and (dis)assembly code of the instruction that caused the "H" to appear.

• Label the next section Task 3.

  • Briefly describe what you did for Task 2.

  • Include the screenshot of program memory along with a brief explanation of what it is and what it signifies. Give the address of the H.

• Attach your case#.s file. Nobody, not even distance students, needs to attach swap.s, or any other file. 

  •  It must be properly commented. The comments should indicate which assembly language source lines implement which C statements and give a register assignment for each line of C. It may contain additional comments helping you to understand what the program is doing.

  • Make sure it has the header filled out with your name and etc.

  • Don't forget to describe the program's functioning at the top, replacing the ???.

  • Tidy it up - align indentations and use the requisite number of blank lines to make it easy to read.

  • Run it again to make sure it still works.

Grading

The report is worth 20 points.The tasks are worth 60 points. If your report indicates that you did not complete or do not understand a task, you will lose credit, even if you performed it during the lab.  The same is true for tasks performed during the prelab.

The following non-exhaustive list of errors will result in losing credit from the report portion of the grade:

• bad screenshot (lazy cropping, little, giant, on a page break, didn't narrow columns)

• garbled / confusing text  ("My merory = "FIRST NSME")

• using vague or incorrect terminology  ("We used C++ to imprecent the varialbefs ")

• multiple mistakes in comments/missing some comments in code

• untidy code (random spacing, no spacing, drunken indentations)

• text is "lab jargon" unintelligible to an outside reader ("I did case7 which uppercase string.")

• text is phrased as instructions to a second party ("Student will translate C to Assembly!")

• text is copy-pasted from the lab directions rather than using your own words.

• text is a literal recap of the activities you performed rather than communicating your results and understanding ("First, I put in register assignments. Then I initialized my variables. Then I set a breakpoint at line 127, in order to see where I was branching wrong..."

• blatantly erroneous text ("I wanted to reverse the strings, so I wrote the following C code...")

• excessive text ("Well, this lab was certainly more difficult than Lab 4. It contained pointer variables, which I first thought I should translate as addresses, but upon reading Donald Knuth's Literate Programming Vol IV....")

• careless use of pagebreaks that leave blank pages, 1-2 lines of text on a page, writing a header on one page and the text all on the following page, etc.

• general unprofessional appearance

There are three tasks. The first task is worth 40 points, the second 10, the third 10. The following non-exhaustive list of errors will result in losing credit from the task portion of the grade:

• missing screenshot 

• screenshot of the wrong thing

• screenshot showing incorrect values

• awful screenshot (didn't crop, tiny, blurry, etc)

• missing text description of task

• Code header describes program function incorrectly, or as "???".

• blatantly erroneous text

  • "This is a screenshot of the program memory" (next to a picture of file registers)

  • "The value of u16_a is..." (while showing sz_1)

  • "sz_2 contains 'mixed case'" (while it contains "Hello")

• missing register assignments in code

• didn't follow basic instructions of programming task (didn't use pointers, pass 2 parameters to subroutine, translate exact C code, etc)

• code doesn't run / doesn't transform strings properly

• used wrong strings

Lab reports that flagrantly violate submission policy (wrong lab, no screenshots, no title page, no text besides headings/labels, mostly blank, assembly code pasted into pdf, paragraphs of lab text pasted in, did wrong case, etc.) will not be accepted. The student will receive a zero for the lab and may resubmit with late penalty.