dave vanhorn wrote:
>
> >What HAS HAPPENED in this situation is that the straps cut through the
> >door frame and the side of the airplane (and anybody who's in the way)
> >and then you get pulled right through the aluminum side of the plane.
> >As our instructor said, "At that point, all your problems are over."
> >Usually, the problems are over for everybody on the plane within a
> >minute or two.  We were shown pictures of one plane that managed to land
> >after one of these incidents and you could see right where the guy got
> >pulled through the metal wall of the airplane.  It was a surprisingly
> >small hole.
> >
> >I vote for a loud "BEEP!" when something malfunctions.
>
> The conclusion I've come to here, is that I don't want a microprocessor
> controlling my chute.
> This sounds a whole lot like the oldest bad idea in rocketry, the
> remote-controller launcher.

  Of course you wouldn't, and the example was just used to make a point,
which people were missing.  Looking off your table is fine on a lot of
other processors, but on a PIC it's the kiss of death, because PIC's
execute the table.  Say a sensor gives you a reading of 0-7, that you
use for a table.  Your program's perfect and logic's flawless, but the
sensor fails and you get 255 or any other number other than 0-7.  My
program ands it with 7, and gets a retlw and comes back.  I can later
DECIDE whether things are in error and whether or not to pull the chute
or do nothing or give an error beep.  I have this ability BECAUSE I had
the andlw 7, staid on the table, and didn't do a hard error and have my
program screw up.
  THEY want hard errors, but somehow magically have their program still
be running to see if they had errors and give a beep.  Hard errors
aren't "do nothing" or "do beep" or "come back with wrong value and
check it later to decide do nothing or beep".  Because they didn't range
check, or and to keep it in range, that hard error on table read is
"STOP executing my program.  Go to PCL+wrong value, and start running
whatever code is there."  They can't do nothing, because they don't know
what's happening in the PIC from that point on.  One error value could
send them back to addwf PCL and they're stuck in a tight loop.  Another
random point might even set them through the code, still clearing
watchdog, but not doing anything else.  Or doing lots else, like falling
straight into the open chute routine.  The point wasn't "is there an
error" or "what to do on an error" but "their program CAN'T decide if an
error happend or what to do, because they can't know for sure where the
program flow went after the addwf PCL with unknown/unlimited value."
Addwf PCL with a wrong value is a random goto.  Not a wrong value coming
back from a table, unless you're wasting that other 248 bytes with
retlws..
  They're arguing for "hard errors by not using andlw to stay in range"
but all the things they say their program will then do, "nothing" or
"beep", can only be assumed to happen if you DON'T go off the table and
start running code from a random point.
  Nuff said by me on the subject.  Someone didn't see any reason to
limit the ranges on table look ups.  There are great reasons if you want
your program to still be running and wrong data comes into the table
routines.  There is a flaw in the logic of "my program went off the
table, but it's still gonna run like I want and see an error and do
nothing or beep like I wanted it to."  I can't see how to make it much
clearer, and at least John Payson saw the same problem so I won't be
loosing sleep thinking "maybe they're right and I'm wrong"..  (Ha! Like
that would happen!  I'm never wrong!!! ;)  )
Alan