Lab 9: Async IO and I2C

This lab has you explore Asynchronous serial I/O and I2C operation.

Prelab (20)

• Unpack this zip archive into your PIC24 code examples folder (under pic24_code_examples, you will have a new folder called lab9 that should be at the same level as the chap8, chap9, etc. folders). Familiarize yourself with the code in MPLAB project lab9/uart_test.c and lab9/i2c_eeprom.c .

• Answer the following questions. Your letter waveform may be handdrawn but it should be reasonably neat. You may handwrite the other answers. You may either rephrase the questions, copy them and fill in the answer blanks, or jot down relevant portions, however you must give an indication of what you are answering. For example:

  • Inadequate: 

2. 42 us

•  Adequate:

2. one bit time: 42 us

1. Take the first letter of your name (capitalize it), and draw the asynchronous serial waveform used to transmit it. Assume data is sent LSB to MSB as 8 data bits + 1 start bit + 1 stop bit. (See Lecture Slides, Chapter9_AsnCom.pdf, p8, Example 3 for how this should look and how it should be labeled. Use the ASCII code for your own letter.) (2)

Using the baud rate that you commonly use for your PIC24 breadboard and BullyCPP connection, compute the following values concerning asynchronous I/O:

2. One bit time, give the answer in microseconds: ________________ (2)

3. The amount of time to send on ASCII character assuming 8 data bits + 1 start bit + 1 stop bit (give the answer in microseconds): ___________________ (2)

4. The amount of time to overflow the dsPIC33EP128GP502 UART assuming that it takes five complete characters, overflow occurs when the 5th character is fully received, and characters are sent with NO dead time between characters: ______________. (2)

5. The amount of PIC24E/dsPIC33E timer ticks equivalent to answer #4 assuming the processor is running at a frequency of 60 MHz, and the prescaler is 8. (Solve for PR2): _________________ (2)

• Have the 24LC512 EEPROM from the parts kit wired up on your board. To learn how, find the datasheet for the part by searching for it on the internet. You need the datasheet to complete this lab. You must look at the datasheet. Connect SDA to the ASDA1 pin on your PIC and SCL to the ASCL1 pin. SDA and SCL must also be connected to 3.3 V using external pullups - the 2.2 K resistors from your parts kit will work. Take the last digit of your student ID, convert it to binary, then use the last three bits for the A2/A1/A0 pins. So, if your last student digit is 5, this is 0b0101, the last three bits are 101, so A2=1 (VDD), A1=0 (GND), and A0 =1 (VDD). All of the pins of the EEPROM must be connected to something, even pin 7 and pin 8. Read the datasheet to find out what.  (10)

Prelab Checkoff

• Waveform drawn and questions answered correctly. (10)

• EEPROM wired correctly using short wires to connect its pins to VDD and/or GND. (5)  

Pins 7 and 8 are not connected to anything (0) 

Wires looping off board, untrimmed resistors, or jumper wires (anywhere on board). (0)

You connected pins 1-4 like the below picture, but your student ID doesn't end in 0 or 8. (0)

• You have a copy of the correct datasheet (pdf open in browser window counts as "having") (5) 

Task 1 - Overflow without ISR (10)

Open the MPLAB X project lab9/uart_test project, compile it, and program your PIC24 with it. This program measures the PIC24 UART overflow time by having the user input a character string, followed by a loop that only reads the first character and ignores the rest of them. The PIC24 timer3 is started after the first character is read, and the loop is exited if either UART1 overflows or the timer overflows (the timer overflow period is much greater than the UART overflow time). Recall that the UART1 overflows when its internal buffer is full (5 characters) and the 6th character is fully received.

Test the program by typing the number "1" into the BullyCPP window. You should get a message saying that "UART overflow did not occur". Next, copy (Ctrl-C) and paste (Ctrl-V) progressively larger strings into the BullyCPP window ("12", "123", etc) until you find the first one that overflows. Call this the "overflow string". Take a screenshot of BullyCPP showing the overflow.

(If you cannot trigger an overflow because BullyCPP reads the Ctrl key as a separate keypress, you will need to download an older version of BullyCPP from the Github page. See Lab 0 for link.)

When the UART overflows, a timer tick value is printed out corresponds to the number of timer ticks after the arrival of the first character (which is read by the program) and UART overflow. Test the program with a few times with your overflow string and take an average of the last three timer tick values you see. The program also uses a GPIO pin to measure UART overflow time by setting RB14 high after receipt of the first character, and then back low when UART overflow occurs.

1. Convert the timer ticks into a time in microseconds (the reverse of prelab question #5).

2. Find the top left wire of the VirtualBench logic analyzer connector (it has 40 wires, colored black, red, green, yellow, blue, and white). It is labeled GND. Stick a small wire from your wiring kit into this wire socket, and plug this into your breadboard on the ground rail.

3. Connect the VirtualBench logic analyzer red wire labeled D0 into the RX pin of your PIC24 (will be the RB10 pin).

4. Connect the VirtualBench logic analyzer red wire labeled D1 into the RB14 pin of your PIC24.

5. Remove the analog input from Channel 1 so the red line goes away. Configure the VirtualBench logic analyzer, enabling D0 and labeling it UART RX, and enabling D1 and labeling it RB14. Set the trigger for a rising edge on RB14.

6. Type in the first capital letter of your name and measure the width of one bit. Take a screenshot.

7. Change trigger to falling edge.Type in your overflow string. Measure the high pulse width (from where it first goes high to where it dips back low) of the RB14 trace using cursors in VirtualBench and compare this time to the time that you computed in step 1 and in the prelab. This is the measured overflow time of the UART. 

8. Capture a VirtualBench screenshot showing all of the characters that were sent on the UART RX trace as well as your measurement of the RB14 high pulse time.

TA Checkoff

You have taken a VirtualBench screenshot showing your overflow string. Should show UART RX and RB14, and measure from where RB14 goes high to where overflow occurs.

Task 2 - Overflow with ISR (10)

This task assumes that you have the VirtualBench connections from Task #1 still connected. Open the lab9/uart_test_interrupt project. This project is the same as uart_test except that it has the compiler flag -DUART1_RX_INTERRUPT defined during compilation, which enables interrupt-driven UART code in the my_pic24_uart.c file (the screenshot below shows how this compile flag is turned on in the project; to reach this, right-click on uart_test_interrupt in the Project panel and select Properties from the pop-up menu). Interrupt-driven I/O uses a software FIFO to store incoming UART receive bytes in order to give a larger number of characters before receive overflow.

1. Open the file my_pic24_uart.c file and find the UART1_RX_FIFO_SIZE #define statement; note that this size is set to 32.

2. Find the UART1 RX interrupt service routine (_U1RXInterrupt) in the my_pic24_uart.c file, and add the line _LATB2 = ~_LATB2; as the first line in this function. This toggles the RB2 pin each time the interrupt is called and a serial character is stored in the software buffer.

3. Compile the program, and download it to your PIC24. Send your overflow string found for Task 1, and you will find that the UART software buffer does not overflow. Keep sending successively larger strings until you find the first one that causes overflow (you will get a software reset, and a report of 'UART1 RX Interrupt FIFO overrun' in BullyCPP). Capture a screenshot of the overflow in BullyCPP and include it in your report.

4. Open the VirtualBench software, and configure it the same way as for task 1 (double check your settings since zoom in/out will change them). Connect one more wire - locate the wire D2 on the logic analyzer connector and plug this wire into the RB2 pin of your PIC24. Label this RB2 in the VirtualBench logic analyzer setup.

5. Configure the VirtualBench for single shot trigger, falling edge and send the same string you found in step 3 that caused overflow. Zoom out on the VirtualBench display until you see all of the characters that were sent, and verify that the RB2 trace toggled for each character that was received. Take a screenshot.

TA Checkoff

You have taken a VirtualBench screenshot showing your overflow string using software FIFO. Should show UART RX, RB14, and RB2. You don't need to measure anything.

Task 3 -- EEPROM (40)

1. Open the MPLAB project lab9/i2c_eeprom. Edit the i2c_eeprom.c file, and change the #define EEPROM 0xA0 statement to the following:

#define READ 0x??

#define WRITE 0x??

These macros define the control byte to send to your EEPROM. The ?? should be replaced by two hexadecimal characters as follows:

Change the line in readOneByteCurrentAddress that says putI2C1(EEPROM | 0x01); to putI2C1(READ);

Compile the program, and then program your PIC24 with the hex file. When run, this program displays three menu options. Option 1 reads a byte from the current address location in the EEPROM, option 2 reads a byte from a specific address, and option 3 writes a byte to a specific address and reads that byte back to verify that the write operation was performed correctly. Take a screenshot of BullyCPP showing option 1 being performed. Option 1 has been implemented for you, while options 2 and 3 need to be completed for this task. 

2. Menu option #2 calls a function named uint8 readOneByteSpecificAddress(uint16 u16_address) that reads one byte from location u16_address and returns it. This function is currently empty. Write a series of I2C function calls that implements this functionality. Use the primitive functions listed below (all of them may not be needed):

void startI2C1(void);

void rstartI2C1(void);

void stopI2C1(void);

void putI2C1(uint8_t u8_val);

uint8_t getI2C1(uint8_t u8_ack2Send);

Test your implementation with the address of the last four digits of your student ID number and take a screenshot of BullyCPP.

Hints

To extract the most significant byte of a 16-bit number into an 8-bit variable, you can do:

u8_msb = (u16_r >> 8) & 0xFF;

To extract the least significant byte of a 16-bit number into an 8-bit variable, you can do:

u8_lsb = (u16_r & 0xFF);

3. Menu option #3 calls a function named void writeOneByteSpecificAddress(uint16 u16_address, uint8 u8_byte); that writes the u8_byte byte value to location u16_address. This function is currently empty. Based on the EEPROM datasheet and the lecture notes, write a series of I2C function calls that implement this functionality. Use the primitive functions listed below (all of them may not be needed):

void startI2C1(void);

void rstartI2C1(void);

void stopI2C1(void);

void putI2C1(uint8_t u8_val);

uint8_t getI2C1(uint8_t u8_ack2Send);

Test your implementation with the address of the last four digits of your student ID number. Write the ASCII code of the first (capital) letter of your name. Take a screenshot of BullyCPP.

4. Remove the RB14, RB2, and UART RX wires, and clear them from the VirtualBench setup. Connect the red VirtualBench wire D3 to the SCL pin on the LC512 EEPROM. Label this SCLK in the VirtualBench setup.

5. Connect the red VirtualBench wire D4 to the SDA pin on the LC512 EEPROM. Label this SDA in the VirtualBench setup. Add an I2C interpreter using these two pins to the VirtualBench logic analyzer setup, as shown in the image below:

6. Set up the VirtualBench software for single shot execution, with trigger on the falling edge of the SDA trace. Set the starting period to 10 us. Start the VirtualBench running -- it should wait for a trigger on the SDA trace. Execute menu option 1 within BullyCPP for the i2c_eeprom program, readOneByteCurrentAddress. You should get a string back indicating that some byte was read from your EEPROM (we don't care what the byte value is). If you get a Watchdog timer timeout with an I2C error message, this means that either your #define READ address is incorrect, or your EEPROM is wired incorrectly (SDA/SCLK lines reversed, no pullup resistors on I2C lines, etc), or both! To debug this, look at the I2C trace that was captured in the VirtualBench software, and see if the correct first byte is being sent to the EEPROM. Take a VirtualBench screenshot.

7. Take a VirtualBench screenshot of readOneByteSpecificAddress in action.

8.  Take a VirtualBench screenshot of writeOneByteSpecificAddress in action.

TA Checkoff:

A read of the address of the last 4 digits of your student ID number produces the first letter of your name. You have taken VirtualBench screenshots showing your I2C transactions. Each should show SCLK, SDA, and BUS1.

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

• Distance students only: Label the first section Prelab. Include your response to the five questions. Your letter waveform may be handdrawn but it should be reasonably neat. Your other answers must be typed, not handwritten and scaneed. You may either rephrase the questions or copy them and fill in the answer blanks, however you must give an indication of what you are answering (not just: 1. True 2. 42 etc). Include a photo showing you have wired your EEPROM on your board.

• Label the first section Task 1. Describe Task 1 so that an outside reader could understand what you measured. Compare your prelab answers to your actual results. Present your data in a coherent and organized fashion. Be sure to include:

  • BullyCPP screenshot of your overflow string

  • Timer tick value of overflow

  •  VirtualBench screenshot showing overflow string and time measurement.

  • VirtualBench screenshot of the first letter of your name with bit time measurement

• Label the second section Task 2. Describe Task 2 so that an outside reader could understand what you measured. Present your data in a coherent and organized fashion. Be sure to include:

  • BullyCPP screenshot of your overflow string

  •  VirtualBench screenshot showing your overflow string.

• Label the third section Task 3. Describe Task 3 so that an outside reader could understand what you did. Be sure to include:

  •  your three BullyCPP screenshots.

  • your three Virtual Bench screenshots.

• Submit your i2c_eeprom.c file

  1. Remove the default boilerplate header above the asterisks.

  2. Be sure the file description atop the file is correct.

  3. Add a header of your own including name, course number, lab number, lab section number, date, and filename.

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

  5. Comment your code, labelling the portions you added and explaining what each line does.

  6. Make sure all existing comments are applicable to the code you are submitting.

  7. If you notice you've made mistakes but the program still somehow runs, fix them.

  8. Build your code and run your program again to make sure they still work right.

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 ("I got my PIC to overflow." "Here is the screenshots of my I2C.")

• text is phrased as instructions to a second party ("Take current measurements.")

• 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 opened an MPLab project. Then I saved the file as...")

• blatantly erroneous text ("These screenshots show the amount of voltage flowing through the pushbutton.")

• garbled / confusing / gibberish text ("The length of one bit is one bit, also known as a byte.")

• using vague or incorrect terminology ("I used Microsoft Excel to builb the program")

• excessive text

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

• general unprofessional appearance

• code is untidy

• code is missing header and/or contains default header

• code has inaccurate/inadequate comments

The tasks are worth 60 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 three tasks. The first task is worth 10 points. The second task is worth 10 points.  The third task is worth 40 points. (Task 3a is worth 10, and 3b and 3c are each worth 15 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

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