LED Matrix Prototype

[solipsistnation]

LED Matrix Prototype
Originally uploaded by solipsistnation

And here it is in action!

This is the lightbox with the 4 LEDs glued into the back of it. (Note: Hot-melt glue works okay as long as you don't poke the LED too much.) I wrote a simple program to send shifting bit patterns to the controller chip and let it run for a while. It lights up everything along the way.

Things to notice:

1. The lower-left green LED is pretty weak. These were VERY cheap LEDs.
2. Everything is more dim than it should be. I may be doing something wrong. Currently I'm using a breadboarded stripped-down version of the circuit. This should be improved with the real design.
3. The wiring on the back of the LEDs is a nightmare. This is not how it will be in the real thing.

Overall, not a bad start.

Comments

[dariusk.livejournal.com]

Can I see the current and final LED driver designs?

[solipsistnation.livejournal.com]

Current is, uh, sort of ad hoc.

Final, I just drew up (more or less) in Eagle. I'll show you that later today if you're on.

[dariusk.livejournal.com]

Hah, I just wanted to compare so I could confirm that yes, your final version will in fact be brighter.

[solipsistnation.livejournal.com]

I actually think I just realized why it's not as bright as it should be. Either I have fundamentally misunderstood what's going on with my breadboard or the bits I left out to simplify the quickie test version were more important than I thought. (Or there's not enough current available when running it over USB. But the regulator didn't get hot or anything...)

[solipsistnation.livejournal.com]

It's an STP16DP05. It acts as the limiting resistor (more or less) based on what you hook up to its R-EXT pin.

The shortcut I took here was driving the LEDs straight off the digital pins of the atmega chip rather than dropping a transistor in between the pins and the LEDs and running them off the +5V rail (I am borrowing liberally from the schematic in this PDF). I think that's the deal there, since those pins provide a max of 40mA and I'm sticking a 60-75mA load on them (I also need to make sure I'm disabling the built-in pull-up resistor on the digital pins). Yeah, now that I've actually thought about it and done the math, that seems likely to be the problem. I'll give it a try the right way tonight.

[solipsistnation.livejournal.com]

Okay, cool. That matches what I thought I knew and what I read. I'm attempting to run the LEDs at ~20mA each, but with 3 per atmega pin, that adds up. The RGB LEDs are common-anode... I was trying to skimp out on breadboarding last night, and I learned something in the process! Hooray! (Part of what's going to probably cause problems as this gets more complex is that I'm basically doing cargo cult electronics design here-- if I make it look sort of like the thing I want it to be, it'll magically happen! I'm not quite THAT clueless, but I'm finding gaps in my knowledge. The transistor thing was a big one, I guess.)

Sooo, you mention PWM... The MeggyJr RGB does PWM in software (tying the LED update to an interrupt and keeping track of 16 levels of brightness per LED). That's the library I'm going to adapt to my thingy. The short form is that it updates about 150 times per second, and each time each LED is either on or off depending on the brightness level to which it's set in RAM. The potential color depth is pretty much limited by CPU speed (16MHz, baby) and how fast you can shove bits down SPI to the chips. MeggyJr is only 8x8x3, for a total of 192 bits. My matrix will be 16x16x3, for a total of 768. It does only update 48 per pass (16xR,G,B) but the result is that the interrupt will take twice as long to run and need to run twice as many times to update the whole screen (48 bits, 16 rows). I may have to lower the possible color depth to 0-12 or 0-8 to keep it updating smoothly, without flickering.

There are ways around this-- TI makes some SPI-bus PWM 12-bit-per-LED controllers that you can just push levels to, but that ends up being a lot of bits. Of course, you only have to do it per change. But since there's only one SPI port on the atmega[16/32]8 it would mean each update would take longer. That might be mitigated by now having to update 16 times to PWM out the gradations of color... I'd have to sit down and do the math on that one.

Part of how I'm designing this, though, involves keeping the LEDs on the other end of a ribbon cable from the control hardware, and making sure anything I might want to upgrade later (like the LED driver chips and the board they're on) I think the 4-to-16 demux and driver transistors are going to end up on a daughterboard, too. If I end up finding better ways to do things (which is pretty likely, considering), I can swap out parts without needing to redo EVERYTHING.

Thanks for you help with this, by the way. I'm glad this mostly makes sense to you.

[solipsistnation.livejournal.com]

That's a good question, about SPI. I know the SPI pins (like most of the atmega pins) can serve double duty as digital IO pins. Looking at the datasheet, it appears that it's a hardware SPI controller, I think for the sake of the clock. (You could fake that too, I bet.) I do have 3 chips here, but it's a total of 48 bits so it's not too bad to update in one shot.

Bypass caps are on there. That's one thing I found with the schematic-to-board transition in Eagle, too-- I put the nice little bypass caps next to the chips and tied them into the +5V and GND nets, and they ended up, when I transferred it to the board design, tied into the +5V and GND nets in random weird ways that aren't actually very useful or particularly close to the chips they're supposed to be protecting. Now I see where this gets REALLY complicated... It does feel like a video game.

Interesting about the drivers being close to the LEDs, too. Hm. Maybe I should shield it or something. I think with the matrix being that big, there's not going to be much avoiding having a giant mesh broadcasting RF interference. The ribbon cable shouldn't be more than a couple of inches long. It's the wires out to the LEDs that get hairy. I still have to figure out how to do that cleanly-- hot glue keeps them in place, but I need a way to make sure that if I squish the back onto it (even with the gap) the leads can't short each other out. It might be cleaner to use little chunks of perfboard, one per LED, and connect wires to those. That's probably better than naked leads poking out.

[dariusk.livejournal.com]

I WANNA SEE SCHEMATICS!

[solipsistnation.livejournal.com]

GET ON AIM. (Oh, you're probably at lunch.)