Stand-by or boot-up
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 realised 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.
Clearly 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 …
Comments
Leave a Reply
You must be logged in to post a comment.
How about MRAM or FRAM do you see that as an alternative to boot memory for fast booting?
Eduardo V:
Yes, those technologies look like possibilities to restore the kind of functionality benefits that core memory had.
The typical (I guess) design of an embedded system has a serial flash to copy the boot image into the system RAM, and an EEPROM to keep various settings, including current state of the embedded application.
There is no reason for slow boot of an application, if a boot monitor, an RTOS, and a firmware use this hardware smartly.
The really significant delays (2-3 seconds) can be caused only by testing the big system memory and mechanical operations like moving the camera lenses into the work position.
For my oppinion, the boot, which takes more than a few seconds, is the symptom of bad design: inappropriate OS, too slow CPU, etc.
The typical (I guess) design of an embedded system has a serial flash to copy the boot image into the system RAM, and an EEPROM to keep various settings, including current state of the embedded application.
There is no reason for slow boot of an application, if a boot monitor, an RTOS, and a firmware use this hardware smartly.
The really significant delays (2-3 seconds) can be caused only by testing the big system memory and mechanical operation like moving the camera lenses into the work position.
For my oppinion, the boot, which takes more than a few seconds, is the symptom of bad design: inappropriate OS, too slow CPU, etc.
The typical (I guess) design of an embedded system has a serial flash to copy the boot image into the system RAM, and an EEPROM to keep various settings, including current state of the embedded application.
There is no reason for slow boot of an application, if a boot monitor, an RTOS, and a firmware use this hardware smartly.
The really significant delays (2-3 seconds) can be caused only by testing the big system memory and mechanical operation like moving the camera lenses into the work position.
For my opinion, the boot, which takes more than a few seconds, is the symptom of bad design: inappropriate OS, too slow CPU, etc.