Jurek and the Amazing Techno, Colored DreamWall

Jurek and the Amazing Techno, Colored DreamWall

The title is mostly a placeholder, as I haven't really figured out a name for it yet. This project is a wall hanging that consists of semi-large triangular pixels using discrete RGB LED's and PWM to control intensity levels of each LED, resulting in a 4096-color display.

Friday, April 14, 2006

Driver board success

Sorry for the lack of updates this week. Lots of stuff going on and it's nice outside.

Driver Boards
So several hours after I made Saturday's post about getting 30 LED triplets done, I finally got the driver board with 4 driver chips communicating properly with the microcontroller. There were several levels of debugging involved.
  • The first was physical. There were two or more communication wires that weren't terminated properly on one end, causing the driver board to not be getting the correct signals. Time To Fix: ~1.5-2 hours (eek)
  • The second was logical. The /RST line going into the boards was being pulled low instead of high. I thought I had hooked it up to a power pin on the microcontroller starter kit board, but I guess I had it hooked up to ground. Time To Fix: ~20 mintues?
  • The third was functional. There were a lot of coding changes that needed to be made to get the uC to talk to 4 chips serially and found several "inconsistencies" with how I was doing it before with just 2 chips.

Programming Issues
I had the TWI slave device address set to active-low, meaning that the port that was low was the active chip. In a 2-chip situation, this wasn't an issue because one was low and the other was high. This was an easy fix; just point to the correct address (0x24 instead of 0x20).

There were a lot of "issues" I thought I was having with software that ended up being the wiring issue above. This caused me to spend most of my time debugging software, trying to figure out what was wrong. In the end, I figured it out, but I had been barking up the wrong tree. As such, I had lots of fun ripping out all the debugging code.

I had been storing each LED intensity value as an unsigned int (hah!). This is 4x the amount of storage space per LED that I needed. 4 bits needed vs. 16 bits per unsigned int. I then converted it to use 1 unsigned int per pixel, leaving only 4 bits per pixel wasted (instead of 36). However, this increased the overhead to store/retrieve the value of any given LED intensity, as I now needed to go through encoder/decoder functions.

I was still having issues getting each pixel to display a random solid color. I would get one of white, green, magenta (red+blue), or black. At first, I was scratching my head as black should have never been coming up. Then I realized that the processor was only 8 bits and an int would only be 8 bits as well. After some calming (count 10... 9... 8...) and looking in the processor spec, I finally find that ints really are 16 bits wide. I spent a little bit of time using the debugger to see if red, green, and blue were getting encoded and decoded properly (it appears they are). I still am not sure why red is showing up as black and blue is showing up as red+blue (or the other way 'round). Hopefully another debugging session will fix all of this.

LED Triplets
Some small progress to the soldering fun. Not much, but 1% is 1%.



Anonymous Anonymous said...

Who knows where to download XRumer 5.0 Palladium?
Help, please. All recommend this program to effectively advertise on the Internet, this is the best program!

Wednesday, November 18, 2009 8:31:00 AM  

Post a Comment

Links to this post:

Create a Link

<< Home