Charlieplexing 7 Segment Displays

This instructable describes how to charlieplex a bunch of 7-segment led displays.

Charlieplexing of discrete leds has been the topic of a few other instructables. The Charlieplexing LEDs- The theory and the How to drive a lot of LEDs from a few microcontroller pins comes to mind. They are both excellent and should be read by anyone that wants to gain a deeper knowledge of how charlieplexing really works.

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.

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.

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 following
It 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.

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.

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.

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.