Secrets for designing with flashing LEDs
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.