A state machine question

I am implementing a state machine which has the following requirement: If the state machine is interrupted by power off, the state machine shall resume from where it was interrupted after the program is restarted ( power on in this case).

A basic idea is to keep a snapshot of the state machine before it is interrupted.

I am seeking a better solution. please advice me.

Thank you very much.

John

Reply to
johnwang1wang
Loading thread data ...

You are going to have to store the last-state, somehow, so I'm not sure what 'better solution' you are after. Plus power recover might need some conditioning, to avoid power-related changes triggering an unwanted early next-state.

-jg

Reply to
Jim Granville

formatting link

martin

Reply to
martin griffith

That's a dubious plan.

You quite definitely don't need a snapshot of "the state machine". If you have more to store than the current state of the machine (i.e. in typically a single number), you didn't have a state machine to begin with.

--
Hans-Bernhard Broeker (broeker@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.
Reply to
Hans-Bernhard Broeker

This is ok. Just store the state of the state machine.

Rene

--
Ing.Buero R.Tschaggelar - http://www.ibrtses.com
& commercial newsgroups - http://www.talkto.net
Reply to
Rene Tschaggelar

Yeah, but where? You also have to consider the case of power interruptions while the state machine is changing state. This pretty well requires that it be driven from an interrupt, be short, and disable the power fail interrupt while executing. In addition the power has to hold up for at least the execution period after the power fail interrupt is generated.

Here a worm, there a worm.

--
"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 
 Click to see the full signature
Reply to
CBFalconer

As CBFalconer pointed out you have to make this immune from power down.

I can think of three ways to do this, with varying levels of function, cost and complexity. All require battery-backed or flash memory, which I'm just going to refer to as 'memory'.

First and easiest is to establish two identical areas in memory where you will keep state data. Make sure there's a time stamp. Protect them with CRC checksums, and ping-pong between them. Each time you save state write to the whole area followed by a checksum. On power up look for the most recent state with a good checksum -- that's your baby.

This method has the disadvantage that important things may happen but not get saved.

Second is to make sure that your power supply hardware will keep the computer up for a while, and will tell you went it can't. Keep one area in memory to save state, with a checksum, and don't write to it if your power supply can't keep things going.

Third is to equip your power supply with a means to interrupt your processor when power goes down, and gives you a guaranteed-good time to save your processor state. Take your _whole_ processor state, along with all of RAM, and save it away, along with a tag to identify the fact that the processor state is good. On power up, check the tag and if it's good then restore RAM and the _whole_ processor state and do a return-from-interrupt. Because you saved the _whole_ processor state it won't know the difference between what just happened and a glitch on the interrupt line.

This is not, by the way, trivial. I know people who've done it and it's quite hard to do right. Furthermore, if you have a customer asking for it they'll get justifiably upset if it doesn't work.

--
Tim Wescott
Wescott Design Services
 Click to see the full signature
Reply to
Tim Wescott

Naa, this is unwieldy. I tend to store states in the embedded EEPROM if the state doesn't change too often. Else if the state changes more often, I'd take an RTC with Li battery and some bytes of RAM in it.

Rene

Reply to
Rene Tschaggelar

If you don't pay attention to those unwieldy details your stored state is worth about as much as a Microsoft OS.

--
"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 
 Click to see the full signature
Reply to
CBFalconer

I'd be cautious. The state of the hardware, and the environment, and indeed the time, are not the same after a powerdown as before.

I'd recommend defining which bits of the *context* you need to maintain through powerdown, and doing a full restart - and then restoring the context intelligently. Simply storing one state (or the entire memory image, as another has suggested) is unlikely to be satisfactory. You may well have to reinitialise peripherals, and recover from interrupted processes and comms.

Unless you have a powerfail interrupt, and enough holdup time to close down cleanly, you will also need to ensure that the "context" is valid at all times.

Steve

formatting link

Reply to
Steve at fivetrees

In core memory systems, it was easy to save the internal state and resume execution at the next instruction, when the power was restored. While the internal state was nicely preserved, the "external" real word situation might no longer match the stored internal state.

Assuming input A changes state before input B you should end in one state, but if B changes before A, you should end in an other state in the state diagram. If both A and B changes state during the state machine power failure and both are ON when the power is restored, did A change before B or vice versa and what should the final state be ?

Thus, it is not enough to store the internal state, but you should also check that similar situations do not exist in the state diagram or have a special transition if both A and B becomes simultaneously ON (indicating a restoration of state machine power).

In more complex systems it would be highly dangerous to resume operation with the settings used before the power failure, without checking the current state of the external world after power restoration.

Paul

Reply to
Paul Keinanen

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.