Re: "Non-volatile" OS ?
- From: "drn@xxxxxxxxxx" <drn@xxxxxxxxxx>
- Date: 26 Aug 2005 14:22:20 -0700
Hi Jim ! Notes inline below...
Jim Granville wrote:
> drn@xxxxxxxxxx wrote:
> > 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... ?
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).
> 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.
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).
> 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.
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.
> 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.
>
> -jg
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).
Hope I'm explaining clearly...
Thanks for the thoughts !
Best Regards, Dave
.
- References:
- "Non-volatile" OS ?
- From: drn@xxxxxxxxxx
- Re: "Non-volatile" OS ?
- From: Lanarcam
- Re: "Non-volatile" OS ?
- From: drn@xxxxxxxxxx
- Re: "Non-volatile" OS ?
- From: Jim Granville
- "Non-volatile" OS ?
- Prev by Date: Re: Slow data rate FT245BM to PC
- Next by Date: Re: Q: Driving a lot of leds
- Previous by thread: Re: "Non-volatile" OS ?
- Next by thread: Re: "Non-volatile" OS ?
- Index(es):
Relevant Pages
|
