Lab 8: Interrupts and Timers

This lab has you re-implement the Button/Switch/LED I/O problem from Lab 7. You will still follow the state machine approach, however you will now use interrupts rather than polling and software delays. You will also generate a simple repeating waveform using a timer interrupt.

Basics

Download the file lab8.zip from Canvas > Labs S2025 > Lab 8. It contains three files, ledsw2_int.c, lab8_int.c, and lab8_wave.c. Unzip it and put the files in C:\ece3724\pic24_code_examples\chap09.  

• ledsw2_int.c is an example program. It is a revised version of the ledsw2.c state machine, which uses a timer interrupt to blink the lights, and a change notification interrupt to change states on button press/releases (along with a timer interrupt to debounce the button). 

• lab8_int.c is all set up to use interrupts. You just need to paste in your state machine from Lab 7, and make a few modifications. You'll be submitting this file.

• lab8_wave.c generates a simple square wave using a timer interrupt. In Task 2, you'll be modifying this program to generate a wave that looks like your student ID number. You'll also be submitting this file.

For reference:

Section 07:

1. LED is on. On press and release, turn LED off, goto #2.

2. On press and release, blink 2 times, goto #3.

3. LED off. Blink while button held down. On release, if switch = 0, then goto #1 else goto next step.

4. Blink rapidly. On a press and release goto next step.

5. LED off. On press, turn LED on. On release, goto #1.

Section 03:

1. LED is on. On press and release, turn LED off, goto #2.

2. After press and release, blink 2 times, freeze on.

3. After press and release, if switch = 0 goto #1 else goto next step.

4. Blink when pressed and held down. After release stop blinking. Another press continue blinking. After another release, goto #5.

5. Blink rapidly. On press and release, go to #1.

Section 04:

1. LED is off. On press and release, turn LED on, goto #2.

2. On press, begin blinking. On release, freeze LED on and go to #3.

3. After press and release, if switch = 1 goto #1, else goto next step.

4. Blink five times. If all five blinks complete then: if switch = 0, go to #1, else goto next step. Any press during the five blinks - abort and goto next step.

5. Blink rapidly while button held down. On release, goto #1.

Section 05:

1. LED is off. On press and release, turn LED on, goto #2.

2. After press and release, begin blinking.

3. After press and release, halt blinking. If select input = 1 goto #1, else goto next step.

4. Turn LED off. On press only, goto #5.

5. Blink rapidly 5 times while button held down. If button released before all 5 blinks complete, go to #1. If all 5 blinks complete, freeze off, and release remains in this state (freeze off). A subsequent press repeats #5.

Section 06:

1. Turn LED on. On press and release, turn LED off, goto #2.

2. On press and release, blink 2 times, goto #3.

3. LED off. Blink while button held down. On release, if input select = 0, then goto #1, else goto next.

4. Blink rapidly. On a press and release goto next.

5. LED off. On press, turn LED on. On release, goto #1.

Prelab (0)

There is no prelab for Lab 8. It is recommended that you start ahead of time so that you can finish during your lab section, but it's up to you. If you have to come back to a later section, please remember that seating priority goes to students in that section. Also keep in mind that Labs 7 and 8 are particularly important for preparing for the practicum, as you will be required to perform similar tasks under duress. Be sure that by the end of this lab you understand completely what is going on in each of these programs so you are able to modify them as needed.

Task 1 - Revised State Machine (30) 

• Open the project ledsw1_cn_revised.X. Add ledsw2_int.c and lab8_int.c to the project.

• Include ledsw2_int.c and exclude the other source files. Open it up and take a look at the code. It's the same state machine as ledsw2.c from last week, but it has been changed to use interrupts rather than software delays and endless polling. Upload it to your board and try it out.

• Now open lab8_int.c, include it, and exclude the other files. This is the framework for a state machine using interrupts. You will need to paste your state machine from lab7.c into it, so open that file in MPLAB X IDE, or a text editor.

• Copy your names of states and state descriptions from lab7.c into lab8_int.c. 

• Copy your state machine (the switch statement) into lab8_int.c. If you botch this up by, for example, missing a bracket or copying the default state twice, try to fix it yourself. The TAs are not going to be able to help you on the practicum.

• Go ahead and build your code and upload it to your board. It should run, but probably behaves erratically, printing the wrong stuff to the screen and/or refusing to blink. To correct it, you need to make the following changes:

• Since the state machine doesn't run until there's an interrupt, we need to print the initial state in main and set the LED to whatever it's supposed to be. The printing is done for you; just uncomment the line to set the LED:

• If you used any while loops in your switch statement in the last lab, change them to if statements. For example: 

while (PB_PRESSED()) {

do something

}

becomes:

do something

if (PB_RELEASED()) {

stop doing the thing 

}

• Move all (non-blinking) output changes that occur in a particular state to the transition to that state. For example, if the LED is supposed to turn off in PRESSED1, instead of this:

case PRESSED1:

LED1 = 0;

if (PB_RELEASED()) {

...

do this: 

case RELEASED1:

if (PB_PRESSED()) {

e_state = PRESSED1;

LED1 = 0;

}

break;

case PRESSED1:

if (PB_RELEASED()) {

    ...

If there are multiple transitions into a particular state, such as back to the first state, you need to edit all of them. Don't worry about blinking - you'll do that next.

• • Replace the DELAY_MS(xxx) software delays that you use to delay between LED blinks in the switch statement with timer3_arm(xxx) where xxx is the number of milliseconds to delay. You should not have to change the delays.

  • Add an additional timer3_arm(xxx) statement to the transitions to blinking states.

  • Upload the program to your PIC and test that it works exactly like it should. 

TA Checkoff

Your state machine functions properly. Your code contains no software delay functions. The while(1) loop in main contains only IDLE().

Report requirements

Take a screenshot of the console output in BullyCPP.

Task 2 - Student ID Squarewave (50) 

Your MSU student ID is of the form Y1Y2Y3Y4Y5Y6Y7Y8Y9. Take each digit of your student ID, and add ‘1’ to it. Your task is to generate a repeating waveform on pin RB2 that looks like the following figure:

• Open the project squarewave.X. Add lab8_wave.c to the project.

• Include lab8_wave.c and exclude the other source files. Open it up and take a look at the code. Right now it outputs a wave consisting of a 6 ms high period and 20 ms low period. Upload it to your board and try it out. If you're not connected to the scope, it should output "`1x" over and over again in BullyCPP.

• Fix Y1, since your student ID number doesn't start with a  5. Add states for digits Y2-Y9.

• In each case of the switch statement, set the PR2 value like this, where X is the number of milliseconds for that state. 

PR2 = msToU16Ticks(X, getTimerPrescale(T2CONbits));

• Make it print "123456789X" to BullyCPP.

• Connect the oscilloscope and examine the waveform generated to make sure it is correct. (RB2 is pin 6.)

TA Checkoff

Your waveform displays properly on the scope. Pulse widths are correct. Output in Bully is "123456789X" on separate lines.

Reporting requirements

• Capture a screenshot of your waveform showing all 10 pulses. You only need one screenshot.

• Measure and record the width of each of your pulses. 

Report

• Your report must have a title page

• You must textually describe what all your images are showing the reader, like this webpage does. E.g. "Below is a state diagram, showing the states used when implementing my problem." or "Above: Screenshot showing measurement of falling edge time of button press." 

• Do not invite the grader to inspect values in screenshots, e.g. "Rise time shown below:" Rather, state the value in your report. "The rise time was 280 ns as seen below."  

• Label the first section Task 1. 

  • Describe Task 1 so that an outside reader could understand what you did. Mention how your solution differs from that of Lab 7. What benefits does this new method offer?

  • Update your state diagram to show the outputs on the transitions and any other changes you made. Use the drawing tools in Powerpoint, Word or some other professional drawing program (not MS Paint or the like) to create the diagram – no scanning of hand-drawn diagrams is allowed. Be sure it is correct and accurately depicts the states you used in your program.

  • Include the screenshot of BullyCPP showing your console output.

• Label the second section Task 2.

   Describe Task 2 so that an outside reader could understand what you did.

• • Include your screenshot of the waveform.

  • Make a nice (NOT HANDWRITTEN) table showing your measured pulsewidths vs. what they are supposed to be.

• • Using the program chap09/squarewave.c, and the formula PR2 = (Timeout period / (clock period x prescaler)) - 1,  determine the frequency of the PIC. PR2 can be found by setting a watch in that program. Timeout period is ISR_PERIOD. Rememeber that frequency is 1 / clock period. Remember what milliseconds are. Show your not handwritten calculations. Adequate calculations are demonstrated in Lab 6. Your answer should be about 60 MHz.

• Submit your lab8_inc.c and lab8_wave.c files.

  • Be sure your name and etc are at the top of each.

  • Be sure to fill in your problem at the top of lab8_inc.c and your student ID number is at the top of lab8_wave.c

  • Be sure the indentation and spacing is consistent and neat.

  • Remove lines you've commented out and be sure any comments you added are correct.

  • If you've made any changes since leaving the lab, build your code and run your programs again to make sure they still work right. It's your responsibility - not the TAs - to make sure that the code you submit is correct.

Grading

If you do not successfully complete a task and your report fails to mention or glosses over this fact, you will receive a zero for the report portion of your grade as well as for the task. If you attempt to deceive the grader, e.g. by including screenshots not generated by the code you submitted, your instructor will be notified and you will be recommended for an Honor Code violation.

The report is worth 20 points for neatly and coherently presenting your information to a reader. The following non-exhaustive list of errors will result in losing credit from the report portion of the lab grade:

• bad screenshots (not cropped properly, blurry, too small)

• text is "lab jargon" unintelligible to an outside reader ("In this lab we redid the state machine of lab 7." "I made a waveformn on the virtual Bench.")

• text is phrased as instructions to a second party ("Produce square wave!")

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

• text is a literal recap of the activities you performed rather than communicating your results ("First I added 1 to each digit of my student ID. For the first digit, 9+1 = 10, when the 1 is carried to the ten's place. Ten is not actually a digit, but...")

• blatantly erroneous text ("My program outputs a square wave where the amplitude correleates to each digit of my netID. ")

• garbled / confusing / gibberish text ("Weave builb a squirl wave l1ke my student's numeral.")

• using vague or incorrect terminology ("sine wave", "the frequency is 3 ms")

• excessive text

• careless use of pagebreaks that leave blank pages, 1-2 lines of text on a page, etc.

• general unprofessional appearance

• state diagram is ugly (arrows criss-crossing, bizarrely-sized state shapes, didn't use arrows, etc)

• code is untidy

• code is missing header or contains default header

• code has inaccurate comments

The tasks are worth 80 points. If your report indicates that you did not successfully 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. There are two tasks. The first task is worth 30 points and the second task is worth 50 points. The following non-exhaustive list of errors will result in losing credit from a task:

• missing screenshot/diagram/text

• screenshot of the wrong thing

• screenshot shows incorrect results 

• cannot read screenshot

• state diagram incorrect

• handdrawn state diagram

• answered questions incorrectly or gave facile answer

• calculations wrong

• missing/incorrect units in calculations

• inadequate calculations

• handwritten calculations

• code won't build

• code performs incorrectly

• code is convoluted

• code uses incorrect methodology; doesn't follow lab directions.

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