Sign In
Forgot Password?
Sign In | | Create Account

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.

RTOS, watchdog, LED

More Blog Posts

About Colin Walls Follow on Twitter

Colin WallsI have over twenty-five years experience in the electronics industry, largely dedicated to embedded software. A frequent presenter at conferences and seminars and author of numerous technical articles and two books on embedded software, I am a member of the marketing team of the Mentor Graphics Embedded Systems Division, and am based in the UK. Away from work, I have a wide range of interests including photography and trying to point my two daughters in the right direction in life. Learn more about Colin, including his go-to karaoke song and the best parts of being British: http://go.mentor.com/3_acv Visit The Colin Walls Blog

More Posts by Colin Walls

Comments 3

Post a Comment
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)

Thomas Bollaert
12:08 AM Nov 7, 2012

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).

Peter Bushell
3:49 PM Nov 8, 2012

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.

Colin Walls
4:09 PM Nov 9, 2012

Add Your Comment

Please complete the following information to comment or sign in.

(Your email will not be published)

Archives

 
Online Chat