Is Multiplexing ever superior to Charlieplexing?

Question

I've reviewed the two methods, and multiplexing really only appears to have one advantage, that it would be easier to track down a failed LED than in a Charlieplex array.

Can someone more knowledgeable explain any other trade-offs?

Answer 1

Yes, multiplexing and charlieplexing both have their advantages, and are each best suited for different tasks.

The main advantage of charlieplexing is that it can be done on a medium-size microcontroller, driving more LEDs with fewer I/O pins, and potentially no external hardware besides the LEDs.

Now, the advantage of "no external hardware" only applies for relatively small numbers of LEDs, up until you reach the current limit of your microcontroller, and it imposes a brightness limit that multiplexed arrays do not have. If you choose to use no external hardware, you are generally limited to driving only one LED in the matrix at any given moment-- unlike a multiplexed array where you drive a full row at a time.

Once you add external hardware to drive the LEDs with higher brightness to match that of a multiplexed array, charlieplexing loses its luster.

First, a multiplexed array is addressed strictly by row and column; it's very straightforward to do this. Turn on row 1, turn on all columns for row 1, turn off row 2, turn on all columns for row 2, and so on. By contrast, a charlieplexed array is much less straightforward. There's always a diagonal row that's useless, and I personally use look-up tables to relate between my arrays and a rectangular array where I store my data.

Secondly, and a killer, is that charlieplexing generally requires tri-state drivers. Multiplexing, however, is performed with strict on-off binary logic. If you have a low pin count microcontroller and want to drive a large array of LEDs, it's straightforward to use external logic chips (e.g., shift register and/or LED drivers) to control both the X and Y axes. Most shift-register type chips don't support the tristating necessary to do the same thing in a charlieplexed array. Dedicated charlieplexed drivers are available, but are not nearly as versatile.

Third, in a charlieplexed array, every pin that's not actively doing something is still hooked up to the LEDs through a weak ("high impedance") connection. And while the connection is weak, it's nonzero. Suppose that you have 25 I/O pins connected to a grid of LEDs. If you light one LED-- taking one of those 25 lines high and one of those 25 lines low, that leaves 23 high-impedance lines. Each place that the high I/O line goes through an LED to a neutral line, there's some possibility to leak current. Not much. Maybe a microamp here or there. But with modern, efficient LEDs, that's often enough to create visible ghosting.

Fourth, it's harder to control LED brightness in a charlieplexed array. In a multiplexed array, you can use any number of commonly available current-regulating "sinking" LED driver chips that regulate the brightness of each column separately, by using current regulation in combination with a PWM driver. To the extent that charlieplexed matrix locations are addressed individually and use only a resistor per row or column, it's much harder to perform dot-brightness correction and full grayscale/color animation in a charlieplexed array.

Answer 2

The most significant disadvantage of "Charlieplexing" lights is that it limits the number of LEDs that can be driven with 'n'-way multiplexing to n(n-1). I don't see the tri-state driver requirement as being much of an issue with the technique as a whole. Certainly having to use two conventional drivers instead of a tri-state driver will reduce the benefit from CharliePlexing, but in some cases advantages may still remain (e.g. it may reduce the number of interconnect wires between a panel with the drivers and a panel with the lights or switches).

As for Charlieplexing switches, the Wikipedia article fails to mention the biggest disadvantage: Charlieplexing does not allow a controller to passively wait for a button push. On the other hand, it's overly pessimistic about component requirements. In 1997, I produced a device which scans eight buttons using three I/O pins and one input-only pin on a PIC12C508, without need for any external diodes or other components except IIRC a pull-up for a PIC pin which didn't have one built in; the approach could have handled ten buttons with the addition of another pull-up resistor (for another I/O pin that didn't have one), but the customer only need eight buttons so there was no need.