[AR] Re: Flight Controller Features
- From: Norman Yarvin <yarvin@xxxxxxxxxxxx>
- To: arocket@xxxxxxxxxxxxx
- Date: Fri, 15 Jan 2016 18:45:39 -0500
On Tue, Jan 12, 2016 at 05:35:59PM -0500, Henry Spencer wrote:
The idea that those computers could be rebooted easily because, well,
after all, they didn't have to remember anything or maintain continuity
for anything important, is sheer ignorance. No, things were not that easy
for software in the old days.
Well, they did have the advantage of designing the computer from the
ground up so that it could be rebooted without losing data (if you can
call having to do that much work an "advantage"). If you're using an
existing hardware and software infrastructure, that'll usually include
some sort of bootloader that does lord-knows-what to memory while it's
booting up, under the assumption that nobody will care.
Even if you take ownership of the bootloader or supplant it entirely,
the chip itself will have its own boot procedure; for instance, an AVR
datasheet states that "port pins are tri-stated when reset condition
becomes active". A line connected to an output pin that's not being
driven either way (for those unfamiliar with the jargon, that's what
"tri-stating" means here) can easily pick up noise and deliver
spurious signals. And you can't just instantly fix this in your reset
code: there's a built-in delay of 4 milliseconds after reset, during
which the processor twiddles its thumbs waiting for power to become
stable (even if the reset originated in software and power stability
isn't really an issue). Likely this can get fixed with a pull-up or
pull-down resistor on that line, which likely would have to be there
anyway for the first boot. But when the processor is in the middle of
doing something, sometimes it is important that an output retain its
state, whatever that state might be. In that case a pull-up or
pull-down resistor won't do; one would need a more complicated
circuit.
And the AVR is a small, simple processor; with more complicated and
powerful processors, there tends to be more involved in the boot
process. Designing the software so that important memory state
survives reboots means doing things differently than the vast majority
of developers do them. Being different always means extra work, and
often means getting into areas of functionality that aren't well
documented and may be unreliable. (Will it refresh DRAM frequently
enough, all through the reset process? Even if that's in the spec,
can you rely on it when hardly anyone else even tries to rely on it?)
Of course surviving reboots is still an inherently attractive idea.
Even with a reboot process that is completely opaque and stomps all
over memory, one could add an extra chip to hold state that needs to
survive reboots. But whether it's worth it depends on how probable
reboots are. If you decided that the Apollo program really had it
right and that you were going to design your own CPU and send it off
to MOSIS to be fabricated in silicon, you'd be able to design the
whole thing so as to be able to reboot instantly without stomping on
any memory or disturbing important outputs. But you'd probably make
enough CPU design errors that you'd really need that feature! More to
the point, the odds of needing a reboot are quite different for a
satellite that has to live in orbit for years, exposed to radiation,
than they are for a launcher which (echoing Ben here) just has to run
for seven minutes.
--
Norman Yarvin
http://yarchive.net/blog
Other related posts:
