Piano KeyBoard LED Light

Weekly Updates:

2/20: Began research on the peripherals and the general structure of our project.

2/23: Zach researched into powering the breadboard that would be our keyboard and how to connect our breadboard to the LPC4088

2/24: Tim began searching trying to search how i2c and GPIO pins could be programmed.

3/06: Zach began making the keyboard.

3/13: Mapped the buttons on the breadboard to GPIO Pins

3/15: Sound plays on the board when keyboard is pressed. Began implementing LED display.

3/17: LED Display mapped out on the GPIO Board. LED Matrix Package Was Delayed

3/19: LED Matrix with I2C backpack successfully implemented onto board. Project Has Been Completed.

Complete Implementation:

BreadBoard:

The breadboard was designed to be able to control 7 different keys through the use of buttons. All of the buttons are tied to the Vcc of 3.3V. The GPIO pins connect to the circuit after the button and incorporates a pulldown resistor to ensure that the GPIO state is not left floating. The program constantly checks the states of all 7 GPIO pins and when a button is pressed, that individual pin is pulled high and is processed.

Onboard Speaker:

The Onboard Speaker utilizes the DAC to play values to it. Each frequency value has a corresponding hex value. The sound is generated in the APP_POLLING_TEST Function that we extracted from the DAC sample code. In the function there is a while loop that repeatedly plays the specific frequency note that was passed into to broadcast.

LED Matrix Display:

The matrix display communicates with the board via I2C. The matrix has two lines, SDA and SCL connected into the respective I2C_SDA and I2C_SCL pins on the J5 expansion connector. The LED lights in the matrix display are controlled by 16 I2C buffers of size 8.

LED Segment Display:

The segment display is connected to the board via GPIO pins.

Joystick Octave Button:

The joystick button had its own conditions. Whenever the button is pressed, a counter is incremented (0 to 2) to denote the change in octaves. A timer is initialized to implement debouncing. The debouncing can be observed on the board as a LED light (LED 3 on LPC4088) toggling on and off. The change was shown in the LED matrix when the next button was pressed.

Combining all the Parts:

The breadboard, which is our keyboard, connects to the GPIO pins on the three available expansion connectors (J3,J4,J5) through port 2 pins. When the board first boots up, the LED segment display is set into a "r" formation, denoting readiness. When a note button on the breadboard is pressed, it turns off the respective GPIO pins that control the segment display and sends a i2c mastersend that controls the note that should be displayed on the matrix. When the joystick is pressed to change octave, the code increments a counter that reconfigured the i2c buffers to change color.

Problems faced during Implementation:

Breadboard:

The first iterations of the breadboard when creating the schematic initially involved a resistor ladder using resistors of the same value to create a voltage drop across that could be read in when a switch was pressed. This iteration was created without knowledge of the GPIO and how it functions, and would have fed in different analog voltage signals to each GPIO. After discovering that the GPIO could just take in 3.3V or 0V and be read as a true or false to the board, this design was scrapped and the current design was adopted.

Onboard Speaker:

When we were configuring the DAC, we weren't able to load full notes into the DAC to play sound. We examined a sample file provided by LPC that played a wav file. Inside the wav file contained 8k sound frequency array of integer values. At first we tried to follow the example, however we could not get produce sound from the board. So we tried to play frequency notes instead. What we found out about playing frequency notes was that the DAC needed a oscillating signal to play sounds. We started off with a large array of 125s but not sound was being broadcasted. Then we experimented by creating a large array (over 1000 lines) of oscillating signals of 125 +-5 . This did produce a sound, but not as clear as the example being played. The idea was scrapped and we switched the DAC code to match periph_dac. Then under the APP_POLLING_TEST function we increased the frequency marginally to maintain a oscillating signal while broadcasting. Finally, we used a frequency tuner to find out whether the frequencies were increasing in correct order to which we found out they were twice the previous frequency. When we modified the DAC code into our project, we tested hex values from the example DAC code that we knew the frequency of, but the same sound wasn't being reflected in our project.

LED Matrix Display:

We had soldering problems :/. The code required 8 rows *2 (one for red and green) and each row contained 8 bits which corresponds to 8 columns. It took us a while to figure out how to configure patterns correctly. Due to soldering problems the top 2 leds on the left were on the whole time in displaying red.

LED Segment Display:

A resistor was required to be placed into the pin that powered the segment display. Not knowing this led us to burn out 2 spare segment displays. Grounding all the pins that correspond to each segment set the default segment display to all on (displaying a 8 in this case). Knowing this we found which pins were needed to be turned off in order to produce all the range of notes we were playing efficiently. Which required 4 GPIO pins.

Combining all the parts:

When we were combining all the parts together, we had a problem of consistently playing frequency notes loud and clear. The sound was extremely choppy and depended on the number of loops the while loops runs. The longer the loop runs the better the frequency sounded. We had to find a good compromise in order to maintain functionality. Still, the frequency notes were not as clear as the DAC example.