embedded software boot camp

When you have nothing to say …

Sunday, September 27th, 2009 by

Many embedded devices have a simple text window, capable of displaying a few dozen characters. These are handy for giving the user simple instructions or displaying error messages if the device, or some connected equipment, misbehaves. In some designs there is an obvious text message to display when the device is not being used – maybe a top-level menu. In other cases, particularly if the display is used to output text, but does not allow user input, there may be nothing to say when the device is idle. In this blog I will explore some of the options in that case.

The idle state can lead to some design contradictions. If there is nothing to say, then leaving the text window blank seems like the most appropriate thing to do. Why give the user something to read (like ‘Status: Normal’) which gives them no information. However a blank display can make the device look as if it is off, which may be misleading.

If something has happened, like an alarm condition, then the user needs to read that and the message displayed in the idle state can be replaced – but most of the time there is no such alarm or other activity to display.

On one project we agreed that it would display the time-of-day. This is commonly done on home appliances such as cookers, or a hi-fi. I am not convinced that time-of-day is a good idea unless the time is being used for other parts of the application. Once you display the time, you are obliging the owner to adjust it for daylight savings. You are almost guaranteed that the time will be wrong the first time it is installed (if the delivery has crossed time-zones), so the first thing the owner finds himself doing is hunting through the manual trying to find out how to set the time, when this activity contributes nothing to the utility of the device.

There are cases where displaying the time is advisable, or even necessary. If the device timestamps events or executes actions at predefined times, then if the time were set incorrectly the device would be out of step with the real world. The only way to be sure the time is right it to make sure the user can see the time so they will notice it is wrong. However in devices where the time is not used for any of its functions I would avoid the extra work for designer and user introduced by displaying the time.

So if time-of-day is not the thing to display in the idle state, maybe a company name or slogan works. I am fond of this idea and it encourages brand recognition. But proceed with caution. I worked on one design where we decided to display the company name at the top of the display. It eventually got dropped because of pressure on space in the text window. The company has since changed names twice, and this would have led to awkward software updates, to prevent the product looking immediately out-of-date.

One current design is following the same route, but because there are number of other configurable items, the string displayed in the idle state can be set in configuration. In this particular application it is often re-branded when sold by distributors so it suits them to be able to display their own brand rather than that of the OEM.

Some systems lend themselves to displaying some internal state or measurement. I recently worked on a device connected to a CAN bus (communications network for automotive and industrial applications). Some of the CAN messages would cause conditions that were displayed on this device, but other messages were not. However it was always interesting to know how much activity was on the bus. If the user pressed a button to drive some part of the equipment, there was usually a burst of CAN traffic, and then the bus would revert to zero traffic. On the device with the LCD we displayed a ‘Traffic = N’ line, where N was the number of messages per second on the bus. This meant that even if you were not displaying a specific message about what was going on, you had a rough measurement of whether the bus was active. A bar-graph might have been more pleasing than a number, since this is only meant to be a rough indicator, but in this case the application was just for in-house factory test, and did not merit the extra development work

Other applications may have other interesting numbers. In business information systems they often refer to Key Performance Indicators (KPI) and seeing the value of these numbers at all times helps manager maintain a feel for how well the business is performing, eve if exact thresholds for those values are not established. In the same way an embedded device would display its most important number. A printer could say how many pages it printed in the last hour. A piece of factory test equipment could display the percentage of manufactured items that passed their test. If the percentage is always higher on a Tuesday, even if within acceptable bounds, then maybe there is a flaw in the system that could be tracked down.

Even if the information displayed does not contribute to analysis of the system, it conveys the impression that the device is either busy on the user’s behalf or ready to obey any command received. This will encourage the warm-fuzzy feeling that the device is eager to please.

Leave a Reply