SMALL FORM FACTOR FORUM
Sleep Can be Deadly
Page 1 of 1
Back in the old days, when people used the word “control” after embedded, there weren’t a lot of options for powering an embedded system. Power was distributed to all system components, including sensors, motors and electronics at appropriate voltages, and with appropriate sequencing, when the system was powered up. All elements stayed powered up until power was removed. Many systems ran 24/7 for years. These systems ran the gamut from industrial controllers running a printing plant, to patient monitoring systems, or weapons targeting systems. Power consumption issues were pretty much relegated to the few battery-powered applications.
In this last decade, we’ve seen growth of embedded (dedicated) applications that only need power when interacting with an operator. The check-in kiosk at the airport, or cash register need not be powered 24/7. In response to the green initiative there is more focus than ever on saving power. There are two elements to saving power in an embedded system. First is the use of low-power electronics. While RISC CPUs have been offering low power for years, Intel architecture (x86) processors and chipsets have finally got some skin in the game with the new Atom family of processors. Nano and Geode processors are designed into some low-power applications as well.
The second component of saving power is to put the system into some form of hibernation or sleep mode when in an idle state. Because of the focus on battery life in the laptop markets, x86 systems have a highly developed set of capabilities for sleep modes. However, until recently, most embedded implementations of x86 architecture failed to provide all the hardware and software support necessary to engage a full range of sleep modes. This is starting to change.
Hibernation / sleep technology is driven by the ACPI Specification. While ACPI contains substantial complexity with regard to how hardware and software should respond in various sleep modes, the overriding architecture is simple. There are five system-level states, ranging from on (full power) to off (no power). Well, not quite. Off doesn’t really mean off. This is the “soft” off you get when you shut down Windows. The power supply is still alive—in a very low-power mode—providing trickle standby power for the chipset to sense wake-up events. Waking up from soft off requires a reboot—not a particularly speedy endeavor.
The three intermediate states trade off power savings against the time it takes for a system to wake up. In general, the more power you save, the longer it takes to wake up. Simple power saving actions such as turning off a display, or stopping disc rotation, save a small amount of power but wake-up is almost instantaneous. Saving the state of a system to disk requires a much longer time to wake up (the famous Resuming Windows progress bar on your laptop), but saves much more power. An interim step, saving the state of a system to RAM, saves somewhat less power (since memory must remain powered), but restarts much more quickly. Unfortunately, this step requires conscious steps early in the design process with regard to the memory power plane, and has frequently been omitted from many embedded SBCs. If this approach is of value for your application, seek CPU boards offering ACPI State S3 (Suspend-to-RAM) support.
An even more gnarly problem revolves around the set of actions that can wake a system from sleep. A keyboard or touch screen press or mouse movement are common and frequently supported wake-up events. Wake on LAN, however, in which a system wakes to respond to a message over Ethernet is much spottier. It requires support in the network controller hardware along with support in the Ethernet driver. And if you want to wake in response to activity on a USB device, we wish you the best of luck. You’ll need it.
Green is good. More importantly, green sells. Embedded designers everywhere are finding reduced power consumption as an important feature of new systems. Go for the new, lower-power processors and chipsets. But before you start factoring hibernation or sleep modes into your application, be very certain that your application can sustain long response times to wake-up events (i.e., probably not for almost any real-time control system), and that your project can accept a longer design cycle, higher product costs and potentially order of magnitude reduction in the set of off-the-shelf SBCs and I/O cards you may choose from. Sleep if you must, but don’t let Prince Charming get too far way. You may need him.