RGB LED Matrix

Hi All,

I've been away for a long while but I'm getting geared up to do some fun PIC projects. Last year I made a controller for RGB LED pixels. It basically does stuff like cycle through the colours of the rainbow using only red, green, and blue LED's. Which is actually a pretty interesting project in itself. But now I want to make a big matrix of "pixels" to which I can upload loops of "pseudo-video". The ultimate goal for me is to have a lighting panel that sort of undulates with colour in various ways. I'm thinking the matrix would be good at about 3x8 pixels (at a minimum). I've found some pretty similar projects but not quite what I want to do. Here's one example http://www.instructables.com/id/watc...-pixel-screen/ Unfortunately it doesn't use PIC's but I think some of the methodology is applicable. The only problems with that way of doing it (with the shift registers etc) is that I think it could be quite difficult to modulate the brightness of the LED components using PWM, which I consider a must. I'm currently thinking the best way is to assign a single PIC to each RGB pixel and address them.

So I'm here to see if anybody has any good idea's or has seen something similar.

Hi,

Assume you have a chain of shift registers driving the columns and another driver for the rows. So basically it is row by row scanning. Since shift registers can be loaded quite fast lets assume yours row refresh rate is 120Hz. Therefore you need an interrupt driven routine that advances the row every 1/120 seconds. Now if you can load the current row with a different value within this time you can actually chop of the allocated time for individual LEDs to obtain pseudo brightness control.

I personally use drivers from Macroblock www.mblock.com.tw but used the technique mentioned above crudely. Only problem is bit depth of modulation and memory manipulation. large displays not possible perhaps. Use of asm compare instruction(18F) to chop off led time is required cause pbp compare takes more ins.cyc

Hmmm, OK, I might give that a try, but I'm still not sure if the refresh rate is going to be suitable. I think my previous displays were cycling at about 1ms per cycle and that produced a very smooth display. I guess your suggesting the shift register display could have a cylcle of about 8ms. I haven't seen RGB LED's blend at an 8ms cylcle but I do know I was using mosfets to drive the blending of colour and I found that not all mosfets produced acceptable results (some seemed to be too slow or something). Anyway, I'll do some investigation. Thanks for the suggestion.

Quote:

---

Originally Posted by ERIK

I found that not all mosfets produced acceptable results (some seemed to be too slow or something).

---

MOSFETs are a bit touchy that way. Gotta check the spec on the MOSFETs gate capacitance (or for that matter stray uF due to the circuit design itself).
Depends on what's driving the MOSFET. You might not have an 'active' turn off to the MOSFET, it just might 'bleed down' instead of being driven off. Those MOSFETs that weren't quite up to snuff might benefit from a pulldown (or pullup) resistor across the gate over to the drain or source. I built a circuit awhile back, used P-channel MOSFETs to drive a bank of LEDs. Turn off the driving circuit, everything was just fine, until about 10 minutes later, somehow the LEDs were gradually turning themselves on. Turns out my pullup to V+ on the P-channel MOSFET wasn't good enough. I had a 100K resistor from the gate to V+. Worked fine during testing because I didn't let it sit long enough. Swapped out the 100K for 10K, everything was much better, even the 'blending' as you call it looked better.