piclist 1999\10\25\221317a >
Thread: Two topics - State Machines & Reliability
face BY : Dennis Plunkett email (remove spam text)

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?


{Quote hidden}

{Quote hidden}

>> > {Original Message removed}

See also: www.piclist.com/techref/microchip/devices.htm?key=pic
Reply You must be a member of the piclist mailing list (not only a www.piclist.com member) to post to the piclist. This form requires JavaScript and a browser/email client that can handle form mailto: posts.
Subject (change) Two topics - State Machines & Reliability

month overview.

new search...