Global Sources
EE Times-India
Stay in touch with EE Times India
EE Times-India > Embedded

Designing a humble UI

Posted: 13 Oct 2015     Print Version  Bookmark and Share

Keywords:embedded systems  LED indicator  graphical display  RAM  RTOS 

It is quite 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):

1 • 2 Next Page Last Page

Comment on "Designing a humble UI"
*  You can enter [0] more charecters.
*Verify code:


Visit Asia Webinars to learn about the latest in technology and get practical design tips.


Go to top             Connect on Facebook      Follow us on Twitter      Follow us on Orkut

Back to Top