Secrets for designing with flashing LEDs

-February 14, 2017

Almost every micro-based project that I have designed in the past 25 years has had a flashing LED, originally as a “health” indicator, but the feature has expanded to use as a status indicator where the number and length of the flash can impart more information. This technique is very common in providing diagnostic information on low end products where there is only a single LED to provide communication. Devices like furnace controllers spring to mind.



Figure 1 An LED matrix controlled by an ICM 7218 LED Display Driver. I wasn't expected to provide any flashing with these LEDs. I just wanted to reinforce the point that you should be using a lookup table to map the physical outputs to the logical output.
 


Figure 2
A controller for a standby diesel driven pump. Each pair of LEDs was connected in parallel for redundancy (a leftover requirement from incandescent lamps). It followed the normal annunciator format of flashing when an alarm was detected and continuously on when acknowledged - so no fancy flashing codes.

On some occasions I have designed products with quite a few LEDs. Figures 1 and 2 show early ones, but in a recent product (Figure 3) the customer wanted a simple multi LED display (instead of an alphanumeric LCD), and with it, the ability to flash them at different rates and codes. Fortunately only one was bi-colour and I treated it as two separate LEDs.


Figure 3
First protoype of a burner controller. There are 15 LEDs in total, down the right hand side. The STOP/RESET and START buttons along with the LEDs will be designed onto a membrane keypad and no doubt the resulting allocation of LEDs to the connector will not match the outputs that I selected initially. As it is, the customer has moved the relative physical locations of the LEDs twice since this photo was taken.

The device shown in Figure 3 is a prototype with the intention of using a membrane keypad to implement the system in the future. For those of you who have never worked on a real live system, let me tell you a secret. Whatever pinout you select to drive the LEDs, it will change at least once over the life of the project. In this case above, the LEDs are driven from individual ports on the micro, but they could just have been driven from an LED controller as shown in Figure 1. The approach is to write a driver that includes a lookup table so that the logical outputs can be mapped to the physical outputs and subsequently shuffled around with the changes being made in only one place. If that’s all you take from this blog I would be satisfied, but there’s more advice.

Continuing reading on Embedded.com for more advice on designing with LEDs.


Loading comments...

Write a Comment

To comment please Log In

FEATURED RESOURCES