Lab 2 : OLED and SPI

EEC 172: Lab #2 - OLED and SPI

Author : Kelly Su, Tony Xiao

Intro

The objective of this lab is to learn how to utilize the OLED display and configure it with the CC3200 LaunchPad using SPI. In addition, we will be learning how to use the Adafruit API functions to write display words, shapes and etc onto the OLED screen for practice. Also, we will be learning how to use the I2C demo and modifying it to communicate with the Bosch BMA222 acceleration sensor in order to detect the orientation of the board, translate it into understandable coordinates in the application, and send information back to the OLED display to respond accordingly. We will also be using the Saleae logic analyzer to detect the SPI and I2C waveforms from both parts of the lab to verify and interpret the data and commands that are being sent to from the CC3200 Launchpad, the application, and OLED interface.

Background

Please reference our lab 1 for background about CCS Software and CC3200 Launchpad, the TI PinMux tool, the UART module, the Uniflash and the GPIO Module.

The OLED Breakout Board measures 128x128RGB pixels and each pixel can be set by a 16-bit number to provide for a large range of color display. The clock, data, chip select, data/command and an optional reset pins must be hooked up with the CC3200 Launchpad to communicate information to the OLED. There is also a Vin+ pin and ground pin to configure the current to supplied from the board.

The Adafruit software provides lower-level functions API used to display shapes, lines and words onto the OLED board display. Some of the functions included are testlines(), testfillrects(), testroundrecs() and testtriangles().

The Saleae USB Logic Analyzer is used to read in data from the circuit board and display it as a waveform on the Saleae Logic software.

The I2C (Inter-Integrated Circuit) module is a tool that can be used by the CCS Software to read information from external I2C devices, in this case, the accelerator sensor on the CCS Launchpad. The acceleration sensor is needed to detect the tilt of the board. In this lab, we use readreg to read the data in from the sensor by specifying the address of the I2C device (0x18 for the accelerator sensor), the register offset to read from (0x3 for x orientation, 0x5 for y orientation and 0x7 for z orientation) and the stop read bit (or the length of bits to read).

The Bosch BMA222 is the acceleration sensor that detects the orientation of the board. The I2C API module is utilized with conjunction of this sensor to detect the signals that correspond to the tilt orientation of the board.

Goals

Part I: Interfacing to the OLED using the Serial Peripheral Interface (SPI)

Implement SPI_demo project on two CC3200 LaunchPads The goal was to have two separate, but identical SPI projects opened on two separate computers and Tera Terms and have them communicate with each other. One of the computers is configured to be a master and the other a slave. The slave should be able to get information from the master and display it on it’s TeraTerm. Implement OLED interface using SPI Configure the correct connections between the OLED Display Module with the SPI example demo and then have something display on the OLED display to make sure the connections made works as expected. Write low-level commands like WriteCommand() and WriteData() in the Adafruit_OLED.c and test.c files that communicate to the OLED screen using the CC3200 LaunchPad pins and SPI. Utilize Adafruit API to be able to display various things on the OLED using built in functions in the library. Verifying SPI waveforms using a Saleae logic Use the Saleae logic to detect the output data of the OLED as it is receiving signals from the CC3200 LaunchPad using the SPI analyzer. Interpret the signals given by the waveform and how they relate to the code.

Part II: Using I2C to communicate with the on-board BMA222 accelerometer

Implement i2c_demo project on a CC3200 LaunchPad Run the i2c_demo project as an example to read the sensor information from the CC3200 LaunchPad. In this case, we are using the Tera Term to read the position and orientation from the acceleration sensors of the CC3200 LaunchPad. Verifying I2C waveforms using a Saleae logic Use the Saleae Logic program and I2C Analyzer to capture the waveforms of the I2C demo. Read the two output signals of the I2C_SCL and I2C_SDA, where I2C_SCL is the clock and the I2C_SDA is the data (x or y position). Application Program Modify the i2c_demo application to draw a ball that shows up on the OLED screen that can move around the screen based on the position and orientation of the CC3200 LaunchPad.

Extra Credit:

Our extra credit application is a Capture-the-Ball game which is an extension of part 2 application program. It is a game that requires the user to roll the blue ball to the position of the red ball’s position three times given a time restraint to win.

Methods

Part I: Interfacing to the OLED using the Serial Peripheral Interface (SPI)

1. Implement SPI_demo project on two CC3200 LaunchPads

To have the two launchpads communicate, we connected the CLK, the CS, MOSI, MISO and ground signals from one board to the other. We followed the SPI demo standard pin numbers: clock was pin bank 1, 7th pin; the CS was bank 2, 3rd pin; etc. Setting the MASTER_MODE of the master to 1 would designate the MOSI pin to be the pin where data is sent out from the master and the slave would be reading in data. When the master communicates data to the slave, the slave can receive it and the slave’s TeraTerm window echo’s what it received from the master.

Implement OLED interface using SPI

We connected the specified OLED signals to the appropriate pins, used PinMux to configure the GPIO pins and SPI pins, and connected the ground and the voltage pins. After connecting the pins, we wrote the writeData() and writeCommand() functions to be able to display stuff on the OLED screen. In both functions, SPI had to be enabled to be able to allow communication via SPI between the OLED and the CC3200 Launchpad. The OLED chip select (OC) signal had to be set to 0 before writing command/data to the SPI register. Then the data/command (DC) signal had to be set 0 for command and 1 for data to signify whether the outputed signal was command or data type. Then the character input would be written to the SPI register and would be displayed on the OLED screen when the OC signal is set to high. At the end, the SPI protocol must be disabled to reset everything so that the OLED is not reading in signals from the connections anymore. Verifying SPI waveforms using a Saleae logic First of all, we can see that the clock signal is correct as it is alternating between high and low. Secondly, we can see that the OC pin is low most of the time, set to low when writeCommand() and writeData() is first called and also low when the SPI is disabled at the end of the functions. The only time when the OC pin is high is after the value written to the register by the MAP_SPIDataPut() function is being displayed or communicated to the OLED once the register written to is ready. DC alternates between high and low to tell the OLED device that the information being passed in from the MOSI is data or command bits. The MOSI pin are data/command bits that tell the slave what to write or execute. We chose the MASTER_MODE 0 for the slave (or the OLED board) because it will be receiving data from the MOSI pin and interpreting it while the master’s (the LaunchPad) MASTER_MODE is 1 since it will be sending out data to the MOSI pin.

Part II: Using I2C to communicate with the on-board BMA222 accelerometer

Implement i2c_demo project on a CC3200 LaunchPad The I2C demo allows the user to read in acceleration sensor information through the BMA222 accelerometer on the launchpad. We connected the GPIO pins of the launchpad to the OLED pins to configure the MOSI and CLK connections. After that we opened up the TeraTerm to display the demo project interface. We then followed directions to read in information from the address of the sensor using readreg and setting the address, the offset and stop bit. We confirmed that the values given would change if we tilted the launchpad. Verifying I2C waveforms using a Saleae logic

With the Logic software, we interpreted the results of the waveform. (Note the labels are wrong). In the top Saleae Logic analyzer image, the bottom waveform is the SCLK which alternatives between high and low consistently. The bottom waveform gives information that the Bosch accelerometer sends to the launchpad to show the x, y and z orientation of the board. In the bottom image, the top waveform is the SCLK and the bottom wavecorm is the SDA which again is the data bits that tell the orientation of the board.

Application Program

Draw the ball using fillcircle function at position [64,64] which is the center of the OLED since the OLED is 128 * 128. In a while loop keep reading the accelerator data by using the function I2C_IF_Write() both in X and Y direction. Then, cast the accelerator data (which is given in unsigned) to signed char then cast it to int. Multiply the int with a constant to control the moving speed then we get the increments in both X and Y direction. Add the increments to the original X and Y, then we get new position of the blue ball. Before drawing the ball, we also need to check if the X,Y is still with in range of (0, 128). Once it beyond the boundary, we set the value to the boundary. Therefore the ball will not move beyond the OLED display screen.

Extra Credit:

We randomized the position of the red ball on the screen and display it to the OLED screen. In an infinite while loop, we kept reading the position of the ball on the OLED screen by getting the previous position of the ball and adding it to the acceleration of the ball. Initially, the ball starts at the center of the screen. We check that the ball doesn’t go out of the screen by constraining it to positions 4-123 in the x and y direction so that the whole ball will always be visible on the screen at all times. We time each game using a timer that increments after every while loop is done executing. At the beginning of each while loop, the new position of the blue ball is recomputed and checked against the position of the red ball to see if they overlap. The game will be a success if it is. A counter keeps track of a total of 3 successes to display a winning message to the user at the end. Anytime the timer times out, the while loop breaks and a losing message appears. Using the same logic as last lab, we enabled the user to try again when they press the sw3 switch on the board.

Discussion

The most difficult part about this lab was getting the OLED screen to display something. We were confused about what all the OLED pins meant, especially the DC pin and what would constitute data bits and command bits. We were also confused about how the slave/master dynamic worked and how they communicated with each other through MOSI. Another thing that was difficult was figuring out the implementation for SPI calls for the writeCommand() and writeData() functions. Interpreting the waveforms was also challenging because we had to know what each signal meant and learn about triggers.

Conclusion

We learned how to use the SPI protocols to have two devices communicate with each other and how to interpret the Logic waveforms coming in from the device(s) to analyze the results. We learned how to use the Adafruit API functions to print things on the OLED screen. We also learned how to utilize the accelerometer sensor on the CC3200 Launchpad using the I2C demo to interpret the orientation of the the board and write an application to respond accordingly. We also learned what all the different pins mean on the OLED like MOSI, DC and OC.