[dorkbotpdx-blabber] Kicked in the Charlieplex part II.

[Jared Boone]

Charlieplexing will drive n * (n-1) LEDs. If you want to drive 1,000
LEDs, solve:

    n * (n-1)
    = n^2 - n
    = 1000

You'd need 32 pins to drive 992 LEDs (close enough to 1,000, I hope).
Here's a cheat sheet (multiplying the equation out for a bunch of
different available pins):

    4 pins: 12 LEDs (3 LEDs/pin)
    8 pins: 56 LEDs (4.7x, 7 LEDs/pin)
    12 pins: 132 LEDs (2.4x, 11 LEDs/pin)
    16 pins: 240 LEDs (1.8x, 15 LEDs/pin)
    20 pins: 380 LEDs (1.6x, 19 LEDs/pin)
    24 pins: 552 LEDs (1.5x, 23 LEDs/pin)
    28 pins: 756 LEDs (1.4x, 27 LEDs/pin)
    32 pins: 992 LEDs (1.3x, 31 LEDs/pin)
    36 pins: 1,260 LEDs (1.3x, 35 LEDs/pin)

Looks like the biggest gain is at the low end -- when you get up into
the dozens, each additional 4 pins gets you less than a doubling of
LEDs. It's easy to tell how many LEDs per pin you can drive, because
it's simply the number of pins minus 1.

There is an upper limit to how many LEDs you can drive with this method.
I think the duty cycle would simply be 100% divided by the number of
pins. As the duty cycle drops, you have to pulse the LEDs with more
current for shorter periods of time. Of course, this limit will vary
depending on how much instantaneous current your LED and drivers can
handle before they melt.

Some other good references (oddly enough, all from Maxim):

    http://www.maxim-ic.com/appnotes.cfm/appnote_number/1883
    http://www.maxim-ic.com/appnotes.cfm/appnote_number/1033

It's interesting to note that their ICs will drive only a 14 x 10 grid.
This limit is likely a combination of factors -- wanting a component in
a nice, easy-to-use 28pin package, having a part that doesn't melt from
driving too many LEDs, and having a nice, round number of 5x7 characters
their customers can stack.

I would take a cue from Maxim and not try to drive more than a few
hundred LEDs from a single device. Instead, chain together several
simple devices, each handling a chunk of the larger display. Using the
drivers you mention would be a good approach, but keeping each driver
responsible for only a few hundred LEDs. Each block of LEDs would be
orchestrated by a microcontroller (or several). This is not dissimilar
from what Maxim's doing with their ICs.

And now for some crazier ideas. I imagine using an FPGA and separate
driver ICs (to offload the current/heat) which implements a high-level
command set which could be used by a microcontroller. Kinda like an
old-school frame buffer and blitter for LEDs. For instance, "show this
string at x,y", "draw this image at x,y", or even "move this sprite from
x1,y1 to x2,y2 at rate z" (Jumbotron Robotron, anyone?). But that's
probably a bit more elaborate (and time-consuming) than you intended...
Using an FPGA does open up other interesting, real-time image-processing
opportunities. Perhaps it takes images from a Webcam and tweaks them
out, live, for display on the LED grid. Of course, it'd be easier just
to hook up a PC to a video projector. Or maybe be able to drive the LED
grid via USB. But sometimes the easy route isn't the most interesting.

    - Jared

Donald Delmar Davis wrote:
> So I went to my local dive after a week of having my son out engineer
> me (never mind the inherent emotional manipulatio) and I tried to
> reverse engineer the concept thinking that if I could drive 20 leds
> from a $1 cent tiny chip how many could i drive off of a 28 pin  $4
> mega chip.  I'll be damned if my napkin skills didnt fail me.
>
> experiment #1
> repeat the above all ye who still have their hair.
>
> experiment #2
> Given a box of >1000 leds for free drive them.
> hc4049, 74hct595, 599 are all less than $1
>
> :)
>
> experiment #3
> Hypothesise about the effects of 1.5 marriages, 1 child, and 20 years
> of heavy drinking on ones ability to solve problems on a napkin.
>
>
> (I must go look into the abyss of mortgages with a non marital partner
> tomorroe so I think I better sleep)