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 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]:

LED_state = 0
if LED_state = 0
LED_state = 1
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
flags = 0xff
if LED_state = 0
LED_state = 1
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.

Post Author

Posted November 5th, 2012, by

Post Tags

, , ,

Post Comments


About The Colin Walls Blog

This blog is a discussion of embedded software matters - news, comment, technical issues and ideas, along with other passing thoughts about anything that happens to be on my mind. The Colin Walls Blog

@colin_walls tweets

Follow colin_walls


3 comments on this post | ↓ Add Your Own

Commented on 7 November 2012 at 01:08
By Thomas Bollaert

This is contrary to what the Doctor said!

“Don’t blink. Blink and you’re dead. They are fast. Faster than you can believe. Don’t turn your back. Don’t look away. And don’t blink. Good Luck”
Doctor Who – Blink (2007)

Commented on 8 November 2012 at 16:49
By Peter Bushell

You could get it to blink continual status messages in Morse! Then, complete failure would be either garbage or complete failure to blink at all (for a specified time).

Commented on 9 November 2012 at 17:09
By Colin Walls

Nice idea Peter. It had crossed my mind, but I suppose that rates as a “complex duty cycle”. The user’s manual would make interesting reading.

Add Your Comment