January 14, 2014 (1 hour):
We met as a team after class to discuss preliminary project proposal. Initial ideas for a project include a music grid as well
as a security system. A security system was chosen with flexibility in mind when picking different parts for sensors like heat, sound, and motion.
January 16, 2014 (3 hours):
We met as a team after class to finish writing preliminary project proposal. Project research was put together to finish up
the homework for this week.
WEEK 01 SUMMARY
Accomplishments: The team submitted a preliminary project proposal for the security system idea.
Weekly Work Total: 4 hours
Project Work Total: 4 hours
January 22, 2014 (2 hours):
We met as a team to divide up the work for homework 1 final project proposal and setup the website. Team roles were decided with
Kevin as the project leader, Brennan as the hardware engineer, Ben as the systems engineer, and Jonah as the software engineer. Each of the professional component homeworks were
divided accordingly as well. A preliminary schedule was created that outlined the workload for each week and different assignments and due dates. Further discussions will need to be
made for budgeting and project research.
January 25, 2014 (5 hours):
We met as a team to revise and finish the final project proposal. Project has changed from a security system to a music grid.
Revisions consisted of conceptualizing the new project idea, brainstorming different components required, and budget costs. Details of the new project include having an 8x8 grid
LED with push buttons that will output varying tones. Variations of colors will light up on the corresponding square on the grid based on the tone that is produced. Users will
have the ability to generate their own music on this grid as well as save and load configurations. An LCD will be used to interface with the grid to interact with the user for
saving and loading. A webapp will be considered to have another method of interaction with the music grid. There is a
software version of the project on the internet.
January 26, 2014 (2 hours):
The group meeting today consisted of finalizing the group schedule and homework. Updates on the team webpage were made to
organize information about notebooks, miscellaneous documents, datasheets, and schematics. We also continued to research parts for use to make the music grid. Some products on
the market available consisted of pre-soldered LEDs on a circuit board.
WEEK 02 SUMMARY
Accomplishments: The project specific success criteria and new project proposals were finalized. The home page of the project was updated to be more
organized and structured with working links.
Weekly Work Total: 9 hours
Project Work Total: 13 hours
January 29, 2014 (4 hours):
Because of the project proposal revision from last week, we met up this week to revise homework 0 with patent research and
market analysis on our music grid project. Market analysis determined that there wasn't a cheap solution to music learning on dedicated hardware. One product required interfacing
a LED grid to a computer in order to make music. Our product would be a much more cheaper alternative that would be simple and easy to use for people of all ages without any need
for external interfacing. Also, the PSSCs were revised to be a bit more challenging which includes saving an audio file to an SD card or USB. Different product materials were
considered to make the LED grid, one of which had built in LEDs on a grid to make soldering wires unnecessary.
January 30, 2014 (4 hours):
Today, work was focused on finishing the individual PCB tutorial required for each team member. The homework assignment
consisted of creating a schematic using specific parts from the Eagle library as well as custom made parts. Following the creation of the schematic, a PCB layout was created with
traces routed to each electrical part on the board.
WEEK 03 SUMMARY
Accomplishments: This week, the individual PCB asssignment was completed with all the team members doing revised market analysis and patent research.
Weekly Work Total: 8
Project Work Total: 21
February 3, 2014 (3.5 hours):
The team discussed part ordering for the music grid. Obvious parts to order for the project included LEDs, speakers, and
pushbuttons. A list of interfaces was also generated as well as design constraints such as power, speed, and memory capacity. The microcontroller that was picked out for
prototyping had 256KB worth of flash so it was necessary to know how much memory would be required to store audio samples.
February 5, 2014 (2 hours):
We went over the design constraints of the project itself including the necessary frames per second an LED must flash in
order to maintain a persistence of vision. We had decided that it would be beneficial to have the LEDs flash at the minimum, thirty frames per second. This would be fast enough for
the human eye to continue to see a solid color.
February 6, 2014 (2 hours):
We calculated the amount of memory required to store 8 various tones on flash. Saving and loading to flash was made a PSSC,
and it was ultimately decided to discard the use of a Raspberry Pi. The team was hesistant about the Raspberry Pi because of the required work possibly needed to additional interface
it along with the mobile application to interact with the music grid.
WEEK 04 SUMMARY
Accomplishments: We made a list of parts for ordering that would fit within the project budget. Design constraints, theoretical voltage and current requirements
were documented for the music grid.
Weekly Work Total: 7.5
Project Work Total: 28.5
February 11, 2014:
Currently out of town for a job interview, Brennan had given me the preliminary sketch of what the music grid packaging could
possibly look like. I had given my acknowledgement of the design.
February 13, 2014 (3.5 hours):
We went over and detailed the drawings for the PCB and the packaging itself. Also, we researched further into another 4-line LCD that
is serial and uses SPI. This would be helpful in saving the amount of pins that would be used on the microcontroller. Here is an example packaging that is similar to what our team is
envisioning for our final product.
http://www.engadget.com/2006/04/14/music-thing-monome-controller/
WEEK 05 SUMMARY
Accomplishments: The initial PCB design and packaging was created. A few revisions were made to the packaging designs itself.
Weekly Work Total: 3.5
Project Work Total: 32
February 17, 2014 (4 hours):
The parts that the team ordered for the music grid arrived. Work today comprised of prototyping the project with
some theoretical work. An example of this is figuring out a method in which to control volume. The speaker volume was very low and needed an op amp circuit to amplify the sound
to make it louder. A rotary pulse generator was considered to control the volume. A digital-analog converter would convert and output analog signals to the amplifier.
February 18, 2014 (3 hours):
Custom parts were compiled into a library on Eagle to make the schematic. Also, since the RGB LEDs and the four breakout
boards were available, work was done to start soldering the LEDs onto the board. This proved to be very time consuming as the board had sixteen of four holes with the padding
very close to each other. Testing on each LED would have to be done to make sure that there were not any connections made between the pins after soldering.
February 19, 2014 (5 hours):
Finally, the boards were finished with soldering. With four of the SparkFun BreakOut boards, a total of sixty-four RBG
LEDs were capable of being soldered on. Another sixty-four 1N4148 diodes were needed to prevent ghosting when using an LED matrix. The pins were clipped from both the RGB LEDs
and the diodes.
February 20, 2014 (3 hours):
Today our team continued to design the schematic while ordering the rest of the parts. Half inch hollow tubes from the
parts cabinet were found that would be ideal to use in holding the board together with the rubber pushbuttons. These tubings had small screw threads inside for screws to be
inserted. Both the board and the rubber material had these holes used to bind them together. The only issue was that the connection pins soldered onto the board had solder that
laid between the rubber and board. This caused to the board to have some inconsistencies after binding the rubber to it. The solder had to be filed down very flat so that the
bumps on the edge of the board were minimal.
WEEK 06 SUMMARY
Accomplishments: A schematic layout was created for the project. The breakout boards were soldered to the RGB LEDs and diodes. Software development
will begin soon next week using Code Composer Studio to prototype and test the shift registers, LCD, and DAC.
Weekly Work Total: 15
Project Work Total: 47
February 24, 2014 (4 hours):
Today consisted of setting up Code Composer Studio to work with our Stellaris TI microcontroller on the lab computer.
Texas Instruments uses Code Composer Studio as their preferred integrated development environment for a lot of their embedded processors. During the installation process however,
there were some issues with library imports for the microcontroller because TI was phasing out the Stellaris library in favor of the Tiva brand. Some specific files were downloaded
that were missing from CCS. This included ccs-cm4f driver files that were needed to call functions to enable different ports on the microcontroller. Fortunately, the missing
Stellaris driver files were able to be located and installed via an open-source GitHub repository.
The Stellaris LaunchPad Tutorial files used can be found on the team website located here.
February 25, 2014 (5 hours):
Because other team members needed to use the lab computer for the PCB layout design, the process of installing Code
Composer Studio was duplicated onto a personal laptop. Initial setup required quite a few detailed steps in order to communicate with the Stellaris LaunchPad:
First Step: Code Composer Studio is the IDE (integrated development environment) used to program the Stellaris LaunchPad. It was downloaded from the
TI website.
Second Step: StellarisWare, LM Flash Programmer, ICDI Drivers, Workshop Lab Files, and PuTTY are required to be installed next along side CCS.
Third Step: One of the driver libraries within StellarisWare, ccs-cm4f, is absent from the default package installation. It can be found
here. The folder belongs in C:\StellarisWare\driverlib.
Fourth Step: After opening CCS and making a new CCS project, the compiler and linker need specific file paths to the driver library that was installed in StellarisWare.
The compiler needs ${PROJECT_ROOT}/../../../ and the linker needs ${PROJECT_ROOT}/../../../../driverlib/ccs-cm4f/Debug/driverlib-cm4f.lib.
After testing out some example programs on the Stellaris, the CCS environment feels very similar to Eclipse. All the regular debug tools are there for stepping in,
inserting breaking points, and analyzing variables values are there to help.
Loading a pre-existing CCS Project requires the user to click "Import Existing CCS Eclipse Project" under the Project tab. The directory should be listed as
C:\StellarisWare\boards\MyLaunchPadBoard\Lab. The window will display discovered projects check marked and clicking finish will load the project.
February 26, 2014 (5 hours):
Work was continued on trying to transmit data to a 595 shift register and light up red LEDs via SPI on the Stellaris
LaunchPad for testing purposes. There are four specific pins on the microcontroller, SSI0_CLK, SSI0_FSS, SSI0_RX, and SSI0_TX, that are used for SPI. CCS does not
automatically recognize the name of the pin in which one is using even after including the pin_map.h header file. Define statements for each pin and their corresponding
hex values must be declared under the include statements of C code. The port/pin mapping definitions for the SSI pins can be located directly in the pin_map.h file itself by
searching for definitions corresponding to the correct microcontroller (in this case the LM4F120H5QR model).
Currently, no apparent data can be seen that is transferred over
to the shift register and lighting up the LEDs. Tools used to debug the issue included stepping through code written to utilize SPI and painstakingly reading descriptions
of various function calls for SPI configuration.
On a side note, the following TI link is useful for debugging issues that occur during
compilation of code with CCS.
February 27, 2014 (5 hours):
Today, we figured out how to use SPI on the microcontroller to drive LEDs with 595 shift registers. Since we are only
using the microcontroller to send data to a slave device, only three pins (SSI0_CLK, SSI0_FSS, SSI0_TX) are required.
Below are the correct pin-to-pin connections for future reference when using SPI:
SER -> PA5
OE -> GND
RCLK -> PA3
SRCLK -> PA2
SRCLR -> VCC
QH' -> SER (when daisy chaining shift registers)
Currently, two 595 shift registers are daisy chained together for prototyping purposes. The final design has eight columns with four pins for red, green, blue, and ground.
8 x 4 = 32 bits that are required to represent all the LEDs on the grid.
32 bits / 8 bit shift register = 4 shift registers daisy chained
Each red LED draws roughly 5.25 mA. Using a digital multimeter, eight red LEDs requires 42 mA. Thus, 42 mA is required to light up one whole column on the grid.
More peripheral prototyping will be continued on this week and next week.
WEEK 07 SUMMARY
Accomplishments: This week comprised of the initial testing and prototyping with the microcontroller. A lot of time was given to get acustom to and
learning how to program with peripherals after setting up Code Composer Studio. The team has begun preparations for the midterm review by practicing for
presentations and creating a powerpoint.
Weekly Work Total: 19
Project Work Total: 66
March 2, 2014 (4 hours):
Initial work began on interfacing the digital analog converter (DAC) and trying to send data through it via I2C. For testing,
an oscilloscope was used to measure Vout for analog output signal.
A flowchart has been designed that outlines the basic behavior of the music grid. Initial phase begins
with a soft reset. A soft reset consists of an LCD reset, Beat logo display, and a sound reset. The user will be prompted on the LCD for a loading configuration if they have any
saved on to flash. If they select YES, the microcontroller will load their configurations and start the normal looping routine. If not, then it will skip to the normal looping
routine. This routine will poll each column for button toggles. If a button was off previously and the button is pressed, it will toggle on and vice-versa. Next, buttons will be
polled for being on. Audio will be played accordingly if so. The music grid will check to see if the user has selected to exit the normal loop state. If they do not select
anything, it will continue to the next column in the regular routine. If they user selects YES, it will ask the user if they want to save their current configurations. If
not, it will proceed to the soft reset phase.
March 3, 2014 (4 hours):
Our team made preparations for the midterm review presentations. Powerpoint slides highlighted project functionality,
schematics, PCB layout, software design, and future development schedule. Each team member was in charge of a portion of the slides. Practicing for the presentation included
mock presentations with timing and anticipating possible questions after the review.
March 5, 2014 (5 hours):
The digital analog converter that will be used to output to the amplifier uses I2C protocol to transmit data. One of the main
reasons for choosing an I2C DAC was because it only required two pins on the microcontroller as opposed to four pins on an SPI DAC. The I2C also included a high-speed mode which
would allow data to be sent at 3.4 MHz. In order to test the DAC, an oscilloscope was used to measure the voltage out. The circuit required for I2C needed two pull-up resistors in
order for the clock and data line to pull their respective lines low.
http://en.wikipedia.org/wiki/Pull-up_resistor
In theory, I2C works by having the master device send out the address of the specific slave it wants to talk to. After a handshaking protocol in which the slave acknowledges the
master's request, the master will initiate data transfer by holding the clock and data lines high and then dropping the data line low. The master device is the one who clocks the
data transfer. Holding the clock high and the data line low, a rising edge on the data line indicates the end of a transfer and an acknowledgement that verifies its correct
completion.
http://www-ee.eng.hawaii.edu/~tep/EE260/Secret/i2c_transfer.gif
Interfacing the DAC with I2C and transmitting data proved to be more difficult than was previously thought.
During the debugging process, clock and data lines remained high while Vout showed no signs of variation. Breakpoints sent throughout the code written revealed that the slave did not
receive nor acknowledge any data transfer. All the pin initializations for the protocol appear to be correct but the data transfer has not been working. Perhaps there may be an issue
with the DAC that was soldered. At this point, the best plan of action is to either solder another DAC and test that out or order an SPI driven DAC.
March 6, 2014 (3 hours):
Issues with testing I2C on the DAC brought about ordering DACs that used SPI instead. DAC testing was critical as that prototyping
had to be done before spring break since the PCB design would have to be completed then. Initial reasons cited for using I2C DACs included lesser pinouts and a supported high-speed mode
that would enable data to be transferred quickly for audio samples. However, if the SPI DACs can be tested successfully instead, it would assure that that part would work accordingly before the PCB
has been produced and ready to solder. The only drawback to the SPI DAC is that it requires four pins (clock, select, transfer, receive) as opposed to the clock and data of I2C. This
would mean that the PCB traces would have to be rearranged again to fit the new DAC. Otherwise, this DAC will run at 10MHz which proves to be far better than the high-speed mode of I2C.
Samples from TI were ordered with overnight shipping. They should hopefully arrive Monday for prototyping.
WEEK 08 SUMMARY
Accomplishments: This week our team was able to present our project for the midterm design review. The feedback received will help in tweaking the design of
the PCB. A software flow chart was created to outline the basic behavior of the music grid; it will be further developed later on as software development progression
continues. Long hours of testing the DAC and I2C have been perplexing and another alternative SPI DAC may be needed.
Weekly Work Total: 16
Project Work Total: 82
March 9, 2014 (3.5 hours):
Testing with I2C appears to have worked when making both the master and slave modules on the microcontroller; thus, this means that the
microcontroller is talking to itself. This was done solely for debugging purposes and making sure I2C was working correctly first. By instantiating two arrays ulDataTx for transferring and
ulDataRx for receiving, one could see the process in which I2C moved the data from ulDataTx to ulDataRx. The debugger allowed for stepping through each call of putting data on the line and
sending it. A couple of things to note include a line of code that makes the master wait until the slave acknowledges that the data has been received successfully.
The next step is to
make sure the microcontroller is talking to the DAC by analyzing the signals on the logic analyzer. The SPI DACs also appeared to have arrived today.
March 10, 2014 (3.5 hours):
While I2C seems to be working with the microcontroller talking to itself, it still does not output clock signals when measured via the
oscilloscope. One possible hypothesis was that one of the ports on the Stellaris was not working correctly. An attempt to troubleshoot the issue, another I2C port was used but this did not
work as well. Online suggestions noted a range of values between 4.7k to 10k were suited for pull-up resistors. We will have to test out various resistors to see if that is part of the issue.
March 11, 2014 (2.5 hours):
The microcontroller was able to successfully output I2C signals to the DAC. Using the oscilloscope, the digital signals from the clock and
data can be seen in the picture below.
D0 is the clock line, and D1 is the data line. Port one (yellow) and port four (red) also showed consistent behavior with the clock and data. One notable
change required was the value of the pull-up resistors being used for clock and data. Two 1k resistors were previously used and were switched out for 4.7k resistors. Resistors of value 10k work
well as pull-up resistors too. An important note to mention about the program code is the necessity of a delay after calling I2CMasterInitExpClk, the function that sets the speed of the bus and
turns on the master module. This delay will assure that I2CMasterSlaveAddrSet sets the correct slave address in time. Also, while(I2CMasterBusy()) line must be used after a start and finish signal
to assure the integrity of the data bus.
WEEK 09 SUMMARY
Accomplishments: This week consisted of further troubleshooting with I2C. An SPI DAC was going to be used as backup if I2C wasn't working before the final PCB layout
submission. However, the Stellaris microcontroller has sucessfully outputted sample data on a clock line using one of the I2C ports now. The next step is to make sure that the
DAC acknowledges the data that is being received and is communicating correctly.
Weekly Work Total: 9.5
Project Work Total: 91.5
WEEK 10 SUMMARY
Accomplishments: THIS WEEK IS SPRING BREAK.
Weekly Work Total: 9.5
Project Work Total: 91.5
March 25, 2014 (4.5 hours):
In order for the DAC to acknowledge the data sent from the microcontroller, it requires the microcontroller to send a specific 7-bit slave address
specified in DAC technical documentation. The first five bits, starting from the most significant bit, is always 10011. The sixth bit, A0, is dependent on whether A0 on the DAC is tied to ground or VCC.
In our design, it is tied to ground and thus, A0 is 0. The seventh bit is defaulted to 0. Turning 1001100 to hexadecimal, 0x4C is used as the address parameter in the function call I2CMasterSlaveAddrSet to
talk to the DAC. After acknowledging the slave address, the DAC requires a control byte to know what function to do, e.g. power off the DAC or writing data to registers.
One of the issues that had come up was conflicting information within the technical documentation between the microcontroller and the DAC about I2C slave addresses. The DAC had specified 8 bits where the
least significant bit is the read/write select for the slave address. However, the documentation for the microcontroller specified only 7 bits for the slave address. Thus, initially the microcontroller was
sending an address of 0x98 to a non-existent slave.
The correct address is 0x4C. This is shown below in the oscilloscope capture where there is no missing acknowledgement bit seen as the data is being
transferred over.
March 26, 2014 (2 hours):
After some trial and error programming, the oscilloscope readings from Vout of the DAC seem to show that it is acknowledging the data transfer from the
Tiva, storing it in its registers, and outputting those values out to Vout. Something to take note of is that the Tiva requires a 7-bit slave address before any transfer occurs. After initializing
that, the Tiva must send out an 8-bit slave address corresponding to the DAC with the least significant bit being zero for writing. A control byte comes next which tells the DAC to store the data in its
registers and output the value of the data that will come in. The next two bytes are the high and low byte respectively of what data value the user wishes to send to the 16-bit DAC.
As one can see, a high byte and low byte set to 0xFF will correspond to the maximum VCC. In this case, VCC is 3.3V and the oscilloscope readings show that.
The next image shows the high byte and low byte set to 0x00 and this corresponds to 0V on the oscilloscope.
March 28, 2014 (12 hours):
The software narrative that is being written details the high level functionality of Beat Square. Beat Square will be driven with a timed interrupt.
Because there is an option to adjust the tempo of the beat, one consideration was to use polling. Extracting the time from the system clock, the length of time between each poll would vary based on the value
of the tempo. As the tempo gets higher, the intervals between polling would get shorter and vice versa. However, it was decided that using a timed interrupt would be a more precise method. By setting the timer
interrupt at its highest rate, it will call the functions to light the LEDs and play audio only when the tempo flag is high. This flag correlates to the current tempo that is set; otherwise the interrupt does
not take any action. User input will also have to be read via timer interrupt as well because data is passed through a shift register and it cannot be read from an external interrupt asynchronously.
WEEK 11 SUMMARY
Accomplishments: The slave acknowledges the data transfer from the Tiva. Oscilloscope measurements on Vout of the DAC appear to correlate to the data that is being sent from the
microcontroller. We will need to test the push button matrix with the microcontroller next and solder parts to the PCB. The software narrative outlines the structure of the program that will
be written.
Weekly Work Total: 18.5
Project Work Total: 110
April 1, 2014 (4 hours):
Using a Blackhawk XDS100v2 ARM JTAG connected to the cortex debugger header pins, a connection test was ran to assure that the JTAG was properly oriented.
Shown below, the test target configuration output shows a good connection.
One of the issues that came about from trying to program the Tiva was a linking error on Code Composer Studio. The startup_ccs.c and tm4c123gh6pm_startup_ccs.c files within the project were conflicting with each
other because they had instantiations of the same functions in them. Excluding one of the files out of the build fixes the problem. A sample program was written to test the heartbeat sensor on the PCB. This would
assure that the microcontroller was functioning correctly. One thing to take note of, in order to light up the heartbeat sensor, the GPIO pin must output a 1 on the fourth bit; otherwise the LED will not light up.
The image below shows the LED strobing with sample code.
April 2, 2014 (5 hours):
The Stellaris microcontroller has a SW1 button that can be used as a programmable input. It was used to test out the voltage output of the DAC. The software was
programmed so that when the button was held down or pushed, the value of the voltage that the DAC outputted would increase until 3.3V. At 3.3V, it would drop back down to 0V and repeat the process. This test helps
prototype the DAC before the RPGs are soldered onto the PCB. After the RPGs are put in place and soldered on, the DAC can be properly tested with them.
April 3, 2014 (4 hours):
The DAC needs to output a sine wave so that the signal can be analyzed with the spectrum analyzer. The data used from the spectrum analyzer will be used to create
a proper low-pass filter for audio production.
Also, prototyping with flash on the Stellaris has been in progress. Using the built-in memory browser tool, the contents within flash can be analyzed while code is
being executed to read / write to flash. In order to clear the memory in flash, ones are set to all the bits. Writing to flash consists of only writing zeroes.
WEEK 12 SUMMARY
Accomplishments: Code ported over from Stellaris prototyping works on the Tiva. The Tiva microcontroller is working correctly from the output of the heartbeat sensor. Next week, the DAC
will need to be prototyped with a sine wave so that audio can be tested properly. Flash programming is in progress.
Weekly Work Total: 13
Project Work Total: 123
April 7, 2014 (4 hours):
Current code is pushed to a new repository of a GitHub account. This will allow other team members to use and edit the code as well as create a backup. Testing is
currently going with the microcontroller and producing a 440 Hz sine wave. This sine wave will be used to produce some sample audio from the speakers. The code composer sine wave generator produces a set of points in
32-bit floating point values. These 32-bit floating point values will need to be truncated to 16-bits for the DAC to take in. With the 16-bits, we will also have to send the data two-bytes at a time as the DAC takes
in the higher byte and then the lower byte before it outputs a voltage level. These data values will need to be converted to hexadecimal.
April 8, 2014 (2 hours):
Brennan and I have been working on taking a sine wave and trying to quantize data points in order to send it through to the DAC. One of the issues encountered with
this was setting the limits of the sine wave to be between the range of 0 - 3.3 volts since this is our voltage capacity for the DAC. MATLAB was used to plot the sine waves of C4, D4, E4, G4, A4, C5, D5, and E5 and
scale it to 3.3 V range. These sine waves are musical notes are referred to in scientific pitch notation and based off the pentatonic scale. This musical scale contains five notes per octave. The number of samples
taken for each signal was 250 in integer form. The raw data taken will need to be formatted with commas in order to declare an array with them in C code.
April 10, 2014 (4 hours):
Using a Python script to generate a comma separated list of quantized values, we are outputting their respective hex values to the DAC and measured it through the oscilloscope.
In theory, it should be a sine wave, but that is not what is appearing as output. For the code to send the data samples in 16-bit hex, the high byte is extracted by shifting the data right by 8 bits and bitwise anding it with
0xFF to assure that what is left is only 8 bits. The low byte is taken from the original data by simply bitwise adding 0xFF. The output from the oscilloscope shows an irregular shaped wave with unusual dips in between.
The samples of data were plotted again to make sure that it was indeed an actual sine wave. The screenshots below show a failed attempt at generating the sine waves. One attempt at fixing the issue at hand was inserting
a decoupling capacitor to try to reduce any noise within the circuit. However, we will continue to troubleshoot this issue with the DAC as audio production can not move forward otherwise.
Below, the yellow signal represents Vout from the DAC. The blue signal is the I2C clock, and the red signal is the digital output from the microcontroller to the DAC. As one can see, the DAC loves to behave
irrationally.
April 11, 2014 (4 hours):
Using the Tiva microcontroller to program the matrix LED, I have attempted to produce a pattern of flashing LEDs using the SPI module that it is connected to. However,
the matrix was not lighting up. It turns out that I had enabled Port A of the microcontroller when in fact, the matrix was connected to Port B. Observing the lights from the LED matrix. They appear to be very dim. The
rubber cover on top contributes to the opacity, but I believe that the primary reason they are dim is because of our current limiting resistors that are placed between the shift registers and the LED matrix. The more LEDs
that the user lights up on the matrix, the dimmer each LED gets. The matrix must be lacking constant current to drive the entire board. For now, our team members have decided to leave the resistors on the board. They may
possibly be removed once the project is fully functional.
WEEK 13 SUMMARY
Accomplishments: Musical notes C4, D4, E4, G4, A4, C5, D5, E5 on the pentatonic scale were selected to be quantized in MATLAB in order to give to the DAC. The output from the oscilloscope of the C4 data samples do not
correspond to a proper sine wave. More troubleshooting will have to be done to figure out why there is a distortion in the wave. Initial programming has been done to try to get the LED matrix working.
This will continue on throughout next week in order to fulfill one of the PSSCs set for Beat Square.
Weekly Work Total: 14
Project Work Total: 137
April 13, 2014 (4 hours):
Analyzing the environmental and ethical effects of manufacturing Beat Square, some of the waste material produced as part of the production in making the PCB, LEDs,
and LCDs from factories commonly cause contamination to the local community. Hydroflurocarbons used in LCD manufacturing are known to cause ozone layer depletion. The largest ethical concern in making Beat Square as a
marketable product is its potential ability to cause seizures among consumers. Beat Square can flash its LEDs at a frequency known to trigger seizures at around 2-4 Hz. The environmental and ethical analysis paper is largely
completed for Beat Square at this point.
April 14, 2014 (5.5 hours):
While working on programming the matrix, one point to take note of is the fact that the board common anode. To light up the first row, one would have to send voltage to
row one and connect all the columns to ground. If any columns were fed voltage, the corresponding button on that column would not light up despite row one having positive voltage. In our PCB, the shift registers are lined up so
that red shifts to green, green shifts to blue, and blue shifts to ground. In total, there are 32-bits of data that needs to be shifted out. To program our previous example of lighting up the first row in red, the binary representation
would be 10000000 00000000 00000000 00000000 or 0x80000000 in hex. The most significant bit represents the first row in red. Continuous testing shows multiple colors flashing rapidly across the matrix. It turns out that the PCB wires
for RCLK and SCLK on the 595 shift registers are tied together. This causes the shifted output to display on the LEDs. This is an issue because we do not want the data to be displayed on the LEDs until all 32-bits of data are shifted in.
The alternative option here is to bit-bang the data into the matrix and controlling the active-low output enable pin on the shift register whenever the data is fully shifted in.
April 15, 2014 (4 hours):
Kevin is currently programming and testing on the Tiva. I have moved my code over to the Stellaris to continue prototyping on the matrix LED. Because RCLK and SCLK are tied on
the PCB, I am programming the output enable line manually and bit-banging the data to show the LEDs only when all 32-bits are shifted in properly. Otherwise, output enable remains high (it is an active low signal). I have met with some
irrational behavior coming from the matrix while connected to the Stellaris microcontroller. Whenever the user puts their hand within one to two inches of the boards surface, the LEDs will light up. When the user takes their hand away
from the board, the lights cease to output. While it is a very interesting feature, it is not a PSSC and is considered a bug for our intents and purposes.
April 16, 2014 (3 hours):
Upon testing the LCD, work was done to output a sample screen to the user. For Beat Square, the main screen will prompt the user to save or load their LED configuration to flash,
store their configuration to an SD card in the form of a MIDI file, or perform a software reset of the whole board. These options are shown in the screenshot below with the four options corresponding to one of the four push buttons.
The LCD has four lines for text. To program to each line, one must enter in a print function their string followed by the line they wish to print to. Currently, the push buttons are not soldered on a protoboard yet, and thus are not
ready for functional testing with the LCD.
April 18, 2014 (2 hours):
Switching back to working on audio, the DAC is currently running at a rate of 333 kHz. This is not sufficient enough for our speaker to output the sine wave that is desired. Since
sine waves inherently do not contain as much energy as a square wave if they have the same peak-to-peak voltage, they require a higher clock speed to have audible effects. The DAC and Tiva microcontroller have the ability to run at
high speed mode which is 3.33 MHz. The issue is setting the proper registers with the right code so that high-speed mode is enabled. Documentation for doing so hasn't been very helpful and there is no example test code from Texas
Instruments that demonstrates it. Another caveat of the DAC is that once the transmission has ended for data transfer, it will revert back to normal operation speeds (around 100 kHz). Thus, high speed mode has to be re-enabled every
time transmission is halted. Currently, the team has decided that it may be much easier to go with square waves rather than sine waves. Ultimately, if high speed mode cannot be achieved within the next couple days, a square wave may be
used instead.
April 19, 2014 (4 hours):
The microcontroller is able to output high speed mode now. In order to run at that speed, the master device must initiate a start condition with the DAC and send it its high
speed code 00001XXX. The critical part is forcing the DAC to NACK the code the master sends because no device is suppose to ACK it. This requires the use of the I2CSlaveACKOverride function which allows the master to
override any ACKs or NACKs from the DAC. Using I2CSlaveACKValueSet, the master can set the acknowledge bit to false so the DAC NACKs. Compiling the code and measuring the frequency of the transfer through the oscilloscope,
it can be seen as roughly 2.778 MHz. However, the big issue here is that the DAC will not respond nor output data sent by the Stellaris.
WEEK 14 SUMMARY
Accomplishments: This week, software for the LED matrix was coded so that it would light up a pattern. The LCD was prototyped to display a selection screen for the user to choose whether they want
to read or write to flash, write to MIDI on an SD card, or do a soft reset. The microcontroller clocks at high-speed mode; however, the DAC does not respond back to the microcontroller. The next step is to
re-establish connection and produce multi-tone audio on the speakers.
Weekly Work Total: 22.5
Project Work Total: 159.5
April 21, 2014 (5 hours):
After doing further research, I2CSlaveACKOverride and I2CSlaveACKValueSet should be set to the slave base address. It was set accidentally to the master base address. Today
the ability to clock at 3.3 MHz could not be replicated for unknown reasons. Basic troubleshooting was done to try and relieve the problem such as replugging the USB to the Stellaris and re-opening Code Composer but to of no
avail. One success of the day was the ability to output the sine wave for C4 and D4. Running at fast mode (400 kbps), the frequency slows down significantly. The 250 data samples of the sine wave are more than a period's worth
and so data will have to be omitted to produce a perfect sine wave.
Below is the sine wave for C4 on the oscilloscope (note that it is not perfect because the DAC is outputting data samples longer than one period).
Below is the sine wave for D4 on the oscilloscope (note that it is not perfect because the DAC is outputting data samples longer than one period).
April 22, 2014 (6 hours):
Truncating the 250 data samples down to 170 samples, a perfect sine wave can be generated on the DAC. However, the sine wave frequency is too low when outputted and high
speed mode doesn't work anymore for unknown reasons. Our alternative is using a square wave to output multi-tone audio. We could also use a sawtooth signal as well.
April 23, 2014 (2 hours):
The microcontroller is able to output a sine wave over 1 MHz now. This is significant enough to produce an audible note. One of the functions used to calculate the clock
divisor was altered so that it would divide by 1 no matter what. The pull-up resistor was changed to a lower value (1.5K) to allow the microcontroller to clock at a higher rate. Upon testing more with the sine wave sample, it
is noted that multiple pitches can be produced by skipping data points. The more data points the programmer skips, the higher the pitch is. Our initial 170 data samples of one sine wave period is proving to be less than what may be
needed to output lower notes. An estimate of 1000 data samples may be needed to generate notes starting from C4.
April 24, 2014 (1 hour):
Without using an interrupt, some notes would not be produced repeatedly when using a while loop. It would "beep" once and stop. Using the timer interrupt, calling the function
that produces a sine wave successfully outputs an audible sound. Multiple pitches were tested by trial-and-error; data samples were incremented at different lengths and sent to the DAC. A very high sounding note, for example, would
require one data sample to be sent to the DAC for every fifteen samples. (x = 0; x < PERIOD; x = x + 15) and data[x] gets sent to the DAC.
April 25, 2014 (2.5 hours):
I am able to manipulate the volume and tempo of a note. The sine data samples quantized for the DAC are set at maximum volume because the amplitude is 3.3 volts. In order to
lower the volume, all that needs to be done is a simple division of the data sample. The higher the divisor, the lower the volume becomes. The tempo is manipulated with the change in the frequency of the timer interrupt. The next
order of business is to produce multi-tone audio which requires outputting multiple notes in sync. This may simply be an addition of sine waves and dividing by two.
WEEK 15 SUMMARY
Accomplishments: This week, we are able to successfully output a sine wave from the DAC in high speed mode (3.3 MHz). The notes are audible and program code for manipulating the volume and tempo also work
as well on the Stellaris microcontroller. Multi-tone audio is the next task to complete and soldering the amplifier and speakers onto the PCB.
Weekly Work Total: 16.5
Project Work Total: 176
April 28, 2014 (4 hours):
Using the 1000 samples of data that had been re-collected from MATLAB, Ben and I have attempted to tune the samples to their corresponding notes on the pentatonic scale by hand.
With the waveform generator set at varying frequencies on a sine wave, I would output different intervals of data samples to see if they would match up to the sound produced by the waveform generator. Below are the
corresponding frequencies that were used (C4 to E5) to match the output of the DAC.
http://www.guitarpitchshifter.com/pitchshifting.html
April 29, 2014 (4 hours):
I am testing with a saw-tooth wave because it has a lot more energy than a sine wave. Working to produce multi-tone audio, the theoretical approach (which almost always never
translates to practical success in my experience) is to take the number of sine waves that one may wish to output, sum them up, and divide by the number notes. The result should be a beautiful sounding chord produced from multiple
notes. In this case, the audible sound that came from the DAC was not very pleasing. One of the many reasons for this may be because sine waves that are out of tone are being added up and do not correspond to a nice note.
May 1, 2014 (6 hours):
With a team consensus, it was decided that tonight would be the last attempt to try and produce multi-tone audio for Beat Square. The difficulties lie within the problem that audio
production requires a very large amount of cycles from the microcontroller. The program has to loop through a peroid of data samples and continue to iterate through this period 500 times continuously for the user to hear anything
audible. The delay this produces can be seen when audio is played from the speakers and the LEDs on the board flicker off for a split-second. In hindsight, it would have been beneficial in our design to include two microcontrollers:
one for implementing audio, and another to handle the LEDs and LCD.
Upon programming the audio into Beat Square, the push buttons for the LCD and rotary encoders ceased to function properly. The second, third, and fourth push
buttons would behave the same, rendering it to essentially two push buttons that work. An attempt to route this problem used a cycling method in programming the push buttons. The first push button would cycle through the save, load,
MIDI, and audio functions (audio settings replaced reset since there was already another reset button next to the power switch) while the second push button would be the selector. The LCD would sometimes display garbage due to some
unset variables within the program. Even though the volume and tempo can be changed, the MIDI functionality has stopped working. At this point, I am unable to fulfill the next PSSC without fixing the old ones.
May 2, 2014 (2 hours):
Our team prepared for the Senior design showcase in the MSEE atrium. We had setup our Beat Square project powered on and along side the software application in another laptop for ease
of demonstration. We also ate Mad Mushroom pizza courtesy of the ECE 477 staff.
WEEK 16 SUMMARY
Accomplishments: While volume and tempo do technically work on the Tiva microcontroller, some functions of Beat Square failed to continue to work as before and so this PSSC may not be fulfilled. A total of
three out of the five PSSCs are able to be achieved within the current timespan. Our team's final tasks are to write up the remaining project documentations and do the final presentation.
Weekly Work Total: 16
Project Work Total: 192
