Windell,

Just wondering why you didn't use a grayscale LED driver (like the TI tlc5940) when you were designing the board.

Version 3.0 perhaps? It would only take 5 of those chips to drive a 25X25 RGB array

That's actually one of the chips that we looked at. It costs more but sure sounds great.... Well, at least until you read the data sheet.

Let's suppose that we're just trying to drive a Peggy 2.0 with it: a 25 x 25 array of LEDs. That means that we need two driver chips, which gives 32 total channels available. To drive a multiplexed array with the TLC5940, we'd need to use the 192-bit sequence for each chip, a total of 384 bits. At 4 MHz, that gives 96 microseconds per refresh, or for 25 rows, 2.5 ms total. Assuming that we refresh the screen with 100% efficiency (a very bad bet-- every transfer has overhead) we might hope to approach 400 Hz refresh rate. So even at best you could hope for, that makes a pretty blinky screen to look at.

Compare this to the ones that we're using that require a 32 bit sequence, all together, so we get a refresh rate much higher. (In principle it should be 5 kHz, but in practice we see 2.5 kHz or so. This suggests that the TLC5940 would really give us 200 Hz or so.) The refresh rate that we get is actually quite comfortable for fast animation, even with modest levels of PWM grayscale.

Now, ignoring how much it would hurt to look at the display based on the TLC5940, let's move on to the next issue: memory requirements. To fully use the 12-bit gray scale, we'd need 12 bits for each LED. In practice, the overhead from using every bit would be pretty uncomfortable, so you'd want to use a 16-bit integer to store each brightness level, which gives 625*2 bytes = 1250 bytes of RAM taken up to store the screen buffer. Doh! The AVR only has 1024 bytes. Supposing that you went through the overhead anyway, you'd need 625*12 bits /8 = 938 bytes of the RAM to store the screen buffer. That may or may not leave enough left over to actually run in the Arduino environment-- I don't know. But it would leave very little space for variables, and almost none for moving data into our out of the display buffer. And, without a display buffer, the refresh rate would be even lower. So, you'd have to compromise, down to the level of 8 or even 4 bits of gray information

For RGB, things get a lot worse. The bit sequence to drive one row is 960 bits-- 0.24 ms for a single row, and the max refresh rate is only 166 Hz, assuming that we have near-zero overhead, a much worse bet for monster transfers like that. In practice, this would be blinking at 80 Hz or so and would *really* hurt to look at.

Also, we'd need much stronger row drive transistors ($10-$15 extra) and don't forget that 625 RGB LEDs at (a very good price of) $0.40 each cost a total of $256 and take *twice* as long to solder. So... the argument that you would "only take 5 of those chips" is a bit of misdirection; there's really a lot more hardware cost increasing than just the driver chips. Yes, the drivers would be cheap, but with that super-low refresh rate it would sure suck-- Peggy in RGB with 5940's wouldn't be something that *I* would want to spend $400 and that many hours soldering for.

Also: Don't forget that the memory requirements for RGB are three times that of monochrome. At a modest 4 bits per color (and accepting the overhead that comes with multiplexing data within bytes), you'd still need that full 938 bytes of RAM (25 rows*25 columns*4 bits*3 colors/8 bits per byte), which would make it nearly impossible to *use* the matrix for anything.

Now, we *do* have plans for future variations on the theme of Peggy, but maybe you can see that this wouldn't really be much of an upgrade. And while we certainly would consider looking at any driver chip that you happen to point out, we might assert that the modest driver chips that we currently use are actually pretty good.

Wow! Now that's a reply!

A few further questions:

1) You mention driving the chips at 4Mhz, why such a (relatively) low speed? Is that the most the Atmel can actually output in terms of functional data speed?

2) Isn't 400Hz (or even 200 Hz for that matter) far faster than the human eye can tell? I was always told that 60Hz was around the threshold for many people, and at 100Hz 99% couldn't see any flicker. Or does this speed still need to be divided by 25 to account for the row multiplexing?

3) 8 bits a channel is still 256 levels of grayscale, and would only require 625 bytes of memory...which is still a lot. Honestly, I never even thought of this issue. Shows that my head is still in the programming PCs, not embedded mindset. Is the overhead for using say 4 bit values, and packing them two per byte really that high?

4) You can use the TLC5940 in dot correction mode, which only requires 96 bits per chip instead of the full 192 bits for the PWM mode. That would double the effective speed (I think).

5) I'm horrible when it comes to finding discrete parts (especially transistors). Which transistor would you use in place of the 2N5401 if you were looking to source additional current (say an amp or so)?

Since tone always comes across horribly in text communication, let me make VERY clear that I'm not trying to question your logic, simply understand why you chose to do what you did. I've already learned scads about designing LED matrixes from assembling peggy, and only brought up the TLC5940 since I've use it in the PIC world to drive VERY small numbers (~16) of RGB LEDs.

Is there any hope for an Atmel driven 25X25 RGB display? After looking at all your (very very valid) points, I've certainly come pretty close to losing hope.

Thanks again!

1) You mention driving the chips at 4Mhz, why such a (relatively) low speed? Is that the most the Atmel can actually output in terms of functional data speed?

Yes, that's the max speed we get, more or less. We're running with a 16 MHz oscillator (like the standard Arduino varieties) and SPI clock frequency is that divided by four.

2) Isn't 400Hz (or even 200 Hz for that matter) far faster than the human eye can tell? I was always told that 60Hz was around the threshold for many people, and at 100Hz 99% couldn't see any flicker. Or does this speed still need to be divided by 25 to account for the row multiplexing?

Under ideal (lab) conditions, that's true. In practice you *can* see the blinking because your eyes are not fixed in place. This is like those cars with annoying blinking LED taillights-- it's supposed to be solid color, but as you look around, you see blinking spots in space. As refresh rates start to head below 400 Hz, you can definitely tell that it's not solid, even when you can't see it directly. It just feels jittery. There are an awful lot of factors that influence this: duty cycle, peak intensity, how much of your visual field is taken up, and size of the light emitting object. So it ends up that a movie projecting at 48 Hz is okay but if it's a few LEDs blinking at the same rate, you can really tell.

3) 8 bits a channel is still 256 levels of grayscale, and would only require 625 bytes of memory...which is still a lot. Honestly, I never even thought of this issue. Shows that my head is still in the programming PCs, not embedded mindset. Is the overhead for using say 4 bit values, and packing them two per byte really that high?

The AVR memory is actually organized as 16-bit words (that's because the instruction set mostly consists of 16-bit words, and the memory sizes are --usually-- such that 16 bits is enough to address everything). So, even pointing to a single 8-bit number can be more overhead than you expect; there's *always* a tradeoff between faster and more space efficient. If you want to extract (say) four bits from an 8-bit number, there's no single operation way to do it. For the lower four bits, you can use a bitwise AND with 0b1111, which is fast. But for the upper four bits, you need to take a bitwise AND with 0b11110000 and then right-shift by four places. This is terribly inefficient-- it actually takes more than twice as long than it would i fyou "only" wanted to multiply two 8-bit numbers.

4) You can use the TLC5940 in dot correction mode, which only requires 96 bits per chip instead of the full 192 bits for the PWM mode. That would double the effective speed (I think).

Maybe. I'd have to try. It's not one of the intended mdes of usage. Also: it gives fewer bits of gray scale.

5) I'm horrible when it comes to finding discrete parts (especially transistors). Which transistor would you use in place of the 2N5401 if you were looking to source additional current (say an amp or so)?

This is a very tough question. STX790A-AP work well, but are too expensive... keeping everything through-hole is a difficult constraint to work under.

Is there any hope for an Atmel driven 25X25 RGB display? After looking at all your (very very valid) points, I've certainly come pretty close to losing hop

Sure, but we're not necessarily going to make one. We have some tricks in mind to make RGB cheaper and easier, but again it willl be "future variations on the theme of Peggy," not necessarily a 25x25 display.

Personally, I like how simple and old school Peggy 2.0 is. It's perfect for someone just starting out or for someone who is getting back into electronics after 20 years (like me).

The only thing missing is an interface to save and load programs from cassette tapes. :-)