Preston Stephens

ECE 443
Project 3
Introduction and Background
The goal of this project was for a PIC32 to receive serial messages from a terminal
emulator (PUTTY) via UART, then store the messages in an EEPROM, before displaying the
messages on an LCD screen when a button is pressed.
This project was implemented in reverse chronological order with respect to the flow of
data. I first implemented the LCD printing and scrolling, then reading from and writing to the
EEPROM, and finally, receiving input from the UART.
LED Screen and Scrolling
Scrolling functionality was implemented first. I was able to use a function that I had
written in ECE341 that would first clear the LCD screen and then print the first 32 characters of
a string to the screen. To make sure that words would not span multiple lines I wrote a function
“format_string” that breaks up strings into 16 character segments and pushes words to the next
segment if they span multiple segments. Pushing words to the next segment is done by
inserting a space character into the string at any given point and pushing the rest of the
characters down to accommodate. A function “add_space” is used to insert the space. This
function copies the contents of a string into a buffer at and following the position where a space
character is to be inserted and then copies the contents back into the character array after the
space has been inserted.
Once every message is broken into 16 character segments, 32 bytes can be printed at a
time without words spanning multiple lines. Every second, the beginning address of the
character string is advanced 16 characters to give the appearance of scrolling until there are no
more characters to read. The design prints the beginning of every message to the top line of the
LCD. It could easily be made to print to the bottom line first by adding 16 bytes of space
characters to the beginning of every message.
EEPROM
A ring buffer was created to handle reads and writes to the LCD screen. This buffer
utilizes 5 separate memory allocations on the EEPROM each with a maximum capacity of 256
bytes. The buffer is characterized by a few variables. These variables are “bottom”, “top”, and
“items”. “Top” corresponds to the memory space to write to and “bottom” corresponds to the
memory space to read from. Both variables range from 1 to 5 and roll over when incremented
past 5. “Items” keeps track of the number of items in the buffer. If “Items” is equal to 0 then read
requests will be ignored. If “items” is equal to 5, write requests will be ignored. Writing and
reading to memory locations on the EEPROM is accomplished using functions written in
ECE341.
UART
UART functionality was implemented using code from ECE341 and example FreeRTOS
code. The UART interrupt writes characters into a global buffer until it encounters a return
character. It then passes a semaphore to a task that calls a function to write the global buffer to
the EEPROM. Handling of the initial button press can be seen in Figure 2.
Buttons
 Button presses were handled in a similar way as in project 2. The change notice ISR
responsible for handling button presses first disables change notice interrupts and then passes
a semaphore to a button task. This can be seen in Figure 1 where the yellow task is the task
that receives the semaphore. The button task then debounces the button and increments a
global variable representing the number of pending messages. The number of pending
messages does not increment past 5. After debouncing the button, the task re-enables change
notice interrupts.
Heartbeat
Heartbeat functionality was implemented as its own task. This task had the highest
priority, priority 2. All other tasks are priority 1.
Project Critiques
Almost all objectives were completed for this project, but there are a few things that
could be fixed. Messages always first appear on the top line instead of the bottom and I could
have used queues to eliminate some of my global variables. I planned to add queues once
everything was functioning properly, but I ran out of time. Also, EEPROM data transfers are not
protected against UART interrupts so pushing the return key multiple times in succession could
cause my project to crash.

Figure 1: Button Handling

Figure 2: Return Character Handling