Searching \ for 'Two topics - State Machines & Reliability' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/devices.htm?key=pic
Search entire site for: 'Two topics - State Machines & Reliability'.

Truncated match.
PICList Thread
'Two topics - State Machines & Reliability'
1999\10\25@201036 by Richard Prosser

flavicon
face
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 removed}

1999\10\25@213921 by Mark Willis

flavicon
face
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:
{Quote hidden}

> > {Original Message removed}

1999\10\25@221317 by Dennis Plunkett

flavicon
face
At 18:37 25/10/99 -0700, you wrote:
{Quote hidden}

Grey coding of hardware is not a simple task.
The idea of monitoring two points in RAM for a "Kill roy" is not quite such
a good idea. If the RAM is corrupted in eitehr these two locations, there
is no guarentee implied or otherwise that the rest of the RAM is either OK
or BAD.

I can remember doing such a search through code like this for a system that
reset itself once every few months or so, just to find out that the thig
was over writting (Software bug) Now this is normaly NO CAUSE for a reset,
WARM boot or process restart.

In such the system at a higher level needs to analyse the current data and
past activites and then pose the question of what will this make me do in
future activites and does this meet critera esstntialy the same as past
paths have lead to. After this is done the L.E.D may be turned on <Grin>

What I am trying to say is that simplistic approaches offer simplistic
results, and the software engineer must assume a cirtain state of operation
at all times.

The detection of failure should be the detection of erratic behaviour, not
Oh gee, I have a bad value in RAM=> I have to reset as the value may have
been written wrong, or the location may be faulty not the system.

After all how many of you do defensive coding? No realy how many of you do
7-3, do you check to see that the result is less than 5 and greater than or
equal to 0?

Dennis





{Quote hidden}

possibility
{Quote hidden}

>> > {Original Message removed}

More... (looser matching)
- Last day of these posts
- In 1999 , 2000 only
- Today
- New search...