Stand by or boot up?

Many embedded systems are devices that are used continuously, like, say, a central heating controller. Many others are switched on and off frequently, often only being used for short periods of time. These two modes of usage have a significant impact on the software design. In particular, attention needs to be paid to power management. This article reviews the design parameters and trade-offs in the development of "occasional" use devices.

The user experienceThere are numerous factors that determine the success of a product, but one that is particularly relevant to electronic devices is the user experience – meeting user expectations. Those expectations may include:

The device does what it is supposed to do.

It is easy to use.

It is reliable.

Power consumption is minimized (either to conserve battery life or just help save the planet)

The device should be ready and available for use when it is needed.

The embedded software developer can influence several of these factors, but we will focus on the last one: availability.

Device start-up – requirementsThe start-up time of a device is the delay between deciding to make use of a device and being able to actually do so. There are broadly four categories:

Always on – e.g., an intruder alarm.

Available almost immediately – e.g., a cell phone.

Ready quite quickly – e.g., a digital camera.

A leisurely start – e.g., a hard disk video recorder.

Understanding which category applies to a device is a key starting point in meeting user expectations.

Device start-up – examplesI will draw on my own experience to illustrate device start-up scenarios in real life.

I have a hard disc video recorder – I have no idea how to watch TV any more without one. It takes forever (well, at least a minute) to start up. I assume that it is booting the software off of the hard drive. I do find this quite frustrating. It is interesting that, when the machine wakes up to perform a programmed record, it bursts into life a couple of minutes before the scheduled recording time. Clearly the designers were fully aware of the slow boot limitations.

I am a keen photographer, an interest I shared with my late wife. We would often go on photographic expeditions together – she was usually looking for butterflies. We each had a digital camera – similar specifications, but different makes. She would carry two spare batteries for hers; I did not even own a spare for mine. I was mystified as to why her camera seemed to consume so much power. Eventually I realized that it was simply because she never turned it off. My mode of photography was: spot a subject, turn on the camera, take the picture(s), and turn off the camera again. Her approach was to turn on the camera and keep it switched on until she had finished looking for subjects. The reason she did this was simple: her subjects might appear suddenly and she needed to be ready to shoot instantly. Her camera would take 30 seconds or so to “warm up” (boot), by which time the butterfly might well have flown away. My camera would be ready in 5 seconds or so.

These examples illustrate how designers respond to user expectations. The video recorder may start up slowly, but that is acceptable (notwithstanding my impatience) and the strategy to avoid missed or late recordings is sensible. In the case of the cameras, I would suggest that my camera was well designed, whereas my wife’s fell short of expectations.

Device start-up – design optionsThe embedded software design decisions relating to start-up are complex. Reviewing the requirements above, (1) is easy enough and (4) is accommodated by a simple boot sequence. (2) and (3) are more subtle – for these, there are broadly two options:

Minimize boot time. This can be done by optimizing the start-up code, but there are limitations with what may be achieved with Linux, for example. A light-weight operating system, such as a real time operating system (RTOS) is likely to offer the fastest boot time by running either directly from ROM or being copied rapidly from flash to RAM.

Utilize a CPU’s low power modes, such as Sleep and Hibernate.

Many microprocessors, cores, and microcontrollers offer a variety of low power modes. These vary from one device to another and there is little agreement on nomenclature. However, two modes of behavior are clearly defined: sleep and hibernate; these closely resemble the power saving modes of a Windows PC.

In sleep mode, the CPU and all peripheral devices are shut down, but power is retained to memory, so that all code and data are maintained intact. This mode has the benefit of being quite fast to enter and exit, however there is a continued drain on batteries to maintain the memory contents. Smart phones are the type of device where sleep mode may be useful, as almost “instant on” is possible.

In hibernate mode, all the memory contents are written out to non-volatile storage (typically flash memory) and everything is powered down. This mode has the benefit of almost zero power consumption, but there is a delay on entry and exit, when extra code is run to do the copy. Digital cameras are possible candidates for the use of this mode.

Regression therapy?It's clear that the start-up behavior of a device can be pivotal to a satisfactory user experience. Designers of embedded devices should take care to select the best strategy for each device.

I find it amusing that we seem to have regressed over the years. The first computers I used had magnetic core memory. You could switch off the machine at the end of the day and turn it on the following morning and carry on immediately from where you left off. The memory would retain the data and consume no power at all in doing so. Of course, that was at a time when a TV really did need to "warm up"; the vacuum tubes and CRT all needed to reach operating temperature before anything could happen. They were simpler times when we were in less of a hurry…

Colin Walls has over thirty 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, Colin is an embedded software technologist with Mentor Embedded (the Mentor Graphics Embedded Software Division), and is based in the UK. His regular blog is located at Mentor Embedded. He may be reached by email.