Minutes Dated Wednesday February 29, 2012 09:00 PM
PCB is working, Writing the report
Location: AK 227
At this moment, Brandon and I have successfully hotwired the PCB to work with the 8x8 matrix despite our issue with all the pins messed up. I will be attaching files to this meeting minutes entry that are needed for our report. We will be working diligently to get the report up to par to submit it tomorrow.
As far as the PCB is concerned, the PCB is working properly. The microprocessor is working properly utilizing the row and column decoders to select a row and column to pulse. It is also working with both the 8 and 16-bit timers to scroll a message across the screen. The final working code will be uploaded at a later time.Entered by Stephen Hansen on 02/29/2012 09:05 PM
Attached Files
This PDF file has three tables which explain what pins from the microprocessor are connected to what pins on the decoders and how it allows us to use only 2 pins from the microprocessor to select one decoder to activate at a time for the columns (whether it be red, green, or blue).
Attachment Added by Stephen Hansen on 02/29/2012 09:09 PM
This is the same as the previous file for the decoder pin layouts, except it is in excel format.
Attachment Added by Stephen Hansen on 02/29/2012 09:12 PM
End of Entry
Minutes Dated Monday February 27, 2012 12:00 PM
Working to get the PCB working
Location: AK 317
Brandon and I met in AK 317 to work on the PCB board to try and get it working. I quickly programmed the microprocessor to work with the PCB board and plugged everything in. Well, it didn't work. I probed around the PCB for a while with the Oscilloscope and found that the red column and the row decoders were both supposed to have enable pins tied to Vcc through a 1 kohm resistor. Problem is, there is not spot on the board for this 1 kohm resistor. so, we had to solder this connecting to an open pin on the microprocessor instead, and ended up soldering it to the gate of the mosfet (I'll explain while we did this soon). We also noticed that the mosfet connections for drain and source were flipped around. We ended up forgetting about the MOSFET altogether because it would be easier just using the row decoder enable pin to turn control the intensity of the LEDs we're turning on.
Even after making these changes, we noticed that all the connections for the 8x8 arrays did not line up at all with where they should go. In the multisim file, the connections appeared to be going to the correct pins, but the pins in Ultiboard were referencing a different ID number than what we were seeing in Multisim. to fix this, we will have to solder 32 wires from the PCB board to 2 breadboards holding a single 8x8 array to get the PCB working. I opened a new spreadsheet and, using the 8x8 matrix datasheet as a reference as to where the pins should be connecting to, I verified where Pin 1 on the 8x8 array was, how the two rows of pins were laid out, and used a pocket volt meter to check for a clean connection between leads on a blank PCB board from the box we ordered. I used the 8x8 array to match up the pin number for the 8x8 array to its respective color and column (or row) and used a blank PCB board to probe for where that connection actually ended up. The resulting excel sheet is attached to this minutes file. We will have the PCB working soon enough. It will look like a giant mutant spider, but it will work. I already verified that the decoders and current sinks and sources are doing what they are supposed to be doing, we just have to connect the board up properly.
I also considered a software solution, but that is not possible because none of the row pins on the PCB are connecting to row pins on the 8x8. The middle 4 pins on the top and the bottom of the rows of each 8x8 matrice's pins are the row pins, all of which are connected to various current sink transistor arrays for various colors of various columns (pins 7,8,9,10 and pins 23,24,25,26).
The attached excel spreadsheet has the actual pin connections for the PCB and shows which pins on the 8x8 they should be connecting to.Entered by Stephen Hansen on 02/27/2012 07:03 PM
Attached Links
In this link, if you change the text after "s=" from "Test" to really anything you want, you will get a 2-dimensional matrix representation of data needed to be placed on the microprocessor to scroll the text you entered across the 8x8 array. In other words, this script is the first step for future groups to use to create a giant array of these 8x8 arrays to show messages such as "Good luck with finals!" (Try entering "Good luck with finals!" It will work.)
Link Entered by Stephen Hansen on 02/27/2012 07:18 PM
Attached Files
This excel sheet shows what pins on the 8x8 should be connected to the respective pins on the PCB board in order for the board to work. It also shows what each pin is for double-checking purposes.
Attachment Added by Stephen Hansen on 02/27/2012 07:23 PM
End of Entry
Minutes Dated Sunday February 26, 2012 12:00 PM
MQP Work Accomplished 2/26/2012
Location: AK 317
Up to this point in the lab, I was able to get the Microprocessor to work with the 8-bit timer to select light intensity levels for each LED. This was simply a matter of setting the atmega8515's internal 8-bit timer up in Clear Timer on Capture (CTC) mode, selecting a clock source, enabling interrupts, and writing the ISR code for the 8-bit timer. The registers that had to be modified to get the timer to work were TCCR0 and the TIMSK registers. TCCR0 is the configuration register for timer 0 (the 8-bit timer). This register was used to select the internal clock source predivided by 8 as well as setting up the timer in CTC mode. The code attached to this minutes file uses the ISR macro to create the ISR code and put the start address of the ISR into its appropriate interrupt vector location. Initially, we used a static 8x8 pattern to test the timer, and by setting the maximum predivided delay time to 60 (60 ticks of the CPU clock divided by 8), we were able to acquire a fairly consistent 65 Hz refresh rate for a single LED display matrix. I also noticed that it was necessary to specifiy minimum color intensity values (and maximum values with ending delays). This matrix display, even though it looks like a typical part of a TV screen, it has nowhere near a total of 255*255*255 (16,581,375) different colors it can make. Its more like 40*40*40 = 64,000 different possible colors with the current CPU configuration without having the microprocessor eat up time required by the LED next to it.
After these few quirks were worked out, a variety of different patterns displayed on the board confirmed that the refresh rate stayed constant at around 65 Hz. Next, I looked into the possibility of scrolling text across the screen. This is very easily doable, however, the way I have the LED memory information stored on the microprocessor doesn't leave much room for numerous characters. Only a few can be added to the system without overrunning the allowable RAM space. This can be fixed by loading any fixed message into the flash memory and in a format where each char in the array is a single column (8 rows, 8 bits defining whether a row is on or off). This may be something to look into for displaying fixed messages on the screen as in this way, an entire sentence and more can be scrolled across a single LED screen without the need for additional memory.
In order to help simplify the process for figuring out what LEDs to turn on to represent a letter on the board, I found an Excel sheet on the internet which maps each commonly used ASCII character to an array of chars which tell which LEDs in a matrix display should be on and which should be off to display a certain letter. I took the data in this script and exported it to a comma separated values file which would be read by a PHP script I wrote which takes a string encoded in the script, matches each character to the data pulled from the Excel sheet, and puts together a long array of chars determining which LEDs should be on or off. Then, to avoid having to spend time restructuring all the functions in the program to determine which LEDs should be on and off, I took this information and converted it, using the same script, into the 2-dimensional text matrix of chars used on the microprocessor currently. This allows for more flexibility towards which pixels are on and what color each one is, however, it eats up a lot of memory and basically wastes a lot of memory. This approach is the one represented in the source files attached to these minutes because it works and I don't have time to fool with getting it to work with the more efficient approach just yet.
Also, in order to get the text to scroll across the screen, I had to setup another timer. Timer 1 on the Atmega8515 is a 16-bit timer with a maximum pre-divided clock of clk/1024 with a clock divider option of one timer tick per every 256 CPU clock ticks available as well. I calculated at that at 8 MHz CPU clock frequency, 31,250 clock ticks would pass by to represent one second. This number is a 16-bit number and was used as the top value stored in OCR1A (split between its high and lo bytes: OCR1AH and OCR1AL respectively). This timer was set up in CTC mode just like the 8-bit timer was and with the divided clock described earlier in this paragraph. Also, the interrupt for Timer 1 A was enabled by altering one bit in the TIMSK register. The ISR simply increments a value (until it gets up to the maximum value of the large 2-dimensional array of color chars the system is representing). This value that is incremented is used in the set_next_color function in the ISR for the 8-bit timer to figure out where in the 2-dimensional array the current column 1 is located (and whether the info on the display should be wrapped around to the beginning of the array.
Please note that the current code attached here uses a 1/2 second interrupt delay for Timer 1 (15,625 ticks) which allows for much quicker "scrolling" of text. Getting the microprocessor to work with the PCB layout is a single step away and all we need to do is replace one of the MOSFETs on the PCB board since the part we soldered to the PCB isn't a MOSFET, but is rather an LM317 voltage regulator...Entered by Stephen Hansen on 02/27/2012 01:34 AM
Attached Files
main.c - application/octet-stream
This contains only the main function which starts both timers and enables interrupts. Thats it.
/* Name: main.c
* Author: Stephen Hansen
*/
#include <avr/io.h>
#include <avr/interrupt.h>
#include "screens.h"
#include "scan_led.h"
#include "scroll_text.h"
/*
void upd_all(unsigned char r, unsigned char c, unsigned char color);
void upd_all(unsigned char r, unsigned char c, unsigned char color){
// simple[r][c]=color;
simple2[r][c]=color;
}
*/
int main(void)
{
initio();
sei();
init_timer0();
init_timer1();
for(;;){
}
return 0; /* never reached */
}
Attachment Added by Stephen Hansen on 02/27/2012 02:05 AM
This is the header file that contains all functions defined in the scan_led.h header file, along with the COLS global constant which is the number of columns in the scrolling 2-dimensional array of characters.
#ifndef SCAN_LED_H
#define SCAN_LED_H
#define COLS 36
void initio();
void turn_off();
void init_timer0();
void set_next_color();
#endif
Attachment Added by Stephen Hansen on 02/27/2012 02:08 AM
This file contains all functions (and ISRs) that work with the 8-bit timer to pulse all LEDs on the display to make the display light up with whatever color we want with whatever intensity.
#include <avr/io.h>
#include "scan_led.h"
#include "screens.h"
#include "scroll_text.h"
#include <avr/interrupt.h>
unsigned char r, c, color,c_on,intensity;
const unsigned char test_scroll[8][36] = {
{c_r,c_r,c_r,c_r,c_r,c_b,c_r,c_b,c_b,c_b,c_r,c_b,c_r,c_r,c_r,c_r,c_r,c_b,c_b,c_b,c_b,c_b,c_b,c_b,c_r,c_r,c_r,c_r,c_r,c_b,c_r,c_b,c_b,c_b,c_r,c_b},
{c_b,c_b,c_r,c_b,c_b,c_b,c_r,c_b,c_b,c_r,c_b,c_b,c_r,c_b,c_b,c_b,c_b,c_b,c_b,c_b,c_b,c_b,c_b,c_b,c_b,c_b,c_b,c_b,c_r,c_b,c_r,c_r,c_b,c_r,c_r,c_b},
{c_b,c_b,c_r,c_b,c_b,c_b,c_r,c_b,c_r,c_b,c_b,c_b,c_r,c_b,c_b,c_b,c_b,c_b,c_b,c_b,c_b,c_b,c_b,c_b,c_b,c_b,c_b,c_r,c_b,c_b,c_r,c_b,c_r,c_b,c_r,c_b},
{c_b,c_b,c_r,c_b,c_b,c_b,c_r,c_r,c_b,c_b,c_b,c_b,c_r,c_r,c_r,c_r,c_b,c_b,c_b,c_b,c_b,c_b,c_b,c_b,c_b,c_b,c_r,c_b,c_b,c_b,c_r,c_b,c_r,c_b,c_r,c_b},
{c_b,c_b,c_r,c_b,c_b,c_b,c_r,c_r,c_b,c_b,c_b,c_b,c_r,c_b,c_b,c_b,c_b,c_b,c_r,c_r,c_r,c_r,c_r,c_b,c_b,c_b,c_r,c_b,c_b,c_b,c_r,c_b,c_b,c_b,c_r,c_b},
{c_b,c_b,c_r,c_b,c_b,c_b,c_r,c_b,c_r,c_b,c_b,c_b,c_r,c_b,c_b,c_b,c_b,c_b,c_b,c_b,c_b,c_b,c_b,c_b,c_b,c_r,c_b,c_b,c_b,c_b,c_r,c_b,c_b,c_b,c_r,c_b},
{c_b,c_b,c_r,c_b,c_b,c_b,c_r,c_b,c_b,c_r,c_b,c_b,c_r,c_b,c_b,c_b,c_b,c_b,c_b,c_b,c_b,c_b,c_b,c_b,c_r,c_b,c_b,c_b,c_b,c_b,c_r,c_b,c_b,c_b,c_r,c_b},
{c_b,c_b,c_r,c_b,c_b,c_b,c_r,c_b,c_b,c_b,c_r,c_b,c_r,c_r,c_r,c_r,c_r,c_b,c_b,c_b,c_b,c_b,c_b,c_b,c_r,c_r,c_r,c_r,c_r,c_b,c_r,c_b,c_b,c_b,c_r,c_b}};
unsigned char simple_colors[8][3] = {
{0,0,0},
{TOTAL,0,0},
{TOTAL,10,0},
{TOTAL,50,0},
{0,TOTAL,0},
{0,0,TOTAL},
{TOTAL,0,TOTAL-30},
{TOTAL,TOTAL,TOTAL-30}};
void initio() {
DDRA = 0xFF;
DDRB = 0xFF;
DDRC = 0xFF;
DDRD = 0xFF;
turn_off();
}
void turn_off(){
PORTA = 0x00; //row select (all off)
PORTB = 0x00; //red
PORTC = 0x00; //green
PORTD = 0x00; //blue
}
//this will START the timer
void init_timer0() {
r=0;
c=0;
color=0;
c_on=0;
TCCR0 = 0x0A;
TIMSK |= 0x01;
TCNT0 = 0x00;
set_next_color();
}
/*
void set_cur_screen(unsigned char** screen){
cur_screen=screen;
}
*/
void set_next_color(){
unsigned char col,actual_column;
color++;
if(color == 3){
color=0;
c++;
if(c == 8){
c=0;
r++;
if(r == 8){
r=0;
}
}
}
actual_column = get_start_col() + c;
if(actual_column >= COLS){
actual_column -= COLS;
}
col=test_scroll[r][actual_column];
intensity=simple_colors[col][color];
PORTA=(0x80 >> r);
if(intensity > 0){
switch(color){
case 0:
PORTB=(0x80 >> c);
break;
case 1:
PORTC=(0x80 >> c);
break;
case 2:
PORTD=(0x80 >> c);
break;
}
c_on = 1;
TCNT0=0x00;
OCR0 = intensity;
} else {
c_on = 0;
TCNT0=0x00;
OCR0 = TOTAL;
}
}
ISR(TIMER0_COMP_vect){
if(c_on == 1){
turn_off();
c_on=0;
if(TOTAL > intensity){
TCNT0=0x00;
OCR0=TOTAL-intensity;
} else {
set_next_color();
}
} else {
set_next_color();
}
}
Attachment Added by Stephen Hansen on 02/27/2012 02:09 AM
This file contains all functions used in the scroll_text.c source file.
#ifndef SCROLL_TEXT_H
#define SCROLL_TEXT_H
void init_timer1();
unsigned char get_start_col();
#endif
Attachment Added by Stephen Hansen on 02/27/2012 02:10 AM
This file contains all function prototyped in the scroll_text.h header file. It also includes the ISR for the 16-bit timer operating in CTC mode.
#include "scroll_text.h"
#include <avr/interrupt.h>
#include "scan_led.h"
unsigned char start_col=0;
void init_timer1() {
TCCR1A = 0x00;
TCCR1B = 0x4C;
OCR1AH = 0x3D; // 0x3D09 = 15625 ticks * 256 = 4000000 ticks per interrupt (1/2 second)
OCR1AL = 0x09; //
TIMSK |= 0x40;
}
unsigned char get_start_col() {
return start_col;
}
ISR(TIMER1_COMPA_vect){
start_col++;
if(start_col == COLS) start_col=0;
}
Attachment Added by Stephen Hansen on 02/27/2012 02:11 AM
This file is most likely exactly the same as the screens.h file from the previous entry, however, posting it here as well as there is a great idea since it allows us to have a complete working copy of the software for the microprocessor on this webpage.
#ifndef SCREENS_H
#define SCREENS_H
#define c_b 0
#define c_r 1
#define c_o 2
#define c_y 3
#define c_g 4
#define c_blu 5
#define c_p 6
#define c_w 7
#define TOTAL 60
#endif
Attachment Added by Stephen Hansen on 02/27/2012 02:12 AM
This is the data pulled from the ASCII to 5x8 excel spreadsheet mentioned in this meeting minutes entry. This file is needed by the PHP script also attached to this entry which matches characters in a string to rows in this file.
Attachment Added by Stephen Hansen on 02/27/2012 02:13 AM
This is the PHP script used to create C code defining what is going to be displayed on the LED board.
Attachment Added by Stephen Hansen on 02/27/2012 02:14 AM
End of Entry
Minutes Dated Monday February 20, 2012 01:00 PM
Meeting with Brandon - Processor to PCB layout
Location: AK 317
Brandon and I met in the lab to go over the working code for the microprocessor and to try and figure out how to interface the microprocessor to the PCB board. We went over the schematic in multisim and were able to identify all I/O pins used on the microprocessor for our PCB layout. In the process, I noticed a few things that were incorrect about the PCB layout. I noticed that both MOSFET gate pins for each row of the PCB were tied together (and consequently tied to only one I/O pin on the microprocessor). This would result in the same image appearing on one 8x8 as the one next to it, instead of the possibility for us to have two completely different images. I also noticed that the source pins for all these MOSFETs were tied to VCC and not ground (which is were they should be) to allow current to flow through it when the gate terminal is pulled high by the microprocessor. After evaluating what needed to be done to make the PCB layout work, Brandon took the board with him to make the necessary changes while I continued working on the code.
First, I split all the code up into separate files to make it easier to work on the project. The working code up to after the code was split up is attached to this minutes entry (each file was individually uploaded with a description of what it contains).
To continue working on bettering our code, I dug through the data sheet for the microprocessor and found the Timer registers for the 8-bit timer. When we adapt the microprocessor to work with the PCB layout, we will be using the 16-bit timers (the atmega8515 has two of them, which is perfect for driving 2 8x8 matrices in the way they are setup). I tried to set the timer up in CTC mode (Clear Timer on Compare) which should clear the timer when the timer count equals the value set in OCR0 (Output Compare Register 0). However, it didn't work as I expected in the lab, and after looking back at the datasheet, I noticed I set the TCCR0 register incorrectly. Bits 6 and 3 determine what counting mode the timer was going to be in. Bit 6 is WGM00 while Bit 3 is WGM01 (WGM = Waveform Generation Mode). WGM00 should be 0 and WGM01 should be 1 to put the timer in CTC mode. I had these values flipped around which put the timer in a down-counting PWM waveform generation mode. I was finding that I had to reset the value of TCNT0 (the actual count of the timer) in order for the timer to do something even remotely close of what I was trying to do. In CTC (Clear Timer on Compare), obviously, you should not have to do this. Also, It was apparent the I could not update the OCR0 register. This is because in the mode it was in, OCR0 can only be updated when the count hits the TOP value (0xFF for this mode). At the time I found this out I was no longer in the lab and was typing the meeting minutes back at my house. I will return to the lab tomorrow to fix the timer register control values and will hopefully be able to acquire some good results before moving to the 16-bit timer.
I took an oscilloscope screenshot of the waveform as it was when I left the lab (with the incorrect timer setup) which is attached to these minutes. The photo is explained below.Entered by Stephen Hansen on 02/20/2012 11:08 PM
Attached Files
main.c - application/octet-stream
This file contains the function "main" for the microprocessor when it was running without timers (using CPU cycle counting to set light intensity in software).
/* Name: main.c
* Author: Stephen Hansen
*/
#include <avr/io.h>
#include <util/delay.h>
#include "old_funcs.h"
#include "screens.h"
#include "new_funcs.h"
//globals
unsigned char simple[8][8] = {
{c_r,c_r,c_r,c_r,c_p,c_r,c_r,c_r},
{c_p,c_r,c_p,c_r,c_r,c_p,c_r,c_p},
{c_p,c_r,c_p,c_r,c_p,c_p,c_r,c_r},
{c_p,c_r,c_p,c_r,c_r,c_p,c_r,c_p},
{c_p,c_r,c_p,c_r,c_p,c_r,c_r,c_r},
{c_b,c_b,c_b,c_b,c_b,c_b,c_b,c_b},
{c_b,c_b,c_b,c_b,c_b,c_b,c_b,c_b},
{c_b,c_b,c_b,c_b,c_b,c_b,c_b,c_b}};
unsigned char simple2[8][8] = {
{c_r,c_r,c_r,c_r,c_r,c_r,c_r,c_r},
{c_r,c_p,c_p,c_r,c_p,c_p,c_r,c_p},
{c_r,c_r,c_p,c_r,c_p,c_p,c_r,c_r},
{c_r,c_p,c_p,c_r,c_p,c_p,c_r,c_p},
{c_r,c_r,c_r,c_r,c_r,c_r,c_r,c_r},
{c_b,c_b,c_b,c_b,c_b,c_b,c_b,c_b},
{c_b,c_b,c_b,c_b,c_b,c_b,c_b,c_b},
{c_b,c_b,c_b,c_b,c_b,c_b,c_b,c_b}};
unsigned char white_screen[8][8] = {
{c_w,c_w,c_w,c_w,c_w,c_w,c_w,c_w},
{c_w,c_w,c_w,c_w,c_w,c_w,c_w,c_w},
{c_w,c_w,c_w,c_w,c_w,c_w,c_w,c_w},
{c_w,c_w,c_w,c_w,c_w,c_w,c_w,c_w},
{c_w,c_w,c_w,c_w,c_w,c_w,c_w,c_w},
{c_w,c_w,c_w,c_w,c_w,c_w,c_w,c_w},
{c_w,c_w,c_w,c_w,c_w,c_w,c_w,c_w},
{c_w,c_w,c_w,c_w,c_w,c_w,c_w,c_w}};
unsigned char single_pixel[8][8] = {
{c_b,c_b,c_b,c_b,c_b,c_b,c_b,c_b},
{c_b,c_b,c_b,c_b,c_b,c_b,c_b,c_b},
{c_b,c_b,c_b,c_b,c_b,c_b,c_b,c_b},
{c_b,c_b,c_b,c_b,c_b,c_b,c_b,c_b},
{c_b,c_b,c_b,c_b,c_b,c_b,c_b,c_b},
{c_b,c_b,c_b,c_b,c_b,c_b,c_b,c_b},
{c_b,c_b,c_b,c_b,c_b,c_b,c_b,c_b},
{c_b,c_b,c_b,c_b,c_b,c_b,c_b,c_r}};
//end globals
void upd_all(char r, char c, unsigned char color);
void upd_all(char r, char c, unsigned char color){
simple[r][c]=color;
simple2[r][c]=color;
}
int main(void)
{
initio();
unsigned char r, c;//, color = 0;
unsigned int i=0;
//binary clock stuff
init_bclock();
//end binary clock stuff
for(;;){
for(i=0;i<=66;i++){
for(r = 0; r <= 7; r++){
for(c = 0; c <= 7; c++){
color_display(r,c, simple[r][c]);
}
}
}
upd_time();
for(i=0;i<=67;i++){
for(r = 0; r <= 7; r++){
for(c = 0; c<= 7; c++){
color_display(r,c,simple2[r][c]);
}
}
}
//white test
for(i=0;i<=67;i++){
for(r = 0; r <= 7; r++){
for(c = 0; c<= 7; c++){
color_display(r,c,white_screen[r][c]);
}
}
}
//single pixel test
for(i=0;i<=67;i++){
for(r = 0; r <= 7; r++){
for(c = 0; c<= 7; c++){
color_display(r,c,single_pixel[r][c]);
}
}
}
upd_time();
}
return 0; /* never reached */
}
Attachment Added by Stephen Hansen on 02/21/2012 12:12 AM
This file contains many constants used in my prototype color definition system, including the maximum intensity value that can be used (to avoid a jumpy image on the display screen). The single digit constants defined in this file are index values of the simple_color array defined in old_funcs.c. This array has the intensity values required to get the color referred to by each of the colors in this file (for example, c_r = red, c_o = orange, etc...).
#ifndef SCREENS_H
#define SCREENS_H
#define c_b 0
#define c_r 1
#define c_o 2
#define c_y 3
#define c_g 4
#define c_blu 5
#define c_p 6
#define c_w 7
#define TOTAL 160
#endif
Attachment Added by Stephen Hansen on 02/21/2012 12:25 AM
This file is the header file for the old_funcs.c source file. It only includes function prototypes.
#ifndef OLD_FUNCS_H
#define OLD_FUNCS_H
//char select_row_column_test(const unsigned char r, const unsigned char c, const unsigned char color);
void delay(unsigned char intensity);
void upd_time();
void upd_pixels(char x_offs,unsigned char val,unsigned char colors);
//void upd_all(char r, char c, unsigned char color);
void color_display(unsigned char r, unsigned char c, unsigned char color);
void init_bclock();
#endif
Attachment Added by Stephen Hansen on 02/21/2012 12:29 AM
This file includes all the functions used in the non-timer (software delay implemented) revision of the prototyping processor code used to draw an image out on the LED matrix. The simple_colors array is defined here. This array is a 2x2 array which has 8 rows of 3 chars (3 chars, one for red, one for green, one for blue, in that order).
#define RED 0
#define GREEN 1
#define BLUE 2
#include <avr/io.h>
#include <util/delay.h>
#include "screens.h"
#include "old_funcs.h"
void upd_all(char r, char c, unsigned char color);
unsigned char simple_colors[8][3] = {
{0,0,0},
{TOTAL,0,0},
{TOTAL,10,0},
{TOTAL,100,0},
{0,TOTAL,0},
{0,0,TOTAL},
{TOTAL,0,TOTAL-20},
{TOTAL,TOTAL,TOTAL-20}};
unsigned char secs,mins,hrs=0;
unsigned char sec_col,min_col,hr_col;
const unsigned char points[6][2]={{2,1},{1,1},{0,1},{2,0},{1,0},{0,0}};
/*
//r is 0-7 for row 0-7, c is 0-7 for column 0-7, color is 0-2 for red, green, blue respectively
char select_row_column_test(const unsigned char r, const unsigned char c, const unsigned char color){
unsigned char intensity = data[r][c][color];
if(intensity == 0){
_delay_loop_1(TOTAL);
return 0;
}
PORTA = (1 << (7-r));
switch(color){
case RED:
PORTB = (1 << (7-c));
break;
case GREEN:
PORTC = (1 << (7-c));
break;
case BLUE:
PORTD = (1 << (7-c));
break;
}
delay(intensity);
}
*/
void delay(unsigned char intensity){
if(intensity > 0){
//clock frequency = 8 MHz, min frequency for 60 Hz = 3 MHz, trying software approach first, timers will come later with interrupts.
// unsigned int i;
//leaving LED on for as long as was specified
if(intensity > TOTAL) intensity = TOTAL;
_delay_loop_1(intensity);
}
PORTA = 0x00; //turn off all row power (done with this intensity level)
//turning off all columns as well
PORTB = 0x00;
PORTC = 0x00;
PORTD = 0x00;
//waiting a while before running to next LED
if(TOTAL - intensity != 0) _delay_loop_1(TOTAL-intensity);
}
void init_bclock(){
sec_col=c_blu;
min_col=c_blu+(c_g << 3);
hr_col=c_blu+(c_r << 3);
secs=0;
mins=15;
hrs=13;
upd_pixels(0,hrs,hr_col);
upd_pixels(3,mins,min_col);
upd_pixels(6,secs,sec_col);
}
void upd_time(){
secs++;
if(secs == 60){
mins++;
secs=0;
if(mins == 60){
hrs++;
mins=0;
if(hrs == 24){
hrs = 0;
}
upd_pixels(0,hrs,hr_col);
}
upd_pixels(3,mins,min_col);
}
upd_pixels(6,secs,sec_col);
}
void upd_pixels(char x_offs,unsigned char val,unsigned char colors){
//goes LSB to MSB
// const unsigned char* points[6][2]={{7,7},{6,7},{5,7},{7,6},{6,6},{5,6}};
unsigned char i;
for(i=0;i<=5;i++){
if(val & 0x01 << i){
upd_all(points[i][0]+5,points[i][1]+x_offs,colors&0x07);
} else {
upd_all(points[i][0]+5,points[i][1]+x_offs,colors>>3);
}
}
}
void color_display(unsigned char r, unsigned char c, unsigned char color){
unsigned char* intensity = simple_colors[color];
if(intensity[0] != 0){
PORTA = (1 << (7-r));
PORTB = (1 << (7-c));
} else {
PORTA = 0;
PORTB = 0;
}
delay(intensity[0]);
if(intensity[1] != 0){
PORTA = (1 << (7-r));
PORTC = (1 << (7-c));
} else {
PORTA = 0;
PORTC = 0;
}
delay(intensity[1]);
if(intensity[2] != 0){
PORTA = (1 << (7-r));
PORTD = (1 << (7-c));
} else {
PORTA = 0;
PORTD = 0;
}
delay(intensity[2]);
}
Attachment Added by Stephen Hansen on 02/21/2012 12:30 AM
This file and its source file (new_funcs.c) were created for the next revision and currently only hold information for a very simple IO initialization function.
#ifndef NEW_FUNCS_H
#define NEW_FUNCS_H
void initio();
#endif
Attachment Added by Stephen Hansen on 02/21/2012 12:32 AM
This file is the source file which will contain all functions used for the timer revision of this code (not implemented as of yet).
#include <avr/io.h>
#include "new_funcs.h"
void initio() {
DDRA = 0xFF;
DDRB = 0xFF;
DDRC = 0xFF;
DDRD = 0xFF;
PORTA = 0x00; //row select (all off)
PORTB = 0x00; //red
PORTC = 0x00; //green
PORTD = 0x00; //blue
}
Attachment Added by Stephen Hansen on 02/21/2012 12:33 AM
This is an oscilloscope waveform collected of our incorrect (and current) timer configuration. In this graph, Channel 1 is connected to the gate of row 7 (0-7). The columns are represented as Channel 2 (red LED), 3 (green LED), and 4 (blue LED). The color shown here should be purple (which it is), however, row select pin should NOT go low for 100 µs after this color has been triggered. Also, the blue and red LEDs are on for the same amount of time in this screenshot. The blue LED should actually be on for a visibly lesser amount of time than the red LED.
Attachment Added by Stephen Hansen on 02/21/2012 12:36 AM
End of Entry
Minutes Dated Friday February 17, 2012 12:00 AM
Late night in the 3rd floor lab
Location: 3rd floor lab
I just finished working in the 3rd floor lab (for now). I connected the ATMEGA8515 processor up to the development board using the 6-pin in-system-programming cable supplied with the kit. This took a while to figure out, but after digging through the datasheets for a while, I finally found the solution and was able to get the microprocessor in the broadboard hooked up to the development board correctly to allow for programming. Also, with my newely acquired administrative access to the computer at the workbench, I was able to install the software needed to download the program for the AVR microprocessor I was working on. I modified the program numerous times and, just to show how well it worked, I coded in two separate screens for the microprocessor to alternate the screen between. Both show the current time in full binary format in the bottom 3 rows with different colors, but one uses the top 5 rows to display "ECE" while the other does the same thing but with "ECE" instead. Now that we were able to successfully program the microprocessors for this very simple testing prototype, it will not be difficult to adapt the programming to the PCB boards we have ordered and already soldered together. I'd say that tonight was a success regardless of the fact that we don't know for sure how well the PCB boards we currently have will work. We will pick this up at a later time. I will upload pictures of the 8x8 prototype working displaying binary time and two different alternating messages.Entered by Stephen Hansen on 02/17/2012 07:27 AM
End of Entry
Minutes Dated Wednesday February 15, 2012 02:00 PM
Working in the 3rd floor lab
Location: AK 3rd floor lab
I have the serial adapter and attempted to get the adapter to work with the development board using my laptop to no avail. I also tried using another laptop I have which has Linux installed on it but was unable to get it to work either. I was able to connect the development board to the 8x8 protoboard setup I built back in December. This will allow for chip programming without having to move the microprocessor from the protoboard to the development board to program it and move it back again to test and see if it works. Instead, all we will have to do is switch the voltage supply to the development board to program, and switch it back to the 8x8 matrix to see if the program worked. I also setup the workbench with a power supply and a Tektronix MSO 2924 Oscilloscope to aid in the debugging process. I also had to hookup the computer at the workbench as it was completely disconnected... The only thing we need now is administrative access to waterville.ece.wpi.edu and we will be able to install the winavr software to program the microprocessors. I will attach links to the software we will be using to download the program (I have used this before and have already verified that it works).
I will upload the old AVR code (the code which is currently programmed to it). It does not work properly and I am in the process of looking through the information on the microprocessor to try and figure out why it is not working the way we want it to. If that doesn't work, I will increase the delay time on the microprocessor to the point where the individual LEDs are turned on one at a time slow enough so the human eye can see what is going on (we should see each LED turn on only when we want it to).Entered by Stephen Hansen on 02/15/2012 04:58 PM
Attached Links
This is the link to the software we need to install in order to download programs to the AVR microprocessors for our MQP.
Link Entered by Stephen Hansen on 02/15/2012 05:06 PM
Attached Files
This is the code that is currently loaded onto one of our microprocessors. It is faulty code and are currently working out solutions to see what is wrong with it.
/* Name: main.c
* Author: Stephen Hansen
*/
#include <avr/io.h>
#include <util/delay.h>
#define RED 0
#define GREEN 1
#define BLUE 2
unsigned char data[8][8][3] = {
{{255,0,0}, {255,0,0}, {255,0,0}, {255,0,0}, {255,0,0}, {255,0,0}, {255,0,0}, {255,0,0}},
{{255,128,0}, {255,128,0}, {255,128,0}, {255,128,0}, {255,128,0}, {255,128,0}, {255,128,0}, {255,128,0}},
{{0,0,0}, {0,0,0}, {0,0,0}, {255,255,0}, {255,255,0}, {0,0,0}, {0,0,0}, {0,0,0}},
{{0,0,0}, {0,0,0}, {0,0,0}, {128,255,0}, {128,255,0}, {0,0,0}, {0,0,0}, {0,0,0}},
{{0,0,0}, {0,0,0}, {0,0,0}, {0,255,0}, {0,255,0}, {0,0,0}, {0,0,0}, {0,0,0}},
{{0,0,0}, {0,0,0}, {0,0,0}, {0,255,128}, {0,255,128}, {0,0,0}, {0,0,0}, {0,0,0}},
{{0,0,0}, {0,0,0}, {0,0,0}, {0,255,255}, {0,255,255}, {0,0,0}, {0,0,0}, {0,0,0}},
{{0,0,0}, {0,0,0}, {0,0,0}, {0,128,255}, {0,128,255}, {0,0,0}, {0,0,0}, {0,0,0}}};
void select_row_column_test(const unsigned char r, const unsigned char c, const unsigned char color);
void delay(const unsigned char intensity, const unsigned char total);
void delay_time(const unsigned char length);
int main(void)
{
DDRA = 0xFF;
DDRB = 0xFF;
DDRC = 0xFF;
DDRD = 0xFF;
PORTA = 0x00; //row select (all off)
PORTB = 0x00; //red
PORTC = 0x00; //green
PORTD = 0x00; //blue
char r, c, color = 0;
/* insert your hardware initialization here */
for(;;){
for(r = 0; r <= 7; r++){
for(c = 0; c <= 7; c++){
for(color = 0; color <= 2; color++){
select_row_column_test(r,c,color);
}
}
}
}
return 0; /* never reached */
}
//r is 0-7 for row 0-7, c is 0-7 for column 0-7, color is 0-2 for red, green, blue respectively
void select_row_column_test(const unsigned char r, const unsigned char c, const unsigned char color){
PORTA = (1 << (7-r));
if(color > 0){
switch(color){
case RED:
PORTB = (1 << (7-c));
break;
case GREEN:
PORTC = (1 << (7-c));
break;
case BLUE:
PORTD = (1 << (7-c));
break;
}
}
unsigned char intensity = data[(short)r][(short)c][(short)color];
delay(intensity,255);
}
void delay(const unsigned char intensity, const unsigned char total){
//clock frequency = 8 MHz, min frequency for 60 Hz = 3 MHz, trying software approach first, timers will come later with interrupts.
// unsigned int i;
//leaving LED on for as long as was specified
delay_time(intensity);
PORTA = 0x00; //turn off all row power (done with this intensity level)
//turning off all columns as well
PORTB = 0x00;
PORTC = 0x00;
PORTD = 0x00;
//waiting a while before running to next LED
delay_time(total-intensity);
}
void delay_time(const unsigned char length){
unsigned int i;
unsigned int max = (unsigned int)(length);
max <<= 5;;
for(i=0;i<max;i++){
}
}
Attachment Added by Stephen Hansen on 02/15/2012 05:14 PM
End of Entry
Minutes Dated Friday February 10, 2012 02:00 PM
MQP Meeting with Professor Bitar
Location: Bitar's Office
Up to this meeting we have been struggling with trying to find a reliable way of programming the microprocessors for the board. We have tried using a USB to serial adapter purchased from staples, but I could not get my laptop to work with it to be able to program the microprocessors. The only solution to this problem is to either purchase a USB to serial adapter for use with a Mac or Linux computer (which is also compatible with the avrdude program which I have been trying to use to program the microprocessors) or find a computer in the lab with a serial port which we can gain administrative access to which we can use to install the necessary software and program our microprocessors. Finding a computer with a serial port is a known working solution as the last computer I used to program the processors was that of a TA in the 3rd floor lab. This is also the only way we have had any luck programming the microprocessors. I will continue to send emails to the ece help desk (and Dr. Robert Brown) to try and acquire administrative access to a computer in the 3rd floor lab that has a serial port. I have also (in the meantime), ordered a usb to serial adapter that has working drivers for Mac OS X and Linux which will arrive early on next week. Once it arrives, I will post back up in the ECE lab and try to use it to program the microprocessors again.Entered by Stephen Hansen on 02/15/2012 04:48 PM
Attached Files
This is the USB to serial adapter i purchased from serialio.com which is known to work for Mac OS X and Linux. If this doesn't get the job done, we will try and gain access to a computer in the 3rd floor lab to program the microprocessors with a serial port directly.
Attachment Added by Stephen Hansen on 02/15/2012 04:56 PM
End of Entry
Minutes Dated Tuesday December 6, 2011 10:00 AM
PCB Layout Progress
Location: AK 227
We have been working on the PCB layout of our final design. Due to our current design idea of having 4 LED matrices on one board, the design has become extremely large. The final design will be modular with our printed circuit boards stacked next to each other side by side 2 8x8 matrices high. Additionally, due to the large number of components on the board, there are many, many connections that need to be made and it will take some time working with Ultiboard and Multisim to get the final design completed. We look for completing the design by the end of B-term and will be ordering the PCBs over winter break so when we get back from break we can start soldering and wiring the boards up to see if they work.Entered by Stephen Hansen on 02/15/2012 04:35 PM
Attached Files
This is the Finalized PCB Layout drawn out in Ultiboard.
Attachment Added by Stephen Hansen on 02/26/2012 07:21 PM
End of Entry
Minutes Dated Tuesday November 15, 2011 09:00 AM
Parts List Finalization: Decoders and Resistor Arrays
Location: AK 227
In this meeting, I demonstrated the 8x8 LED protoboard design to the group and experimented with different duty cycles with a 5 V 60 Hz square waverform and a 10 Ω resistor. We also experimented with varying the input voltage to the transistor arrays from +5 V up to +12 V. We found that as the voltage increased, the brighter the LEDs were at the very low duty cycles (.2% to .5%). Also, we found that with higher voltages, the colors of the individual LEDs changed (green had the most noticeable change in which it seemed to turn into a sort of blueish green at higher voltages).
Looking at these results, it may be worth looking at the possibility of using constant current drivers to turn the LEDs on and off instead of resistors, however, even with that said, it looks like we will be able to implement our design just fine using 10 Ω resistor arrays, a supply voltage of +12 V to the each 8x8 panel, and a supply voltage of +5 V to the transistor array inputs.
Also during this meeting, we looked at row and column decoders for the TTL logic family. After looking at 4:16 decoders, we decided to settle on using 3 3 to 8 decoders. We can use the same decoder we are using for the rows since that decoder has 3 enable pins and will only reflect its inputs at the output if E3 is high and the other two are BOTH a logic low. If either of the other two are a logic high, then, regardless of what any other pin is, all outputs will be set to a logic low. A drawing of how this is possible without inverters will be attached to these minutes in due time.
Additionally, we looked at purchasing power MOSFETs to use to enable to power to flow through the current source transistor arrays (basically gives us an enable bit). All parts are listed in the table attached to these minutes. Their datasheets are also attached to this meeting minutes entry as well.Entered by Stephen Hansen on 11/15/2011 10:20 AM
Attached Files
This is the datasheet for the MOSFET switch we plan on using to implement the enable bits to control the intensity of each 8x8 matrix.
Attachment Added by Stephen Hansen on 11/15/2011 10:55 AM
This is the resistor array of 10 ohm resistors we plan on using to limit the current in our final design.
Attachment Added by Stephen Hansen on 11/15/2011 10:58 AM
This is the 3 to 8 decoder we plan on using for the row select for our final design. We can also use 3 of these without any inverters to select the columns as well. This 3 to 8 decoder has 3 enable pins. If E3 is HIGH and the other two are low, it will be active. In any other configuration, the chip will be inactive and all output pins will be set to a logic low. This chip uses the same 74HC logic that the microprocessor uses and is non-inverting.
Attachment Added by Stephen Hansen on 11/15/2011 11:01 AM
End of Entry
Minutes Dated Saturday November 12, 2011 11:00 AM
Working on a Saturday
Location: AK 227
I decided to use this Saturday to get some work done on our MQP. I pulled out the datasheet for the 8x8 matrix array and began wiring a broadboard up to prepare for interfacing the matrix with a microcontroller. It took a while to connect all the wires but right now, everything is connected and it has been tested with a power source. It is a messy board, but all rows can be selected and all columns (each color) can be selected as well by simply using two pull-up resistors and connecting them to the inputs on a row and column (through the transistor array). Currently, the current flowing to the 8x8 matrix is limited using a 330 ohm resistor on the current source transistor array.Entered by Stephen Hansen on 11/12/2011 04:42 PM
Attached Files
This is an image of the circuit that I created. There is enough space left on the boards for one microprocessor to test the LED panel with. All that is left is to program one of the AVR microprocessors and watch our circuit work!
Attachment Added by Stephen Hansen on 11/14/2011 08:47 AM
End of Entry
Minutes Dated Friday November 11, 2011 09:00 AM
Friday 11/11/2011 Meeting
Location: AK 227
We met in the lab to work on the schematic for one module of our final product. I had a new idea prior to this meeting which involved using a single decoder for the 24 columns and a second decoder for 8 rows (the column decoder would be connected to ALL respective column pins on each 8x8 LED matrix and the row decoder would be connected to ALL respective row pins on each 8x8 LED matrix). In between the decoder and all 8 8x8 matrices would be the transistor array ICs (one UDN2981 and three ULN2803 per matrix (red, green and blue)). The one thing that would allow the microcontroller to still make each LED matrix display something different would be the use of power transistors controlling current flow to the rows of each individual 8x8 matrix (enable pins, one per 8x8 matrix). These 8 pins would be the one that are pulse-width modulated to allow for different color combinations and intensities across the entire module. We started redrawing our schematic to show the new design and should be able to have something to present to Professor Bitar by the time our next meeting rolls around next week.
We also discovered prior to this meeting that our AVR microcontrollers and transistor arrays are all part of the TTL logic family (we will need to get decoders that match this logic family to ensure that everything will work flawlessly with everything else on the module).
Also, I was able to create some testing code for one of our microcontrollers to test one 8x8 with one microcontroller and our transistor arrays.
The code holds an array of 192 chars (one per LED) that will, when run very quickly on the AVR microcontroller, will display a T on the 8x8 matrix with colors changing from Red gradually to Blue from top to bottom. The code was slowed down and compiled and run on a Linux machine to verify that it is working correctly. From what we could see, it works properly and cannot wait to put it on the ATmega8515 and connect it to an 8x8 matrix of RGB LEDs!
Also, we found some development software that will allow us to build machine code for our microprocessors and download it to them. The only thing that stands in our way that my laptop doesn't have an RS232 port which is required to interface with the development board.Entered by Stephen Hansen on 11/12/2011 04:27 PM
Attached Links
This link contains a walkthrough of how to install and use the AVR development tools for Unix.
Link Entered by Stephen Hansen on 11/15/2011 08:58 AM
Attached Files
This is a Multisim File showing our first draft of one module which will have 8 8x8 LED matrices on it.
Attachment Added by Stephen Hansen on 11/15/2011 01:50 PM
End of Entry
Minutes Dated Tuesday November 8, 2011 11:00 AM
MQP Group Meeting
Location: AK 113
In this meeting we finished drawing out our schematic for the final module design which will encorporate two rows and 4 columns of 8x8 LED matrix displays. We plan to use an extra number of encoders to allow us to work with two LEDs in this display at a time (e.g. tie all rows together, use two encoders for 2 sets of columns and another 2 encoders for the other 2 sets of columns). At a short meeting last week on 11/4/2011, we experimented with pulsing one LED for a very small amount of time with a 60 Hz square wave (60 Hz PWM with a .1 to .4 % duty cycle). To allow the LED to be visible, we had to increase the supply voltage to the LED up to 12 V and decrease the resistance to a 10 ohm resistor (we were testing on the RED led which requires more current). With a .1 % and a .2 % duty cycle, the LED was easily visible and the difference between .1 and .2% was dramatic (good thing).
Attached is an excel spreadsheet showing math to figure out a required minimum clock frequency for our microcontroller for 8 intensity bits for controlling 8 8x8 displays (but working with two LEDs at a time). We found that with this configuration working with a 60 Hz refresh rate, the minimum clock frequency is 11.796 MHz which is well within the scope of our selected microcontroller. This is based on findings that the required resolution per LED for ONE 8x8 LED matrix display was 339 ns. See attached excel sheet for more details. The lab notebook page with math written on it will be uploaded and attached to these minutes as well.Entered by Stephen Hansen on 11/08/2011 12:00 PM
Attached Files
This is a worksheet showing the minimum clock frequency needed to achieve the desired refresh rate with the desired number of intensity bits along with other parameters.
Attachment Added by Stephen Hansen on 11/08/2011 12:07 PM
End of Entry
Minutes Dated Friday October 7, 2011 02:00 PM
8x8 LED Testing and Proposal Split-Up
Location: AK 317A
For this meeting, we met in the 3rd floor of AK since AK 227 was being used by a lab at the time. At this meeting, we tested our 8x8 LED displays with a 300Ω resistor at 5V and 3.43V (for all 3 colors: red, green, and blue). Details about these findings are attached in a pdf file of pages 71 and 72 of my lab notebook. To summarize our findings, we found that with 5 volts, the LEDs were relatively bright and the power consumption of 62 8x8 LED matrices with every color on would be 461.28 watts. On the other hand, we tested the 8x8 display with 3.43 V and found that each color was still easily bright enough and the power consumption for 62 8x8 LED matrices with all colors glowing would be 133.4 watts! Both options are definitely within the scope of the project. Another consideration we may want to look at is running the display with a higher voltage and using a significantly larger resistor to limit current flowing through the display (for our 3.43V test, the entire current needed to have every LED on would be 38.8864 amps). This could be reduced by running the displays at 5V with bigger resistors to limit the current to the values acquired for the 3.43 V test (5.4 mA for red, 2 mA for green, and 2.4 mA for blue).
Again, see the scanned document below for more information. Our final proposal is attached to these minutes.Entered by Stephen Hansen on 10/10/2011 08:24 PM
Attached Files
This file is a scanned PDF of the pages in my lab notebook which contain the work I did figuring out power dissipation by 62 LED 8x8 panels running at both 5 and 3.43 volts using a 300Ω current-limiting resistor.
Attachment Added by Stephen Hansen on 10/10/2011 08:50 PM
This file is the final proposal for our MQP. It contains all information for the top high resolution portion we plan to build as well as the larger interactive low resolution portion with sensors we plan on building and putting on the wall as well.
Attachment Added by Stephen Hansen on 10/11/2011 11:19 AM
End of Entry
Minutes Dated Wednesday October 5, 2011 08:00 PM
Log of Work iin AK227
Location: AK227
I worked alone in AK227 after receiving a text that our 3 sample 8x8 matrix displays had arrived. I realized we had no microcontrollers with a high enough I/O current rating to drive the display and started searching to find something that would suite our needs. I found someone who drove an 8x8 LED display (not RGB, one color only) using an ATmega8515 32-bit microprocessor. The schematic I found is attached to this entry. The schematic shows the use of two buffer ICs (one for current supply, a second for current sink), however, I don't think they are necessary since the ATmega8515 chip has an absolute maximum I/O pin current rating of 40 mA per pin (also, there are 220 ohm resistors after the current supply IC which, with a 5V source, limits current to about 22 mA which is probably much higher than we need anyways). I submitted a request for samples of the ATmega8515 microprocessor chip (to the company that makes the microcontrollers (Atmel)) to see if they would be willing to send us some samples to use to drive our 8x8 RGB displays (these chips have 44 I/O, leaves 12 I/O free after all pins on the 8x8 display is connected to the ATmega8515 chip). I will also look into ordering some current supply/sink chips just incase. We will also need to acquire the development package for the ATmega8515 chip in order to program them to display what we want to display on our 8x8 matrices.
After some searching, I found a compatible development board for the ATmega8515 microcontrollers: the STK500. Its users guide is attached along with a link to it on Amtel's website. The board costs $79... Will probably need to get reimbursed for this...
I also, alternatively, found a debugging board for the ATmega8515 that uses USB. This may be better to use than the STK500. The model number for this board is ATAVRDRAGON.Entered by Stephen Hansen on 10/05/2011 09:13 PM
Attached Links
This is a link to Atmel's website showing the ATmega8515 chip. This is the link I went through to request samples of the chip.
Link Entered by Stephen Hansen on 10/05/2011 09:23 PM
This is a link to buy the STK500 development board on Atmel's website.
Link Entered by Stephen Hansen on 10/05/2011 10:05 PM
This is the debugging board that costs $49 for the ATmega8515 chip.
Link Entered by Stephen Hansen on 10/05/2011 10:32 PM
Attached Files
This schematic shows how the ATmega8515 microcontroller is connected to a non-RGB 8x8 LED display through the use of current sink and supply IC chips.
Attachment Added by Stephen Hansen on 10/05/2011 09:20 PM
This is the datasheet for the ATmega8515 32-bit microcontroller.
Attachment Added by Stephen Hansen on 10/05/2011 09:21 PM
This is the users guide for the development board for the ATmega8515 microcontroller.
Attachment Added by Stephen Hansen on 10/05/2011 10:05 PM
This PDF includes order information of the development board and the microprocessors purchased.
Attachment Added by Stephen Hansen on 10/07/2011 12:47 AM
This file is the order confirmation for the current sink and supply ICs ordered to drive the LED screens.
Attachment Added by Stephen Hansen on 10/07/2011 12:48 AM
This is the data sheet for the ULN2803A current sink transistor arrays that will be used for the columns of the 8x8 screen (one for each different color).
Attachment Added by Stephen Hansen on 02/29/2012 09:47 PM
This is the datasheet for the UDN2981A current source transistor arrays we will use connected to the rows of the 8x8 LED screen.
Attachment Added by Stephen Hansen on 02/29/2012 09:49 PM
End of Entry
Minutes Dated Tuesday October 4, 2011 02:00 PM
Second to last Meeting with Bitar
Location: Professor Bitar's Office
During this meeting, we showed Professor Bitar the ideas we had come up with during the previous week including how we planned for the individual modules to communicate with the main processing unit to display information and update the screen. We also expressed our concerns about the data rate we would need to acquire in order to tell each module what to display fast enough to update the entire screen 60 times per second (from calculations, this value turned out to be about 7.02 MB/s).
We also showed Professor Bitar the sensacell boards we found that could be purchased for about $200 per square foot. This is a low resolution version of what we are trying to build and uses a very small number of LEDs (low resolution) but it is still able to cover a very large area (light spread out over a wide area).
Seeing the sensacell boards we found and our data rate/power consumption problem (Professor Bitar recently expressed concerns that our final design, if running continuously, would need 2400 watts worth of power to function), Professor Bitar suggested a compromise in which we would build a strip of the smaller high resolution LED screen on top of a large low-resolution interactive, artistic LED display screen. The top banner could scroll data and information across the top while the bottom larger low resolution display could be used solely for people to wave their hands across it to change the pattern that is being displayed there.
For our next meeting, Professor Bitar wants us to draw up proposal(s) for EXACTLY what we are going to lock ourselves into for the rest of our MQP including statistics, communication specifics, pros and cons, power requirements, etc...Entered by Stephen Hansen on 10/05/2011 06:49 PM
End of Entry
Minutes Dated Tuesday October 4, 2011 01:00 PM
Group meeting in AK227
Location: AK 227
This meeting was held to outline the agenda for our upcoming meeting with Professor Bitar.
8x8 LED matrix displays have been ordered and we are still in the process of choosing microprocessors to be used for the individual modules. I found a PIC microprocessor that could potentially be used for the main microprocessor on each module: PIC18F14K22. We also have been researching using CLPD programmable logic boards to drive the display itself (advantages are that these CLPDs flash themselves upon startup and can support up to 20 mA of current through each of their I/O pins. These boards are relatively inexpensive, however their development kits are a little expensive (we only need one of those anyways).
A general working block diagram of an individual module has been produced and will be scanned and uploaded to this minutes entry.
During this meeting, we also explored a new product we found known as sensacell which is a low resolution RGB LED modular board which uses a very few number of LEDs to cover a large area and use motion sensors to achieve a large variety of effects. Some links and datasheets for these products are attached to this meeting below.Entered by Stephen Hansen on 10/04/2011 01:45 PM
Attached Links
This is the same 8x8 LED module board we ordered. We would like to clarify the LED current ratings listed on this link.
Link Entered by Stephen Hansen on 10/04/2011 01:55 PM
These CLPDs are programmable logic boards which have many I/O pins and can withstand up to 20 mA per I/O pin. This would be very useful in our project since it would do away with the need for demux chips and MOSFETs to turn on and off the LEDs individually (to drive the overall board).
Link Entered by Stephen Hansen on 10/05/2011 07:59 PM
This is a video showing the sensacell in action. There are many more videos like this one that show the endless possibilities of this product.
Link Entered by Stephen Hansen on 10/05/2011 07:59 PM
This is sensacell's website which shows in detail all the different products they offer and how they work together with each other to achieve the desired overall effect. These modular boards have been used in everything from floors, walls, to bar surfaces.
Link Entered by Stephen Hansen on 10/05/2011 08:00 PM
Attached Files
This file describes how each Sensacell module communicates with one another and shows how they are able to detect where an object over it is moving and how far away it is to determine what to do with the RGB LEDs they are controlling.
Attachment Added by Stephen Hansen on 10/05/2011 08:09 PM
This is a scan of Page 63 of my lab notebook showing what we expect the circuitry of one single module will look like.
Attachment Added by Stephen Hansen on 10/10/2011 08:17 PM
End of Entry
Minutes Dated Monday September 26, 2011 03:00 PM
LED Display Approaches Possibilities
Location: AK 227
I was absent for this meeting unfortunately. In this meeting our group put together an outline of the different approaches we will consider with Professor Bitar at our meeting on 9/27/2011. The documents attached include an outline of what we went over during this meeting as well as a pdf file detailing what was mentioned in the outline. This file includes many links to different manufacturer websites showing the different possible approaches we have considered thus far for creating an LED display for the AK Power Panel Lounge.Entered by Stephen Hansen on 09/27/2011 01:11 PM
Attached Files
This file contains only the outline of the types of approaches we came up with during this meeting for creating our finished product.
Attachment Added by Stephen Hansen on 09/27/2011 01:14 PM
This file includes all the detailed description of what is outlined in the outline PDF file.
Attachment Added by Stephen Hansen on 09/27/2011 01:15 PM
This file is a quote we received from a company known as betlux for a quantity of 600 8x8 LED RGB dot matrix displays. It is important to note that this quote lists the displays as costing us $6.90 per unit ($4140 for all of them). The model number is BL-M23B881RGB-11 : the exact same 8x8 LED dot matrix display we initially found on evilmadscience.com which cost $20 each on that site.
Attachment Added by Stephen Hansen on 09/27/2011 01:16 PM
This is the datasheet for the 8x8 matrix display module.
Attachment Added by Stephen Hansen on 09/27/2011 06:12 PM
End of Entry
Minutes Dated Monday September 19, 2011 12:00 PM
LED Sensor Experiments (1 and 2)
Location: AK 227
We all met in AK 227 with a lab kit and built the simple circuit that Bitar told us about. However, we were not able to get it to work the first time (see attached lab notebook image).
After going back home and analyzing the circuit we built, I noticed that all current from the LED sensor was getting drowned out by the current through the feedback loop of the inverting amplifier. I drew up a new circuit with a unity gain buffer and went back to the lab later that night (see the "prelab" images). I built the circuit I drew up and modified the feedback resistance value until I was able to see some very promising results when using my phone's extremely bright LED on the LED sensor on the board (see attached lab notebook scans, oscilloscope photo, and breadboard circuit photo). If we used brighter LEDs for this experiment, the sensing capabilities would probably not require a ridiculous 510 V/V gain (and definitely not the further ridiculous 10,200 V/V gain I was trying to get to but was unable to because of oscillations caused by current driving limitations of the LM741 op-amps).
From this experiment, using my phone to provoke the LED gave a maximum voltage difference of 1.57 V (difference between output voltage with ambient light and output voltage with my phone's LED approximately 1.5 cm away from the sensing LED on the breadboard).Entered by Stephen Hansen on 09/20/2011 12:36 AM
Attached Files
This is an oscilloscope photo showing the voltage changes at the output of the inverting op-amp in the second (working) part of this experiment. Channel 1 was connected to the output of the inverting amplifier, Channel 2 was connected to the unity gain buffer's non-inverting input.
Attachment Added by Stephen Hansen on 09/20/2011 12:49 AM
This image shows the circuit that was used to acquire the Oscilloscope image attached to this entry.
Attachment Added by Stephen Hansen on 09/20/2011 12:51 AM
This shows the information recorded for trial 1 of the LED sensor experiment.
Attachment Added by Stephen Hansen on 09/20/2011 08:40 AM
This shows work I did after the first failed experiment to figure out what went wrong and how to fix it. Also, please note, the new circuit created is on page 52 (see the LED sensor experiment 2 below).
Attachment Added by Stephen Hansen on 09/20/2011 08:41 AM
This is the lab entry which goes along with the pictures entered last night (top of attachments list). It shows the data recorded and notes taken during the second (and successful) LED sensor experiment.
Attachment Added by Stephen Hansen on 09/20/2011 08:42 AM
End of Entry
Minutes Dated Friday September 16, 2011 02:00 PM
MQP Group Meeting - Protocol and block diagram
Location: AK 113
Our group spent this meeting trying to get a working block diagram of exactly how our finished system will (hopefully) work. I did a lot of work in my lab notebook and will scan in those pages and post them under this meeting. They show our plan for one module of LED lights: 8 by 8 (in terms of LEDs and most likely inches as well) with infrared LED pairs spaced equidistant from the center of each module in a line from the center to one of each of the 4 corners of the panel (see attached drawings). We also brainstormed how the microprocessing units on each module will be able to read information from the LED sensors and apply send signals to other modules if necessary. A generic protocol was drawn up which will allow each module to be interrupted to listen for communication from the main CPU or other surrounding modules. LOTS of multiplexing will be used to minimize the number of digital I/O pins needed.
The generic proposed layout of each module of each module is that each module will have two microcontrollers. One is the "brain" of each module, the second will be the slave module which will be specifically in charge of displaying the information stored in its memory on the LED matrix display. The "brain" of each module will be in charge of everything else: grabbing data from the main CPU, listening for communication from other surrounding boards, reading data from the infrared LED sensors, pulsing each infrared LED with a PWM signal with a varying frequency (frequency will slow down over time if nothing is sensed to save power). Also, for the "brain" to be able to communicate with surrounding modules, it will use two outputs to select an adjacent board (and will have to use a third output to actually send a voltage to the corresponding input of the receiving module). The receiving module will acknowledge by doing the same thing for the sending module and will wait for the transmission on its SPI pin for inter-module communication. The two outputs used for selecting a board to listen to or talk to will be connected to both a demux and mux circuit which will be used for connecting the SPI pin to the correct module in order for the chip to be able to receive data.
Our idea for getting the main CPU controlling the entire screen to communicate with the individual modules will work exactly the same way as the second microcontroller controlling the individual LEDs: it will be addressing a matrix of modules. By selecting a row and column to talk to, the main CPU can transmit data to one module at a time. Additionally, on the receiving end, all that is necessary (instead of 2 digital inputs (one for the row, one for the column) is an AND gate connected to one digital IO on the "brain" of each module. When this digital input receives a logic high value, the module will be interrupted and will listen for new data to display from the main CPU.Entered by Stephen Hansen on 09/20/2011 12:13 AM
Attached Files
This is a PDF file containing all the information I recorded during this meeting. It shows all the details I explained here in these minutes on paper.
Attachment Added by Stephen Hansen on 09/20/2011 08:37 AM
End of Entry
Minutes Dated Tuesday September 13, 2011 02:00 PM
Meeting with Bitar #3
Location: Professor Bitar's Office
Discussed with Bitar what our group has done in the past week (outlined our idea of having 24 1' by 1' panels to make a display of 12' by 2' (as an example, not a concrete idea just yet)). During this meeting, Bitar discussed using LEDs as sensors to sense motion (or light) instead of using actual motion sensors. We drew up a quick schematic at the end of the meeting to test out in the coming week to test the phenomenon in which light from an LED that emits the same wavelength of light as another one can cause current to flow through an LED in reverse bias. We will make it our goal to test this experiment out this week. Additionally, we may want to go to the library and read some previous MQP reports (one group has already done a project that involved using LEDs as sensors to sense the intensity of light emitted by their surrounding neighbors).Entered by Stephen Hansen on 09/20/2011 12:07 AM
End of Entry
Minutes Dated Tuesday September 13, 2011 12:00 PM
LED Display Screen Research
Location: AK 227
During this meeting, we spent our time researching LED matrix technology and tried to get an estimate on how much we would be spending and how many RGB LEDs we would need for a display screen of a specific length and height. I created a spreadsheet allowing us to change the length and height of our desired final display with parameters such as LEDs per inch and price per LED to give us the total number of LEDs in our final design as well as the final cost of just the LEDs alone.Entered by Stephen Hansen on 09/13/2011 12:37 PM
Attached Links
This is a link to an 8x8 matrix display we found. Each panel is a 2.37" square, each square containing 64 diffused LEDs and costs $20 each ($15 each for 100 or more).
Link Entered by Stephen Hansen on 09/13/2011 12:42 PM
Attached Files
This is the datasheet for the 8x8 matrix display. It shows a schematic representation of how each LED is connected to each other in a matrix formation. Connecting the leads to shift registers driven by some sort of microprocessor would give us simple functionality for each 8x8 square.
Attachment Added by Stephen Hansen on 09/13/2011 12:51 PM
End of Entry
Minutes Dated Tuesday September 6, 2011 02:05 PM
Meeting With Bitar #2
Location: Professor Bitar's Office
After explaining to Professor Bitar all the details we found during the previous week, we discussed the implementation of some sort of interactive LED display screen which will utilize digital circuitry including shift registers and a matrix of LEDs to display an image. Professor Bitar gave us a head start on how display screen work and mentioned he will talk to Professor McNeil to see if our idea of some sort of interactive display screen is something acceptable for us to do. We will, in the meantime, research how LCD and LED screens work to get a better understanding of what sort of system we will be looking to build.
Some ideas tossed around during the meeting were using a single LED per pixel of our screen (these LEDs have red, green, and blue LEDs all in one container). We may also use PWM signaling to control the brightness of each individual LED within each individual container to create an image. We may not go into a route this complicated as we would basically be recreating a display screen from scratch and it would require a lot of digital circuitry and programming to simply get something capable of driving this thing. For now, our options are still open and we will research this possibility.
During the coming week we will also continue to research solar power and batteries and other ways of powering this system, including an estimate on power needs for the finished product. We will write up a proposal for creating this LED display for the lounge tomorrow to be sent to Professors Bitar and McNeil to give them a better understanding of what we are looking to accomplish.Entered by Stephen Hansen on 09/06/2011 05:02 PM
Attached Files
This is the proposal outlining exactly what we have in mind for the power panel lounge. Even with this idea in mind, the possibilities of what we can do with it remain endless.
Attachment Added by Stephen Hansen on 09/07/2011 01:46 PM
End of Entry
Minutes Dated Monday September 5, 2011 02:20 PM
Brainstorming
Location: AK 113
This meeting was held to compile everything we had researched over the previous week in preparation with our next advisor meeting.
Questions that came up during this meeting included the following:
Budget - How much do we have to spend?
LED lighting - Is this project supposed to replace the current lighting for the lounge or simply be some sort of interactive just-for-fun system?
Ideas that were tossed around during the meeting about power generation included coupling some solar panels with the windmill on the roof of AK. Also, solar panels angled to the southern sky at 42 degrees from straight up would yield the best efficiency of stationary panels (and would also allow for snow to fall from the panels in the winter).
We came to the consensus of using Lead-Acid battery technology for energy storage. We found a special brand of battery specifically for storing solar-generated electricity: Trojan Deep Cycle Solar Batteries. We found a large 370 AH 6V lead-acid battery for $330 on their site. Purchasing 4 would give us 1,240 AH which is more than enough for anything we plan to run and will stay within the limits of the maximum suppliable current of the battery anywhere in a 24 hour period.
LED lighting ideas: found 12" by 12" interactive LED squares consisting of 80 LEDs in each piece which used motion sensors to sense when an object (a hand) was close. Build something similar people could walk on? Display something like "ECE" and "Atwater Kent"? Our names? This approach could be kept purely analog with the use of op-amps and RC networks controlling power running through a transistor to drive an LED light (light up when there is motion, and slowly dim down after object disappears).
Another interactive idea was the production of a large cube of LED lights driven by a computer or large microprocessor. this approach could scroll text, produce 3D objects, rotate text around an axis, etc...
Links and attachments are soon to come.Entered by Stephen Hansen on 09/05/2011 11:48 PM
Attached Links
Video showing a general idea of our LED display idea. We are planning on using a digital driver circuit to control the display and analog circuitry to deal with proximity sensing.
Link Entered by Stephen Hansen on 09/06/2011 04:03 PM
These are the 6V Solar Deep Cycle Lead Acid batteries we found during this meeting and are planning on using them to store the energy needed for our final project to draw power from. The solar panels we will be placing on the roof of AK will be charging these giant batteries.
Link Entered by Stephen Hansen on 09/06/2011 04:37 PM
End of Entry
Minutes Dated Tuesday August 30, 2011 02:00 PM
First meeting with Bitar
Location: Professor Bitar's Office
During this meeting, the possibilities for our project were discussed amongst the 4 of us: Myself, Brandon, Jordan, and Professor Bitar. The general theme of the project is "Interactive energy display for Power Panel Lounge". The following week until the next meeting, our group will discuss how power will be generated (solar power?), stored (batties? supercapacitors?), and also what sort of device will we be powering.
The general consensus was that our main output was going to be some sort of LED lighting. The question is how many and how powerful are the LEDs we are going to be powering? Some ideas tossed around about the LED lighting included using red, green, and blue LEDs to change the overall color of the lounge to any color.
For the first week, we will brainstorm and try to come up with some sort of a plan that our group wants to pursue.Entered by Stephen Hansen on 09/05/2011 11:02 PM
End of Entry