> > A robust program always resets or clears every register it uses upon
> > initialization, anyway, so it's a moot point.
>
> This has been stated before on Piclist, but I am not so sure it is true.
If
> you cannot trust the chip to initialize itself the way it is supposed to
why
> should trust it to, say, get 4 when adding 2+2.

I don't see the point to resetting or clearing every register either, but I
do initialize all special function registers for modules that I use.  In
other words, my code at 0 assumes the machine is in an unknown state.  The
advantages I see for this are:

1  -  The initialization routines document what hardware is used and how it
is set up.

2  -  Some bits really are undefined, even on a power up reset.  These bits,
plus the ones that I want different from the default would have to be set at
a minimum.  Setting all remaining control bits for the modules used takes
little, if any, additional instructions.

3  -  Microchip has never promised that the wake up state will be the same
on future machines.  Assuming everything wakes up unknown doesn't guarantee
portability to different or future PICs, but it does make it more likely.

4  -  There are various reasons why execution could end up at 0, like power
up, MCLR reset, brown out reset, watchdog reset, accidental GOTO 0, or
deliberate GOTO 0.  These have different guarantees (or not) about the state
of the machine.  I like to have my code do a complete clean "reboot" when
execution gets to 0 regardless of the reason.  I don't use deliberate GOTO 0
much, but one example is when an unexpected interrupt occurs.  That can only
happen do to a firmware bug which somehow enabled an interrupt condition
that it wasn't supposed to.  There is no good answer at this point.
Resetting everything, including the interrupt system, is probably the least
of the evils.

I've also used a deliberate GOTO 0 after configuration changes were made by
the user and stored in EEPROM.  It was simpler to restart the system which
then had to configure to the EEPROM setting anyway than to change
configuration on the fly.


********************************************************************
Olin Lathrop, embedded systems consultant in Littleton Massachusetts
(978) 742-9014, olin@embedinc.com, http://www.embedinc.com

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.