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 by Jim Granville●April 8, 20062006-04-08
johnwang1wang@yahoo.com wrote:
> 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.
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 by martin griffith●April 8, 20062006-04-08
On 7 Apr 2006 23:01:35 -0700, in comp.arch.embedded
johnwang1wang@yahoo.com wrote:
>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
http://www.semiconductors.philips.com/acrobat/applicationnotes/AN468_1.pdf
martin
Reply by Hans-Bernhard Broeker●April 8, 20062006-04-08
johnwang1wang@yahoo.com wrote:
> 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).
That's a dubious plan.
> A basic idea is to keep a snapshot of the state machine before it is
> interrupted.
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 by Rene Tschaggelar●April 8, 20062006-04-08
johnwang1wang@yahoo.com wrote:
> 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.
> johnwang1wang@yahoo.com wrote:
>
>> 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.
>
> This is ok. Just store the state of the state machine.
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
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
More details at: <http://cfaj.freeshell.org/google/>
Also see <http://www.safalra.com/special/googlegroupsreply/>
Reply by Tim Wescott●April 8, 20062006-04-08
johnwang1wang@yahoo.com wrote:
> 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
>
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
http://www.wescottdesign.com
Posting from Google? See http://cfaj.freeshell.org/google/
Reply by Rene Tschaggelar●April 9, 20062006-04-09
CBFalconer wrote:
> Rene Tschaggelar wrote:
>
>>johnwang1wang@yahoo.com wrote:
>>
>>
>>>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.
>>
>>This is ok. Just store the state of the state machine.
>
>
> 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.
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 by CBFalconer●April 9, 20062006-04-09
Rene Tschaggelar wrote:
> CBFalconer wrote:
>> Rene Tschaggelar wrote:
>>> johnwang1wang@yahoo.com wrote:
>>>
>>>> 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.
>>>
>>> This is ok. Just store the state of the state machine.
>>
>> 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.
>
> 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.
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
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
More details at: <http://cfaj.freeshell.org/google/>
Also see <http://www.safalra.com/special/googlegroupsreply/>
Reply by Steve at fivetrees●April 9, 20062006-04-09
<johnwang1wang@yahoo.com> wrote in message
news:1144476095.695349.223130@v46g2000cwv.googlegroups.com...
>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.
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
http://www.fivetrees.com
Signal Processing Engineer Seeking a DSP Engineer to tackle complex technical challenges. Requires expertise in DSP algorithms, EW, anti-jam, and datalink vulnerability. Qualifications: Bachelor's degree, Secret Clearance, and proficiency in waveform modulation, LPD waveforms, signal detection, MATLAB, algorithm development, RF, data links, and EW systems. The position is on-site in Huntsville, AL and can support candidates at 3+ or 10+ years of experience.