Blinking is good

I like simple things. In particular, I like clean and simple ways to solve a problem. For example, user interaction with an embedded system might be something very slick – touch screen LCDs seem to be fitted to everything nowadays. But sometimes a simple LED indicator is enough.

I was entertained to read a blog by Ken Wada on embedded.com recently, where he sang the praises of a simple, blinking LED. This got me thinking about the various nuances of programming such a humble device …

On most hardware designs, an LED is illuminated by setting a bit in a register to 1 and correspondingly extinguished by setting it to 0. This aspect of using such an indicator is quite straightforward. However, there are quite a few details that need care.

The first thing to think about is the control register that addresses the LED. This is likely to have 8/16/32 bits, only one of which controls the LED in question. It is entirely possible that some or all the other bits control other devices [maybe other LEDs]. Typically such a register is write-only [i.e. you cannot read back its current status], so it is necessary to keep a copy of the data in RAM and use that each time an update is required. This can get tricky, if things like reentrancy need to be addressed. Handling write-only ports is quite a rich subject, that I have written and talked about from time to time.

An LED can show that a board is alive and functioning correctly or it can show that an error has been detected. On the surface, it might seem that putting the LED on might indicate “alive”, with flashing being reserved to grab attention to an error. However, a board might easily die, leaving the LED in an on state, even though the software is not doing anything [useful].

Alternatively, the LED could flash to indicate that things are OK, with steady on or off being indicative of an error condition. That approach is alright, but there is no attention grabbing indication of a problem. Also, care is needed with the code used to make the LED flash. It might seem obvious to do this in the timer interrupt service routine. However, it is quite possible to imagine a situation where the interrupt response is fine, but the mainline [useful] code is looping helplessly. If you are using an RTOS, then a dedicated task might be worthwhile. Then, at least, a flashing LED indicates that the task scheduling is being handled, which is some assurance that all is well. Such a task might look like this [in pseudo code]:

FLASH_DELAY = 500

LED_state = 0

loop-forever

{

sleep(FLASH_DELAY)

set_LED(LED_state)

if LED_state = 0

LED_state = 1

else

LED_state = 0

}

 

There is a better way: flash the LED at a modest rate [a “heartbeat”] normally, but faster to indicate that a problem has been detected. One way to do this is to make the LED flash task a little more sophisticated so that it performs the functions of a “watchdog”. In this example, the task sets a bank of 8 event flags each to 1. It is expected that other, critical tasks, check and clear down these flags regularly. If the watchdog task observes that an event flag has not been cleared down, it sounds the alarm – i.e. starts flashing the LED faster. Here is the basic logic:

LONG = 500

SHORT = 50

flash_delay = LONG

LED_state = 0

loop-forever

{

flags = 0xff

sleep(flash_delay)

set_LED(LED_state)

if LED_state = 0

LED_state = 1

else

LED_state = 0

if flags <> 0

flash_delay = SHORT

}

 

I am sure that my code could be optimized, but I hope that it illustrates the idea, which is that, broadly, a humble LED can be used to convey quite a lot of information. I am using just 2 flash rates here, but it might be possible to use more in a meaningful way, along with adjustments to duty cycle. Of course, if you can change the color of the LED and/or have multiple LEDs available, there are many more possibilities.