Actually, we got that paranoid.
Learning and taking ideas from the APM open source
autopilots we had two autopilots side by side, both receiving the
same data. Only one
autopilot was actually active while the second sent the same commands
into oblivion.
Again taking from the APM autotune system we backed up the data from
all the sensors
except the GPS data onto to separate chips, The data was kept for 30
seconds and
then rewritten by the next save routine.
In the event of a failure anywhere, the autopilot would switch to the
second autopilot
and a warning would be sent to the GCS saying there was an event. in
the case of a
second event the autopilot went into failsafe. Since our system
always had 3 sets of
back up data all of which were the crafts attitude and not actual
position and it was
being written twice by two different systems a failure on the first
did not mean a failure
on the second.
In the end we ditched the system and went back to just a redundant
autopilot that
can be switched manually or by the first autopilot going it failsafe
mode. This way
the second autopilot determines if it actually needs to be in
failsafe mode or if
there some type of problem with the first autopilot. If it's
determined that something
other than the autopilot, lost heart beat, etc, triggered the
failsafe then the first
autopilot will resume operation.
Robert
At 12:08 PM 1/16/2016, you wrote:
On Fri, Jan 15, 2016 at 11:11:55PM -0600, Robert Watzlavick wrote:
>Good points about the tri-state lines. I was more worried about them
>turning on or off during reset so I picked lines that defaulted to
>tri-state at boot. Most of my digital output lines drive optocouplers
>so they will default to "off". But to maintain state, something
>external to the processor would be required (and without the reset line
>connected). One way to handle keeping state for DIO lines would be to
>use an I/O expander. In the old days, there was the 8255 but here's
>some newer parts:
>http://www.ti.com/lsds/ti/interface/i2c-io-expander-products.page
If you want to be really paranoid, consider the case when you're right
in the middle of writing to such a device when the reset occurs.
(That much paranoia is probably not warranted, unless you're
constantly writing to it, but say it happened.) Then the device will
receive part of a control word (since those chips communicate over a
serial line), a lot of zeros as the CPU reboots (because of the
pulldown resistor you added for just this scenario), then a whole new
control word from the rebooted CPU as it tries to reestablish control.
That's likely to confuse it. Even if you remembered exactly where you
were in the process of writing the control word to the serial line,
and restarted the serial write at exactly that place, the I/O expander
chip might get confused by the intervening zeros.
Now, there likely is an expander chip out there that can be used in an
airtight fashion here. It might, say, take a "serial line valid"
signal line, in addition to data and clock, and reject partial control
words if the valid signal goes low; then you can just re-send anything
you were in the middle of sending when you got reset. But this is not
an easy problem. Parallel programming is hard, and making things
restartable gets into some of the complexity that makes it hard.
Note, for instance, that when Henry wrote about saving state, he
specified using a checksum, and only using the saved state if the
checksum is correct. That'd be to catch not only the cases where a
bug corrupts the saved state, but also the case that the state was in
the middle of being rewritten when a reset occurred. But if you
really needed a piece of state, that might not be enough; you might
have to save two copies of it, each with a checksum, and refresh them
alternately.
That level of paranoia, worrying about rare subcases of rare cases, is
worth it when one is writing an operating system to be used by
millions of people. For amateur rockets, not so much: you're not
going to have literally trillions of tries at hitting the ultra-rare
behavior.
--
Norman Yarvin http://yarchive.net/blog
