Open side-bar Menu
 Embedded Software
Colin Walls
Colin Walls
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 … More »

Stand-by or boot-up

July 22nd, 2014 by Colin Walls

Like most people nowadays, I have a selection of electronic devices that have become part of the fabric of my life. I have certain expectations: I want a device to do what it is supposed to do. I want it to be easy to use. I am after reliability. I want it to consume the minimum amount of power – either to conserve battery life or to simply be environmentally friendly. Lastly, I want the device to be available and ready to use when I want it.

As such devices are generally embedded systems, my requirements are generally met [or not!] by the software. It is the last of my criteria, and the influence that software might have on it, that I find particularly interesting…

There are a selection of factors that can affect the availability and readiness of a device. Obviously, it has to be affordable and compatible with the rest of my world. For a portable device, its power consumption affects availability, as a dead battery can be something of a show stopper. But a really key parameter is start up time. How fast a device starts up can have a significant effect upon its usability.

For example, I am a keen photographer, an interest which I shared with my late wife. We would often go on photographic expeditions together – she was typically looking for butterflies. We each had a digital camera – similar specifications, but different makes. She would typically carry two spare batteries for hers; I did not even own a spare for mine. I was mystified for ages as to why her camera seemed to consume so much power. Eventually I realized that it was simply because she would never turn it off. My mode of photography was: spot a subject; turn on the camera; take the picture(s); 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 typically appear very 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.

nucleus-power-managementClearly the design of the software and what kind of operating system [if any] is in use have a fundamental effect upon the start up time of a device. If the OS can initialize very rapidly, because the image is simply loaded into memory [or is there anyway], it will obviously make a device more immediately usable than an OS that needs to go through a long boot sequence.

Another example: I have a hard disc video recorder – I have no idea how to watch TV any more without one. It takes for ever [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.

One way to provide a fast start up is to avoid booting at all – just have everything in memory ready to go. This is how suspend works on a PC. The downside is that, with current memory technology, significant power is required to sustain the data integrity.

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 …

Related posts:

Leave a Reply

Your email address will not be published. Required fields are marked *


DownStream: Solutions for Post Processing PCB Designs
TrueCircuits: IoTPLL

Internet Business Systems © 2018 Internet Business Systems, Inc.
25 North 14th Steet, Suite 710, San Jose, CA 95112
+1 (408) 882-6554 — Contact Us, or visit our other sites:
TechJobsCafe - Technical Jobs and Resumes EDACafe - Electronic Design Automation GISCafe - Geographical Information Services  MCADCafe - Mechanical Design and Engineering ShareCG - Share Computer Graphic (CG) Animation, 3D Art and 3D Models
  Privacy PolicyAdvertise