Hi All - I'm looking for a "non-volatile" OS.
Perhaps there's a more common name ?
Anyway, here's what I'm looking for, to support
an embedded system that operates in a "flakey"
power environment where power has a nasty
tendancy to kinda disappear for a while...

- On power-down, OS supports QUICK save of
state of all processes, and
- On power-up, OS restores in-progress processing
and messages tasks that "there was a power
event, reinitialize as required".

What I did in past was use battery-backed
static RAM, and write my own OS. That's a
bit dated in approach, though lots of units
in service !

This is very interesting topic. until now, I didn't see any REAL OS
which can support this feature. Though Non-volatile memory hasn't
developed so mature as well. It is potentially big change for OS. I
would like to know more people's points regarding this.

OK lets see what are options are...an OS typically resides in a non-volatile
form of memory when it is powered down like a hard disk or Flash in a PDA.
Upon power up, portions of the OS are moved to a form of memory with quick
read/write times, typically RAM. The problem is that RAM is volatile.

If you replaced the RAM with Flash you would run into problems. However, the
read/write speed of Flash isn't one of them. In theory, running multiple
Flash chips in parallel could achieve read/write speeds equal to or better
than RAM. The real problem is that Flash has a limited amount of read/write
cycles. Typically "up to 100000". Exceed this limit and sectors would drop
and the computer would soon fail.

Ramtron has non-volatile memory with access speeds like RAM called FRAM
(Ferroelectric non-volatile RAM). It has an unlimited amount of read/write
cycles. However, the chips MByte capacities are currently small and real
haven't been designed with this application in mind. It probably would work,
but I don't know what the end cost to a consumer would be.

My personal belief is that certain kinds of RAM don't require much current
to back-up, so get the UPS guys and the PC guys to agree on a standard that
supplies DC power from the UPS to the PC in order to back up the RAM. Then
your OS is non-volatile and you don't have to wait for that ever growing
length of time it takes for a PC to boot. Laptops already have batteries to
back-up the RAM and could be set as a user option at the cost of killing
your battery if left unplugged for a while.

FRAM is still very expensive. Static RAM, while easy to back up with
low power consumption, is much more expensive than dynamic RAM.
However, the OS still needs to be able to tolerate turning off and on
(reinitialization of low-levels without disruption of any processing in
progress during suspend-resume). Flash lifetime wouldn't be a problem
with the number of cycles my particular application requires, however
the best would be a serial-flash that has onboard wear-leveling and
error-correction.

In the days of core memory, such features were common. When the AC was
lost, the power fail interrupt was activated, which saved the CPU
registers as well as the peripheral register contents into core memory
and then halted the processor.

Upon power restoration, the power fail interrupt was executed again,
restoring the registers just as returning from the interrupt. Some
operations might need retrying (such as disk access), but that would
be the case even if the processor was halted and then resumed or
single stepped..

Even with dynamic-RAMs, the memory could be maintained with battery
power, that powered the memory chips and the refresh circuit to
refresh the chips every 2 ms, which did not consume a lot of power.

For the O.P's question I would suggest looking into a system that
doesn't store everything back to non-volatile memory, but simply
goes into a super low power hibernate mode, preserving RAM memory
contents and CPU state at some small current usage.

A bit of power fail detect, power switching/charging circuitry, a
decent battery should get you through a short interruption without
trying to save all that state. Hopefully the OS could be
minimally modified to deal with this.

A lot of this kind of circuitry has been put out for the laptop
and low power embedded market (think PDA, cell phone processors
and battery circuits) and can be adapted to embedded uses.

You have essentially described a small PC --- so why not use one?
Modern ones and their OSes all support some "hibernation" (also known
as sleep-to-disk) mode. That's doing exactly what you're asking for.

--
Hans-Bernhard Broeker ( snipped-for-privacy@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.

That's a good question. I need suspend and resume times in large
numbers of milliseconds, whereas (for example) my XP machine takes many
many seconds to suspend and to resume. Any suggestions as to OS that
can do this in sub-second time ?
Thanks !

Whats a good question? You must include context in your articles.
There is no guarantee that any previous article is available to the
reader at any time. Instructions for doing this on even the foul
google usenet interface are in my sig, below.

--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on

A Pocket PC kind of does this (Windows CE). That is, when you turn your PDA
off the OS and apps are still intact when you turn it back on. All a PDA
doing is battery backing it's RAM. The OS will last weeks on a charge and a
lot more with a slightly bigger battery.

The "state of all processes" includes the state of all RAM used by the
process plus any OS resources used by the process (things like file
handles, or the state of an OS call in progress at shutdown, all need
to remain valid)....

File handles ? - you mean this has to survive a power fail during a
file write - to what HDD/FlashDrive/USB Drive... ?

First, you need a Board/BIOS that can start quickly, and the
more complex that is, the less likely you are to control that.
[Your mention of USB and File handles makes this sound a little
scary...]

Next, you need to define the data-sets of all processes,
ie Sizes/Content/Integrity checks, and the risk/consequence of
any errors.

If you have control on the HW, then you should look to use
FRAM or MRAM (or BB SRAM), and map all those data-sets into
the NV space.

On startup, your SW needs to check validity of the datasets,
and decide if a full-init is needed, or if a quick-go is OK.
The OS cannot do this for you. It has no idea of the HW
and real world changes that may, or mat not, affect your code.

An alternative approach, is to use Microcontrollers for the
Real-World IO stuff, and they CAN re-start very quickly indeed,
then run safely whilst they wait for an update from the slower OS.
There are plenty of uC now, with large resource sets :
64KB RAM/256K Flash and USB/Ethernet/CAN etc

Maxim have an interesting MAX3420 SPI-USB device, that looks
to be able to add 12Mbd USB to almost any small uC.
SPI to the uC makes sense here; much faster than the RS232-USB devices,
and fewer pins than the FIFO USB devices.

Sure. Assume there's an embedded flash file system, and another
file system plugged in on a USB key. For the first, the supercap
is sized to guarantee completion of an IO operation and leaving
the device in a sane state. For the second, it might fail, and
return an IO error to the app (just like if the user unplugs
the thing while its in use).

Right, this is what I did in the OS I wrote. If there wasn't
a smooth shutdown (integrity check failed), it did a cold-start.
Of course that never happens (it really does not happen).

The OS can ensure that a sane shutdown was performed, such that
it is safe to restart all processes, then perform any required
low-level HW reinit, then restart all processes and message them
that a restart happened.

The low-level stuff is easy; what I'm looking for is safe
save/restart of the larger high-level stuff (whose context is
large and thus obnoxious to serialize and restart from at the
app level).

Which seems to be what the OP wants. The difficulty is in defining
"context", and validating that context at power-up.

With a dedicated product, it's easy enough - decide which parameters/states
are expensive to restart, and store these at power-down in non-vol memory.
Do some sanity-checks at power-up, and you're done.

With a general-purpose RTOS, if you're trying to keep the RTOS task states
during power-down, it's a different ballgame, and I'm not convinced it's
either desirable or necessary as a general OS feature - the *actual*
physical context may be entirely different when the system wakes up,
seconds, hours, years later. Hardware will need re-initing anyway. Seems to
me better to store "hints" as to initial context, than to depend on an OS to
(effectively) pick up after an indefinite pause in a now-different hardware
environment with no insight into what's changed.

Many PDP-11 and VAX processors had the option of supplying the DRAM
from a battery and since the operating systems dated from the core
memory days, they could handle the power failures quite nicely as long
as the battery power lasted.

It depends how the real time clock behaves. As long as the I/O
requests timeout immediately after restoration of power, the operation
can be retried immediately.

For control loops, it might be a good idea e.g. to reinitialize the
PID-controllers, but you would need this feature anyway to handle an
intermittent sensor failure. Thus, it would be enough for the sensor
driver to report "sensor failure" for a few cycles after power-up,
which would also reinitialize the PID controller.

Thanks all for the comments ! However, I don't think
anyone has suggested a real-life-available COTS
OS that has the required features, other than possibly
Windows CE (which probably doesn't meet the
toolchain requirements).