You want to detect "invalid" states in embedded systems, and re-boot (so
to speak), also use the watchdog for if hardware latchup happens, and in
addition put some "fence" values out in RAM (i.e. write 0xA5 to one
location, 0x5A to another, then come back & test these values - if one
changes, reboot.)  As the state register's in PIC Ram on PICs, you
cannot do much in the way of "refreshing" it (unless you copy OldState =
CurrentState = {NextStateNumber} at each time you set the upcoming state
for the next "pass", then compare them at the top of the loop, which
would let you know it was time to re-boot!) - though it will change
fairly regularly, usualy, this would catch situations like waiting for
successive keypresses when you had jumped invalidly from some other
state, due to a cosmic ray hit, etc.

SCR Latchup isn't handled by the WDT, of course, so you try to prevent
that in critical circuits! <G>

And, for the finnicky: yes, my state machine that I tacked together &
showed was a hybrid, but such hybrids are eminently PRACTICAL, IMO, so
I'm not apologizing <G>

  Mark

Richard Prosser wrote:
>
> This now has triggered a long-time query re these devices.
> As I understand it the basis of the state machine is a register containing
> data relating to the "state" of the device or process. This is updated by
> inputs and used to define the outputs.
>
> Now, the question is how often do I need to refresh it?
>
> In the ideal situation I would monitor the inputs and only change the state
> register when required but in the real world there is always the possibility
> of data corruption whether from cosmic rays, static discharge etc.
>
> So, the question is, how reliable is the ram in a PIC (or Atemel, Scenix,
> etc. etc.)?
> Once I've recognised an input condition and acted on it - do I need to
> continually refresh the internal registers or can I leave them alone until
> something changes. I've always been a bit on the conservative side -
> checking & updating as often as convienent but at times this does limit
> other options.
>
> If the registers should be refreshed at regular intervals - then what about
> the program - surely it is also susceptable to the same sort of thing -
> although possibly to a lesser degree. If the data is totally secure once
> written, then this is brilliant but somehow I don't really believe it!
>
> Does anyone have any figures and experiences as to this question? I realise
> that the  operating environment will be a major factor but even in a benign
> environment there may be some corruption mechanisms.
>
> Thanks,
> Richard P
>
> > -----Original Message-----
> > From: Dan Larson [mailto:dlarson@CITILINK.COM]
> > Sent: Tuesday, October 26, 1999 10:28 AM
> > To: PICLIST@MITVMA.MIT.EDU
> > Subject: Re: Two topics - State Machines
> >
> >
> > >Software types are likely to
> > >cheat and cause their code to break by doing things only
> > when a state is
> > >entered or exitted.
> >
> > AS as "software type", I usually create three states in such
> > cases: One for the
> > "entry" state, one for "polling, looping, etc", and one for
> > the "exit" state.
> >
> > I don't know if *this* is cheating or not, but sometimes the
> > next state to
> > be transitioned to from the current state depends on the
> > previous state.
> > Sort of like subroutine calls within a state machine.  I only
> > use such a
> > technique in order to avoid duplication of state.  Avoiding
> > duplication
> > also avoids bugs cause by changes made to one of the any identically
> > functioning state but not the rest.
> >
> > I once wrote a state machine for a "game show" program which had
> > over 150 states!  Mind blowingly complex, but it would have
> > been almost
> > impossible with traditional logic structures (if then else).
> >
> > State machines rule!
> >
> > Dan
> >
> > >
> > >BillW
> > >
> >