I am tragicallly aware that the Arduino doesn't have 192 PWM pins laying around it's circuity, but that is exactly what I need. I'm working on making an LED cube, 8*8*8, with tri-color LEDs. I'm looking at using the PCA9635 ( datasheet here http://www.standardics.nxp.com/products/pca/datasheet/pca9635.pdf ) but I have one hangup. I don't know how to use the chip. Has anybody used this or any other PWM enabled LED driver? I know I'll be using multiple chips, I just can't seem to find a good introduction to using ICs like these on the internet.
8*8*8*3 is 1,536 LEDs, not 192. That's 2,048 solder points minimum.
I have a feeling you're not going to be able to run this sort of project with anything resembling PWM. PWM relies on being enabled for a period of time, multiple cycles of the pulse frequency, to average out to a given brightness. Then it takes time to tell the PWM driver new data for the next "tier" of outputs, whether it's rows or columns or levels, during which the driver is off. You have to get through all of the rows/columns/levels fast enough to avoid flicker.
Even if all that's true, you barely have the RAM on an Atmel processor to support one byte per LED, not counting any variables to iterate through the rows/columns/levels, not to mention anything to do with animating or receiving new data.
Just for point of reference, people are working with a single layer of 1*8*8*3 LEDs, and it's a bit of work to avoid flicker whether you use PWM or not.
If you don't need I2C, you could look at the TLC5940. There's a fantastic library for it already in the playground. You can chain them together to get more outputs. I've only done 2 chips so far, I don't know if you'd run into any troubles with 12.
Read through the latter parts of this thread for lots of great info on that chip.
It is 192 LEDs. The way it's constructed I have all the LEDs in a vertical column hooked together by their anodes, so a column of eight is essentially a single LED. When I multiplex through their cathodes, that is when the eye percieves them all to be different. Now, take those 64 columns, 8*8, and multiply them by the three colors. After that math, it works out to be 192 LEDs, or it at least looks like 192 to the Arduino.
Hmmm, I didn't think about flicker, thanks man. Say I just want to control the 192 leads using digital, on off logic. What chips would be best for that?
Your math is silly. It's 192 LEDs in each level. It's not "essentially a single LED," it's still a tower of eight devices. The soldering job isn't going to go away just because you say you're going to multiplex them.
One of these parts is 192 LEDs:
And you're going to have eight times that number if you're making a cube of color lights, regardless of how you think you can timeslice the display job.
And as I've explained, just driving one layer, one part like I've pictured, takes about half of the processing capabilities of the Atmel processor at 16MHz. (The other half is ready for communication or animation.) And you're going to try to run eight times that number...
Hmm, if it takes half the power of the processor, I’m glad It’ll only take an eighth the power of my sanguino. Now, if we can’t get back on topic instead of questioning me, what are some damn chips?
Since when does the Sanguino run with 64MHz ?
No, not 64mHz, it's got 64k memory and 64k RAM, so most shortcomings I face with the Arduino can be worked out by using the larger chip.
More RAM doesn't make multiplexing faster. However, it's good to see such determination. Show us your progress
if when you've gotten farther along. :)
I wasn't suggesting faster multiplexing. "just driving one layer, one part like I've pictured, takes about half of the processing capabilities of the Atmel processor" I was suggesting a better processor.
Use the TLC5940 chip. Just 2 of those will let you control a full RGB LED Matrix with PWM.
Alternatively you could use the the 74HC595N shift register, 4 per LED module.
Flickershow: the Sanguino ain't four times faster than the stock Arduino, and it's raw clock speed that matters here. The fly in the ointment that's being alluded to by halley is that the TLC5940's shift register needs to be updated on every PWM cycle. One of the things in my queue of logic puzzles is how to arrange a chain of TLC5940s so the data recirculates on each cycle rather than requiring external updates each cycle. The trick is arranging this such that you can write to the chain when you want to and without necessarily having to write at the full output speed.
Oh, and both you are wrong about how many LEDs there are. Each of the six faces of the cube has 192 LEDs, for a total of 1152 LEDs on 72 5940s. That's 13,824 bits of information that have to be shifted into the 5940 chain each PWM cycle. If you bypass the Arduino language and write directly in C, you can probably get the the sustained update down to sixteen instructions per update, for a data rate of 1 Mbps... implying a maximum PWM frequency of 72 Hz if your Arduino is doing nothing else.
Now, it turns out that writing all eight bits in a bank is a single-instruction task on the ATmega (it's just a register load from memory). This means you can break the total down into eight strings of nine each, and write them each just as fast. Now you just have to write out 1728 bytes each PWM cycle... and you can still do that just as fast as if you were writing a single chain. Peak PWM frequency (if doing nothing else) rises to 578 Hz. I just costs seven more pins and you have to make sure eight of them are on the same bank. If you dial back the PWM update frequency to 120 Hz (which isn't going to flicker for anyone), you still have plenty of processing power to do whatever.
If you have common cathode LED's you can use the Austria Microsystems AS1107 which is almost the same as the TLC5940 except it requires NO multiplexing at all as it stores the data in an internal eeprom area and refreshes itself. All you do is sent it the LED data and it will keep on multiplexing what is in its buffer. This also means you free up clock cycles on the Microcontroller.
It's a fantastic and dead easy chip to work with. You can see a test I did with this chip here - http://www.vimeo.com/2948446
EEPROM means you can't constantly update the display with changes, or it will fail very quickly. I didn't see EEPROM mentioned in the AS1107 datasheet, it uses plain RAM. (The TLC5940s have a dot-correction register in EEPROM which is not the image memory but semi-permanent adjustments in case of uneven lamp brightness.)
Driving a mono-color matrix with no dimming from the AS1107 is indeed super-easy. Not sure how well it would perform for a tri-color matrix, as it is expecting to sink current for 8 segments through common cathodes, but a common-cathode matrix has 24 separate LEDs per cathode, and a common-anode matrix has 24 separate cathodes per anode. This might end up confusing the heck out of the "constant current" type outputs.
While it's possible that we're still misunderstanding the layout of FlickerShow's LEDs, I'm pretty sure he's not talking about the six faces of a cube, but a common three-dimensional matrix, such as seen in this video. http://www.youtube.com/watch?v=Pq0dPLPeQpY - which with 8*8*8 = 512 RGB LEDs, and *3 for 1536 LEDs in total. Since this guy posts his schematics, I suggest FlickerShow start there for project help.
OK ram then. Either way it stores the LED data internally and hence no multiplexing required.
Here is a guy who used one for an RGB display - http://www.truveo.com/RGB-LED-driving-using-the-AS1107/id/3717394723
The AS1107 is a mux’d on-off driver… the AS1112 looks like a TLC5940 clone with higher power dissipation (a useful and interesting thing in and of itself). The datasheet looks very similar to the TLC5940 – does anyone else see anything that makes them think it doesn’t have the 5940’s annoying refresh requirement?
Another thing I find annoying about the TLC5940 is it’s inability to get the same voltage out of each channel and hence non-uniformity of brightness across the matrix. The DOT correction is a pain in the ass.
The AS1112 does look nice. Shame it’s only available in a TQFN package though.
I agree with you that TQFNs are annoying, but Schmartboard makes an adapter board for prototyping with 32-QFNs that it should be possible to solder one down to without killing yourself or the chip.
I found this nice tutorial on YouTube yesterday about soldering SMD components.