Charlieplexing 7-segment displays is more or less the same as doing it with discrete leds, but with some changes to handle the fact that all the led segments have a common pin instead of being separate, and the need for buffering of the common output so the poor microcontroller can cope with the load.

Step 1: Why

While building a quick n' dirty pulse generator that I needed to test coils for a HV power supply I decided that it'd look more funky if I used a 6-digit seven segment display instead of the ubiquitous and boring LCD display.

Due to a shortage of available i/o-pins on the Atmel Tiny26 that I've used for the pulse generator project I couldn't use the standard multiplexed way of doing this. The standard multiplex would require 14 i/o-pins - 8 for the segments (don't forget the dot) plus 6 for the common anode/cathode of each display.

By Charlieplexing the displays I only need 9 i/o-pins and the displays are still muxed in a 1:6 way acheving the same brightness as standard muxing. Charlieplexing usually only light up one led at a time thus giving a reduced brightness if you want several leds to be (visibly) lit at the same time.

Of course I could have used a BCD-to-7segment decoder chip (74LS48) plus a 1-to-8 decoder (74LS138) but that would have been cheating, and i didn't have any '48ths as hand and I really wanted to be able to fit the pulse generator in an Altoids-like box.

Step 2: Disclaimer for Bad Design Practices

Normally you must connect leds via a current limiting resistor in order to keep them alive for more than a few milliseconds.

Here I'm not using any resistors since the display is connected to the output pins of a microcontroller that normally can't sink or source more than a few times the current the leds/displays can handle continuously. Since we're multiplexing the displays they will only be on for 1/6'th of the time and can handle much more current than if they were on all the time.

In the following schematics and in my construction I've left out the current limiting resistors, both for the leds themselves and also the base resistor for the transistors.

Please note the followingIt is a really bad construction practice to skip the current limiting and rely on luck and that duty cycle combined with the relatively low sink capability of the processor and the probable underrating of the leds maximum specs.

In anything that you do professionally, or just want to keep running for an extended period of time (longer than your first test run) one should adhere to good construction practices, read the datasheets and to the maths.

And read rgbphils comment about running leds over the rated current in the comments section of this instrucatble.

Step 3: Normal Multiplexed Displays

The displays I'm using here is of the Common Anode -type. That means that all the segments have a common positive pin. In order to light one segment you connect the common pin to plus and one or more of the segment pin(s) to minus.

A normal multiplexed display have all A-segments connected together in one line, and then all B-segments and so on. The common pins are then connected individually to the microprocessor. This makes eight lines for the segments and one line for the anode on each individual display.

Step 4: Charlieplexed Displays

As shown in the previous step we needed 14 (or 16 if we had 8 displays) connections to the microcontroller to control 6 displays.

If we instead use the Charlieplexing technique we can reduce the connection count to just 9, this regardless if we have 2, 3, 4, 5, 6 ,7 or even 8 displays.

The drawback of using Charlieplexing is that the connections to the displays is a bit more complex and the software that will scan each display one by one will also become somewhat more complex. But hey! If you can save 7 output pins on the microcontroller I think a couple of more lines of code is a cheap price. As you can see in the software step in this instructable the scanning software isn't really that complex and can easily be implemented in your language of choice.

The hardware is actually the same as in the standard multiplex example only some of the connections are changed.

The major change is that an additional line for the segments is added. On the first display the new line is connected to the A-segment, on the second display the B segment and so on. All other segments are connected as usual. All A's together, All B's together (with the exception of previously mentioned specials)...

The transistor for the first display is then connected to the the line where the A-segment should have been. The transistor for the second display is connected to the line where the B-segment should have been and so on.

To address on of the displays now the processor have to first output a high value on the line that its transistor is connected to, then output a low value on the lines that are connected to the segments that should be lit and disconnect (high impedance) the lines for the segments that should be off.

The last part is the most important here, because if the processor would output a high level for the segments that should be off the transistors connected to those segments would also be activated and cause some other displays to be activated at the same time. And that is not a good thing. Multiplexing always relies on that only one display at a time is activated. One by one in a rapid fashion so the brain/eyes gets fooled and thinks that they are all on at the same time.

Since each display is connected in a slightly different way than the others the scanning software must handle this by special code for each display.

Step 5: The Software

Here's the code written in C for the Atmel Tiny26-processor. It should be really easy to adapt to any other Atmel processor. I don't think that there would be any major obstacles to convert to some Basic dialect for the Microchip PIC processors either. I leave that as an exercise for the readers :-)

You might notice that I've allocated the i/o-ports for the display a bit strange, the reason for that is that the ports not used here is used for other purposes in the project that I'm using this display for. If you want to rearrange the ports it's really easy, just change the #defines remembering to update the A/B-suffix on the names so you won't miss to move them between the groups later on in the code.
It might sound a bit strange and hard to understand what I've just said, but look at the code and ask me if you need any help. I'd be glad to help.

matseng, this is a cool manual and very useful for multi-display projects. I'll need to use one myself soon, so thank you for the schematics you posted. Even if you're generally familiar with how this works, it's almost impossible to put this together properly without constantly looking at the schematics. I'll be sure to have yours printed and pinned to the board while I'm doing it.

There is only one critical comment I have thought: this is not Charlieplexing! I don't mind calling this approach Matsengplexing for future references, but actual Charlieplexing requires you to switch polarities of the LEDs around thus achieving an enormous amount of LEDs connected to limited amount of I/Os, such as 4 I/O to 12 LEDs. Switching polarities is not possible in LED matrices like these 7-segs where all 8 LEDs share a common cathode (or was it anode?) . Using actual Charlieplexing you would be able to light 72 LEDs from 9 I/Os, meaning more than 10 digits and two digital points. But of course, noone makes 7 segment indicators with all LEDs separately pinned on the back, so it's purely theoretical. Matsengplexing is the only approach possible.

Yo dude, I have a TI MSP430 with 8 I/O pins n I'm trying to control (4) 7-segment displays. I only need the 7 segments (no dot) and it seems according to this way of charlieplexing that it might be possible after all. Could you help me understand how exactly the charlieplexing works in simpler terms. It seems to me that if you power one of the segments with another segment's transistor on the same wire, you'd get some unwanted results, unless i'm totally confused.

I was quite confused at first, but I think I've got it. The real trick is to realize that the uCPU lines are actually tri-state: high, low, and high-impedance (disconnect). This design takes advantage of all 3 states. Using this matseng has used HIGH to select a display and LOW to select a segment:

1. The "sink" on each display is connected to a DIFFERENT line (look very closely at the diagram). You drive this line HIGH to select the display.

2. Now, the actual segments are wired almost like normal, except that one of them will no be connected to the new data line (the one that would have been connected to the line you just drove high). You need to drive the segments you want on LOW.

3. Unlike a standard design, you MUST set the segments you don't want enabled to high-impedance (singe high would select a 2nd display, and low would select another segment).