The simplest possible UI -

The simplest possible UI


It is very easy to think that all embedded systems are complex devices, with powerful CPUs – maybe more than one – and a rich array of peripherals. This might include a screen, on which extensive user information may be displayed. However, there are many systems that are the other end of the complexity scale. Deeply embedded systems typically have no user interface, which is a challenge to the software designer who needs to communicate some simple information to the user. A common solution is the provision of a simple LED indicator. This article reviews how such a humble “UI” can be used to good effect.

Simple Things
Simple things are good. In particular, clean and simple ways to solve a problem are pleasing. 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.

There is a surprising amount of scope to communicate using a simple, blinking LED. It is worth considering the various nuances of programming such a humble device …

LED Addressing
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 (often called a “shadow” copy) 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 a surprisingly rich subject, the details of which are beyond the scope of this article.

LED Indications
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 the user's attention to an error. However, a board might easily die, leaving the LED illuminated, 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 all right, 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 = 500LED_state = 0loop-forever{     sleep(FLASH_DELAY)     set_LED(LED_state)     if LED_state = 0          LED_state = 1     else          LED_state = 0}

Next Page >

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. Oneway to do this is to make the LED flash task a little more sophisticatedso that it performs the functions of a “watchdog”. In this example, thetask 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 thewatchdog task observes that an event flag has not been cleared down, itsounds the alarm – i.e. starts flashing the LED faster. Here is thebasic logic:

LONG = 500SHORT = 50flash_delay = LONGLED_state = 0loop-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 this code could be optimized, but hopefully itillustrates the idea, which is that, broadly, a humble LED can be usedto convey quite a lot of information. Here, just two flash rates areused, but more sophistication is possible.

More Indications
The range of possible indications using a single LED may be expanded in several ways:

  • More than two flash rates could be used. Maybe slow for a “heartbeat”, faster flash for a non-critical problem and very fast for something more serious. It is unlikely that a human observer could usefully differentiate between more than three flash rates.
  • The duty cycle can be varied. Normally the LED would be on and off for equal periods of time (a 50% duty cycle), but a short on time followed by a long off time (and vice versa) is another possibility, thus:
  • The LED may be pulsed several times and then turned off for a period. The number of pulses could signify specific statuses or error conditions. Perhaps the greater the number of flashes the more severe the error. The waveform looks like this:
  • The limit of complexity with flashing a single LED is probably to employ flashes of differing duration – maybe just short and long flashes. This approach can actually reduce documentation, because a well-known, international communications standard can be used: Morse Code. A few letters may be flashed in order to describe a wide range of statuses or error conditions. Here is an example that reports a serious problem:
  • Some LEDs support multiple color displays. These are interfaced with two bits (3 colors) or three bits (7 colors). The difference between a green heartbeat and a fast flashing red LED would be hard for any operator to ignore.
  • If more than a single LED is available, the possibilities are extended further. In an ideal world, if there are multiple LEDs available, they might be labelled (on the board or control panel) with their meaning. However, this takes away some of the possible software flexibility.

Although an LED is no substitute for agraphical display, which can communicate in very user-friendly terms,the possibilities available as a simple diagnostic indicator are quiteextensive, just requiring a little imagination.

Colin Walls has over thirty years experiencein the electronics industry, largely dedicated to embedded software. Afrequent presenter at conferences and seminars and author of numeroustechnical articles and two books on embedded software, Colin is anembedded software technologist with Mentor Embedded (the Mentor GraphicsEmbedded Software Division), and is based in the UK. His regular blogis located at: He may be reached by email at

10 thoughts on “The simplest possible UI

  1. “We've been using morse code on a single LED a long time. The small program code is exactly the same all the years, however using calls to external functions to init and write to the LED, as the hardware may be different.nnFor customer release we use onl

    Log in to Reply
  2. “@Dl2iac – Good to hear that my points are rooted in the real world. I agree that using Morse Code for more text would not be very useful.”

    Log in to Reply
  3. “I have wanted to use Morse code for a long time for things like this. Agree that simpler is better but as long as you are going to use beeps or flashes, might as well use something that actually means something ! And for any kind of debugging without a

    Log in to Reply
  4. “Then we could move it to infra red and maybe call it IRDA or something :-)nnYes, I too have used Morse code from LEDs and beepers.nnThe first time I heard a mobile 'phone go … — … I laughed out loud.”

    Log in to Reply
  5. “@GordonScott: Yes, of course there's nothing new in the world. At least using a visible LED would get the attention of a human operator. It was the Morse “SMS” bleeps that gave me this idea originally.”

    Log in to Reply
  6. “I think possibly both @K7IQ and I were being ironic.nThere are new things in the world, or at least new things for us to learn. I've always been in thrall of the progression of electromagnetic propagation from DC through stripline, slotline and waveguid

    Log in to Reply
  7. “I've just realised that you may have thought I was poking fun. Well, I guess I was a bit, but I meant no offence and I worry I may have caused some. Sorry if I have.nnMeaningful flashes and beeps _are_ a way to impart information and a reminder of that

    Log in to Reply

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.