8x8 Matrix Red/Green LEDs photos by Gary Fixler click images for 2048x1536 versions (~100-400kb/ea.)

Today, 16 8x8 matrix red/green LED displays from Futurlec arrived in the mail. The price had dropped from over $4/ea to under $2/ea for a special they're running, so I ordered enough to make a 32x32 LED display wall. All total, they cost about $30. $35.40 with shipping. As with the Alphanumeric LEDs from Electronics Goldmine, I had to take some artsy photos. At 32mm square, the 4x4 signboard will be 128mm square (5.04"). With 24 pins per display, that's 384 pins total. The faces are a bit chipped up, some pins a little bent, probably from being stored in bins. No biggie.

The backs have a neat metal-under-resin reflectance that won't be visible in the final design. Makes me think clear PCBs would look awesome. Google gives me nothing for clear, transparent, or see-through PCBs or circuit boards. Perhaps I've found a new modders' niche market? I was able to test one of the displays with a 3v battery pack and some clipwires. The LEDs work great, and are very bright. I especially liked finding that the 24 pins are divvied up into 3 sets of 8. One set is the common anode, the other 2 sets are the red and green cathodes. If I clipped a common anode to positive, I could run the other clip across the 12 pins on one side, and it would flash through the red and green values of one half of a row in alternating order (red, green, red, green). It would skip whenever I hit another common anode. If I ran it along the other set of 12 pins, it would do the other half of that row (or was it a column?). If I did it very quickly, it looked like an orange dot animating across the display. Woo hoo.

I really want to rig this thing up in a scanning fashion. Ideally, I'd just run through every pixel in a row, then every pixel in the next, etc., and then loop. If a light should be on, flash it, and if not, don't. Also, I want to store brightness. With 5-bit sequential counter ICs I can easily use a single pin each for row and column selection, especially since I'm looping. I've been looking everywhere for 5-bit counters, but they seem to only come in anything but. The most popular are 4 and 8, of course, but I'd love to get away from needing to use a reset pin for each. Otherwise, my 8-bit microcontroller is down to 4 pins, which I'd use for 16 levels of brightness, most likely with a binary ladder network of resistors. If I can get away with no reset, that gives me two extra pins to play with, maybe for serial communication?

Say this was only 10x10. I could easily rig up 2 4017 decade counter dividers, one each for row and column selection. Then I just use pin 1 to clock the column, and after 32 clockings, I clock it again to loop, and clock the row 4017 once via pin 2. That would also loop at the end of the rows. No resets needed, and very fast (I think). If I can't find or design a simple 5-bit sequential counter, I'll have to reset each counter manually after I hit the 32nd bit. I'm also realizing that a 5-bit sequential counter would require 32 output pins. Maybe I'll look for 5-bit binary counters, and demux them (or is it mux? I can never keep those straight).

One more pin sent through a 2-bit mux (demux?) can let me pick red or green for a particular element, so that's also easy and fast (again, I think). I don't know yet, but it might be best to run through all of one color first, then all of the other. This way I'm not wasting time with 2 switches between for every pixel while scanning. I'm thinking I could even rig it so it does every other row, and then goes back and fills in the rest, interleaving like a television, to help reduce any flicker if it becomes a problem. In fact, I could do that and couple it with running the second color the opposite way, also interleaved. It would mean a more complex coding for the software, but once in the PIC's memory, the scanning each pin would function the same. It would just require wiring it that way. I could even use jumpers or double-pole dip switches to rewire it on the fly and just choose a different scanning approach either by reprogramming the PIC, or leaving a pin or two open for button selection of scan-type. Or not.

I don't yet know how to communicate with a PIC microcontroller via RS-232, and I'm not sure how fast it would be with so much data. If I just do red or green, I'll need 1 bit per LED - on or off. Since I want red and green, AND orange (what red and green together become), I'll need 2 bits per LED, for off, red, green, or orange. That's 2048 bits for the whole screen, and that's not counting the 4 bits of brightness I'd like, ideally. That makes it 8192 bits to store for a single screen image. That means I need exactly 1024 bytes of ram, somewhere. That also means if I want to change the entire screen, I have to change 1024 bytes of data. I don't think RS-232 can keep up with that at a decent framerate, but I don't know for sure. Obviously I'm looking forward to playing animations, animated icons, scrolling text, et al on this thing :)

Another thing I'd like to know is how fast I can communicate with the RAM. I haven't done any research or experimenting on this front. I did hook up a little ram chip to my BASIC Stamp, and that worked fine, but I did no speed testing, and dismantled it soon after to prototype other things unrelated to RAM. I don't know if I can continuously read from an external RAM device at speeds high enough. Most likely. I'm sure (okay, I hope) Microchip makes PICs that have onboard RAM sizes of 1024 or higher. I believe I only need exactly that.

My thinking behind the animations is FIRST: get it so it can scream through all the locations in RAM and display a single image from memory at blazing fast speed using the scanline approach, and SECOND: figure out a way to change the contents of RAM on the fly, either all at once between frames, or sequentially alongside its scanning. The latter would mean I update the contents of memory just behind the scanning line, bit-for-bit, or in trojan orbit with the scanline, where I'm updating the bits on the other side of ram while it's scanning a half-phase away. The former would be easier from a programming standpoint, but would require a fast-enough routine that all 1024 bytes could be changed without lagging the start of the next frame. I'm assuming this will be PC controlled, and so programming on the PC end will control frame rate. I just want it so when I tell the chip to replace its ram with the incoming data, it does it in a blink before the next frame starts drawing. Don't know if RS-232 is that fast, though. I'm thinking 30fps, if you're wondering. Wishful thinking, perhaps.

This tower of LEDs brings up another interest of mine. Once I get this and the 45" alphanumeric display bar working, I'd like to branch out and see if I can create more organic shapes with LEDs. I'd really like to see a curvy object with leds all around it in a less rectangular matrix pattern, still able to display text and imagery all over it. I'm guessing and hoping that in the future, when LED technology gets much better, we'll somehow figure out the embedding of surface mount LEDs in stretchable, or even heat-shrinkable matrix surfaces. Then we can have any shape of object whirl with colors, change patterns, or act as a highly sophisticated mood lamp. You heard it here first.

If this didn't bore you into a sound sleep, don't forget to check out the pretty pictures in the alphanumeric display gallery. It sure will be fun when work lets up enough for me to actually make these work in the manner in which they were originally intended, using electricity and whatnot.