Maker Pro
Maker Pro

64 LEDs set out in a square?

DrBwts

Dec 7, 2013
12
Joined
Dec 7, 2013
Messages
12
Hi All,

I would like to control 64 LEDs set out in an 8 x 8 square.

I'm not after a LED block matrix as the LEDs will need to be quite far apart from one another.

I was wondering if it was possible to control such an arrangment with 16 digital output pins?

Had a look at using the Aduino Micro which has 20 pins on offer.

Any thoughts or help would be appriciated. I have a basic electronics background.

Thanks
 

KrisBlueNZ

Sadly passed away in 2015
Nov 28, 2011
8,393
Joined
Nov 28, 2011
Messages
8,393
Yes, you can do this with a technique called multiplexing.

Your software drives the LEDs one column at a time. It outputs the eight control signals for the leftmost column on its eight row drivers, enables the leftmost column, and waits for a short time. Then it disables the leftmost column, outputs the control signals for the next column on the row drivers, and enables the next column, and so on. When it has done the rightmost column, it loops back to the leftmost column.

If the whole loop is performed at least 60 times per second, persistence of vision makes it appear that the LEDs are steadily lit.

Multiplexed display driving is often performed using a timer interrupt, since there is very little code required on each update.

From a hardware point of view there are several things to consider regarding driving the LEDs.

Since an illuminated LED will only actually be illuminated for one eighth of the time, you need to drive each LED at a current roughly eight times higher than the current that gives the desired brightness. This could be as much as 200 mA. So you need transistors or MOSFETs to drive the rows, unless you want your LEDs to be quite dim (or unless you use high-efficiency LEDs, which are expensive).

The column situation is even worse, since there could be up to eight LEDs illuminated in the column, each running at up to 200 mA. So you definitely need transistors or MOSFETs to drive the columns.

The forward voltages of the LEDs are important because they determine whether you can run the LEDs and the MCU from the same supply or not. In a typical application with a 5V supply rail, you can drive LEDs with a forward voltage up to about 4V. The remaining voltage is dropped across the series resistors, which are connected between the row drivers and the LED matrix.

If the LED forward voltages are higher than about 4V then you need a second supply rail with a higher voltage, and you need some kind of level translation to convert the 0V/5V signals from the MCU to a higher voltage to control the drivers.

You can save five pins on the microcontroller if you use an external 3-bit binary decoder such as a 74HC138. This accepts a 3-bit number and activates one of eight outputs according to the number at its input. So instead of the MCU driving one of eight column control signals active for each column, it provides a 3-bit number to select the column it wants.

Multiplexing is a widely used technique and you will find lots of information with a Google search with appropriate keywords.

If you have any specific questions, please tell us more about your application and we will be happy to answer them.
 

KJ6EAD

Aug 13, 2011
1,114
Joined
Aug 13, 2011
Messages
1,114
Many LEDs can't be driven at 8X their rated maximum at such a high (12.5%) duty cycle without being damaged or destroyed so for full brightness a shift register is often used as a buffer to hold control values from the MCU.

A TPIC6B595 for example is often used as a column driver in arrays.
 
Last edited:

DrBwts

Dec 7, 2013
12
Joined
Dec 7, 2013
Messages
12
Thanks for the speedy replies.

I did a Google search on multiplexing LEDs (thanks Kris) it seems straight forward enough.

So what is the issue with the current & how would a shift register help with that?
 

KJ6EAD

Aug 13, 2011
1,114
Joined
Aug 13, 2011
Messages
1,114
Look at the data sheet for an LED. You'll find current limit, pulse width and duty cycle information there.

The shift register can drive a column continuously at a safe full brightness current level while getting updated by the multiplex output from the MCU.
 
Last edited:

KrisBlueNZ

Sadly passed away in 2015
Nov 28, 2011
8,393
Joined
Nov 28, 2011
Messages
8,393
Good point KJ6EAD.

He is talking about driving the LEDs continuously, using serial-to-parallel shift registers, or dedicated LED drivers that are configured using a serial data stream.

A simple approach is to use shift registers, such as the 74HC595. A data sheet is at http://www.fairchildsemi.com/ds/MM/MM74HC595.pdf

These devices receive data through an SPI (serial peripheral interface) connection, which uses three signals: data (called SER on the Fairchild data sheet), a serial clock (SCK), and a latch clock (RCK).

The MCU clocks eight bits of data into the 74HC595, one at a time, using SER and SCK. The 74HC595s can be cascaded, by feeding the serial data output (Q'H) of one into the data input of the next. This creates a 64-bit shift register.

Once 64 bits of data have been clocked into the cascaded devices, the MCU transfers new data to the output latches in the 74HC595, and therefore to the LEDs, by pulsing RCK. This whole process needs to be done every time any LED state is changed; typically it's done at regular intervals.

The outputs that drive the LEDs are continuously enabled, and the LEDs receive a steady current, instead of bursts of high current which could damage them.

The 74HC595 is just a generic logic IC and it can't provide a high output current, but there are dedicated LED driver ICs that work in the same way.

Shift registers are a generic way to expand I/O capacity. They are slower to update than I/O ports, because the data must be clocked in serially. Some MCUs have an SPI peripheral built in, which takes care of converting data to serial form and clocking it through an external device like a shift register.

If you don't have an SPI peripheral in your MCU, you can speed up the transfer of data to a group of shift registers by driving the SER input of each shift register from a separate I/O pin on the MCU, and clocking them all together. This requires eight I/O pins for data (one for each 74HC595), plus two more for SCK and RCK. It means only eight clocks are required to update all eight shift registers, instead of the 64 clocks that would be required if they were cascaded.

There are other approaches you can take. For example, you could multiplex the LEDs two columns at a time, instead of one column at a time. This would reduce the LED current to about four times the average current needed to achieve the brightness you want, at the expense of another eight control outputs. You can also use one or more shift registers to drive the columns, to save on I/O pins, but still use multiplexing by 4 or 2.
 

(*steve*)

¡sǝpodᴉʇuɐ ǝɥʇ ɹɐǝɥd
Moderator
Jan 21, 2010
25,510
Joined
Jan 21, 2010
Messages
25,510
how would a shift register help with that?

A shift register allows you to use a small number of pins on your processor (1 to 3) to control an arbitrary number (essentially unlimited) of output pins.

The device suggested (I assume the same as a 74HC595) is a shift register with a latch.

You send out (in your case) 64 states, one at a time and they filter through all the chips. Then when you have them set up, you activate the latch and all the outputs change to your newly loaded values.

This allows each output to drive a single LED (or more complex stuff if you require)

Because they're not multiplexed, the driving is simple, just a resistor.

As an aside, the specs of some LEDs will include a graph showing you maximum current on one axis, and pulse duration on the other. This allows you to determine the maximum current which can be used safely during multiplexing. I've seen it as high as 1A per LED for short duration pulses. However, the problem is, if your code ever locks up and fails to keep multiplexing the display, the LEDs that are stuck on will burn out *very* rapidly.

Generally speaking, it is the temperature of the die which is a major factor in the aging of the LED. Within reasonable limits, maintaining the same dissipation by increasing the current and reducing the time is OK. There are a couple of caveats though. Firstly, the colour can change when the LED is operated at higher current (this is typically true of LEDs which use phosphors to create a particular colour. Secondly, the light output may increase at a rate slightly lower than the increasing current. Thirdly, the forward voltage increases with current. Two and three provide a theoretical upper limit to the multiplexing because it eventually becomes impossible to achieve the desired brightness without exceeding the dissipation limits (At this point you may also be at or beyond the absolute maximum current for pulsed usage of the LED).

The question becomes... How far can you push it?

For High power LEDs, the limits are easily reached. CREE provides this advice. It boils down to -- You can double the current for 50% duty cycle at 1kHz, but the limit for triple the current is a 10% duty cycle. They provide a lot of interesting information about current crowding and migration of the metals used in the bonding connections for the device.

For lower power LEDs, you can go further. Here is a recommendation as to how to handle a particular type of 20mA LED. Notice that the upper limit allows 100mA peak current. Also notable is the observation that the LEDs degrade much faster, but are effectively on for less time, so the degradation over 100,000 hours is roughly equivalent.

The other question you have to ask is "Do I need my device to last 100,000 operating hours?" If the answer is Yes (say for a digital clock) then you need to keep strictly within the limits. If you answer is No (Say for an emergency beacon that may only have a required life of 100 hours) then you can push things a little harder.

With the increasing efficiencies of LEDs, it is rarely a requirement to push LEDs as far as it may have been in the past. One exception is in remote controls, but the chance that you will have your finger on a button for 100,000 hours is pretty small :)
 

KrisBlueNZ

Sadly passed away in 2015
Nov 28, 2011
8,393
Joined
Nov 28, 2011
Messages
8,393
... maximum current which can be used safely during multiplexing. I've seen it as high as 1A per LED for short duration pulses. However, the problem is, if your code ever locks up and fails to keep multiplexing the display, the LEDs that are stuck on will burn out *very* rapidly.
Good point.

Lots of very good information in that post, Steve!
 

DrBwts

Dec 7, 2013
12
Joined
Dec 7, 2013
Messages
12
I like the shift register idea thanks Steve I'll look into it. Seems a much simpler way of doing things.
 
Top